Re: Strawman RADIUSEXT WG charter

[Jari Arkko <jari.arkko@piuha.net>]

Looks good to me. A few nits 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,
Maybe explicitly say somewhere that actual attrs for IP telephony
are done elsewhere, even if the attr space extension and other
features provided by this WG are used at the bottom?

> 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.
>
> 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.
>
> - 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.
s/suport/support/

> Dec 04  RADIUS attributes for LANs submitted as an Informational RFC.
Is there a specific target group for this item? 802.11<something>?
What is their deadline, is Dec 04 OK for that? Or are there multiple
groups? If yes, do their ideas about the attributes agree?

--Jari



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