Re: IANA assignment policies

[Tero Kivinen <kivinen@iki.fi>]

Paul Hoffman / VPNC writes:
> No. The private use proposal is fine. However, as Michael Richardson 
> said on the list over a week ago, "I think that the consensus of the 
> WG list is that all values should be a consistent "Expert Review"." 
> This is an easy-to-understand policy on IANA assignments. There were 
> people in favor, one concerned, and I believe his concerns were 
> allayed.

I agree that Expert review is the propably best if we want to have
only one method (and having only one method is good, as it simplifies
things), so we should go ahead with expert review.

I little bit lost track whether we are going to put the IANA registry
document out as separate document or not? All the information in the
document except the allocation policy is already in the
draft-ietf-ipsec-ikev2 document (or should be, the numbers are copied
from there and if we added any private use ranges or similar we should
make the base ikev2 document and this document consistent).

I propose that we change the IANA section in the base ikev2 draft to
following:

----------------------------------------------------------------------
6 IANA Considerations

   This document defines a number of new field types and values where
   future assignments will be managed by the IANA. 

   The following registries should be created.

   Note: when creating a new Transform Type, a new registry for it must
   be created.

      IKEv2 Exchange Types
      IKEv2 Payload Types
      IKEv2 Transform Types
          IKEv2 Proposal Substructure Protocol-IDs
          IKEv2 Transform Attribute Types
          IKEv2 Encryption Transform IDs
          IKEv2 Pseudo-ramdom Function Transform IDs
          IKEv2 Integrity Algorithm Transform IDs
          IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs
          IKEv2 Extended Sequence Numbers Transform IDs
      IKEv2 Identification Payload ID Types
      IKEv2 Certification Encodings
      IKEv2 Authentication Method
      IKEv2 Notification Payload Types
          IKEv2 Notification IPCOMP Transform IDs
      IKEv2 Security Protocol Identfiers
      IKEv2 Traffic Selector Types
      IKEv2 Configuration Payload CFG Types
      IKEv2 Configuration Payload Attribute Types

   New allocations to any of those registries may be allocated by
   expert review.

   Also the following entry should added to the existing "Next Payload
   Types" registry for the "Internet Security Association and Key
   Management Protocol (ISAKMP) Identifiers" (ikev1):

   	RESERVED for IKEv2			33-63
----------------------------------------------------------------------

Would that be ok for everybody? This way the base draft includes the
real IANA actions needed, and the draft-ietf-ipsec-ikev2-iana can be
given to the IANA to be used as initial registry (no need to publish
that, as all information is already in the base ikev2 draft).

There are currenty some registries which do not have private use
range, namely:

IKEv2 Proposal Substructure Protocol-IDs
IKEv2 Extended Sequence Numbers Transform IDs
IKEv2 Identification Payload ID Types
IKEv2 Traffic Selector Types

so if we want to each registry to have private use ranges those
registries should also have that.

Other inconsistencies between base ikev2 draft and the initial iana
registry document:

The "IKEv2 Proposal Substructure Protocol-IDs" registry have reserved
to IANA range, but that is not mentioned in the base ikev2 draft (only
in the IANA registry).

For the "IKEv2 Extended Sequence Numbers Transform IDs" registry the
base ikev2 draft says that 2-65536 is reserved, but initial iana
registry document says reserved to IANA (and no private use range).

For the "IKEv2 Identification Payload ID Types" the base ikev2 draft
has IANA range 12-200 and private use range 201-255, but the initial
iana registry document have only reserved to IANA range 12-255.

For the "IKEv2 Security Protocol Identfiers" registry the initial iana
registry document have reserved to IANA and private use ranges, but
the base ikev2 document only defines numbers 1,2,3, i.e. it does not
tell there is private use or any other ranges.

For the "IKEv2 Traffic Selector Types" registry the base ikev2 draft
does not have reserved to IANA range or private use range, and the
initial iana registry document have reserved to IANA range (but no
private use range). 
-- 
kivinen@safenet-inc.com