Re: [Emu] IANA allocation issue in EAP-FAST Documents
"Glen Zorn" <glenzorn@comcast.net> Thu, 05 February 2009 04:43 UTC
Return-Path: <glenzorn@comcast.net>
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A952A3A6873 for <emu@core3.amsl.com>; Wed, 4 Feb 2009 20:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.327
X-Spam-Level:
X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBqtSt7k2bOz for <emu@core3.amsl.com>; Wed, 4 Feb 2009 20:43:36 -0800 (PST)
Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 43E8D3A6359 for <emu@ietf.org>; Wed, 4 Feb 2009 20:43:36 -0800 (PST)
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA07.westchester.pa.mail.comcast.net with comcast id BrUg1b00F0SCNGk574iHZn; Thu, 05 Feb 2009 04:42:17 +0000
Received: from gwzPC ([124.120.227.205]) by OMTA09.westchester.pa.mail.comcast.net with comcast id C4hb1b0024SXqDG3V4hktc; Thu, 05 Feb 2009 04:42:12 +0000
From: Glen Zorn <glenzorn@comcast.net>
To: 'Bernard Aboba' <bernard_aboba@hotmail.com>
References: <BLU137-W547A5050188473B7B99FA693C00@phx.gbl>
In-Reply-To: <BLU137-W547A5050188473B7B99FA693C00@phx.gbl>
Date: Thu, 05 Feb 2009 11:41:14 +0700
Message-ID: <001b01c9874c$1006b8b0$30142a10$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C98786.BC6590B0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmHNZBBnWUPW7ErQ0OV9RgmTEnRlgADBk9A
Content-Language: en-us
Cc: Dan Harkins <dharkins@arubanetworks.com>, emu@ietf.org, iesg@ietf.org
Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 04:43:36 -0000
Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes: Dan Harkins said: > draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 > but nowhere in that RFC can I find description of the following label > for an initial assignment of repository values: > > "allocated for management by Cisco" > > yet the draft instructs IANA to set aside values 11-63 for just that > purpose. I think that's very inappropriate. Not only is it telling IANA > to cede some of its authority to a large multinational corporation but > it is decidedly *NOT* documenting existing use! If this whole exercise > is to document existing use then where are the specifications for these > PAC attribute types? Are you saying that the registry of "EAP-FAST PAC Attribute Types" also relates to RFC 4507, which is a standards track document? AFAICT, the two seem unrelated. If so, then I may see your point. RFC 5226 does permit vendor-specific registries. I can't find this in 5226. Are you perhaps referring to Private Use registries? If so, RFC 5226 has this to say about them: Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments (since IANA does not record them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). Essentially, Private Use numbers are neither allocated nor recorded by IANA & there is certainly no guarantee that any two sites (or vendors) won't use the same number for different purposes or vice-versa. Although it's not completely clear from the document, draft-cam-winget-eap-fast-provisioning appears to be setting up registries managed by IANA with a policy of Specification Required for everybody but Cisco; Cisco would simply allocate numbers out of their reserved range internally and use IANA to promulgate their decisions to the outer world. I can't find anything in RFC 5226 that even remotely suggests that this is permissible behavior. However, if the registry relates to a Standards Track protocol under IETF change control, then restricting vendor-specific extensions to only one vendor would be highly unusual.
- Re: [Emu] IANA allocation issue in EAP-FAST Docum… Bernard Aboba
- Re: [Emu] IANA allocation issue in EAP-FAST Docum… Joseph Salowey (jsalowey)
- Re: [Emu] IANA allocation issue in EAP-FAST Docum… Glen Zorn