perfsonar development work

Author: swany
Date: 2007-02-01 12:14:24 -0500 (Thu, 01 Feb 2007)
New Revision: 193

Modified:
   trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
   trunk/nmwg/doc/nm-schema-base/nm-schema-base.html
   trunk/nmwg/doc/nm-schema-base/nm-schema-base.pdf
   trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml
Log:
security concerns



Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo     2007-02-01 16:42:26 
UTC (rev 192)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo     2007-02-01 17:14:24 
UTC (rev 193)
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?><fo:root 
xmlns:fo="http://www.w3.org/1999/XSL/Format"; font-family="serif" 
font-size="10pt"><meta-info 
xmlns="http://www.renderx.com/XSL/Extensions";><meta-field name="title" 
value="&#xA;&#x9;An Extensible Schema for Network Measurement and Performance 
Data&#xA;  "/><meta-field name="author" 
value="Swany"/></meta-info><fo:layout-master-set><fo:simple-page-master 
master-name="first-page" margin-left="1in" margin-right="1in" 
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in" 
margin-top="1in"/><fo:region-after extent="1cm" 
region-name="footer"/></fo:simple-page-master><fo:simple-page-master 
master-name="other-pages" margin-left="1in" margin-right="1in" 
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in" 
margin-top="1in"/><fo:region-before extent="1cm" 
region-name="header"/><fo:region-after extent="1cm" 
region-name="footer"/></fo:simple-page-master><fo:simple-page-master 
master-name="other-pages-dc"
  margin-left="1in" margin-right="1in" page-height="11in" 
page-width="8.5in"><fo:region-body margin-bottom="1in" margin-top="1in" 
column-count="2"/><fo:region-before extent="1cm" 
region-name="header"/><fo:region-after extent="1cm" 
region-name="footer"/></fo:simple-page-master><fo:page-sequence-master 
master-name="sequence"><fo:single-page-master-reference 
master-reference="first-page"/><fo:repeatable-page-master-reference 
master-reference="other-pages"/></fo:page-sequence-master></fo:layout-master-set><fo:bookmark-tree><fo:bookmark
 internal-destination="rfc.status"><fo:bookmark-title>Status of this 
Memo</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.copyrightnotice"><fo:bookmark-title>Copyright 
Notice</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.1"><fo:bookmark-title>1 
Introduction</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.1.1"><fo:bookmark-title>1.1 
Goals</fo:bookmark-title></fo:bookmark></fo
 :bookmark><fo:bookmark internal-destination="rfc.section.2">!
 <fo:book
mark-title>2 Design Philosophy</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3"><fo:bookmark-title>3 Basic 
Elements</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.3.1"><fo:bookmark-title>3.1 
Metadata</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.3.1.1"><fo:bookmark-title>3.1.1 
Subject</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.2"><fo:bookmark-title>3.1.2 Event 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.3"><fo:bookmark-title>3.1.3 
Parameters</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.2"><fo:bookmark-title>3.2 
Data</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4"><fo:bookmark-title>4 XML 
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5"><fo:bookmark-title>5 
Versioning</fo:bookma
 rk-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6"><fo:bookmark-title>6 Metadata 
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.7"><fo:bookmark-title>7 Operation 
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.8"><fo:bookmark-title>8 Base 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.9"><fo:bookmark-title>9 Time 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.references"><fo:bookmark-title>10 
References</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.authors"><fo:bookmark-title>Author's 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectual Property and 
Copyright 
Statements</fo:bookmark-title></fo:bookmark></fo:bookmark-tree><fo:page-sequence
 master-reference="sequence" language="en"><fo:static-content flow-name="hea
 der"><fo:table width="100%" text-align="center" space-before!
 =".2cm" 
table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(8)"/><fo:table-column 
column-width="proportional-column-width(70)"/><fo:table-column 
column-width="proportional-column-width(8)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
 text-align="start">RFC </fo:block></fo:table-cell><fo:table-cell 
text-align="center"><fo:block>
+<?xml version="1.0" encoding="UTF-8"?><fo:root 
xmlns:fo="http://www.w3.org/1999/XSL/Format"; font-family="serif" 
font-size="10pt"><meta-info 
xmlns="http://www.renderx.com/XSL/Extensions";><meta-field name="title" 
value="&#xA;&#x9;An Extensible Schema for Network Measurement and Performance 
Data&#xA;  "/><meta-field name="author" 
value="Swany"/></meta-info><fo:layout-master-set><fo:simple-page-master 
master-name="first-page" margin-left="1in" margin-right="1in" 
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in" 
margin-top="1in"/><fo:region-after extent="1cm" 
region-name="footer"/></fo:simple-page-master><fo:simple-page-master 
master-name="other-pages" margin-left="1in" margin-right="1in" 
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in" 
margin-top="1in"/><fo:region-before extent="1cm" 
region-name="header"/><fo:region-after extent="1cm" 
region-name="footer"/></fo:simple-page-master><fo:simple-page-master 
master-name="other-pages-dc"
  margin-left="1in" margin-right="1in" page-height="11in" 
page-width="8.5in"><fo:region-body margin-bottom="1in" margin-top="1in" 
column-count="2"/><fo:region-before extent="1cm" 
region-name="header"/><fo:region-after extent="1cm" 
region-name="footer"/></fo:simple-page-master><fo:page-sequence-master 
master-name="sequence"><fo:single-page-master-reference 
master-reference="first-page"/><fo:repeatable-page-master-reference 
master-reference="other-pages"/></fo:page-sequence-master></fo:layout-master-set><fo:bookmark-tree><fo:bookmark
 internal-destination="rfc.status"><fo:bookmark-title>Status of this 
Memo</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.copyrightnotice"><fo:bookmark-title>Copyright 
Notice</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.1"><fo:bookmark-title>1 
Introduction</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.1.1"><fo:bookmark-title>1.1 
Goals</fo:bookmark-title></fo:bookmark></fo
 :bookmark><fo:bookmark internal-destination="rfc.section.2">!
 <fo:book
mark-title>2 Design Philosophy</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3"><fo:bookmark-title>3 Basic 
Elements</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.3.1"><fo:bookmark-title>3.1 
Metadata</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.3.1.1"><fo:bookmark-title>3.1.1 
Subject</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.2"><fo:bookmark-title>3.1.2 Event 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.3"><fo:bookmark-title>3.1.3 
Parameters</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.2"><fo:bookmark-title>3.2 
Data</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4"><fo:bookmark-title>4 XML 
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5"><fo:bookmark-title>5 
Versioning</fo:bookma
 rk-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6"><fo:bookmark-title>6 Metadata 
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.7"><fo:bookmark-title>7 Operation 
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.8"><fo:bookmark-title>8 Base 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.9"><fo:bookmark-title>9 Time 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.10"><fo:bookmark-title>10 Security 
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.references"><fo:bookmark-title>11 
References</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.authors"><fo:bookmark-title>Author's 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectual Property and 
Copyright Statements</fo:bookmark-title></
 fo:bookmark></fo:bookmark-tree><fo:page-sequence master-refe!
 rence="s
equence" language="en"><fo:static-content flow-name="header"><fo:table 
width="100%" text-align="center" space-before=".2cm" 
table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(8)"/><fo:table-column 
column-width="proportional-column-width(70)"/><fo:table-column 
column-width="proportional-column-width(8)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
 text-align="start">RFC </fo:block></fo:table-cell><fo:table-cell 
text-align="center"><fo:block>
        An Extensible Schema for Network Measurement and Performance Data
   </fo:block></fo:table-cell><fo:table-cell 
text-align="end"><fo:block>January 
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:static-content
 flow-name="footer"><fo:table text-align="center" width="100%" 
table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(7.5)"/><fo:table-column 
column-width="proportional-column-width(13)"/><fo:table-column 
column-width="proportional-column-width(7.5)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
 text-align="start">Swany</fo:block></fo:table-cell><fo:table-cell><fo:block 
text-align="center">Informational</fo:block></fo:table-cell><fo:table-cell><fo:block
 text-align="end">[Page 
<fo:page-number/>]</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:flow
 flow-name="xsl-region-body"><fo:table width="100%" 
table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(1)"/><fo:table-column 
column-width="propo
 
rtional-column-width(1)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block>Network
 Measurement Working Group</fo:block></fo:table-cell><fo:table-cell><fo:block 
text-align="right">M Swany, 
Editor</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block/></fo:table-cell><fo:table-cell><fo:block
 
text-align="right">UDel</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block>Intended
 status: Informational</fo:block></fo:table-cell><fo:table-cell><fo:block 
text-align="right">January 
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table><fo:block
 text-align="center" font-weight="bold" font-size="18pt" space-before="3em" 
space-after="3em">
        An Extensible Schema for Network Measurement and Performance Data
@@ -112,7 +112,7 @@
          <fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
 # 
 # File:         nmbase.rnc - Main schema definition
-# Version:      $Id: nmbase.rnc 185 2007-01-31 17:28:49Z boote $
+# Version:      $Id: nmbase.rnc 189 2007-01-31 20:46:21Z boote $
 # Purpose:      This is the main relax schema file, it defines 
 #               the general makeup of an NMWG structured message.
 # Reference:    http://books.xmlschemata.org/relaxng/page2.html
@@ -557,7 +557,7 @@
          <fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
 # 
 # File:         nmtime.rnc - NMWG Time definitions
-# Version:      $Id: nmtime.rnc 185 2007-01-31 17:28:49Z boote $
+# Version:      $Id: nmtime.rnc 189 2007-01-31 20:46:21Z boote $
 # Purpose:      This describes a general time format for 
 #               representing measurements.  It is far from complete, 
 #               and may be best represented by other methods.
@@ -640,7 +640,26 @@
            </fo:block>
 
 
-       </fo:block><fo:block font-weight="bold" font-size="14pt" 
keep-with-next="always" space-after="7pt" page-break-before="always" 
id="rfc.authors">Author's Address</fo:block><fo:block 
space-before="1em"><fo:wrapper font-weight="bold">Martin 
Swany</fo:wrapper><fo:wrapper> (editor)</fo:wrapper></fo:block><fo:block>
+       </fo:block><fo:block font-weight="bold" font-size="14pt" 
keep-with-next="always" space-after="7pt" page-break-before="always" 
id="rfc.section.10">10.  Security Concerns</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">There are important 
security concerns
+         associated with the making and distribution of network measurement
+         information.  For example, ISPs frequently consider network
+         configuration and performance information to be proprietary.
+         Furthermore, observing traffic, and in particular collecting packet
+         headers, is frequently considered a violation of the presumption of
+         privacy on the network.  Systems that collect the measurements
+         described here are sometimes regarded as invasive, and indeed poorly
+         designed or configured monitoring tools can consume a 
disproportionate
+         amount of network bandwidth.  Port blocking, protocol blocking, and
+         traffic shaping can impact many measurement tools.  Tools, such as
+         traceroute, that send UDP probes to increasing port numbers can 
appear
+         to be port scans and raise security alerts.</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">We do not address 
those concerns in this document, but implementers
+         are encouraged to consider the security implications of making and
+         distributing measurement information.  While distribution of
+         end-to-end application-level measurements is generally accepted,
+         measurements that identify individual users or consume noticeable
+         amounts of resources should be taken carefully, and the distribution
+         of information to other sites that cannot be obtained readily by 
other
+         users at those sites should be considered 
carefully.</fo:block><fo:block font-weight="bold" font-size="14pt" 
keep-with-next="always" space-after="7pt" page-break-before="always" 
id="rfc.authors">Author's Address</fo:block><fo:block 
space-before="1em"><fo:wrapper font-weight="bold">Martin 
Swany</fo:wrapper><fo:wrapper> (editor)</fo:wrapper></fo:block><fo:block>
       University of Delaware
     </fo:block><fo:block font-weight="bold" font-size="14pt" 
keep-with-next="always" space-before="14pt" space-after="7pt"><fo:block 
id="rfc.copyright"/>Full Copyright Statement</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
           Copyright © The Open Grid Forum (2007). All Rights Reserved.

Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.html
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.html   2007-02-01 16:42:26 
UTC (rev 192)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.html   2007-02-01 17:14:24 
UTC (rev 193)
@@ -293,11 +293,11 @@
       content: normal;
     }
 }
-</style><link rel="Author" href="#rfc.authors"><link rel="Copyright" 
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction" 
href="#rfc.section.1"><link rel="Chapter" title="2 Design Philosophy" 
href="#rfc.section.2"><link rel="Chapter" title="3 Basic Elements" 
href="#rfc.section.3"><link rel="Chapter" title="4 XML Namespaces" 
href="#rfc.section.4"><link rel="Chapter" title="5 Versioning" 
href="#rfc.section.5"><link rel="Chapter" title="6 Metadata Chaining" 
href="#rfc.section.6"><link rel="Chapter" title="7 Operation Metadata" 
href="#rfc.section.7"><link rel="Chapter" title="8 Base Schema" 
href="#rfc.section.8"><link rel="Chapter" title="9 Time Schema" 
href="#rfc.section.9"><meta name="generator" 
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291, 
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica 
http://www.saxonica.com/";><link rel="schema.DC" 
href="http://purl.org/dc/elements/1.1/";><meta name="DC.Creator" 
content="Swany, M"><meta name="D
 C.Date.Issued" scheme="ISO8601" content="2007-01"></head><body><table 
summary="header information" class="header" border="0" cellpadding="1" 
cellspacing="1"><tr><td class="front left">Network Measurement Working 
Group</td><td class="front right">M Swany, Editor</td></tr><tr><td 
class="front left"></td><td class="front right">UDel</td></tr><tr><td 
class="front left">Intended status: Informational</td><td class="front 
right">January 2007</td></tr></table><p class="title">An Extensible Schema 
for Network Measurement and Performance Data</p><h1><a id="rfc.status" 
href="#rfc.status">Status of this Memo</a></h1><p>This memo provides 
information for the Grid community. It does not specify any standards or 
technical recommendations. Distribution is unlimited.</p><h1><a 
id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright 
Notice</a></h1><p>Copyright � The Open Grid Forum (2007). All Rights 
Reserved.</p><hr class="noprint"><h1 id="rfc.section.1" class="np"><a 
href="#rfc.sect
 ion.1">1.</a>&nbsp;<a id="intro" href="#intro">Introduction<!
 /a></h1>
<p id="rfc.section.1.p.1">This document presents an extensible encoding 
standard for network measurement and performance data. Uniform encoding of 
this class of information is a key problem for federated network management, 
multi-domain dynamic provisioning of network circuits as well as in advanced 
distributed computing environments such as Grid computing.</p><p 
id="rfc.section.1.p.2">This work is born of the need for a common mechanism 
for the exchange of network measurement and performance data. In the case of 
research-oriented networks, parties often want to exchange network 
performance data with neighbors for debugging purposes. In general, however, 
there is no single system that is in use. In the Grid community, the need to 
exchange network metrics of various sorts is often highlighted. In short it 
is highly desirable to have an extensible schema for network performance 
information that gives a common, general framework for representation and 
exchange.</p><p id="rfc.sec
 tion.1.p.3">This document builds on previous versions of the network 
measurement schemata. This document describes Version 2 of the Grid Forum's 
Network Measurement Working Group (NM-WG) schema.</p><h2 
id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Goals</h2><p 
id="rfc.section.1.1.p.1">The goal is to define a neutral representation for 
network measurements that can be easily extended to support new types of 
data. This representation should identify forms of network performance data 
as well as to create standardized mechanism to both describe and publish 
these metrics.</p><hr class="noprint"><h1 id="rfc.section.2" class="np"><a 
href="#rfc.section.2">2.</a>&nbsp;Design Philosophy</h1><p 
id="rfc.section.2.p.1">One of the high-level goals of this representation is 
to "normalize" the data representation by removing as much redundancy as 
possible. The basic schema design is based on the observation that network 
measurement data can be divided into two major classes. 
 The first class is the Metadata, which describes the type of!
  measure
ment data, the entity or entities being measured and the particular 
parameters of the measurement. The second class is the data itself, which is 
at its simplest a timestamp and a value, or vector of values. This division 
of Metadata and Data is present throughout the system. This structure is 
present both in the "Messages" sent between various data elements, and in 
data "Stores" - persistent storage of XML documents representing system 
state.</p><hr class="noprint"><h1 id="rfc.section.3" class="np"><a 
href="#rfc.section.3">3.</a>&nbsp;Basic Elements</h1><p 
id="rfc.section.3.p.1">This schema defines the basic elements that can be 
used to represent performance data. The first distinction is between the 
"Metadata", the relatively static information regarding the data, and the 
"Data" itself, which generally changes over time. The key idea is that for 
repeated measurements, a common case for performance data in networks and 
Grids, the Metadata need not be passed repeatedly, saving
  space and effort.</p><h2 id="rfc.section.3.1"><a 
href="#rfc.section.3.1">3.1</a>&nbsp;Metadata</h2><p 
id="rfc.section.3.1.p.1">The Metadata must describe the Data unambiguously. 
In order to accomplish this, the Metadata must include three key things. They 
are:</p><dl class="empty"><dd>"Subject" -- The Subject identifies the entity 
being measured. This could include the network path between a pair of hosts, 
an interface on a router, or a specific location on the network from which 
flow or packet data is captured.</dd><dd>"EventType" -- The EventType 
identifies exactly what sort of measurement Event 
occurred.</dd><dd>"Parameters" -- The Parameters describe the details of the 
measurement.</dd></dl><h3 id="rfc.section.3.1.1"><a 
href="#rfc.section.3.1.1">3.1.1</a>&nbsp;Subject</h3><p 
id="rfc.section.3.1.1.p.1">The "Subject" identifies the measured entity. For 
networks this may represent a path between two hosts or an interface on a 
network device.</p><h3 id="rfc.section.3.1.2"><
 a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;Event Type</h3><p!
  id="rfc
.section.3.1.2.p.1">The "Event Type" is the canonical name of the aspect of 
the subject being measured, or the actual event (i.e. ``characteristic'') 
being sought</p><h3 id="rfc.section.3.1.3"><a 
href="#rfc.section.3.1.3">3.1.3</a>&nbsp;Parameters</h3><p 
id="rfc.section.3.1.3.p.1">The "Parameters" describe the exact way in which a 
particular measurement was gathered.</p><h2 id="rfc.section.3.2"><a 
href="#rfc.section.3.2">3.2</a>&nbsp;Data</h2><p id="rfc.section.3.2.p.1">The 
"Data" element refers to the "Metadata" which describes it. It contains some 
number of "Datum" elements, which hold the actual timestamp and value of the 
measurement, or value of the event.</p><hr class="noprint"><h1 
id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;XML 
Namespaces</h1><p id="rfc.section.4.p.1">We have adopted XML namespaces to 
vary the schema of the basic elements for various different types of 
measurements.</p><p id="rfc.section.4.p.2">We envision there being two major 
cl
 asses of namespace URIs. The first is a canonical name based on the 
Hierarchy of Network Measurements (cite). The second is based on an 
organization's domain name and allows for autonomous extension.</p><hr 
class="noprint"><h1 id="rfc.section.5" class="np"><a 
href="#rfc.section.5">5.</a>&nbsp;Versioning</h1><p 
id="rfc.section.5.p.1">While the working group has made every effort to 
completely describe a few measurement types, we are well aware that tools, 
and ideas about how to represent them, may change. For this reason, each of 
the schema areas must have a version number.</p><p id="rfc.section.5.p.2">To 
accomplish this, each of the URIs that comprise the namespaces end in a 
version number. TBD, conforming to recent GFD on namespaces.</p><hr 
class="noprint"><h1 id="rfc.section.6" class="np"><a 
href="#rfc.section.6">6.</a>&nbsp;Metadata Chaining</h1><p 
id="rfc.section.6.p.1">While a complete Metadata block can be used to 
unambiguously describe a data block, it is often desira
 ble to combine multiple partial Metadata blocks together. Th!
 e main r
eason for this is reuse of information. Using the "metadataIdRef" attribute 
of a Metadata block allows us to form a "chain" of Metadata blocks.</p><hr 
class="noprint"><h1 id="rfc.section.7" class="np"><a 
href="#rfc.section.7">7.</a>&nbsp;Operation Metadata</h1><p 
id="rfc.section.7.p.1">In addition to describing sets of raw data, Metadata 
blocks can also be used to describe transformations performed on a dataset. 
Thus a list of Metadata blocks, including origin and transformations, can be 
used to unambiguously describe the provenance of any network data.</p><p 
id="rfc.section.7.p.2">This relationship between Metadata blocks is expressed 
by having the Subject metadataIdRef refer to another Metadata, which denotes 
having it be input to a operation.</p><hr class="noprint"><h1 
id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a>&nbsp;Base 
Schema</h1><p id="rfc.section.8.p.1"> <pre>
+</style><link rel="Author" href="#rfc.authors"><link rel="Copyright" 
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction" 
href="#rfc.section.1"><link rel="Chapter" title="2 Design Philosophy" 
href="#rfc.section.2"><link rel="Chapter" title="3 Basic Elements" 
href="#rfc.section.3"><link rel="Chapter" title="4 XML Namespaces" 
href="#rfc.section.4"><link rel="Chapter" title="5 Versioning" 
href="#rfc.section.5"><link rel="Chapter" title="6 Metadata Chaining" 
href="#rfc.section.6"><link rel="Chapter" title="7 Operation Metadata" 
href="#rfc.section.7"><link rel="Chapter" title="8 Base Schema" 
href="#rfc.section.8"><link rel="Chapter" title="9 Time Schema" 
href="#rfc.section.9"><link rel="Chapter" title="10 Security Concerns" 
href="#rfc.section.10"><meta name="generator" 
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291, 
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica 
http://www.saxonica.com/";><link rel="schema.DC" href="http://purl.org/dc
 /elements/1.1/"><meta name="DC.Creator" content="Swany, M"><meta 
name="DC.Date.Issued" scheme="ISO8601" content="2007-01"></head><body><table 
summary="header information" class="header" border="0" cellpadding="1" 
cellspacing="1"><tr><td class="front left">Network Measurement Working 
Group</td><td class="front right">M Swany, Editor</td></tr><tr><td 
class="front left"></td><td class="front right">UDel</td></tr><tr><td 
class="front left">Intended status: Informational</td><td class="front 
right">January 2007</td></tr></table><p class="title">An Extensible Schema 
for Network Measurement and Performance Data</p><h1><a id="rfc.status" 
href="#rfc.status">Status of this Memo</a></h1><p>This memo provides 
information for the Grid community. It does not specify any standards or 
technical recommendations. Distribution is unlimited.</p><h1><a 
id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright 
Notice</a></h1><p>Copyright � The Open Grid Forum (2007). All Rights 
Reserved.</p>
 <hr class="noprint"><h1 id="rfc.section.1" class="np"><a hre!
 f="#rfc.
section.1">1.</a>&nbsp;<a id="intro" href="#intro">Introduction</a></h1><p 
id="rfc.section.1.p.1">This document presents an extensible encoding standard 
for network measurement and performance data. Uniform encoding of this class 
of information is a key problem for federated network management, 
multi-domain dynamic provisioning of network circuits as well as in advanced 
distributed computing environments such as Grid computing.</p><p 
id="rfc.section.1.p.2">This work is born of the need for a common mechanism 
for the exchange of network measurement and performance data. In the case of 
research-oriented networks, parties often want to exchange network 
performance data with neighbors for debugging purposes. In general, however, 
there is no single system that is in use. In the Grid community, the need to 
exchange network metrics of various sorts is often highlighted. In short it 
is highly desirable to have an extensible schema for network performance 
information that gives a comm
 on, general framework for representation and exchange.</p><p 
id="rfc.section.1.p.3">This document builds on previous versions of the 
network measurement schemata. This document describes Version 2 of the Grid 
Forum's Network Measurement Working Group (NM-WG) schema.</p><h2 
id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Goals</h2><p 
id="rfc.section.1.1.p.1">The goal is to define a neutral representation for 
network measurements that can be easily extended to support new types of 
data. This representation should identify forms of network performance data 
as well as to create standardized mechanism to both describe and publish 
these metrics.</p><hr class="noprint"><h1 id="rfc.section.2" class="np"><a 
href="#rfc.section.2">2.</a>&nbsp;Design Philosophy</h1><p 
id="rfc.section.2.p.1">One of the high-level goals of this representation is 
to "normalize" the data representation by removing as much redundancy as 
possible. The basic schema design is based on the observati
 on that network measurement data can be divided into two maj!
 or class
es. The first class is the Metadata, which describes the type of measurement 
data, the entity or entities being measured and the particular parameters of 
the measurement. The second class is the data itself, which is at its 
simplest a timestamp and a value, or vector of values. This division of 
Metadata and Data is present throughout the system. This structure is present 
both in the "Messages" sent between various data elements, and in data 
"Stores" - persistent storage of XML documents representing system 
state.</p><hr class="noprint"><h1 id="rfc.section.3" class="np"><a 
href="#rfc.section.3">3.</a>&nbsp;Basic Elements</h1><p 
id="rfc.section.3.p.1">This schema defines the basic elements that can be 
used to represent performance data. The first distinction is between the 
"Metadata", the relatively static information regarding the data, and the 
"Data" itself, which generally changes over time. The key idea is that for 
repeated measurements, a common case for performance data i
 n networks and Grids, the Metadata need not be passed repeatedly, saving 
space and effort.</p><h2 id="rfc.section.3.1"><a 
href="#rfc.section.3.1">3.1</a>&nbsp;Metadata</h2><p 
id="rfc.section.3.1.p.1">The Metadata must describe the Data unambiguously. 
In order to accomplish this, the Metadata must include three key things. They 
are:</p><dl class="empty"><dd>"Subject" -- The Subject identifies the entity 
being measured. This could include the network path between a pair of hosts, 
an interface on a router, or a specific location on the network from which 
flow or packet data is captured.</dd><dd>"EventType" -- The EventType 
identifies exactly what sort of measurement Event 
occurred.</dd><dd>"Parameters" -- The Parameters describe the details of the 
measurement.</dd></dl><h3 id="rfc.section.3.1.1"><a 
href="#rfc.section.3.1.1">3.1.1</a>&nbsp;Subject</h3><p 
id="rfc.section.3.1.1.p.1">The "Subject" identifies the measured entity. For 
networks this may represent a path between two ho
 sts or an interface on a network device.</p><h3 id="rfc.sect!
 ion.3.1.
2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;Event Type</h3><p 
id="rfc.section.3.1.2.p.1">The "Event Type" is the canonical name of the 
aspect of the subject being measured, or the actual event (i.e. 
``characteristic'') being sought</p><h3 id="rfc.section.3.1.3"><a 
href="#rfc.section.3.1.3">3.1.3</a>&nbsp;Parameters</h3><p 
id="rfc.section.3.1.3.p.1">The "Parameters" describe the exact way in which a 
particular measurement was gathered.</p><h2 id="rfc.section.3.2"><a 
href="#rfc.section.3.2">3.2</a>&nbsp;Data</h2><p id="rfc.section.3.2.p.1">The 
"Data" element refers to the "Metadata" which describes it. It contains some 
number of "Datum" elements, which hold the actual timestamp and value of the 
measurement, or value of the event.</p><hr class="noprint"><h1 
id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;XML 
Namespaces</h1><p id="rfc.section.4.p.1">We have adopted XML namespaces to 
vary the schema of the basic elements for various different types of measure
 ments.</p><p id="rfc.section.4.p.2">We envision there being two major 
classes of namespace URIs. The first is a canonical name based on the 
Hierarchy of Network Measurements (cite). The second is based on an 
organization's domain name and allows for autonomous extension.</p><hr 
class="noprint"><h1 id="rfc.section.5" class="np"><a 
href="#rfc.section.5">5.</a>&nbsp;Versioning</h1><p 
id="rfc.section.5.p.1">While the working group has made every effort to 
completely describe a few measurement types, we are well aware that tools, 
and ideas about how to represent them, may change. For this reason, each of 
the schema areas must have a version number.</p><p id="rfc.section.5.p.2">To 
accomplish this, each of the URIs that comprise the namespaces end in a 
version number. TBD, conforming to recent GFD on namespaces.</p><hr 
class="noprint"><h1 id="rfc.section.6" class="np"><a 
href="#rfc.section.6">6.</a>&nbsp;Metadata Chaining</h1><p 
id="rfc.section.6.p.1">While a complete Metadata bloc
 k can be used to unambiguously describe a data block, it is !
 often de
sirable to combine multiple partial Metadata blocks together. The main reason 
for this is reuse of information. Using the "metadataIdRef" attribute of a 
Metadata block allows us to form a "chain" of Metadata blocks.</p><hr 
class="noprint"><h1 id="rfc.section.7" class="np"><a 
href="#rfc.section.7">7.</a>&nbsp;Operation Metadata</h1><p 
id="rfc.section.7.p.1">In addition to describing sets of raw data, Metadata 
blocks can also be used to describe transformations performed on a dataset. 
Thus a list of Metadata blocks, including origin and transformations, can be 
used to unambiguously describe the provenance of any network data.</p><p 
id="rfc.section.7.p.2">This relationship between Metadata blocks is expressed 
by having the Subject metadataIdRef refer to another Metadata, which denotes 
having it be input to a operation.</p><hr class="noprint"><h1 
id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a>&nbsp;Base 
Schema</h1><p id="rfc.section.8.p.1"> <pre>
 # ##############################################################
 # 
 # File:         nmbase.rnc - Main schema definition
-# Version:      $Id: nmbase.rnc 185 2007-01-31 17:28:49Z boote $
+# Version:      $Id: nmbase.rnc 189 2007-01-31 20:46:21Z boote $
 # Purpose:      This is the main relax schema file, it defines 
 #               the general makeup of an NMWG structured message.
 # Reference:    http://books.xmlschemata.org/relaxng/page2.html
@@ -739,7 +739,7 @@
 # ##############################################################
 # 
 # File:         nmtime.rnc - NMWG Time definitions
-# Version:      $Id: nmtime.rnc 185 2007-01-31 17:28:49Z boote $
+# Version:      $Id: nmtime.rnc 189 2007-01-31 20:46:21Z boote $
 # Purpose:      This describes a general time format for 
 #               representing measurements.  It is far from complete, 
 #               and may be best represented by other methods.
@@ -819,7 +819,7 @@
         element nmtm:end {
                 TimeContent
         }
-           </pre> </p><hr class="noprint"><h1 id="rfc.authors" 
class="np">Author's Address</h1><address class="vcard"><span 
class="vcardline"><span class="fn">Martin Swany</span>
+           </pre> </p><hr class="noprint"><h1 id="rfc.section.10" 
class="np"><a href="#rfc.section.10">10.</a>&nbsp;Security Concerns</h1><p 
id="rfc.section.10.p.1">There are important security concerns associated with 
the making and distribution of network measurement information. For example, 
ISPs frequently consider network configuration and performance information to 
be proprietary. Furthermore, observing traffic, and in particular collecting 
packet headers, is frequently considered a violation of the presumption of 
privacy on the network. Systems that collect the measurements described here 
are sometimes regarded as invasive, and indeed poorly designed or configured 
monitoring tools can consume a disproportionate amount of network bandwidth. 
Port blocking, protocol blocking, and traffic shaping can impact many 
measurement tools. Tools, such as traceroute, that send UDP probes to 
increasing port numbers can appear to be port scans and raise security 
alerts.</p><p id="rfc.secti
 on.10.p.2">We do not address those concerns in this document, but 
implementers are encouraged to consider the security implications of making 
and distributing measurement information. While distribution of end-to-end 
application-level measurements is generally accepted, measurements that 
identify individual users or consume noticeable amounts of resources should 
be taken carefully, and the distribution of information to other sites that 
cannot be obtained readily by other users at those sites should be considered 
carefully.</p><hr class="noprint"><h1 id="rfc.authors" class="np">Author's 
Address</h1><address class="vcard"><span class="vcardline"><span 
class="fn">Martin Swany</span>
           (editor)
         <span class="n hidden"><span class="family-name">Swany</span><span 
class="given-name">Martin</span></span></span><span class="org vcardline">
       University of Delaware

Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.pdf
===================================================================
(Binary files differ)

Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml    2007-02-01 16:42:26 
UTC (rev 192)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml    2007-02-01 17:14:24 
UTC (rev 193)
@@ -244,7 +244,33 @@
   </section>
 
 
-  
+  <section title="Security Concerns">
+       
+       <t>There are important security concerns
+         associated with the making and distribution of network measurement
+         information.  For example, ISPs frequently consider network
+         configuration and performance information to be proprietary.
+         Furthermore, observing traffic, and in particular collecting packet
+         headers, is frequently considered a violation of the presumption of
+         privacy on the network.  Systems that collect the measurements
+         described here are sometimes regarded as invasive, and indeed poorly
+         designed or configured monitoring tools can consume a 
disproportionate
+         amount of network bandwidth.  Port blocking, protocol blocking, and
+         traffic shaping can impact many measurement tools.  Tools, such as
+         traceroute, that send UDP probes to increasing port numbers can 
appear
+         to be port scans and raise security alerts.</t>
+ 
+       <t>We do not address those concerns in this document, but implementers
+         are encouraged to consider the security implications of making and
+         distributing measurement information.  While distribution of
+         end-to-end application-level measurements is generally accepted,
+         measurements that identify individual users or consume noticeable
+         amounts of resources should be taken carefully, and the distribution
+         of information to other sites that cannot be obtained readily by 
other
+         users at those sites should be considered carefully.</t>
+
+
+  </section>
          
          
 </middle>