Draft of extensions format

[Alan DeKok <[e-mail]>]

  Avi and I talked at the last IETF, and have had a number of follow-up
conversations since then.  I've just submitted the resulting document.

  At a high level, this document:

a) requests allocation of 6 "reserved" attributes

b) assigns 4 to a new format, which has one octet of "extended type"
   TYPE LENGTH Extended-Type Value...

c) assigns 2 to a new format which allows for more than 252 octets
   of data, using another octet for a "more" flag

d) defines a TLV data type, for TLV nesting as done in WiMAX and 3GPP2.

e) creates 6 VSA containers using the above formats

  This extends the RADIUS attribute type space by over 1500 possible
attributes.  It allows for a generic "long" attribute.  It allows for
better grouping than RFC 2868.  For most of the attributes, the new
format has only 1 octet of overhead over the current format.

  The document contains an analysis of how the new format will affect
existing systems.  It also contains a stub "guidelines" section, for how
attributes of the new format should be designed.

  Alan DeKok.

------
A new version of I-D, draft-dekok-radext-radius-extensions-00.txt has
been successfully submitted by Alan DeKok and posted to the IETF repository.

Filename:	 draft-dekok-radext-radius-extensions
Revision:	 00
Title:		 Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions
Creation_date:	 2010-09-01
WG ID:		 Independent Submission
Number_of_pages: 23

Abstract:
The Remote Authentication Dial In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit attribute type space.  In
addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data.  This
document defines changes to RADIUS which address all of the above
problems.




The IETF Secretariat.



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