Re: Strawman RADIUSEXT WG charter

[Greg Weber <gdweber@cisco.com>]

> 
> Here is a proposed strawman charter for a RADIUSEXT WG.  Comments welcome.

Some comments and questions inline.

> 
> --------------------------------------------------------------------------
> 
> RADIUS Extensions Working Group (RADIUSEXT)
> Last Modified: 2003-08-19
> 
> Chair(s):
> Bernard Aboba <aboba@internaut.com>
> David Nelson <dnelson@enterasys.com>
> 
> Operations and Management Area Director(s):
> Randy Bush <randy@psg.com>
> Bert Wijnen <bwijnen@lucent.com>
> 
> Operations and Management Area Advisor:
> Randy Bush <randy@psg.com>
> 
> Mailing Lists:
> General Discussion: radiusext@ops.ietf.org
> To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe
> Archive: http://ops.ietf.org/lists/radiusext
> 
> Description of Working Group:
> 
> The RADIUS Extensions Working Group will focus on extensions
> to the RADIUS protocol required to enable its use in applications
> such as IP Telephony and Local Area Network authentication,
> authorization and accounting.  All extensions produced by this
> working group are required to demonstrate backward compatibility with
> the existing RADIUS protocol as well as compatibility with the
> equivalent capabilities in the Diameter protocol. No new RADIUS commands
> will be defined.

Would this last sentence preclude future work items to 
specify the behavior of packet types reserved by RFC 3575, but
not defined by RFC 2882?  In particular, I think producing 
a specification for packet type codes 33 & 34 (Event-Request/
Response) will be useful in a number of forums and can be 
done in a Diameter compatible way.

> The immediate goals of the RADIUSEXT working group are to address the
> following issues:
> 
> - Attribute space extension.  The RADIUS protocol, defined in
>   RFC 2865, has an eight (8) bit attribute space, a good portion
>   of which has already been allocated or is in use.  In order to
>   address attribute exhaustion, an extended attribute space will be
>   defined.

Will this work item include addressing the attribute size
limitation in the extended space?  A number of methods 
for fragmenting large values across attributes have popped 
up, e.g. as in the PacketCable 1.0 spec.  It would be nice 
to have a standard way of doing this.

Greg

> 
> - RADIUS UDP transport profile.  The transport behavior of the RADIUS
>   protocol is unspecified in RFC 2865 and 2866.  This has resulted in
>   implementations lacking support for congestion control. This task
>   involves specification of the RADIUS UDP transport mapping,
>   providing support for congestion control and jittering.  Failover
>   behavior is not part of this work item, although it may be
>   considered in the future.  An explicit non-goal of this work item
>   is to bring RADIUS up to the level of reliability achievable in
>   Diameter.
> 
> - Pre-paid support.  Pre-paid services are contemplated in a number
>   of potential applications, including wireless LAN access and IP
>   telephony. In order to enable support of pre-paid services in an
>   interoperable way, a specification is required.  The implementation of
>   RADIUS prepaid needs to be compatible with RFC 2865 and 2866,
>   as well as with Diameter prepaid capabilities.
> 
> - LAN attributes.  A number of additional attributes have been
>   proposed to enable use of RADIUS authentication, authorization and
>   accounting in wired and wireless LANs.  Standardization of these
>   attributes will enable improved interoperability.
> 
> Goals and Milestones:
> 
> Apr 04  RADIUS attribute space extension submitted as a Proposed Standard RFC.
> Apr 04  RADIUS UDP transport profile submitted as a Proposed Standard RFC.
> Sep 04  RADIUS pre-paid suport submitted as an Informational RFC.
> Dec 04  RADIUS attributes for LANs submitted as an Informational RFC.
> 
> --
> 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/>
> 


--
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/>