Re: IANA document

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

At 9:01 AM -0500 1/29/04, Theodore Ts'o wrote:
>RFC 2434 also states that this text needs to be in an RFC; so I don't
>think just publishing this in an I-D and giving it to the IANA cuts
>it.

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.

>   There still is the question of whether it needs to be in the
>IKEv2 specification or in a separate stand-alone document.  I'm
>personally agnostic on the subject, except insofar as which one gets
>us done faster.

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

>In addition, I am wondering if we need to adjust the allocation
>policies as currently defined in ikev2-iana-01 document.  It seems
>strange to me that the relatively small ranges, such as the IKEv2
>Payload types (only 255 possible values) have relatively loose
>policies, such as "Specification Required", whereas some ranges that
>are much larger, such as the IKEv2 Integrity Algorithm Transform ID's
>(with 65536 possible values) have "Expert Review" as the policy. 
>
>I understand that you probably just used the IANA policies from the
>original IKEv1 and ISAKMP specs.  But it's not clear to me that they
>are completely coherent.
>
>Comments?

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.

Having the WG chairs ask at this late date for even more delay on 
IKEv2 seems unreasonable.

--Paul Hoffman, Director
--VPN Consortium