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

Re: IANA document



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