RADEXT charter for comment - Take 7

[Bernard Aboba <aboba@internaut.com>]

RADIUS Extensions Working Group (RADEXT) Charter
Last Modified: 2004-03-16

Chair(s):
David Nelson <dnelson@enterasys.com>

Operations and Management Area Director(s):
David Kessens <david.kessens@nokia.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:
David Kessens <david.kessens@nokia.com>

Technical Advisor:
Paul Congdon <paul_congdon@hp.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.

In order to ensure backward compatibility with RADIUS as well as
Diameter, the following restrictions are imposed on extensions considered
by the RADIUSEXT WG:

- All work MUST be backward compatible with existing RADIUS RFCs,
  including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All work MUST be compatible with equivalent facilities in Diameter.
- The RADIUS maximum packet size (4K) will not be increased.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
- New attributes which contain sub-attributes must use only one level of
  nesting, and be compatible with the construction used for VSAs in RFC
  2865.
- The RADIUS maximum packet size (4K) will not be increased.

Work Items

The immediate goals of the RADIUSEXT working group are to address the
following issues:

- RADIUS design guidelines.  This document will provide guidelines
  for design of RADIUS attributes, including discussion of the
  appropriate use of RADIUS SDO-Specific Attributes (SSAs).

- Revised NAI specification.  This document, known as "RFC 2486bis"
  will revise the NAI specification to provide more details on
  routing as well as handling internationalization.

- Pre-paid support.  Prepaid 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, the WG will provide definitions of the
  attributes required to support operator service models for
  pre-paid, as documented in liaison communications.  Support
  will be included for time, volume, and event oriented charging
  as well as support for limited differential charging.
  This document will be compatible with Diameter Credit Control.

- SIP support.  RADIUS is currently used for SIP authentication,
  authorization and accounting.  Standardization of these attributes
  will enable improved interoperability.

- LAN attributes.  New 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.

- MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
  changes are required to address this issue.

Goals and Milestones:

Dec 04  Updated RADIUS MIBs submitted for publication.
Jun 05  RADIUS design guidelines submitted as a Proposed Standard RFC.
Jun 05  RFC 2486bis submitted as a Proposed Standard.
Dec 05  WLAN attributes submitted as a Proposed Standard RFC.
Dec 05  LAN attributes submitted as a Proposed Standard RFC.
Dec 05  SIP authentication draft submitted as a Proposed Standard RFC.
Dec 05  Prepaid draft submitted as a Proposed Standard RFC.

Quality Control Plan

In order to ensure quality of work:

* This WG will not be chartered until sufficient resources can be
  demonstrated to be available to guarantee a high probability of
  success.  This includes recruitment of a core of editors and
  reviewers with significant IETF experience and demonstrated time
  commitment.

* All drafts will need to undergo review prior to acceptance as WG work
  items, which includes demonstration that the drafts are backward
  compatible with RADIUS RFCs and are compatible with equivalent
  facilities in Diameter.

* The WG will utilize an issue tracking system.

* XML to RFC will be used in production of documents.  This enables
  production of HTML and text files from a single source file as
  well as automated production of difference files.

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