perfsonar development work

[Jason Zurawski <>]

Roman;

> 1) 
> http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/store.xml 
>
>
> I think the namespace 'errors' for parameters element in metadata is 
> not needed because eventType says what parameters are expected. I 
> suggest to use 'nmwg' namespace there:
>
>    <nmwg:parameters id="p1">
>      <nmwg:parameter name="valueUnits">Eps</nmwg:parameter>
>    </nmwg:parameters>
>
>  besides valueUnits parameter is already located in the key (but I 
> assume we may have some parameters for errors)


The reasoning for allowing non nmwg namespaced parameters is to cover 
situations where we may have specific items we wish to describe.  Using 
nmwg is perfectly fine (and allowed) here as well, as it is the most 
general to handle. 


> 2) 
> http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/store.xml 
>
>
> supportedEventType parameter is not needed in the key. Data element 
> with a key refers to metadata where supportedEventType is present.


We will need to have this in the key (or perhaps just eventType) for 
situations when a metadata element describes multiple eventTypes, and 
may be used by several data blocks w/ keys.  Consider a metadata 
description  that is used for utilization, errors, and discards.  The 
corresponding RRD description may use two files (one for utilization, 
another for errors/discards):

<metadata id="1">
 <eventType>1</eventType>
 <eventType>2</eventType>
 <eventType>3</eventType>
</metadata>

<data id="d1" idRef="1">
 <key>
   <eventType>1</eventType>
 </key>
</data>

<data id="d2" idRef="1">
 <key>
   <eventType>2</eventType>
   <eventType>3</eventType>
 </key>
</data>


> 3) 
> http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/store.xml 
>
>
> This file is store file so metadata should contain this:
>
>        <nmwg:parameters>
>            <nmwg:parameter 
> name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter> 
>
>        </nmwg:parameters>
>
> instead of this:
>
>        
> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType> 


We should move away from 'supportedEventType' and start using actual 
eventTypes so we can get rid of the layer of indirection that parameters 
gives us. 


> 4) For now I suggest not to use more than one supportedEventType 
> parameters in metadata in a store file. Let's start with one such 
> parameter. Later we will add support for multiple.

This is reasonable.


> 6) 
> http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/MDKRequest2.xml 
>
>
> Parameters in the key in metadata m3 represent more than one namespace 
> so it should look like this:
>
>    <nmwg:key id="1">
>      <nmwg:parameters id="1">
>        <nmwg:parameter 
> name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter> 
>
>        <nmwg:parameter name="type">rrd</nmwg:parameter>
>        <nmwg:parameter name="valueUnits">Eps</nmwg:parameter>   
>        <nmwg:parameter 
> name="file">/home/jason/perfSONAR-PS/MP/SNMP/mead.rrd</nmwg:parameter>
>        <nmwg:parameter name="dataSource">eth0-ifInErrors</nmwg:parameter>
>      <nmwg:parameters id="2">
>      <select:parameters id="2">
>        <nmwg:parameter name="startTime" value="N-50" />
>        <nmwg:parameter name="endTime" value="N" />
>        <nmwg:parameter name="resolution" value="1" />
>        <nmwg:parameter name="consolidationFunction" value="AVERAGE" 
> />           </select:parameters>
>    </nmwg:key>
>
> This approach should be used in requests and responses.

This is too cumbersome and allowing multiple parameters blocks doesn't 
look correct in this case.  We really should use a chain to describe 
what is going on, or because the contents of the key is opaque it should 
not matter what namespace is used to describe the internals. 

-jason