NMC-WG Session 2 June 22 nd 2010, OGF 29 Martin Swany – University of Delaware Jason Zurawski – Internet2

“I acknowledge that participation in this meeting is subject to the OGF Intellectual Property Policy.” Intellectual Property Notices Note Well: All statements related to the activities of the OGF and addressed to the OGF are subject to all provisions of Appendix B of GFD-C.1, which grants to the OGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in OGF meetings, as well as written and electronic communications made at any time or place, which are addressed to: the OGF plenary session, any OGF working group or portion thereof, the OGF Board of Directors, the GFSG, or any member thereof on behalf of the OGF, the ADCOM, or any member thereof on behalf of the ADCOM, any OGF mailing list, including any group list, or any other list functioning under OGF auspices, the OGF Editor or the document authoring and review process Statements made outside of a OGF meeting, mailing list or other function, that are clearly not intended to be input to an OGF activity, group or function, are not subject to these provisions. Excerpt from Appendix B of GFD-C.1: ”Where the OGF knows of rights, or claimed rights, the OGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant OGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the OGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the OGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification.” OGF Intellectual Property Policies are adapted from the IETF Intellectual Property Policies that support the Internet Standards Process. 2 – 6/28/2016, © 2009 Internet2 OGF IPR

Review Document By Sections – 2 Introduction – 3 Motivation – 4 Messages – 5 Chaining – 6 Result Codes – 7 Extension – 8 Security Considerations Other Comments 3 – 6/28/2016, © 2010 Internet2 Outline

Summary: – Purpose should be to discuss the ‘base’, e.g. common portions, of a protocol to control and interact with a performance measurement framework. – Agnostic to transport protocol – subsequent description will exist in profile documents (e.g. SOAP over HTTP) – Mention the tie in to other WGs (NM, NML) Comments: – No Comments 4 – 6/28/2016, © 2010 Internet2 Section 2 - Introduction

Summary: – Describe the common high level view of communication (Request/Response Paradigm, Subscription/Notification). – Describe the break down of documents. E.g. we need to say we are doing the base to save space/time, then we get to the specific messages. Comments: – Don’t use the word ‘redundancies’ – 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. 5 – 6/28/2016, © 2010 Internet2 Section 3 - Motivation

Summary: – Basic examples. – Examples and schemata, as complete as possible. Request message and Response message. Elements and full descriptions Comments: – Large section, break up? – Protocol … do we need more on the state machine of actions? – 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. 6 – 6/28/2016, © 2010 Internet2 Section 4 - Messages

Comments: – 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 patters 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. 7 – 6/28/2016, © 2010 Internet2 Section 4 – Messages, cont.

Summary: – Describes chaining as used in the protocol. – Open questions about how much of merge/operator chaining to use – Changes to what is described in NM? Comments: – Need to simplify the section – reference as much as we can. – Search for filter. – 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. 8 – 6/28/2016, © 2010 Internet2 Section 5 - Chaining

Summary: – TBD section, group debate ongoing. Comments: – Based on HTTP status codes – convey the messages from the services. Try to group. – Do not want to use built in SOAP codes 9 – 6/28/2016, © 2010 Internet2 Section 6 – Result Codes

Summary: – Echo protocol (complete) – How to extend the Echo Protocol Comments: – Need more howto make your own? The way that it is extended belongs here. Don’t want to get too much into developers actions. – – duplicate text? – – choose your own uri. Doesn’t need to be in a specific namespace. 10 – 6/28/2016, © 2010 Internet2 Section 7 - Extension

Summary: – New section, contributed by Michael Bischoff Comments: – 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. 11 – 6/28/2016, © 2010 Internet2 Section 8 – Security Considerations

Profile Document – SOAP over HTTP – not started yet – Right way to do it? Start it stand alone to see how much meat it has. Could be distilled to a paragraph – ‘this is how we did it’. Make it an information section in this document? Context is very important. Any guidance that is required to make a ‘conforming’ implementation. Valid soap envelope, etc. Service URLs? – Is the structure important enough to denote? Notes on current conventions? Something else? What else is needed to make someone write something that can communicate 12 – 6/28/2016, © 2010 Internet2 Other Comments?

NMC-WG Session 2 June 22 nd 2010, OGF 29 Martin Swany – University of Delaware Jason Zurawski – Internet2 For more information, visit 13 – 6/28/2016, © 2010 Internet2