January 2010 - Nmc-wg - lists.ogf.org

Result Codes Poll
by Jason Zurawski 30 Jan '10

30 Jan '10

All; On the Jan 28th call we proposed getting some final feedback on the result codes proposals before going back to pS (and completing this section of the document). A reminder that the proposals are here: http://doodle.com/r?url=https%3A%2F%2Fforge.gridforum.org%2Fsf%2Fsfmain%2Fd… I have set up a doodle poll where people may vote for their favorite: http://doodle.com/ybzmgkaiae4tibew Please vote by Feb 11th, and we will discuss the results on the call. I have also made this a 'secret' ballot, so no one gets to cheat and see what is most popular :) Thanks; -jason

1 0

Call Reminder - Jan 28th, 2010 - 16:00 UTC
by Jason Zurawski 30 Jan '10

30 Jan '10

All; A reminder we will have a call on Thursday, let me know if you can't attend so I can adjust the actions accordingly. Agenda is not set yet, but will be formed here: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki /20100128Notes Thanks; -jason

1 1

NMC Ma document review
by Piotr Pikusa 29 Jan '10

29 Jan '10

Hi all! I have reviewed the document and have one question. Section 4 is DataInfo message type. As wiki says it is probably used only in pSPS. In geant perfsonar MA services (SQL MA nad RRD MA) don't use it and actually I don't know anything about this type of message. Could you tell me what is used for? And should we implement it in our services to be compatible with pSPS or it is not obligatory message type? Regads Piotr Pikusa PSNC

2 1

Documents review (Michael)
by Michael Bischoff 28 Jan '10

28 Jan '10

Hello all, After reviewing the documents I, as I'm sure other people did, found a couple of lesser important points that probably should be addressed. For example the copyright notice 2008-2009 -> 2008-2010. As Jason has already indicated that one should just send in the patches/commit to svn I will not go over them here. My more general points: - Subscription isn't currently implemented as a fire and forget MEP(perhaps we are not talking about the same subscription?) - Security considerations seem to be absent, like the transport layer that soap uses should provide integrity and privacy protection to avoid MITM-attacks etc. - Avoid "MUST" with fuzzy concepts. only use MUST for formal, well scoped, unambiguous statements. - Avoid unnecessary statements/(verbosity without added clarity) Example: "As described in Section 3, the communication protocol is simple and based on the notion of Request and Response messages." "As described in Section 3, the communication protocol is simple and based on the notion of Request and Response messages." "As described in Section 3, communication is based on the Request Response MEP." (related to the point below:) - Ensure clear separation between concepts by choosing carefully/utilising the terminology used and be consistent Example: (from MA document) "The Measurement Archive protocol features three *messages* used to query services identifying themselves as long or short term storage locations of measurement data." ->Message types, message sets(as interfered from definition) or Message exchanges(as interfered from description) - On what standards do we build? NM, NML, others? 'perfsonar URNs'? We probably expect some pre-existing knowledge from our readers. - 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. - focus more on stucture of cooperating parts and communication patterns and tie the message content and/or structure to it. avoid having just a bunch the gritty protocol details - an attached schema in relaxng or xsd with inline comments can already convey this - put differently I first need to figure out which kind of message I'm suppose to start sending before I even care about how it's constructed. - Scope, scope scope. *What* *can* and *what can't* I find in this document/chapter? - Focus on the widely used stuff first. Be critical of what you include now, favor adding stuff in later versions if concepts haven't beeing fully explorered / widely used. (removing something later is hard) - are we intentionally not touching upon AA and Lookup functionally in the base document and if so why not? It feels really hard to grasp whats going on without introducing it. Overall I what I'm trying to stress is that the spec should be written as such that it enables one to easily implement it as opposed to 'just' documenting rules. Now this doesn't mean that it should be turned into a manual, as that is actually counter productive as that would only add verbosity where it could just as easy be placed in a separate document. What I mean with easy to implement strive to enable easy lookup of specific parts. (as that is how a spec is typically consumed) On a related note: While separating everything across documents so that it may be extended easily seemed like a good idea to me as well when we initially started, given how it is shaping up, I'm not sure that I still stand by it. As it might well increase ambiguousness as it invites violating DRY also as time increases having more then one document with more then one version might be hard to consume. Kind regards, Michael Bischoff

2 2

Clarifications on the base-doc
by Inder Monga 28 Jan '10

28 Jan '10

Hi All, These were my comments on the base document. I am still new to perfSONAR suite of services, so would love to get educated as well through the responses. I volunteer to fix the nits on SVN if you agree they are valid comments :). 1. It seems odd to have requirements specific MUST, SHOULD in a preliminary example. It would be great to consolidate the requirements either in Sections 4.3/4.4 or message structure protocol requirements before the example in Section 4.1. 2. In Section 4.1, page 7 a. I understand the concept behind "rejected outright" but it will good to elaborate what that means like " message is discarded and an response sent with a corresponding error message". b. In my understanding "Note this message is similar to the response in many ways" - the word response should actually be "request"? 3. In section 4.3.2.2, it seems that different services can react radically differently to the presence of objects in an API. I do not think it is wise for some services to view inclusion of this element as an "error". For optional elements, if a service that does not expect those elements and they are not mandatory, it should ignore it, as long as the overall request makes sense. Is there a particular case where inclusion of this element should generate an error? 4. It is mentioned many times that id may be used to track state between messages and services. The examples in the doc do illustrate how request/response and metadataidref use the id to do chaining. What is unclear is what other state can be tracked with "id"'s? An example would be great here. 5. Section 5.1, it seems like incorrect bold/highlighting of should, shall etc. I think Freek volunteered to fix it...but I could take a shot there as well. 6. Section 5.1.2 - The first line "When we are faced with like elements that MAY NOT share a common namespace, we SHOULD NOT combine." I am unclear what it means, would the meaning the sentence means to convey stay the say if I rephrased it as "When we are faced with like elements that do not share a common namespace, we SHOULD NOT combine". In the current instantiation within the document, it seems to indicate that if there are like elements that share a common namespace, there may be reasons not to combine. If there are exceptions like these, we should highlight what cases might those be..... 7. I am still trying to wrap my head around all the nuances of chaining, though the base concepts are simple. The confusion is especially around the descriptions of the three approaches "safe and stupid, dangerous yet intelligent and slow and steady". Should these three approaches be broken into their own sub-sections for better readability? Thanks, Inder

3 3

[ogf nmc-base svn commit] r12 - /
by svn＠ogf.org 28 Jan '10

28 Jan '10

Author: zurawski Date: 2010-01-28 08:03:50 -0600 (Thu, 28 Jan 2010) New Revision: 12 Modified: extension.tex messages.tex nmc-base.pdf Log: Correcting errors and adding comments from Slawek. -jason Modified: extension.tex =================================================================== --- extension.tex 2010-01-28 13:53:49 UTC (rev 11) +++ extension.tex 2010-01-28 14:03:50 UTC (rev 12) @@ -209,7 +209,7 @@ \paragraph{Response Message Schema} \label{s:echo_protocol_response_schema} -The following schema is a native description of the request schema as in the RELAX-NG\cite{relaxng} language. Through the use of tools such as Trang\cite{trang} and MSV\cite{msv} it is possible to convert this to other widely accepted formats such as XSD\cite{xsd}. The following describes the \textbf{EchoRequest} schema. Note that this will only validate \textbf{EchoRequest} messages. +The following schema is a native description of the response schema as in the RELAX-NG\cite{relaxng} language. Through the use of tools such as Trang\cite{trang} and MSV\cite{msv} it is possible to convert this to other widely accepted formats such as XSD\cite{xsd}. The following describes the \textbf{EchoResponse} schema. Note that this will only validate \textbf{EchoResponse} messages. \tiny \begin{verbatim} @@ -403,6 +403,14 @@ \paragraph{Response Message Example} \label{s:echo_protocol_response_example} + +% XXX jz - 1/28/2010 +% +% A comment from Slawek: +% +% Fix the examples to use new result codes. +% + The first example shows a correct configuration for an \textbf{EchoResponse} message. \tiny Modified: messages.tex =================================================================== --- messages.tex 2010-01-28 13:53:49 UTC (rev 11) +++ messages.tex 2010-01-28 14:03:50 UTC (rev 12) @@ -46,7 +46,7 @@ \begin{itemize} \item \textbf{Message Type} - Every \textit{message} \textbf{MUST} contain a \textit{type}, these facilitate the semantic intentions of the internal data -\item \textbf{Message Structure} - There\textbf{MAY} be \textit{metadata} and/or \textit{data} elements in each message, and there \textbf{MAY NOT} need to be a matching data for every metadata (e.g. \textit{Chaining}, see Section~\ref{s:information_chaining}) +\item \textbf{Message Structure} - There \textbf{MAY} be \textit{metadata} and/or \textit{data} elements in each message, and there \textbf{MAY NOT} need to be a matching data for every metadata (e.g. \textit{Chaining}, see Section~\ref{s:information_chaining}) \item \textbf{Metadata} - \textbf{SHOULD} contain measurement data, identifying information about a service, or even information meant to serve as a modifier (see see Section~\ref{s:information_chaining}). Note that we still loosely observe the static rule of thumb \item \textbf{Data} - Serves a dual role: in request messages this \textbf{MAY} be empty (e.g. this is a \textit{data trigger}, it lets the service know we need action on the accompanying metadata), or it \textbf{MAY} contain dynamic measurement data or even other metadata elements \end{itemize} Modified: nmc-base.pdf =================================================================== (Binary files differ)

1 0

[ogf nmc-base svn commit] r11 - /
by svn＠ogf.org 28 Jan '10

28 Jan '10

Author: zurawski Date: 2010-01-28 07:53:49 -0600 (Thu, 28 Jan 2010) New Revision: 11 Modified: introduction.tex motivation.tex nmc-base.pdf nmc-base.tex Log: Adding comments from Michael on areas that need to be addressed. -jason Modified: introduction.tex =================================================================== --- introduction.tex 2010-01-27 13:20:20 UTC (rev 10) +++ introduction.tex 2010-01-28 13:53:49 UTC (rev 11) @@ -5,3 +5,10 @@ The work presented here builds upon the output of other working groups focused on the accurate description of network measurements \cite{nmwg} and topological representation of network elements \cite{nmlwg}. When applicable, we will directly cite terminology and ideas from these working groups. We do not describe a particular system currently in use, although several prototypes exist that implement messaging similar to this work. +% XXX jz - 1/28/2010 +% +% A comment from Michael: +% +% 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. Modified: motivation.tex =================================================================== --- motivation.tex 2010-01-27 13:20:20 UTC (rev 10) +++ motivation.tex 2010-01-28 13:53:49 UTC (rev 11) @@ -19,6 +19,17 @@ \label{fig:exchange2} \end{figure} +% XXX jz - 1/28/2010 +% +% A comment from Michael: +% +% Subscription isn't currently implemented as a fire and forget MEP(perhaps we +% are not talking about the same subscription?) +% +% Other Notes: +% Should read WS-Subscription std. See what OSCARS is doing w/ Notification +% Service. + Another interaction is the notion of a \textit{Subscription}, \textit{Notification} or other form of ``one-sided'' exchange. Services may use this to perform tasks such as subscribing to status updates from a service, or otherwise alerting a service or client about the existence of some key piece of information. Figure~\ref{fig:exchange3} describes this exchange in detail. \begin{figure}[h!] Modified: nmc-base.pdf =================================================================== (Binary files differ) Modified: nmc-base.tex =================================================================== --- nmc-base.tex 2010-01-27 13:20:20 UTC (rev 10) +++ nmc-base.tex 2010-01-28 13:53:49 UTC (rev 11) @@ -115,7 +115,14 @@ The key words ``MUST'' ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and ``OPTIONAL'' are to be interpreted as described in RFC 2119 \cite{rfc2119} -\section{Security Considerations} +\section{Security Considerations} +% XXX jz - 1/28/2010 +% +% A comment from Michael: +% +% Security considerations seem to be absent, like the transport layer that soap +% uses should provide integrity and privacy protection to avoid MITM-attacks +% etc. There are no security considerations.

1 0

[ogf nmc-base svn commit] r10 - /
by svn＠ogf.org 27 Jan '10

27 Jan '10

Author: zurawski Date: 2010-01-27 07:20:20 -0600 (Wed, 27 Jan 2010) New Revision: 10 Modified: messages.tex nmc-base.pdf Log: Fixing a minor error in section 4, adding more comments to address. -jason Modified: messages.tex =================================================================== --- messages.tex 2010-01-15 13:20:22 UTC (rev 9) +++ messages.tex 2010-01-27 13:20:20 UTC (rev 10) @@ -51,6 +51,18 @@ \item \textbf{Data} - Serves a dual role: in request messages this \textbf{MAY} be empty (e.g. this is a \textit{data trigger}, it lets the service know we need action on the accompanying metadata), or it \textbf{MAY} contain dynamic measurement data or even other metadata elements \end{itemize} +% XXX jz - 1/27/2010 +% +% A comment from Inder: +% +% 2. In Section 4.1, page 7 +% a. I understand the concept behind "rejected outright" but it will good to +% elaborate what that means like "message is discarded and an response +% sent with a corresponding error message". +% +% +% The above text should be altered to address this. + Simply stated, we are sending a request (either partial or complete) to a capable service to perform some interactive behavior. We are interested in having the service verify that it \textbf{MAY} or \textbf{MAY NOT} be able to service our request. We are interested in either setting or retrieving information on this target data set - subsequent operations may be required. When the service receives this request it will check for several things: \begin{itemize} @@ -78,7 +90,7 @@ \end{verbatim} \normalsize -Note this message is similar to the response in many ways. The major differences: +Note this message is similar to the request in many ways. The major differences: \begin{itemize} \item \textbf{Message Type} - This becomes the foil of the previous request; it is common to simply replace the word ``Request'' with ``Response''. Modified: nmc-base.pdf =================================================================== (Binary files differ)

1 0

Review of documents
by Freek Dijkstra 22 Jan '10

22 Jan '10

Hi all, My apologies for the (very) late reply. I have a few generic comments and questions on "Extensible Protocol for NMC" for now and will follow up with some more detailed remarks later. (I planned to have the detailed remarks now, but was not able to finish reading all I wanted). My main point of criticism is that I do not (yet) understand why this protocol was developed; as a naive reader it seems to highly overlap with what has been done with WSDL. Unfortunately, I'm not an expert on either, so I might miss the point. WSDL was developed as a generic request-response protocol framework, and so is "Extensible Protocol for NMC". I still like the work, for example the idea on metadata is good. I just recommend to (a) build more on existing frameworks (e.g. specify that the protocol MUST use webservices instead of SHOULD, and refer to WS-whatever for authentication extension) and (b) make it more clear what was added. While I'm not very familiar with RELAX-NG, I think it is a good way forward, as it can be translated to XSD, and hopefully, this means there can be automated syntax check for messages. Has this been done so far? Last, the wording could be better in some places, especially when it comes to the RFC 2119 words (MUST, SHOULD, MAY). Two examples: "MAY or MAY NOT" (page 6), and my favourite: "Data MUST contain information, especially if it was empty in the initial request". Beside the obviousness of this statement (what else then information?) and the unclarity where "it" refers to, it seems that "SHOULD" was intended here, not MUST (why else the "especially"?). Summarizing: - The ideas are good - It should build more on WS-stuff (especially since this is the OGF, which is quite WS-frantic if you aks me). - The wording could be more strict. I hope to have more detailed replies while I finished the reference document, and read a bit on WSDL. (the awful truth is that I have not programmed a webservice yet). Regards, Freek

7 15

Netconf in pS
by Roman Lapacz 21 Jan '10

21 Jan '10

Hi, I'm sending you some info about the investigation work (by Arne Oslebo) on Netconf in pS which is being done in Geant3. After a while I will add a detailed description from one of project documents but it's still under review process so it must wait a bit. http://software.uninett.no/stager/wiki/netconf Roman

2 2