Coordinates

OGF 29 - Chicago IL

• http://ogf.org/gf/event_schedule/index.php?id=2049

Agenda

• Session 1 (Outreach Session)
  • Document Working Session
• Session 2 (Canceled)

Notes

Notes were recorded in the slides for future reference: https://forge.gridforum.org/sf/go/doc16004?nav=1

Section by section notes:

• Section 2 Introduction
  • Reiterate that the base is the common portions of the protocol.
  • Some discussion on the agnostics treatment of SOAP/HTTP. It may be enough to forget about the idea of profile and go with a paragraph for information purposes, e.g. "done using SOAP over HTTP"
  • Ensure the other WGs are mentioned and motivated properly
• Section 3 Motivation
  • Don’t use the word ‘redundancies’ in section 3.
  • Freek: Not clear if this document is a ‘requirements’ document, or a description of future work that will be requirements. (need to be more clear). Freek to make text change.
  • Expected extensions (maybe in Messages? Conclusions?). Doesn’t belong where it is.
  • Bulk transfer – is a derivation of one of the other two.
• Section 4 Messages
  • Large section, break up? - No
  • Protocol … do we need more on the state machine of actions? - No
  • Request/Response – Subscription/Notification. Need to point out that these are the same structure.
  • In 4.1 – using the example we are explaining the structure. Its not as much about the example, its about describing. ‘Basic Message Structure’ or ‘Basic Message Properties’ should be the title.
  • 4.1 – Finish the ‘metadata’ thought. ‘Data’ – reference the structure of metadata/data from NM. Don’t let the trigger come out of the blue.
  • Be clear if this is a capability of verifying a message, or actual actions from service. Pronoun use is making it harder to understand. Client/Service point of view is being munged.
  • Declaration vs questions – declarations must be used instead.
  • Suggestion: describe what happens when a service receives a message. Checking the of the syntax/structure. Then the posssible actions that can result. Then move into a more specific description of the request/response. Then the semantics of each.
  • Build on the semantics on a couple of different levels. “There is a data that points to a metadata”. Semantic use of id/idref instead of syntactic. Idref that doesn’t point to anything = bad.
  • Semantics that arrise from patterns of messages like request/response.
  • ‘State’ machine is not really, but it seems to be complete.
  • Need a good editor for all of the XML sections.
• Section 5 Chaining
  • Need to simplify the section – reference as much as we can.
  • Search for filter and replace with 'operator'
  • Are we removing Merge?
    • Proposed removal = simplification of the entire thing. Want the option still available in the base.
    • ‘Prefer’ to eliminate it in the profile documents, not the base. Exactly described in nmbase. Martin to re-bring up on the mailing list.
  • Do we need a drastically different section for operator?
    • Examples may belong more in NMC
    • NM should describe the idea.
    • ‘Walking the chain’ and resolving the references. What happens when they don’t exist? Basic checks need to be performed to ‘validate’ things.
• Section 6 Result Codes
  • Based on HTTP status codes – convey the messages from the services. Try to group.
  • Do not want to use built in SOAP codes
  • Need to finish this effort.
• Section 7 Extension
  • Need more howto make your own?
    • The way that it is extended belongs here. Don’t want to get too much into developers actions.
  • 7.1.2.1 – duplicate text
  • 7.1.5.1 – choose your own uri. Doesn’t need to be in a specific namespace.
• Section 8 Security Considerations
  • Is it needed?
    • Worry about this last?
    • Need to find the securty person to ask them…
    • Subsequent revisions may describe Auth etc.
  • Too much, too little?
    • May be too much. DDoS considerations for an XML protocol may be overkill.
  • AUTH is coming, describe it somewhere else.

Next Meeting

• August 5th 2010 - 15:00 UTC

Actions

• Jason: Implement changes suggested above
• Freek: Read and edit the document, changing grammer and language use as required.