[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-aboba-radius-iana-04.txt



> I think the missing words are that for Specification Required with an RFC, 
> allocation will happen as part of the RFC publication process.
> For non-RFC specs, there is a deadlock problem if they want the assigned 
> number in the spec but can't get the number before the spec is published - 
> no shining ideas on how that should be solved.

And what I have always recommended in this situation is "IESG
Consensus" (as defined in 2434, not as how some people assume they
know what those words are supposed to mean):

      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG. Typically, the IESG will seek
           input on prospective assignments from appropriate persons
           (e.g., a relevant Working Group if one exists).


But if people don't like this term any more...

Or, how about text something like the following (for 2.1)

   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.  But in order to allow for the
   allocation of values prior to the RFC being approved for
   publication, the Designated Expert can approve allocations once it
   seems clear that an RFC will be published.  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 and publish a notice of the decision to the AAA WG mailing
   list or its successor, as well as informing IANA.  A denial notice
   must be justified by an explanation ...

If you go with the above type wording, it's not clear the document
even needs to use the term "Specific Required". The intent of that
wording was specifically to allow non-RFC documentation to be
used. But if the real intent is to allow only RFC documentation,
mentioning "Specification Required" seems a distraction.

Thomas