Re: IANA document allocation

[Eric Rosen <[e-mail]>]

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.