Re: IANA document

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 1:42 PM -0500 1/29/04, Theodore Ts'o wrote:
>Currently the January 6th I-D states that the IANA considerations will
>be in a separate document.  As part of any edits or changes that arise
>either as a result of the IETF-wide last call, or from the IESG (and I
>agree with you that given the nature of the review and the legnth of
>the document, this is virtually a certainty), we will have an
>opportunity to add Michael's document into the IKEv2's IANA
>Consideration section, and replace it with its current pointer to
>Michael's I-D, if that be the consensus of the working group.

...or if it is what the IESG asks for. The IESG talks with IANA on 
all these issues, so IANA might ask for it one way or another.

>That being said, at this point, let me take my working group chair hat
>off, and make a formal proposal that we change the allocation policies
>in Michael's document in the following way: That all registries that
>require reflect 8 bit values shall require "Expert Review" and that
>all registries of numbers that are 16 bits or larger shall use the
>"Specification Required" as defined in RFC-2434.  The rationale for
>making this change is that currently, some 8-bit registries are
>"Specification Required".  This is unwise, as little as 122 or so
>specifications presented to the IANA (they don't even have to be
>Informational RFC's, according to RFC 2434), would be all that would
>be required to exhaust the number of available IKEv2 traffic selector
>types or configuration payload types.
>
>Comments?

Having all of the values have the same requirements would make 
allocation more predictable to people in the future. Doing so also 
gives more uniform results in cases where an IKEv2 extension requires 
a couple of values from different registries. Your proposal is OK, 
but a more consistent proposal is simply that all values require 
"Expert Review".

--Paul Hoffman, Director
--VPN Consortium