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
- Re: IANA document Theodore Ts'o
- Re: IANA document Paul Hoffman / VPNC
- Re: IANA document Michael Richardson
- Re: IANA document Theodore Ts'o
- Re: IANA document Paul Hoffman / VPNC
- IKEv2 allocation policies Michael Richardson
- Re: IKEv2 allocation policies Michael Richardson
- Re: IKEv2 allocation policies Jari Arkko
- Re: IKEv2 allocation policies Paul Hoffman / VPNC
- Re: IANA document Theodore Ts'o
- Re: IANA document Michael Richardson
- Re: IKEv2 allocation policies Michael Richardson
- Re: IANA document Theodore Ts'o
- Re: IKEv2 allocation policies Jari Arkko
- Re: IKEv2 allocation policies, etc. Paul Hoffman / VPNC
- Re: IKEv2 allocation policies, etc. Michael Richardson
- Re: IKEv2 allocation policies, etc. Paul Hoffman / VPNC
- RE: IANA document Eastlake III Donald-LDE008