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.