Subject: Re: IANA document allocation

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Dec 2004 15:03:08 -0500

> Indeed, one of the things that might be good to have words about in
> the IANA document (if Expert Review is chosen) is what type of
> requests are expected to be approved, and what sort of review is
> needed prior to granting a request.

To followup, e.g., it wouldn't be unreasonable for the expert to ask
the WG and for the WG to have to agree to an assignment (if that is
what the WG wants).

For another perspective,  look at RFC 3575 "IANA Considerations for
RADIUS", section 2.1, which says: 

2.1.  Recommended Registration Policies

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  The intention is that any allocation will be
   accompanied by a published RFC.  However, the Designated Expert can
   approve allocations once it seems clear that an RFC will be
   published, allowing for the allocation of values prior to the
   document being approved for publication as an RFC.  The Designated
   Expert will post a request to the AAA WG mailing list (or a successor
   designated by the Area Director) for comment and review, including an
   Internet-Draft.  Before a period of 30 days has passed, the
   Designated Expert will either approve or deny the registration
   request, publish a notice of the decision to the AAA WG mailing list
   or its successor, and inform IANA of its decision.  A denial notice
   must be justified by an explanation and, in the cases where it is
   possible, concrete suggestions on how the request can be modified so
   as to become acceptable.

The point is, it would be good to provide some general guidelines for
what is an acceptable request and what is not, so both the requestor
and the expert are on the same page. But it is also best not to get
too explicit, since flexibility is needed to handle each request on a
case-by-case basis and to deal with things that come up that might not
have been thought through at the time the document was written. That
is, give the expert general guidelines, but then give him/her the
authority to do the right thing.

Thomas

---

From: Eric Rosen <[email-masked]>
Date: Fri, 17 Dec 2004 15:38:11 -0500

Thomas> What is the  point of having an "IETF Consensus"  range if one could
Thomas> also just get a code point via FCFS? 

That's a good  question.  What it means in practice  is that assignments are
made FCFS until the FCFS space  gets used up; thereafter assignments need to
be made  via IETF  consensus.  New developments  generally get  shipped with
codepoints from this  space, and then keep those  codepoints even after they
get standardized.

Thomas> it  mentions "vendor-specific" ranges,  but I  don't know  what that
Thomas> means

I think  most documents refer to  this as "private use",  i.e., it basically
means "not  to be  assigned by IANA".   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.

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