Re: IANA document

"Theodore Ts'o" <tytso@mit.edu> Thu, 29 January 2004 21:19 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 QAA19009 for <ipsec-archive@lists.ietf.org>; Thu, 29 Jan 2004 16:19:43 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00564 Thu, 29 Jan 2004 09:33:38 -0500 (EST)
Date: Thu, 29 Jan 2004 09:01:16 -0500
From: Theodore Ts'o <tytso@mit.edu>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: Barbara Fraser <byfraser@cisco.com>, Charlie Kaufman <charliek@microsoft.com>, ipsec@lists.tislabs.com
Subject: Re: IANA document
Message-ID: <20040129140116.GB27702@thunk.org>
References: <3453.1075344391@marajade.sandelman.ottawa.on.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3453.1075344391@marajade.sandelman.ottawa.on.ca>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

On Wed, Jan 28, 2004 at 09:46:31PM -0500, Michael Richardson wrote:
> I don't know where things are going with this. If it will be published,
> then it needs a revision perhaps, and I'd like to do this before document
> deadline. 
> 
> If it isn't going to be published (original plan), then I think that it is
> done, and should go to some kind of WG last call, and get fed to IANA for
> their thoughts.
> 
> I'm totally cool if Charlie just takes the text and puts it into IKEv2.

Hi Michael, I was planning on sending this note a few days ago, but
work just got me completely swamped.  My apologies for it being
somewhat terse, but I figured it would be better to send something
short rather than to delay replying to you...

I've been looking at RFC 2434, and it looks like there are some
requirements for what needs to be in the IANA consideration section
that doesn't quite meet with what's in draft-ietf-ipsec-ikev2-iana-01.txt.
In particular, what RFC 2434 suggests that the text read something like:

	Following the policies outlined in [RFC 2434],
        numbers in the range 0-1234 are allocatred using the Expert
	REVIEW policy, and the numbers in the range 1024 - 65535 are
	reserved for Private Use.

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.  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.

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?  

						- Ted