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

Bernard Aboba <bernarda@windows.microsoft.com> Wed, 04 February 2009 21:19 UTC

Return-Path: <bernarda@windows.microsoft.com>
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 C329D3A6832 for <emu@core3.amsl.com>; Wed, 4 Feb 2009 13:19:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.373
X-Spam-Level:
X-Spam-Status: No, score=-109.373 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 oEn0CEKtK3BW for <emu@core3.amsl.com>; Wed, 4 Feb 2009 13:19:46 -0800 (PST)
Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E1A093A698C for <emu@ietf.org>; Wed, 4 Feb 2009 13:19:46 -0800 (PST)
Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 4 Feb 2009 13:19:20 -0800
Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Wed, 4 Feb 2009 13:19:20 -0800
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Wed, 4 Feb 2009 13:20:49 -0800
From: Bernard Aboba <bernarda@windows.microsoft.com>
To: "emu@ietf.org" <emu@ietf.org>
Date: Wed, 04 Feb 2009 13:19:04 -0800
Thread-Topic: IANA allocation issue in EAP-FAST Documents
Thread-Index: AcmHDPGhDtdqMsPaT++CTA72hptm2AAAKZ+w
Message-ID: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
References: <BLU137-W531ACB9BE00127DB8595D993C30@phx.gbl> <bc4003aaf07c34543e6c57a477240728.squirrel@www.trepanning.net> <BLU137-W5B91C637F3D0C1BFEC34A93C30@phx.gbl>
In-Reply-To: <BLU137-W5B91C637F3D0C1BFEC34A93C30@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2828BDE8DC61004E8104C78E82A0B39713F1D62D97NAEXMSGW601wi_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 11 Feb 2009 21:23:33 -0800
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: Wed, 04 Feb 2009 21:19:50 -0000

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?)