Subject: Re: PSAMP IANA considerations section

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Feb 2006 16:41:07 +0100

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>