[Nmc-wg] Documents review (Michael)

[Michael Bischoff]

On 01/28/2010 02:52 PM, Jason Zurawski wrote:
>> ...
>
>
> I have added this comment for you.  Subscription may not be a regular 
> message exchange right now but it is something that we must document 
> as it does have implications for future services.  For example the IDC 
> protocols (dynamic circuit related - something that Internet2's ION 
> and AutoBAHN implement) have a subscription message that perfSONAR-PS 
> services will eventually utilize and implement to gain information 
> about aspects of the dynamic circuit networks.
>
I'm not familiar with ION and AutoBAHN, I'll try to read up on it. The 
subscription I was talking about is the one featured here:
http://svn.geant.net/GEANT/SA2/ps-java-services/trunk/ps-mdm-flowsub-mp/doc/examples/
I wasn't involved when it was designed (I do love to improve it(To allow 
different types of tunnels for example))
> I have added your name to the TODO list to fill out this section. 
> Please research these topics and document the most important areas we 
> should consider.  Security is very broad and not the focus of this 
> work, but we can spend some space describing the risks and steps we 
> can take to mitigate.

>> - On what standards do we build? NM, NML, others? 'perfsonar URNs'? We
>> probably expect some pre-existing knowledge from our readers.
>
>
> Pre-existing knowledge will come from references because we (and other 
> groups) should not be re-inventing the wheel.  We will not be 
> re-defining concepts like URNs (there are several GFDs that describe 
> this as well as work that NML will publish 'real soon now') or 
> topology descriptions (also something NML will be providing).
What I meant was that we don't actually mention in the document that we 
aren't reinventing the wheel and that we do depend on other specs. 
Depending on what you consider references, we might be talking about the 
same thing.

With regards to URN's I was specifically refering to 
http://code.google.com/p/perfsonar-ps/wiki/URNs Was this serialized in a 
spec somewhere? NML?
Or perhaps superseded by something better?
> There will of course be caveats.  For example we don't implement 
> namespaces exactly as GFD.84 recommended - so we note that we liked 
> the standard and made some changes to better suit our needs.  I would 
> expect there to be caveats surrounding the NML work as well (unless we 
> want to gang up on Freek and force him to change things to fit our 
> exact needs :))
:D
> I do disagree with your synopsis of where to include schematic 
> details.  I think everyone who has been with the perfSONAR project 
> remembers that the schema files (and their associated comments) where 
> not viewed as often as they should be.  For over 3 years there has 
> been a call to document the details, at a higher level and separate 
> from the RNC descriptions. 
What I meant is that although what is currently there is an improvement, 
we need to extend even more that way. So instead of following the 
contents of the messages and explaining/documenting them better we 
should go even further and think in high level concepts and then recap 
it as we highlight parts of the actual message contents.
> Comments in schema are the same as comments in source code - they give 
> you a tiny piece of information that is worthless almost all of the 
> time.  I agree that communication patterns are important, but message 
> and protocol details are just as important.
- are we intentionally not touching upon AA and Lookup functionally in
> I am going to address your last point first since it effects my answer 
> to the previous two: the documents are not being split to allow for 
> easy extension, they are split to eliminate repetitive language and 
> concepts.  This work is one part of the entire 'spec', it represents 
> the most basic and fundamental set of rules and interactions that are 
> required for any 'real' exchanges. I would not call the contents of 
> the base useful for anything other than reference - there will 
> probably never be a service that speaks 'base' for example.
That's fine. Will we, in the end, role those documents into chapters of 
a master document? even if not, it's still fine.
> There will be an IS document to describe IS (topology/lookup) messages 
> and I would expect there will be an AA document as well.  There is a 
> work for MAs started and MPs and TSs will want to get in on the action 
> evetually.  The strength of doing it in this manner is to save time by 
> trying to not violate the DRY rule.  I do not think that this document 
> can be viewed as an island and judged on what it does (or does not) 
> contain without considering the remaining steps this working group was 
> formed to do.  While I agree with your point that the focus should be 
> on easily implementation/lookup of information in the end, consider 
> that the entire spec is series.  I will reiterate that for this 
> portion of the spec, rules should be a primary concern.
I don't think our opinions aren't that different, I just having the 
concern that people new to the spec might find that they see a large 
system of islands and have no idea what island to start off with, the 
base document could fulfill a role here (or some other island or a 
suppliment 'primer' document) Where or what doesn't matter to me but as 
long as it's there.

I'll see if I can get some writing done tonight or tomorrow,

regards,
Michael