Subject: Re: IANA document allocation

From: Luca Martini <[email-masked]>
Date: Wed, 22 Dec 2004 10:36:32 -0700

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
>
>  
>

---

From: Eric Rosen <[email-masked]>
Date: Wed, 22 Dec 2004 15:30:49 -0500

Thomas> "private use" is also not really for deploying proprietary stuff, at
Thomas> least not for  a _vendor_ to do so. It is  intended that an end-user
Thomas> can  do this (within  an environment  they do  control, so  they can
Thomas> assure that numbers won't conflict).

This is not very realistic. 

Thomas> If a  vendor needs to  deploy something, we  need to make  sure that
Thomas> they  use unique  numbers so  that the  numbers don't  conflict with
Thomas> those used by some other vendor/purpose.

That's why FCFS  is really better; otherwise "private  use" becomes "defacto
FCFS by the largest vendors". 

Thomas> please have a  look at draft-iesg-vendor-extensions-02.txt, as there
Thomas> is much experience with problems caused by unreviewed extensions

That  document  is  woefully  incomplete,  as it  neglects  to  catalog  the
following situations:

- problems caused by reviewed extensions
- unreviewed extensions that don't cause problems
- problems caused by the inability to get an allocation in a timely manner
-  problems caused  because the  "expert review"  was  insufficiently expert
  (perhaps it  was political  rather than technical,  or perhaps  the expert
  simply did not appreciate the valid need for the extension). 

and my favorite: 

- problems  caused  when  unreviewed  extensions are  made  by  overloading
  existing codepoints. 

I can  think of a  couple of cases  of the latter where  existing codepoints
were simply reinterpreted  to have a different meaning  in certain contexts.
(For instance,  a 32-bit  field may be  reinterpreted as two  16-bit fields,
even if everyone really knows that at  least one of the 16-bit fields is too
short. "We can't make it any larger, that would require a new code point".)
This enables  the protocol to be  extended without need of  a new codepoint,
but it usually causes a number of undesirable side-effects. 

IMHO, draft-iesg-vendor-extensions-02.txt  does not present  a very balanced
analysis. 

Luca> I do  like the expert  allocation method, but  to support some  of the
Luca> objections made here, I think it should be a "light" expert review.  I
Luca> would put forward that the expert should be required to present strong
Luca> proof why a particular value should not be allocated. 

The fact  of the matter  is that there  is no process  in the IETF  which is
known  to  provide  timely   and  objective  results  here.   Modifying  our
description of the  non-existent process to make it  sound better doesn't do
anything but make it sound better.