Subject: Extensions document

From: Alan DeKok <[email-masked]>
Date: Mon, 05 Sep 2011 10:31:17 -0400

The latest rev is here:

http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-01

  There has been little discussion on this document.  There are multiple
inter-operable implementations.  There are drafts which could benefit
from it's format now.  There's an individual draft which uses the format.

  Can we do a WG last call on it?  There have been no objections to the
document, so it would seem to be "baked".

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 8 Sep 2011 12:19:33 +0300

Folks,

This mail starts two weeks WGLC for draft-ietf-radext-radius-extensions-01. Send your comments to the list and also record them to the issue tracker. The WGLC ends 22nd September, 23:59 CET+1.

The authors are encouraged to recruit reviewers for the I-D.

Cheers,
	Jouni & Mauricio

---

From: jouni korhonen <[email-masked]>
Date: Fri, 23 Sep 2011 13:09:27 +0300

Folks,

The WGLC ended for this I-D yesterday. There were no comments, which I don't feel too comfortable with. However, regarding this particular I-D it has been around for quite some time and we know there are already multiple inter-operable implementations. We'll move the I-D forward.

- Jouni

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 25 Sep 2011 10:03:37 -0700

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.