Re: WGLC for draft-ietf-radext-radius-extensions-01
Alan DeKok <aland@deployingradius.com> Tue, 25 October 2011 19:44 UTC
Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66C121F8C0C for <ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com>; Tue, 25 Oct 2011 12:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCKKFDgzGEPn for <ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com>; Tue, 25 Oct 2011 12:44:50 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CA5C921F8C04 for <radext-archive-IeZ9sae2@lists.ietf.org>; Tue, 25 Oct 2011 12:44:50 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1RImsO-0004Wt-4q for radiusext-data0@psg.com; Tue, 25 Oct 2011 19:41:33 +0000
Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <aland@deployingradius.com>) id 1RImsL-0004Wf-Li for radiusext@ops.ietf.org; Tue, 25 Oct 2011 19:41:30 +0000
Message-ID: <4EA710E3.7010206@deployingradius.com>
Date: Tue, 25 Oct 2011 21:41:23 +0200
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01
References: <4E64DD35.4030306@deployingradius.com> <A1D0B8C0-D679-4066-8623-C7E837A3A639@gmail.com>, <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <BLU152-W2657B534FF7211C3E7252993F20@phx.gbl>
In-Reply-To: <BLU152-W2657B534FF7211C3E7252993F20@phx.gbl>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>
I've submitted -02 which addresses the concerns below. All SHOULD / MAY / MUST / etc. has been removed from the IANA considerations section. It repeated text elsewhere in the document, so there is no loss. Alan DeKok. Bernard Aboba wrote: > Here are my comments: > > The IANA Considerations section needs to be revised. It is recommended > that the IANA considerations section be rewritten according to the > recommendations of RFC 5226, and that this be cited as a normative > reference. > > Some issues: > > 1. The IANA considerations section does not specify how attributes are > to be allocated from the extended space, using policy terms defined in > RFC 5226. > 2. Normative language terms "SHOULD"/"SHOULD NOT" are used in Sections > 9.1 and 9.5. > > The IANA is not a policy making body and therefore is not capable of handling MAY, SHOULD or SHOULD NOT directives. > > > 9.1. Attribute Allocations > > > > IANA is requested to move the "Unassigned" numbers in the range > 144-191 from "Unassigned" to "Deprecated". This status means that > allocations SHOULD NOT be made from this space. Instead, allocations > SHOULD be taken from the Extended Type space, starting with lower > numbered attributes. However, allocation from the "Deprecated" space > MAY still be performed by publication of an IETF specification, where > that specification requests allocation from the "Deprecated" space, > and gives reasons why use of the Extended Type space is impossible. > > > [BA] > > It seems that the goal is to still allow allocation from the Unassigned range, while preferring allocation from the Extended Type space. > > A more implementable way of accomplishing this might be to say that unless specifically requested to allocate from the Standard RADIUS space, > IANA should make allocations from the extended type space. > > > 9.5. Extending the RADIUS Attribute Type Space > > > > The extended RADIUS Attribute Type space may eventually approach > exhaustion. When necessary, the space SHOULD be extended by > publication of a specification which allocates new attributes of > either the "Extended Type", or the "Extended Type with flags" format. > > [BA] This material relates to IETF not IANA processing, and so is not > appropriate for an IANA considerations section. The IANA cannot handle > the policy decisions that are implied here. > > > The specification SHOULD request allocation of a specific number from > the "Reserved" RADIUS Attribute type space, such as 247. The > attribute(s) SHOULD be given a name which follows the naming > convention used in this document. The Extended-Type value of 26 MUST > be allocated to a "Vendor Specific" attribute, of data type "esv". > The Extended-Type values of 241 through 255 MUST be marked as > "Reserved". > > IANA SHOULD allocate the attribute(s) as requested. For example, if > allocation of attribute 247 is requested, the following definitions > MUST be made in the specification, and allocated by IANA. > > * 247.1 Extended-Attribute-7 > * 247.{1-25} Unassigned > * 247.26 Extended-Vendor-Specific-7 > * 247.{27-240} Unassigned > * 247.{241-255} Reserved > > We note,however, that the above list is an example, and we do not > request or perform allocation of attribute 247 in this document. > > > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- Extensions document Alan DeKok
- WGLC for draft-ietf-radext-radius-extensions-01 jouni korhonen
- Re: WGLC for draft-ietf-radext-radius-extensions-… jouni korhonen
- RE: WGLC for draft-ietf-radext-radius-extensions-… Bernard Aboba
- Re: WGLC for draft-ietf-radext-radius-extensions-… Alan DeKok
- RE: WGLC for draft-ietf-radext-radius-extensions-… Leaf yeh
- Re: WGLC for draft-ietf-radext-radius-extensions-… Alan DeKok
- RE: WGLC for draft-ietf-radext-radius-extensions-… Leaf yeh
- Re: WGLC for draft-ietf-radext-radius-extensions-… Alan DeKok
- RE: WGLC for draft-ietf-radext-radius-extensions-… Leaf yeh
- Re: WGLC for draft-ietf-radext-radius-extensions-… Alan DeKok
- Re: [radext] WGLC for draft-ietf-radext-radius-ex… Leaf yeh
- Re: [radext] WGLC for draft-ietf-radext-radius-ex… Alan DeKok