Subject: IANA assignment policies

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 13 Feb 2004 00:08:35 -0500

There has been no further activity on the mailing list about IANA
assignment policies for IKEv2, and we need to somehow make progress.

So I'm going to make a set of proposals given the discussion which we've
had on the subject:

1) All numberspaces should have at least some (perhaps a very small)
    Private Use, per David Black's concerns about being able to do
    private experiments.

2) All 16-bit and greater number spaces will have a policy of
   Specification Required for the portion of the space which is reserved
   for IANA assignment.

3) All 8-bit number spaces shall have the following policy for the
   portion of the space which is reserved for IANA assignment.  A number
   may be assigned EITHER via a standards-track RFC OR by satisfying
   both of the following policies: Specification Required and Expert
   Review.  Furthermore, the review by the expert must follow a two-week
   public discussion on a mailing list.  As always, the decision of the
   expert may be appealed to the IESG who may decide to affirm or
   override the Expert's decision.

Does this satisfy everyone's concerns?  I'd like to call the question
and come to a decision within a week.

							- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 13 Feb 2004 07:44:40 -0800

At 12:08 AM -0500 2/13/04, Theodore Ts'o wrote:
>Does this satisfy everyone's concerns?

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.

Splitting the decision by size of field will not be easy to figure 
out for implementers, yet they are the main users of the IANA 
registry. The proposal of having some numbers be "Specification 
Required" for some spaces but Specification Required or expert review 
for other spaces means that proposals that include some of both have 
to deal with different requirements for a single proposal. Worse yet, 
"Specification Required" forces IANA to decide if a non-RFC document 
is "permanent and readily available". Knowing that has proven to be 
something that is well outside of IANA's skill set.

Please go with the earlier WG consensus, which is to make all values 
"Expert Review" instead of creating a new and more difficult to 
understand one.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Feb 2004 01:38:26 +0200

> and come to a decision within a week.

I think this is reasonable. I'd also be satisfied by a simpler standards
track only policy for #3.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Feb 2004 20:08:10 +0200

> people in favor, one concerned, and I believe his concerns were 

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). 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Feb 2004 14:59:59 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    Tero> I propose that we change the IANA section in the base ikev2 draft
    Tero> to following:

  That's perfect as far as I'm concerned.

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

  Yes.

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

  "Reserved" means what vs "Reserved to IANA" ?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Feb 2004 23:05:29 +0200

>   "Reserved" means what vs "Reserved to IANA" ?

I think if it says Reserved to IANA, then IANA can allocate entries
from that area, but if it simply says Reserved (as it says for most
tables for value 0), it means that numbers are reserved and cannot be
allocated.

I was mostly pointing out that in other places it says Reserved for
IANA and here it didn't (i.e. the documents are inconsistent), so the
base document should be fixed to have Reserved for IANA too. 
-- 
[email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 18 Feb 2004 13:49:53 -0800

"Reserved for IANA" is a silly and confusing convention that early 
IPsec documents used. Everything is reserved for IANA that is not 
allocated, yes? Having "reserved" meaning "IANA should never 
allocate" and "reserved for IANA" meaning "IANA should allocate" is 
bound to end up in tears. Drop all the "reserved for IANA" strings. 
Any developer who really cares can figure out what the last available 
number in a range is.

--Paul Hoffman, Director
--VPN Consortium