perfsonar-dev - nmwg: r226 - trunk/nmwg/doc/nm-schema-base
Subject: perfsonar development work
List archive
- From:
- To: ,
- Subject: nmwg: r226 - trunk/nmwg/doc/nm-schema-base
- Date: Wed, 2 May 2007 14:25:36 -0400
Author: zurawski
Date: 2007-05-02 14:25:36 -0400 (Wed, 02 May 2007)
New Revision: 226
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/stuff.sh
Log:
Document(s) after the editing pass.
-jason
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2007-05-02 18:16:45
UTC (rev 225)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2007-05-02 18:25:36
UTC (rev 226)
@@ -1,6 +1,6 @@
-<?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="
	An Extensible Schema for Network Measurement and Performance
Data
 "/><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>
+<?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="
	An Extensible Schema for Network Measurement and Performance
Data
 "/><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(6)"/><fo:table-column
column-width="proportional-column-width(70)"/><fo:table-column
column-width="proportional-column-width(6)"/><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">
+ </fo:block></fo:table-cell><fo:table-cell text-align="end"><fo:block>May
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="proportio
nal-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">May
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
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-before="14pt" space-after="7pt"><fo:block
id="rfc.status"/>Status of this Memo</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
This memo provides information for the Grid community.
@@ -12,9 +12,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.
</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
This work is born of the need for a common mechanism for the
exchange of network measurement and performance data. In the
@@ -44,23 +44,24 @@
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.
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.3">3. Basic Elements</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.
+ 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.
</fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.3.1">3.1 Metadata</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
- 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:
</fo:block><fo:list-block
provisional-distance-between-starts="2em"><fo:list-item space-before=".25em"
space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block>
"Subject" -- The Subject identifies the entity being
measured. This could include the network path
between a
@@ -73,15 +74,14 @@
</fo:block></fo:list-item-body></fo:list-item><fo:list-item
space-before=".25em" space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block>"Parameters" -- The Parameters describe
the details of
the measurement.
</fo:block></fo:list-item-body></fo:list-item></fo:list-block><fo:block
font-weight="bold" font-size="11pt" keep-with-next="always"
space-before="11pt" space-after="3pt"
id="rfc.section.3.1.1">3.1.1 Subject</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.</fo:block><fo:block
font-weight="bold" font-size="11pt" keep-with-next="always"
space-before="11pt" space-after="3pt" id="rfc.section.3.1.2">3.1.2 Event
Type</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">The "Event Type" is the canonical
name of the aspect of the subject being measured, or the
- actual event (i.e. ``characteristic'') being
sought</fo:block><fo:block font-weight="bold" font-size="11pt"
keep-with-next="always" space-before="11pt" space-after="3pt"
id="rfc.section.3.1.3">3.1.3 Parameters</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">The "Parameters"
describe the exact
- way in which a particular measurement was gathered.
</fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.3.2">3.2 Data</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.4">4. XML Namespaces</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">We have adopted XML namespaces to vary
the schema of the
+ actual event (i.e. "characteristic") being
sought.</fo:block><fo:block font-weight="bold" font-size="11pt"
keep-with-next="always" space-before="11pt" space-after="3pt"
id="rfc.section.3.1.3">3.1.3 Parameters</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">The "Parameters"
describe the exact
+ way in which a particular measurement was gathered.
</fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.3.2">3.2 Data</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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. </fo:block><fo:block font-weight="bold"
font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always" id="rfc.section.4">4. XML
Namespaces</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">We have adopted XML namespaces to vary the schema of the
basic elements for various different types of measurements.
</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">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
@@ -93,26 +93,27 @@
namespaces end in a version number. TBD, conforming to recent
GFD on namespaces.
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.6">6. Metadata Chaining</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- 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.
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.7">7. Operation Metadata</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- 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.
</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- 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.
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.8">8. Base Schema</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
<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 189 2007-01-31 20:46:21Z boote $
+# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
# 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
@@ -187,12 +188,12 @@
# ##############################################################
-# Metadata is the 'data' that describes physical measurements.
-# Metadata can be something such as a physical address, or
-# a geographical location; any form of static, re-usable
-# designation. It is important to note that the subject
-# namespace and parameters namespace MUST match (or the parameters
-# can be a generic NMWG) or bad things will occur.
+# Metadata is the 'data' that describes physical measurements.
+# Metadata can be a physical address or a geographical location;
+# any form of static, re-usable designation. It is important to
+# note that the subject namespace and parameters namespace MUST
+# match (or the parameters can be a generic NMWG) or bad things
+# will occur.
#
# Example:
#
@@ -239,10 +240,10 @@
# ##############################################################
# Subject identifies an endPoint (or points), perhaps the name of
-# a service, or some other form of physical location. For the
-# purpose of the general case we make no assumptions on potential
-# elements and allow all elements, in any namespace. Verification
-# can be handled in subsequent schema files.
+# a service or some other form of physical location. For the
+# purpose of the general case, we make no assumptions on potential
+# elements and allow all elements, in any namespace. Verification
+# can be handled in subsequent schema files.
#
# Example:
#
@@ -270,14 +271,14 @@
# ##############################################################
-# Parameters and Parameter elements can be used in a number of
-# ways: in the message to signify items such as time stamp or
-# authorization, in metadata or data to specify filters or
-# special cases for the information. A 'parameters' block
-# has an id, and encloses one to many 'parameter' elements.
+# Parameters and Parameter elements can be used in a number of
+# ways in: 1) the message to signify items such as time stamp
+# or authorization or 2) metadata or data to specify filters or
+# special cases for the information. A 'parameters' block
+# has an id and encloses one to many 'parameter' elements.
# These elements have a required 'name', and may contain
-# an attribute, element, or text value (only one please,
-# software using this should consider complex elements, then
+# an attribute, element, or text value (only one please;
+# software using this should consider complex elements, then
# text, and finally the value attribute; exceptions should
# be thrown on duplicates).
#
@@ -343,8 +344,8 @@
# ##############################################################
-# The key is used to return a 'pointer' or otherwise special chunk
-# of identifying information in response to a request. For now
+# The key is used to return a 'pointer' or otherwise special piece
+# of identifying information in response to a request. For now,
# this information is enclosed only within a parameters block.
# The optional ID can be used to track past searches.
#
@@ -370,10 +371,10 @@
# ##############################################################
-# The data block is complex, and has the potential to contain
-# many things. The data block can be used to return a metadata
-# block from a request, commonTime or datum elements, keys,
-# or something that we have perhaps not defined as of yet.
+# The data block is complex and has the potential to contain
+# many things. The data block can be used to return a metadata
+# block from a request, commonTime or datum elements, keys,
+# or something that we have perhaps not defined as of yet.
#
# Example:
#
@@ -423,11 +424,11 @@
}
# ##############################################################
-# CommonTime is used a a shortcut able to 'factor out' a frequently
-# occurring time range that a bunch of datum (or other) elements
-# might share, thus reducing complexity of XML representation.
-# CommonTime is similar to the other NMWG time stamps (from
-# nmtime.rnc) in its potential time representations.
+# CommonTime is used as a shortcut that is able to 'factor out'
+# a frequently occurring time range that a bunch of datum (or
+# other) elements might share, thus reducing complexity of XML
+# representation. CommonTime is similar to the other NMWG time
+# stamps (from nmtime.rnc) in its potential time representations.
#
# Example:
#
@@ -470,7 +471,7 @@
# ##############################################################
-# The datum is meant to be generic in this case, because specific
+# The datum is meant to be generic in this case because specific
# namespace declarations should be used to better define what
# format that datum should have.
#
@@ -492,8 +493,8 @@
# ##############################################################
-# Common elements defined as named patterns, as they are re-used
-# several times.
+# Common elements are defined as named patterns as they are re-
+# used several times.
# ##############################################################
Identifier =
@@ -511,7 +512,7 @@
# ##############################################################
# This sequence allows any element, attribute, or text (regardless
-# of name, or namespace) into the document when invoked.
+# of name or namespace) into the document when invoked.
# ##############################################################
anyElement =
@@ -549,7 +550,6 @@
anyNMWGAttribute |
text
)*
-
</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.9">9. Time Schema</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
@@ -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 189 2007-01-31 20:46:21Z boote $
+# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
# Purpose: This describes a general time format for
# representing measurements. It is far from complete,
# and may be best represented by other methods.
@@ -573,11 +573,11 @@
# ##############################################################
-# Regular time is attached to a specific datum instance, it is
-# essentially the the same as before, but cannot have anything
-# 'inside' of it. The type can be simple like UNIX, etc. or it
-# could be something like timeRange, or timeInterval. If this is
-# the case we would then see the two extra time designators for
+# Regular time is attached to a specific datum instance; it is
+# essentially the same as before, but cannot have anything
+# 'inside' of it. The type can be simple, like UNIX, or it
+# could be something like timeRange or timeInterval. If this is
+# the case, we would then see the two extra time designators for
# the start and end (or duration)
#
# Example:
@@ -640,26 +640,28 @@
</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>
+ </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
+ 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. </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 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. </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-05-02 18:16:45
UTC (rev 225)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.html 2007-05-02 18:25:36
UTC (rev 226)
@@ -264,7 +264,7 @@
content: "RFC ";
}
@top-right {
- content: "January 2007";
+ content: "May 2007";
}
@top-center {
content: "
@@ -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"><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> <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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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-05"></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">May 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> <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, and
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 co
mmon, 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> 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> 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 observa
tion that network measurement data can be divided into two m!
ajor cla
sses. 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> 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, which is a common case for perf
ormance 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> Metadata</h2><p
id="rfc.section.3.1.p.1">The Metadata must describe the Data unambiguously.
To accomplish this, the Metadata must include three key things:</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> 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> 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> 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> Data</h2><p id="rfc.section.3.2.p.1">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.</p><hr class="noprint"><h1
id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> 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 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> 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> Metadata Chaining</h1><p
id="rfc.section.6.p.1">While a complete Metadata block can b
e used to describe, unambiguously, a data block, it is often!
desirab
le 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> 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 describe, unambiguously, 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 an operation.</p><hr class="noprint"><h1
id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a> Base
Schema</h1><p id="rfc.section.8.p.1"> <pre>
# ##############################################################
#
# File: nmbase.rnc - Main schema definition
-# Version: $Id: nmbase.rnc 189 2007-01-31 20:46:21Z boote $
+# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
# 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
@@ -372,12 +372,12 @@
# ##############################################################
-# Metadata is the 'data' that describes physical measurements.
-# Metadata can be something such as a physical address, or
-# a geographical location; any form of static, re-usable
-# designation. It is important to note that the subject
-# namespace and parameters namespace MUST match (or the parameters
-# can be a generic NMWG) or bad things will occur.
+# Metadata is the 'data' that describes physical measurements.
+# Metadata can be a physical address or a geographical location;
+# any form of static, re-usable designation. It is important to
+# note that the subject namespace and parameters namespace MUST
+# match (or the parameters can be a generic NMWG) or bad things
+# will occur.
#
# Example:
#
@@ -424,10 +424,10 @@
# ##############################################################
# Subject identifies an endPoint (or points), perhaps the name of
-# a service, or some other form of physical location. For the
-# purpose of the general case we make no assumptions on potential
-# elements and allow all elements, in any namespace. Verification
-# can be handled in subsequent schema files.
+# a service or some other form of physical location. For the
+# purpose of the general case, we make no assumptions on potential
+# elements and allow all elements, in any namespace. Verification
+# can be handled in subsequent schema files.
#
# Example:
#
@@ -455,14 +455,14 @@
# ##############################################################
-# Parameters and Parameter elements can be used in a number of
-# ways: in the message to signify items such as time stamp or
-# authorization, in metadata or data to specify filters or
-# special cases for the information. A 'parameters' block
-# has an id, and encloses one to many 'parameter' elements.
+# Parameters and Parameter elements can be used in a number of
+# ways in: 1) the message to signify items such as time stamp
+# or authorization or 2) metadata or data to specify filters or
+# special cases for the information. A 'parameters' block
+# has an id and encloses one to many 'parameter' elements.
# These elements have a required 'name', and may contain
-# an attribute, element, or text value (only one please,
-# software using this should consider complex elements, then
+# an attribute, element, or text value (only one please;
+# software using this should consider complex elements, then
# text, and finally the value attribute; exceptions should
# be thrown on duplicates).
#
@@ -528,8 +528,8 @@
# ##############################################################
-# The key is used to return a 'pointer' or otherwise special chunk
-# of identifying information in response to a request. For now
+# The key is used to return a 'pointer' or otherwise special piece
+# of identifying information in response to a request. For now,
# this information is enclosed only within a parameters block.
# The optional ID can be used to track past searches.
#
@@ -555,10 +555,10 @@
# ##############################################################
-# The data block is complex, and has the potential to contain
-# many things. The data block can be used to return a metadata
-# block from a request, commonTime or datum elements, keys,
-# or something that we have perhaps not defined as of yet.
+# The data block is complex and has the potential to contain
+# many things. The data block can be used to return a metadata
+# block from a request, commonTime or datum elements, keys,
+# or something that we have perhaps not defined as of yet.
#
# Example:
#
@@ -608,11 +608,11 @@
}
# ##############################################################
-# CommonTime is used a a shortcut able to 'factor out' a frequently
-# occurring time range that a bunch of datum (or other) elements
-# might share, thus reducing complexity of XML representation.
-# CommonTime is similar to the other NMWG time stamps (from
-# nmtime.rnc) in its potential time representations.
+# CommonTime is used as a shortcut that is able to 'factor out'
+# a frequently occurring time range that a bunch of datum (or
+# other) elements might share, thus reducing complexity of XML
+# representation. CommonTime is similar to the other NMWG time
+# stamps (from nmtime.rnc) in its potential time representations.
#
# Example:
#
@@ -655,7 +655,7 @@
# ##############################################################
-# The datum is meant to be generic in this case, because specific
+# The datum is meant to be generic in this case because specific
# namespace declarations should be used to better define what
# format that datum should have.
#
@@ -677,8 +677,8 @@
# ##############################################################
-# Common elements defined as named patterns, as they are re-used
-# several times.
+# Common elements are defined as named patterns as they are re-
+# used several times.
# ##############################################################
Identifier =
@@ -696,7 +696,7 @@
# ##############################################################
# This sequence allows any element, attribute, or text (regardless
-# of name, or namespace) into the document when invoked.
+# of name or namespace) into the document when invoked.
# ##############################################################
anyElement =
@@ -734,12 +734,11 @@
anyNMWGAttribute |
text
)*
-
</pre> </p><hr class="noprint"><h1 id="rfc.section.9"
class="np"><a href="#rfc.section.9">9.</a> Time Schema</h1><p
id="rfc.section.9.p.1"> <pre>
# ##############################################################
#
# File: nmtime.rnc - NMWG Time definitions
-# Version: $Id: nmtime.rnc 189 2007-01-31 20:46:21Z boote $
+# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
# Purpose: This describes a general time format for
# representing measurements. It is far from complete,
# and may be best represented by other methods.
@@ -755,11 +754,11 @@
# ##############################################################
-# Regular time is attached to a specific datum instance, it is
-# essentially the the same as before, but cannot have anything
-# 'inside' of it. The type can be simple like UNIX, etc. or it
-# could be something like timeRange, or timeInterval. If this is
-# the case we would then see the two extra time designators for
+# Regular time is attached to a specific datum instance; it is
+# essentially the same as before, but cannot have anything
+# 'inside' of it. The type can be simple, like UNIX, or it
+# could be something like timeRange or timeInterval. If this is
+# the case, we would then see the two extra time designators for
# the start and end (or duration)
#
# Example:
@@ -819,8 +818,8 @@
element nmtm:end {
TimeContent
}
- </pre> </p><hr class="noprint"><h1 id="rfc.section.10"
class="np"><a href="#rfc.section.10">10.</a> 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)
+ </pre> </p><hr class="noprint"><h1 id="rfc.section.10"
class="np"><a href="#rfc.section.10">10.</a> Security Concerns</h1><p
id="rfc.section.10.p.1">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.</p><p id="r
fc.section.10.p.2">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.</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
</span></address><h1><a id="rfc.copyright" href="#rfc.copyright">Full
Copyright Statement</a></h1><p>Copyright � The Open Grid Forum (2007). All
Rights Reserved.</p><p>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.</p><p>The limited
permissions granted above
are perpetual and will not be revoked by the OGF or its successors or
assignees.</p><p>This document and the information contained herein is
provided on an “As Is” basis and the OGF disclaims all
warranties, express or implied, including but not limited to any warranty
that the use of the information herein will not infringe any rights or any
implied warranties of merchantability or fitness for a particular
purpose.</p><hr class="noprint"><h1 class="np"><a id="rfc.ipr"
href="#rfc.ipr">Intellectual Property</a></h1><p>The OGF takes no position
regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any license
under such rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. Copies of claims of
rights made available for publication and any assurance
s of licenses to be made available, or the result of an atte!
mpt made
to obtain a general license or permission for the use of such proprietary
rights by implementers or users of this specification can be obtained from
the OGF Secretariat.</p><p>The OGF invites any interested party to bring to
its attention any copyrights, patents or patent applications, or other
proprietary rights, which may cover technology that may be required to
practice this recommendation. Please address the information to the OGF
Executive Director.</p></body></html>
\ No newline at end of file
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.pdf
===================================================================
(Binary files differ)
Modified: trunk/nmwg/doc/nm-schema-base/stuff.sh
===================================================================
--- trunk/nmwg/doc/nm-schema-base/stuff.sh 2007-05-02 18:16:45 UTC (rev
225)
+++ trunk/nmwg/doc/nm-schema-base/stuff.sh 2007-05-02 18:25:36 UTC (rev
226)
@@ -1,7 +1,7 @@
#!/bin/sh
HOME=`pwd`
-JAVA=java
+JAVA=/usr/lib/jvm/java-1.5.0-sun/jre/bin/java
SAXON=./saxon8.jar
FOPDIR=/usr/local/fop/build
FOP=./fop.jar
- nmwg: r226 - trunk/nmwg/doc/nm-schema-base, svnlog, 05/02/2007
Archive powered by MHonArc 2.6.16.