Re: PSAMP IANA considerations section

[Benoit Claise <bclaise@cisco.com>]

Juergen,

This open issue should find a solution for the next version of the 
draft, to be published by Monday.
See inline.
> --On 21.12.2005 11:14 Uhr +0100 Benoit Claise wrote:
>
> > Dear all,
> >
> > Here is a proposal for the IANA considerations section.
> >
> >
> > 1. 9. IANA Considerations
> >
> > The PSAMP Protocol, as set out in this document, has two sets of 
> > assigned numbers.  Considerations for assigning them are discussed in 
> > this section, using the example policies as set out in the 
> > "Guidelines for IANA Considerations" document IANA-RFC
> > [RFC2434].
> >
> >      9.1 IPFIX Related Considerations
> >
> > As the PSAMP protocol uses the IPFIX protocol, refer to the IANA 
> > considerations section in [IPFIX-PROTO] for the assignments of 
> > numbers used in the protocol and for the numbers used in the 
> > information model.
> >
> >       9.2 PSAMP Related Considerations
> >
> > Each new selection method MUST be assigned a unique value for the 
> > selectorAlgorithm Information Element.  Its configuration 
> > parameter(s), along with the way to report it/them with an Options 
> > Template, MUST be clearly specified.
> >
> > Each new selection method MUST be assigned a unique value for the 
> > selectorAlgorithm Information Element.  New assignments for the PSAMP 
> > selection method will be administered by IANA, on a First Come First 
> > Served basis [RFC 2434], subject to Expert
> > Review [RFC 2434], i.e. review by one of a group of experts 
> > designated by an IETF Operations and Management Area Director.  The 
> > group of experts must double check the Information Elements 
> > definitions with already defined Information Elements for
> > completeness, accuracy and redundancy.  Those experts will initially 
> > be drawn from the Working Group Chairs and document editors of the 
> > IPFIX and PSAMP Working Groups.
> >
> > Now, two questions:
> > 1. I'm not too sure whether we should mandate a new IETF RFC for the 
> > new selection method description?
>
> This would be a tough requirement.  However, it would make sure that the
> new methods is well documented.
So the text proposal is fine with you, right?
> > 2. I'm not too sure whether we should mandate new IANA-registered 
> > information elements for the new selection method?
>
> Since we do not have vendor IDs in here, this is the only way of 
> achieving
> interoperability.
I had in mind that the selectorAlgorithm could be specified with the 
Entreprise Number, for proprietary purposes

      0                   1                   2                   3  
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |E|  Information Element ident. |        Field Length           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                      Enterprise Number                        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
     
         Figure G: Field Specifier format 


> >     In other words, can we have proprietary selection method in the 
> > selectorAlgorithm Information Element?
>
> Can't we assign an interval, say [1024 - ...] and declare selection 
> methods
> with identifiers in that interval as 'experimental' or even 
> 'implementation specific'?
Do we need this if we use a I.E. proprietary definition with the 
Entreprise Number?

Don't forget that the selectorAlgorithm is specified as an octet.

Regards, Benoit.
> > Regards, Benoit.


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>