Re: IANA assignment policies
Tero Kivinen <kivinen@iki.fi> Tue, 17 February 2004 20:41 UTC
Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04020 for <ipsec-archive@lists.ietf.org>; Tue, 17 Feb 2004 15:41:50 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19940 Tue, 17 Feb 2004 12:56:37 -0500 (EST)
X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16434.22666.257287.681344@fireball.acr.fi>
Date: Tue, 17 Feb 2004 20:08:10 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: Theodore Ts'o <tytso@mit.edu>, ipsec@lists.tislabs.com, mcr@sandelman.ottawa.on.ca, charliek@microsoft.com
Subject: Re: IANA assignment policies
In-Reply-To: <p06020402bc529e750e58@[63.202.92.153]>
References: <E1ArVZ5-0002K8-Ae@thunk.org> <p06020402bc529e750e58@[63.202.92.153]>
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Edit-Time: 25 min
X-Total-Time: 31 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit
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
- IANA assignment policies Theodore Ts'o
- Re: IANA assignment policies Paul Hoffman / VPNC
- Re: IANA assignment policies Jari Arkko
- Re: IANA assignment policies Russ Housley
- Re: IANA assignment policies Tero Kivinen
- Re: IANA assignment policies Michael Richardson
- Re: IANA assignment policies Tero Kivinen
- Re: IANA assignment policies Paul Hoffman / VPNC