- Nmc-wg - lists.ogf.org

Update for 3/4
by Jason Zurawski 04 Mar '10

04 Mar '10

- Have not had a chance to doing any document writing. Will be starting next week. - Talked with Jeff offlist about XML/SOAP/HTTP. We are going to write a clarifying statement on how to proceed - expect this in the next week. Group will have a chance to weigh in. Thanks; -jason

1 0

Conf call March 4th
by Roman Lapacz 04 Mar '10

04 Mar '10

Hi, unfortunately, I will not be able to attend the conf call tomorrow. Input from me: - Slawek and I have sent a doc with result codes proposal (see my previous email) - I declared to revise example messages in the base doc and I'll try to do this asap (I hope tomorrow) Cheers, Roman

2 2

[ogf nmc-base svn commit] r14 - /
by svn＠ogf.org 23 Feb '10

23 Feb '10

Author: imonga Date: 2010-02-23 16:31:15 -0600 (Tue, 23 Feb 2010) New Revision: 14 Modified: chaining.tex messages.tex Log: Chaining.tex: Made changes to bold SHOULD, MUST text in section 5.1 Messages.tex: various nits changed including added text after "message is rejected outright" Modified: chaining.tex =================================================================== --- chaining.tex 2010-02-23 22:02:19 UTC (rev 13) +++ chaining.tex 2010-02-23 22:31:15 UTC (rev 14) @@ -10,18 +10,18 @@ \subsection{Merge Chaining} \label{s:information_chaining_merge} -As the name implies, we intend to \textit{merge} or combine metadata elements through this structure. There are many things we \textbf{MAY} consider when describing this operation: +As the name implies, we intend to \textit{merge} or combine metadata elements through this structure. There are many things we may consider when describing this operation: \begin{itemize} \item Which elements are \textit{mergeable}? \item How much \textit{recursion} is needed for merge-able elements? -\item When \textbf{SHOULD} we \textit{duplicate} elements? -\item When \textbf{SHOULD} we \textit{replace} elements in the course of merging? +\item When should we \textit{duplicate} elements? +\item When should we \textit{replace} elements in the course of merging? \end{itemize} -As stated previously, the schemata itself does not offer any suggestions as to what is a \textit{good merge} vs. a \textit{bad merge}. There are no rules regarding which \textit{types} of data \textbf{SHOULD} and \textbf{SHOULD NOT} be merged. There is no guidance on when we \textbf{SHOULD} duplicate or replace elements. +As stated previously, the schemata itself does not offer any suggestions as to what is a \textit{good merge} vs. a \textit{bad merge}. There are no rules regarding which \textit{types} of data should and should not be merged. There is no guidance on when we should duplicate or replace elements. -We \textbf{RECOMMEND} some very simple and succinct guidelines that services may implement for this particular style of merging. There \textbf{SHALL} always be exceptions to rules, therefore the reader is encouraged to think carefully about what a specific service \textbf{MAY} need when implementing this recommendation. +We recommend some very simple and succinct guidelines that services may implement for this particular style of merging. There shall always be exceptions to rules, therefore the reader is encouraged to think carefully about what a specific service may need when implementing this recommendation. \subsubsection{Mergeable Elements and Recursion} \label{s:information_chaining_merge_elements} Modified: messages.tex =================================================================== --- messages.tex 2010-02-23 22:02:19 UTC (rev 13) +++ messages.tex 2010-02-23 22:31:15 UTC (rev 14) @@ -11,13 +11,13 @@ % % The original thinking was the NM-WG document, "An Extensible Schema for % Network Measurement and Performance Data", would contain the entire -% explanation of namespaces (the idea itself coming from another OGF WG). +% explanation of namespaces (the idea itself coming from another OGF WG). % % Any future documents from related projects (NMC, NML, others?) would reference -% this and only note caveats to the original rule. The NM-WG doc is here: -% -% https://forge.gridforum.org/sf/go/doc15649?nav=1 -% +% this and only note caveats to the original rule. The NM-WG doc is here: +% +% https://forge.gridforum.org/sf/go/doc15649?nav=1 +% % Namespaces are in section 4. Regardless, we need to discuss this and provide % the reference somewhere before we discuss the message structure. @@ -67,8 +67,8 @@ \begin{itemize} \item \textbf{Syntax} - Does the request parse correctly? Incorrect syntax will trigger \textit{error routines}. -\item \textbf{Message Type} - Can this service accept and act on this kind of message? An unexpected message \textbf{MUST} be rejected outright. -\item \textbf{Structure} - Is there at least a single metadata and data pair that is capable of being acted on? A service that cannot determine if there is actionable content in the request will \textit{reject} the message with an \textit{error routine}. +\item \textbf{Message Type} - Can this service accept and act on this kind of message? An unexpected message \textbf{MUST} be rejected outright by discarding it and responding with a corresponding error message. +\item \textbf{Structure} - Is there at least a single metadata and data pair that is capable of being acted on? A service that cannot determine if there is actionable content in the request will \textit{discard} the message with an \textit{error routine}. \item \textbf{Semantics} - Does the request make sense according to the schematic rules; can the metadata be acted upon; are the chains resolved properly? Handling of semantic rules are the discretion of the service: \textit{error routines} are possible or perhaps some form of \textit{panic parsing} may result in partial completion of a request. \end{itemize} @@ -269,8 +269,17 @@ \item \textbf{Parameter} - Described in Section~\ref{s:request_message_analysis_parameter} \end{itemize} -Note that the use of this element (in this particular location) is \textbf{OPTIONAL}. Services are not required to understand this element and in some cases \textbf{MAY} view inclusion as an error. Please consult service documentation before proceeding. +% XXX imonga - 02/23/2010 +% +% Comment: I am making the change the line below to the following +% "Services are not required to understand this element and SHOULD ignore this +% element if not expected by the service" +% +% + +Note that the use of this element (in this particular location) is \textbf{OPTIONAL}. Services are not required to understand this element and \textbf{SHOULD} ignore this element if not expected by the service. Please consult service documentation before proceeding. + \paragraph{Parameter} \label{s:request_message_analysis_parameter} @@ -400,7 +409,7 @@ \paragraph{Key} \label{s:request_message_analysis_key} -example of status response in 4.1 does not explain too much (looks the +example of status response in 4.1 does not explain too much (looks the > same as earlier response example) % XXX jz - 1/13/2010 @@ -444,7 +453,7 @@ The key element is rooted in the concept of a \textit{hash function} --- a function or process designed to convert a variable amount of information into a single value or \textit{index}. Once converted this single value can then be used a shorthanded notation to reference the original entity, imparting a performance increase for computational tasks. -The key structure \textbf{SHALL} used to convey sensitive or private information to and from the service. For this reason the contents of the key \textbf{SHOULD} be viewed as ``opaque'', and \textbf{MUST NOT} be dissected. The key \textbf{SHOULD} contain a \textit{Parameters} (see Section~\ref{s:request_message_analysis_parameters}) element. There is only one attributes possible: \textit{id}. This \textbf{MAY} used to track state. A detailed description follows: +The key structure \textbf{SHALL} used to convey sensitive or private information to and from the service. For this reason the contents of the key \textbf{SHOULD} be viewed as ``opaque'', and \textbf{MUST NOT} be dissected. The key \textbf{SHOULD} contain a \textit{Parameters} (see Section~\ref{s:request_message_analysis_parameters}) element. There is only one attribute possible: \textit{id}. This \textbf{MAY} used to track state. A detailed description follows: \begin{itemize} \item \textbf{id} - Identifying attribute that \textbf{MAY} be used to track state.

1 0

[ogf nmc-base svn commit] r13 - examples
by svn＠ogf.org 23 Feb '10

23 Feb '10

Author: imonga Date: 2010-02-23 16:02:19 -0600 (Tue, 23 Feb 2010) New Revision: 13 Modified: examples/request2.xml Log: corrected spelling of parameters Modified: examples/request2.xml =================================================================== --- examples/request2.xml 2010-01-28 14:03:50 UTC (rev 12) +++ examples/request2.xml 2010-02-23 22:02:19 UTC (rev 13) @@ -2,7 +2,7 @@ type="request" id="message2"> - <nmwg:parameters id="paraemters1"> + <nmwg:parameters id="parameters1"> <nmwg:parameter name="something">something else</nmwg:parameter> </nmwg:parameters>

1 0

Re: [Nmc-wg] Transport protocol
by Freek Dijkstra 22 Feb '10

22 Feb '10

Michael Bischoff wrote: > After discussing some of this off list with Jason it seems we are > leaning towards how it was done SAML spec the base is completely > transport agnostic and perhaps specify later how to bind these > (http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) I think it is reasonable if the base document is transport agnostic, but I would be very much in favour if it is documented somewhere: after all, if I read NM charter, it is chartered with defining a schema, while NMC is chartered with defining a protocol. So, I would say: define exactly what is going over the wire. That includes specifying the underlying transport protocol, as long that is a concern for the end-hosts (so it must be defined up to the transport layer (in this case: define that we use SOAP + HTTP + TCP and that the port number should be looked up in the lookup service). The only drawback of this approach is the plethora of documents we're creating, but otherwise it seems fine with me. If we agree, I will rework the SHOULD and MUSTs in the base document according to this agreement, and note that the transport protocol is defined elsewhere. Regards, Freek

6 8

Relation between documents.
by Michael Bischoff 19 Feb '10

19 Feb '10

Hello all, As it seems that I wasn't the only one who wasn't sure about certain things perhaps it's usefull to bring an other point that I discussed with Jason up to the list: I'd like to quote Roman from the other discussion as a starting point: > - base doc > -- extension doc (e.g. for MA) > --- transport implementation doc (including, for example WS info) > > (lower level doc refers to upper level doc) Now we also have some other documents and I was wondering how everyone thinks those would relate. We (also) have: Information Services document(LS & TOPO-service) Authentication and authorization document(AA) I'm also interested in what order people expect the documents to be read. Regards, Michael.

1 0

Reminder - Call tomorrow (2/18) at 16:00 UTC
by Jason Zurawski 18 Feb '10

18 Feb '10

All; We will hold a quick call tomorrow, agenda will be located here: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/201002… Topics are still TBD, but will probably related to recent mailing lists discussion and the plan for the next 3-4 weeks before OGF 28. If you have not done so, please vote in the result code poll. Thanks; -jason

3 3

Transport protocol
by Freek Dijkstra 18 Feb '10

18 Feb '10

Hi all, I was just going through the document again to see what can be improved. A few issues on the transport protocol. The document never makes it clear what kind of transport protocol is used. Section 2 say "The proposed architecture should mae this functionality available vai Web Services (WS) [...]" While there are different types of webservices, e.g. * XML in SOAP over HTTP * XML in SOAP over AMQP * XML in SOAP over JMS * XML in SOAP over TCP or UDP * XML over HTTP (the recent low-overhead RESTful webservices) In practice, only XML in SOAP over HTTP seems to be used. To we want to impose that? I think it should be, though I am fine if it is either in the NMC base document or in another document (which has the advantage that if we later want to change the transport protocol, it is not necessary to update the base document). At least, when I play with the PerfSONARUI (great work by the way, it allows me to understand PerfSONAR a bit better!), I see that a request like this: > <?xml version="1.0" encoding="UTF-8"?> > <nmwg:message id="message1266324754" type="EchoRequest" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"> > <nmwg:metadata id="meta"> > <nmwg:eventType>http://schemas.perfsonar.net/tools/admin/echo/2.0</nmwg:eventType> > </nmwg:metadata> > <nmwg:data id="data" metadataIdRef="meta"/> > </nmwg:message> Is transformed on the wire to this: > POST /geant2-java-rrd-ma/services/MeasurementArchiveService HTTP/1.0 > Content-Type: text/xml; charset=utf-8 > Accept: application/soap+xml, application/dime, multipart/related, text/* > User-Agent: Axis/1.4 > Host: 62.40.123.162:8080 > Cache-Control: no-cache > Pragma: no-cache > SOAPAction: "" > Content-Length: 559 > > <?xml version="1.0" encoding="UTF-8"?> > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <soapenv:Body> > <nmwg:message id="message1266324654" type="EchoRequest" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"> > <nmwg:metadata id="meta"> > <nmwg:eventType>http://schemas.perfsonar.net/tools/admin/echo/2.0</nmwg:eventType> > </nmwg:metadata> > <nmwg:data id="data" metadataIdRef="meta"/> > </nmwg:message> > </soapenv:Body> > </soapenv:Envelope> Beside describing the transport protocol, which document is to defined the preferred TCP server ports for a given service? I presume the documents describing the individual services should define the later. Regards, Freek

5 5

Proposal to postpone this week's call
by Jason Zurawski 11 Feb '10

11 Feb '10

Hi All; I will be unavailable on 2/11 and would like to propose we meet 2/18 instead. If this is a problem for anyone please speak up ASAP. Thanks; -jason

1 2

Fwd: [Nml-wg] Soliciting Public Comments on "Network topology descriptions in hybrid networks"
by Jason Zurawski 08 Feb '10

08 Feb '10

Hi All; FYI: Comment period ends next Monday. This document has the potential to effect future pS development considerations so please fwd to anyone involved who may not be subscribed to OGF activities. -jason -------- Original Message -------- Subject: [Nml-wg] Soliciting Public Comments on "Network topology descriptions in hybrid networks" Date: Sat, 16 Jan 2010 02:04:29 +0100 From: Freek Dijkstra <Freek.Dijkstra(a)sara.nl> To: Network Markup Language Working Group <nml-wg(a)ogf.org> All, Our first deliverable, "Network topology descriptions in hybrid networks", is now soliciting public comments. If you have any comments, or know anyone who like to comment on this document, please do so at http://www.ogf.org/gf/docs/comment.php?id=327. The official public comment period ends Feb 15, 2010. My apologies to Paola Grosso for the very long delay (over a year) between the final editing and this public comments. This was mostly due to negligence and unfamiliarity of procedures on my part. With kind regards, Freek Dijkstra

2 2