[Nmc-wg] [ogf nmc-base svn commit] r7 - /
svn at ogf.org
svn at ogf.org
Wed Jan 13 06:37:46 CST 2010
Author: zurawski
Date: 2010-01-13 06:37:45 -0600 (Wed, 13 Jan 2010)
New Revision: 7
Modified:
acknowledgements.tex
chaining.tex
conclusion.tex
introduction.tex
messages.tex
motivation.tex
nmc-base.bib
nmc-base.pdf
nmc-base.tex
result_codes.tex
Log:
Summary of changes:
- Update cp information/title page
- Add a note regarding the status of namespace explanation
- Add a note for someone to update a response message example
- Add more clarification for the key element
- Correct a reference to GFD.23 (char doc)
- Typo in 4.4.1
- Remove supportedEventType examples from chaining section
- Add a note regarding the enhancement of the result codes
- misc. word changes (nothing structural)
-jason
Modified: acknowledgements.tex
===================================================================
--- acknowledgements.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ acknowledgements.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -1,4 +1,4 @@
\section{Acknowledgements}
\label{s:acknowledgements}
-The authors gratefully acknowledge the contributions of the perfSONAR consortium to this work. Specifically staff and member institutions from ESnet, Geant, Internet2, and RNP have provided extensive input and feedback into the implementation of this and all NMC protocols.
+The authors gratefully acknowledge the contributions of the perfSONAR consortium to this work. Specifically staff and member institutions from ESnet, Geant, Internet2, and RNP have provided extensive input and feedback into the implementation of this and all NMC-WG protocols.
Modified: chaining.tex
===================================================================
--- chaining.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ chaining.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -34,7 +34,7 @@
\item Elements sharing the same (or ``similar'') eventType
\end{itemize}
-When this first criteria is met, we \textbf{SHOULD} recurse downward and keep trying until we reach the bottom of the structure. How far should we venture into the XML structure looking for similarities or differences? This question does not have a definite answer such as \textit{stop at the grandchild of the current element}. While this \textbf{MAY} be frustrating, domain knowledge \textbf{MAY} help you make a passable decision especially with regards to topology based elements.
+When this first criteria is met, we \textbf{SHOULD} traverse the chain \textit{downward}, recursively. A clear question to answer is ``How far should we venture into the XML structure looking for similarities or differences''? This question does not have a definite answer such as ``Stop at the grandchild of the current element''. While this \textbf{MAY} be frustrating, domain knowledge \textbf{MAY} help you make a passable decision especially with regards to topology based elements.
\textit{Like} elements that do not share a common namespace \textbf{SHALL} require special rules that \textbf{MAY} differ from service to service. Depending on the level of protection or speed we wish to attain, these rules \textbf{MAY} vary. Service and protocol documentation \textbf{SHALL} fill in details beyond the scope of this work.
@@ -67,10 +67,6 @@
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="m1">
@@ -92,8 +88,16 @@
\end{verbatim}
\normalsize
-Note that the chaining is performed via the use of the \textit{metadataIdRef} tag in the metadata element. This is a signal for services (specifically the SNMP MA or RRD MA) to keep looking deeper in an effort to resolve the chains. The Figure~\ref{fig:chain} demonstrates the linking between the metadata elements. The resulting XML structure after chaining is also listed below.
+
+% XXX jz - 1/13/2010
+%
+% Need references for the services.
+
+
+
+Note that the chaining is performed via the use of the \textit{metadataIdRef} tag in the metadata element. This is a signal for services (specifically perfSONAR services such as the SNMP MA or RRD MA) to keep looking deeper in an effort to resolve the chains. The Figure~\ref{fig:chain} demonstrates the linking between the metadata elements. The resulting XML structure after chaining is also listed below.
+
\begin{figure}[h!]
\centering
\includegraphics[width=1.5in]{chain.eps}
@@ -116,10 +120,6 @@
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="m1">
@@ -135,10 +135,6 @@
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m3" metadataIdRef="m1">
@@ -154,10 +150,6 @@
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -180,23 +172,14 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="m1">
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m3" metadataIdRef="m2">
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -226,9 +209,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="m1">
@@ -244,10 +224,6 @@
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m3" metadataIdRef="m2">
@@ -264,11 +240,6 @@
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -291,9 +262,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="m1">
@@ -325,9 +293,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="m1">
@@ -342,9 +307,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -366,9 +328,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="1">
@@ -380,9 +339,6 @@
</nmwgt:interface>
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -402,9 +358,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="1">
@@ -423,9 +376,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -445,9 +395,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="1">
@@ -462,9 +409,6 @@
</nmwgt:interface>
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -486,9 +430,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="1">
@@ -503,9 +444,6 @@
</nmwgt:interface>
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -523,9 +461,6 @@
</nmwgt:interface>
</neterr:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="1">
@@ -535,9 +470,6 @@
</nmwgt:interface>
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -555,9 +487,6 @@
</nmwgt:interface>
</neterr:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2" metadataIdRef="1">
@@ -569,10 +498,6 @@
</nmwg:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
\end{verbatim}
@@ -628,10 +553,6 @@
</netutil:subject>
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
- <nmwg:parameters id="p1">
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:parameter>
- <nmwg:parameter name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="m2">
Modified: conclusion.tex
===================================================================
--- conclusion.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ conclusion.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -1,4 +1,8 @@
\section{Conclusion}
\label{s:conclusion}
+% XXX: jz - 1/13/2010
+%
+% Conclusion is weak, this needs to be two paragraphs and sum up the work.
+
The preceding work has described a simple protocol that will form the basis of communication for software exchanging both network measurements and topological information. This protocol is both minimal and flexible --- extension to specific use cases is possible and expected. This work has been careful to retain the concepts described in other working groups including \textbf{NM-WG} and \textbf{NML-WG} in an effort to remain compatible with the primary data types.
Modified: introduction.tex
===================================================================
--- introduction.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ introduction.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -1,7 +1,7 @@
\section{Introduction}
\label{s:introduction}
-This document describes a \textit{protocol} designed to manage the interaction between systems focused on the \textit{collection}, \textit{storage}, and eventual \textit{exchange} of network performance information. This protocol becomes relevant in an incarnation of a performance measurement framework; said construct consists of a set of services, each acting as an intermediate layer, between the performance measurement tools and the diagnostic or visualization applications all within a federated environment. The proposed architecture \textbf{SHOULD} make this functionality available via \textit{Web Services} (WS) and to use a service-oriented design style, implying that a set of elementary functions has been isolated and can be delivered by potentially different software entities. In this model, all services \textbf{MUST} communicate using well-defined protocols.
+This document describes a \textit{protocol} designed to manage the interaction between systems focused on the \textit{collection}, \textit{storage}, and eventual \textit{exchange} of network performance information. This protocol becomes relevant in an incarnation of a performance measurement framework; consisting of a set of services, each acting as an intermediate layer, between the performance measurement tools and the diagnostic or visualization applications all within a federated environment. The proposed architecture \textbf{SHOULD} make this functionality available via \textit{Web Services} (WS) and to use a service-oriented design style, implying that a set of elementary functions has been isolated and can be delivered by potentially different software entities. In this model, all services \textbf{MUST} communicate using well-defined protocols.
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.
Modified: messages.tex
===================================================================
--- messages.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ messages.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -3,6 +3,26 @@
As described in Section~\ref{s:motivation}, the communication protocol is simple and based on the notion of \textit{Request} and \textit{Response} messages. The construction of the \textit{message} itself takes advantage of work produced in the \textbf{NM-WG} by re-using several key constructs. Both message types are fundamentally the same: a series of \textit{metadata} and \textit{data} units linked via identifying attributes (e.g. \textit{id} and \textit{idRef} attribute values). These concepts, shown in \cite{nmwg-base,zurawski06scalable}, observe the same rules with regards to splitting both measurement and communication.
+
+
+% XXX jz - 1/13/2010
+%
+% A comment from Roman: "I think the structure of namespace could be explained"
+%
+% 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).
+%
+% 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
+%
+% Namespaces are in section 4. Regardless, we need to discuss this and provide
+% the reference somewhere before we discuss the message structure.
+
+
+
\subsection{Preliminary Example}
\label{s:preliminary_example}
@@ -77,6 +97,17 @@
The general format of a status message is as follows, parallels between the previous response as well as the request can easily be drawn.
+
+
+% XXX jz - 1/13/2010
+%
+% Comment from Roman: "example of status response in 4.1 does not explain too
+% much (looks the same as earlier response example)"
+%
+% This example should be clarified to make it different from the previous.
+
+
+
\tiny
\begin{verbatim}
<message type="response">
@@ -357,6 +388,20 @@
\paragraph{Key}
\label{s:request_message_analysis_key}
+example of status response in 4.1 does not explain too much (looks the
+> same as earlier response example)
+
+% XXX jz - 1/13/2010
+%
+% Comment from Roman: "the concept of key could be explained more (for me
+% the key represents some bigger information structure; reasons: performance,
+% simplicity)"
+%
+% I have added a comparison to a hash function (pretty much the reason for the
+% key if my memory of 5 years ago is correct) but can use more work.
+
+
+
\tiny
\begin{verbatim}
@@ -385,6 +430,8 @@
\end{table}
\label{t:request_key}
+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:
\begin{itemize}
@@ -418,7 +465,7 @@
\end{table}
\label{t:request_eventtype}
-The eventType element \textbf{SHOULD} used to describe a measurement's specific data type (e.g. closely matching the definitions from the \textbf{NM-WG}'s ``Characteristic'' document) or \textbf{MAY} be used to trigger an internal event within the service. This element contains no attributes, and \textbf{MUST} only contain text, normally in the form of a \textit{URI}. There \textbf{MAY} be \textit{many} eventType elements in a single metadata.
+The eventType element \textbf{SHOULD} used to describe a measurement's specific data type (e.g. closely matching the definitions described in \cite{chardoc} and \cite{chargrid03}) or \textbf{MAY} be used to trigger an internal event within the service. This element contains no attributes, and \textbf{MUST} only contain text, normally in the form of a \textit{URI}. There \textbf{MAY} be \textit{many} eventType elements in a single metadata.
\paragraph{Data}
\label{s:request_message_analysis_data}
@@ -515,7 +562,7 @@
\subsection{Response Message}
\label{s:response_message}
-The response message is a container filled with the results of a \textit{Request Message} from a capable service. Enclosed in this simple envelope \textbf{SHALL} be a series of metadata and data pairs containing the results of actions performed by a service. We first present a very simple schema in Section~\ref{s:response_message_schema} along with an analysis of the elements in Section~\ref{s:response_message_analysis}. We conclude with examples in Section~\ref{s:response_message_example}.
+The response message is a container filled with the results of a \textit{Response Message} from a capable service. Enclosed in this simple envelope \textbf{SHALL} be a series of metadata and data pairs containing the results of actions performed by a service. We first present a very simple schema in Section~\ref{s:response_message_schema} along with an analysis of the elements in Section~\ref{s:response_message_analysis}. We conclude with examples in Section~\ref{s:response_message_example}.
\subsubsection{Response Message Schema}
\label{s:response_message_schema}
Modified: motivation.tex
===================================================================
--- motivation.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ motivation.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -1,7 +1,7 @@
\section{Motivation}
\label{s:motivation}
-A common message exchange pattern for web services in general is a \textit{Request} followed by a \textit{Response}. This particular communication pattern is important and involves two actors for the general case. Consider the example in Figure~\ref{fig:exchange} of a \textit{client} application interacting with some \textit{measurement service} in search of data. This exchange assumes that both the client and the service speak a common dialect of communication protocol.
+A common message exchange pattern for Web Services (WS) is a \textit{Request} followed by a \textit{Response}. This particular communication pattern is important and involves two actors for the general case. Consider the example in Figure~\ref{fig:exchange} of a \textit{client} application interacting with some service, in this case a \textit{measurement service}. This exchange assumes that both the client and the service speak a common dialect of some communication protocol.
\begin{figure}[h!]
\centering
@@ -19,7 +19,7 @@
\label{fig:exchange2}
\end{figure}
-A less common 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.
+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!]
\centering
Modified: nmc-base.bib
===================================================================
--- nmc-base.bib 2010-01-12 13:16:39 UTC (rev 6)
+++ nmc-base.bib 2010-01-13 12:37:45 UTC (rev 7)
@@ -80,3 +80,19 @@
howpublished = "\url{https://wiki.man.poznan.pl/perfsonar-mdm/index.php/Result_codes}"
}
+ at TechReport{chardoc,
+ Title = "{A Hierarchy of Network Performance Characteristics for Grid Applications and Services}",
+ Author = "B. Lowekamp and B. Tierney and L. Cottrell and R. Hughes-Jones and T. Kielmann and M. Swany",
+ institution = "Global Grid Forum",
+ year = "2003", howpublished = {GWD-C},
+ type = "Community Practice",
+ month = "June"
+}
+
+ at inproceedings{chargrid03,
+ Title = "{Enabling Network Measurement Portability Through a Hierarchy of Characteristics}",
+ Author = "B. Lowekamp and B. Tierney and L. Cottrell and R. Hughes-Jones and T. Kielmann and M. Swany",
+ booktitle = {4th International Workshop on Grid Computing (Grid2003)},
+ year = "2003"
+}
+
Modified: nmc-base.pdf
===================================================================
(Binary files differ)
Modified: nmc-base.tex
===================================================================
--- nmc-base.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ nmc-base.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -68,7 +68,7 @@
\begin{minipage}[t]{2.5in}
\raggedleft
Jason Zurawski, Internet2\\
-Martin Swany, UDel\\
+Martin Swany, University of Delaware\\
\today
\end{minipage}
}
@@ -83,7 +83,7 @@
{\noindent\bf Copyright Notice} \\
-{\noindent Copyright \copyright \ Open Grid Forum (2008-2009). All Rights Reserved.}
+{\noindent Copyright \copyright \ Open Grid Forum (2008-2010). All Rights Reserved.}
\section{Abstract}
@@ -151,7 +151,7 @@
\section{Full Copyright Notice}
-Copyright \copyright \ Open Grid Forum (2008-2009). All Rights Reserved. \\
+Copyright \copyright \ Open Grid Forum (2008-2010). All Rights Reserved. \\
{\noindent This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the OGF or other organizations, except as needed for the purpose of developing Grid Recommendations in which case the procedures for copyrights defined in the OGF Document process must be followed, or as required to translate it into languages other than English.} \\
Modified: result_codes.tex
===================================================================
--- result_codes.tex 2010-01-12 13:16:39 UTC (rev 6)
+++ result_codes.tex 2010-01-13 12:37:45 UTC (rev 7)
@@ -1,8 +1,18 @@
\section{Result Codes}
\label{s:result_codes}
-There are currently two hierarchical systems that \textbf{MAY} be used to return status information about services. Each of these approaches takes into account the facts that there are many diverse services as well as different status messages that \textbf{MAY} be returned. The later system also allows for versioning and backwards compatibility that the original attempt did not consider. Either system will accomplish the goal of providing a scalable and readable result code tree. It is recommended that the latter approach be adopted as it contains superior features.
+
+% XXX jz - 1/13/2010
+%
+% Comment from Roman: "I think we have to rebuild Result Code section and finish
+% the discussion on new ideas proposed by Slawek and Jeff. That's very important
+% and must be done."
+
+
+
+There are currently two hierarchical systems that \textbf{MAY} be used to return status information about services. Each of these approaches takes into account the facts that there are many diverse services as well as different status messages that \textbf{MAY} be returned. The later system also allows for version control and backwards compatibility that the original attempt did not consider. Either system will accomplish the goal of providing a scalable and readable result code tree. It is recommended that the latter approach be adopted as it contains superior features.
+
The original idea for result codes comes from the perfSONAR\cite{perfsonar} framework and is explained in \cite{psresult}. This approach relies on a static tree of status information that is branched first by general features (i.e. success, error) and later by more specific characteristics such as service and error type. This hierarchy is missing the ability to offer versions of different codes that could become forward or backwards compatible (seen now in the \textit{eventType} system that takes the form of \textit{URI} strings).
\begin{tabular}{lll}
More information about the Nmc-wg
mailing list