Overall

Last update: March 22, 2010

Overall

• Correct RFC 2119 words (usage and intention) throughout the entire document
  • Inder & Freek
  • Some progress made - need to review whole document
• Considering a move to lock down the protocol
  • Jeff & Jason
  • Proposal to use profile document(s) to describe transport medium

Sections 1/2/8/9 (Abstract/Introduction/Conclusion/Acknowledgements)

• Each should be checked to be sure they sum up the document correctly
• Additional references to related work may be required
• Add foundation/Convey intention(improve introduction?) example: why do we have perfsonar(/nmc)? - not to 'sell it' but outline to convey intent so that one can interpret the rest of the document better.

Editors: Martin, Jeff, Inder, Roman, Michael

Section 3 (Motivation)

• Do the pictured exchanges accurately describe perfsonar?
  • Any additions?
  • Any changes?
• Does this section accurately describe what is about to follow?
  • need to scope this a bit more, e.g. where we are going and how to split the content between the base and other things
• Push the idea of WS use/purpose more
• Push the idea of the original NM-WG/perfSONAR story as to why we need an NMC
• Motivate the profile doc for transport layer
• Do we need more in this section?

Editors: Roman, Jeff, Freek

Section 4 (Messages)

• This is the largest section, so it needs the most attention
• Is the XML accurate and schema accurate?
• Are the descriptions that follow each XML element accurate?
  • Hint: be sure the required/optional elements and attributes are described correctly. May be cut and paste errors. Also check namespaces.
  • Add an extra row to each table to signify multiple elements
• Clarifications on types of message. Be clear on what 'rejected outright' means, include examples where applicable.
• Clarifications on what to do for expected vs. unexpected elements. Do we error? Do we proceed without warnings? examples and explicit rules are required.
  • Avoid being unclear 'e.g. an error may occur'. Be conservative in what you send and liberal in what you accept.
• Rules regarding the state transferred via Ids and IdRefs. Don't go into detail on chaining, but say when state may matter (message id) and when it doesnt (subject/parameter id)
• Are we missing any?

Section 5 (Chaining)

• There are two types of chaining:
  • Merge chaining
  • Operation chaining
• Read NM-WG document to see what extend things are explained. This section should include NMC specific extensions or corrections.
• Are we missing use cases for NMC specifically?
• Would more examples help - or does NM need them?
• Which explanations need to be edited?
• Do we need merge chaining in NMC? Proposal on list to see if it is a valid use case.

Editors: Martin, Jeff, Roman, Aaron

Section 6 (Result Codes)

• Requires group concensus
• Requires extensive research and identification of potential use cases

Writers: Slawomir, Roman, Jason Editors: Jason, Roman, Jeff, Nina, David S (DFN)

Section 7 (Extension)

• The echo protocol is simple, but we need verification that the current description is accurate.
  • As in Section 4, check the XML, the descriptions
  • Check result codes (depends on Section 6 work)
• Extension section should be checked for accuracy
• Data Type extensions?
• Adding new messages?

Editors: Sławomir, Piotr, Inder

Section 11 (Security Considerations)

• Security considerations seem to be absent, like the transport layer that soap uses should provide integrity and privacy protection to avoid MITM-attacks etc.

Writers: Michael Editors: Martin, Jeff

Section 12?

• Explain how to use profile documents with the base

Writers: Jason Editors: TBD