Re: [Emu] IANA allocation issue in EAP-FAST Documents

"Glen Zorn" <glenzorn@comcast.net> Thu, 12 February 2009 05:30 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 E2F5B3A696E for <emu@core3.amsl.com>; Wed, 11 Feb 2009 21:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.001, 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 B0MolR7zy6Ah for <emu@core3.amsl.com>; Wed, 11 Feb 2009 21:30:47 -0800 (PST)
Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 280573A6A18 for <emu@ietf.org>; Wed, 11 Feb 2009 21:30:47 -0800 (PST)
Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA09.westchester.pa.mail.comcast.net with comcast id EtFC1b00216LCl059tWtr5; Thu, 12 Feb 2009 05:30:53 +0000
Received: from gwzPC ([124.120.218.181]) by OMTA06.westchester.pa.mail.comcast.net with comcast id EtWS1b0093vQyGU3StWa8E; Thu, 12 Feb 2009 05:30:52 +0000
From: Glen Zorn <glenzorn@comcast.net>
To: 'Bernard Aboba' <bernarda@windows.microsoft.com>
References: <BLU137-W531ACB9BE00127DB8595D993C30@phx.gbl> <bc4003aaf07c34543e6c57a477240728.squirrel@www.trepanning.net> <BLU137-W5B91C637F3D0C1BFEC34A93C30@phx.gbl> <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Date: Thu, 12 Feb 2009 12:29:58 +0700
Message-ID: <002701c98cd3$01f98e50$05ecaaf0$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C98D0D.AE586650"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmHDPGhDtdqMsPaT++CTA72hptm2AAAKZ+wAXE5BSA=
Content-Language: en-us
Cc: emu@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, 12 Feb 2009 05:30:55 -0000

Hi, Bernard.  I can't find anything in 5226 that says anything about
vendor-specific registries.  Can you send a quote?

 

From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of
Bernard Aboba
Sent: Thursday, February 05, 2009 4:19 AM
To: emu@ietf.org
Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents

 

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?

It would appear that the registry of "EAP-FAST PAC Attribute Types" relates
to a Standard Track document, RFC 4507, although the document itself

doesn't indicate that it updates RFC 4507. 

 

RFC 5226 does permit vendor-specific registries, although it is somewhat odd
to

enable vendor extensions for only one vendor, particularly if this does
relate to

an IETF standards track document (which would imply IETF change control,
no?)