Re: IANA document allocation

[Luca Martini <[e-mail]>]

Thomas,

I think that the private use terminology is better , and I will change 
the "vendor specific" range to "private use".
I do like the expert allocation method, but to support some of the 
objections made here, I think it should be a "light" expert review.
I would put forward that the expert should be required to present strong 
proof why a particular value should not be allocated.
For values allocated in the data plane ( like for the CW ) I think we 
should probably only have a "IETF consensus" section. The potential for 
abuse in this area is significant.
However, things like error status codes are probably ok with a FCFS 
section. The PW type should probably be expert review, and private use. 
PW type may be  easily converted from one to another, so even if 
something starts out into private use, and equivalent code point can be 
allocated by expert review,

Luca


Thomas Narten wrote:

>>I think  most documents refer to  this as "private use",  i.e., it basically
>>means "not  to be  assigned by IANA".
>>    
>>
>
>"Private use" is a defined term in 2434. If that is what is meant, it
>is better to use standard terminology.
>
>  
>
>>In general, this only gets used if there is no FCFS space.  However,
>>values in this space may also end up becoming de facto standards.
>>Private use values could also be used if someone wanted to deploy a
>>proprietary and non-interoperable extension, though I'm sure that no
>>one would ever want to do that.
>>    
>>
>
>"private use" is also not really for deploying proprietary stuff, at
>least not for a _vendor_ to do so. It is intended that an end-user can
>do this (within an environment they do control, so they can assure
>that numbers won't conflict). (If a vendor needs to deploy something,
>we need to make sure that they use unique numbers so that the numbers
>don't conflict with those used by some other vendor/purpose.)
>
>  
>
>>One thing that might be rational would be to make the FCFS space
>>bigger, but to also leave a reserved space.  If at some point we
>>actually look to be in danger of running out of FCFS space, we can
>>then decide whether to extend the FCFS space.
>>    
>>
>
>I think one really needs to look at each name space individually and
>consider such things as:
>
> - is the space large enough to accomodate likely usage?
>
>Separately, one needs to consider how much review is necessary. For
>some name spaces, I agree that little or no review is needed. But for
>others, it is. Again, please have a look at
>draft-iesg-vendor-extensions-02.txt, as there is much experience with
>problems caused by unreviewed extensions.
>
>  
>
>>I do not at all like the idea of "expert review", as it creates a
>>process which is all too easily subverted by cronyism and political
>>agendas, or which might just fail to deliver results.
>>    
>>
>
>Well, if you are not willing to have _any_ review, there is a risk
>that bogus extensions will get defined and deployed that negatively
>impact other deployments, the overall pwe3 architecture, etc. IMO,
>expert review provides the reasonable balance between no review (which
>has caused significant problems with some protocols) vs. an even
>higher bar, such as requiring an RFC publication, (or even higher,
>requiring a standards track document).
>
>Thomas
>
>  
>