Re: IANA document

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Jan 29, 2004 at 09:09:27AM -0800, Paul Hoffman / VPNC wrote:
> Maybe you are mistaking the fact that RFC 2434 is *about* IANA 
> sections in RFCs. If fact, in the middle of section 2, it says "In 
> some cases, however, the burden of publishing an RFC in order to get 
> an assignment is excessive." That seems pretty clear.

To get an assignment, yes.  But the allocation policies for the
various registries I read as being required for to be specified in the
RFC.  These do not change, but IMHO should be documented in a
permanent location.  An Area Director may correct me, but that was my
reading of RFC 2434.

> Putting it in the main IKEv2 document would seem to be faster: there 
> is one less place for coordination.

True.  

> Put Michael's text in Charlie's document wholesale with no further 
> discussion. After we have an RFC, if we need to tweak the allocation 
> policies, we can revise IKEv2 in a new RFC. Given the way the WG has 
> gone so far, the chance that the current IKEv2 will have no errors is 
> close to zero, so we should expect a second version anyhow.

Actually, we're through working group last call already, and the
changes which Charlie made in the -12 version of the I-D January 6th
reflect the second time that that we've pushed the ikev2 document to
Russ's reading queue for IETF-wide last call.

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.

However, while this is going on, we do still have an opportunity to
make changes to the allocation policies, which up until now have had
pretty much zero discussion on the mailing list.  So I raised this
question about the allocation policies not because I wanted to add
delay; indeed what we've done has been to move the ikev2 document
along the track as quickly as possible.  Instead, I'm raising this
question because I want the result to be as high-quality as possible,
while minimizing or eliminating any delay that might be introduced
into the process.  We *can* have this discussion without delaying ikev2.

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?

						- Ted