perfsonar development work

Author: zurawski
Date: 2007-05-02 14:16:15 -0400 (Wed, 02 May 2007)
New Revision: 224

Modified:
   trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml
Log:
Update after Editing pass.

-jason



Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml    2007-04-26 14:12:07 
UTC (rev 223)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml    2007-05-02 18:16:15 
UTC (rev 224)
@@ -19,12 +19,12 @@
   </title>
   <author initials='M' surname='Swany'
           fullname='Martin Swany'
-                 role='editor'>
+                 role='Editor'>
        <organization abbrev='UDel'>
       University of Delaware
     </organization>
   </author>
-  <date month="January" year="2007"/>
+  <date month="May" year="2007"/>
 </front>  
 
 <middle>
@@ -34,9 +34,9 @@
         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.
+     management, and multi-domain dynamic provisioning of network
+     circuits, as well as in advanced distributed computing
+     environments, such as Grid computing.
    </t>
 
     <t>
@@ -82,11 +82,11 @@
          two major classes.  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
+         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
+         between various data elements and in data "Stores" -- persistent
          storage of XML documents representing system state.
        </t>
 
@@ -99,16 +99,17 @@
       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.
+      time. The key idea is that, for repeated measurements, 
+      which is a common case for performance data in networks and 
+      Grids, the Metadata need not be passed repeatedly, saving 
+      space and effort.
        </t>
 
     <section id="metadata" title="Metadata">
       <t>
-               The Metadata must describe the Data unambiguously. In order to
+               The Metadata must describe the Data unambiguously. To
         accomplish this, the Metadata must include three key
-        things. They are:
+        things:
          </t>
 
       <list>
@@ -131,14 +132,14 @@
 
       <section id="subject" title="Subject">
         <t>The "Subject" identifies the measured
-          entity. For networks this may represent a path between two
+          entity. For networks, this may represent a path between two
           hosts or an interface on a network device.</t>
       </section>
 
       <section id="eventtype" title="Event Type">
         <t>The "Event Type" is the canonical
           name of the aspect of the subject being measured, or the
-          actual event (i.e. ``characteristic'') being sought</t>
+          actual event (i.e. "characteristic") being sought.</t>
       </section>
 
       <section id="parameters" title="Parameters">
@@ -149,11 +150,10 @@
     </section>
 
     <section id="data" title="Data">
-      <t>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.</t>
+      <t>The "Data" element refers to the "Metadata" that describes 
+         it. It contains some number of "Datum" elements, which hold 
+         the actual timestamp and value of the measurement or value 
+         of the event. </t>
     </section>
   </section>
 
@@ -185,27 +185,28 @@
   <section id="metadata_chaining" title="Metadata Chaining">
 
     <t>
-         While a complete Metadata block can be used to unambiguously
-      describe a data block, it is often desirable 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.
+    While a complete Metadata block can be used to describe, 
+    unambiguously, a data block, it is often desirable 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. 
        </t>
   </section>
 
   <section id="operation_metadata" title="Operation Metadata">
     <t>
-         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.
+         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 describe, unambiguously, 
+         the provenance of any network data. 
        </t>
 
        <t>
-         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.
+     This relationship between Metadata blocks is expressed by 
+     having the Subject metadataIdRef refer to another Metadata, 
+     which denotes having it be input to an operation. 
        </t>
   </section>
 
@@ -246,28 +247,30 @@
 
   <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>There are important security concerns associated with the 
+       generation 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>
+       <t>We do not address those concerns in this document, but 
+       implementers are encouraged to consider the security implications 
+       of generating 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>