[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Strawman RADIUSEXT WG charter - Take Three



OK.  Here's another try...

-------------------------------------------------------
RADIUS Extensions Working Group (RADIUSEXT)
Last Modified: 2003-08-22

Chair(s):
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.

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

- No new RADIUS commands will be defined.  Documentation of commands
  currently in use may be considered in the future.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
- No changes will be considered to the RADIUS attribute format.
- No new RADIUS attribute data types will be defined.
- The RADIUS maximum packet size (4K) will not be increased.
- No RADIUS "sub-types" will be defined.
- No "attribute grouping" mechanis will be defined.
- No new RADIUS security mechanisms will be defined.
- All changes MUST be backward compatible with existing RADIUS RFCs.

Work Items

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

- RADIUS UDP transport profile.  The transport behavior of the RADIUS
  protocol is unspecified in existing RFCs.  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.  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 existing RADIUS RFCs
  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 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.

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.  The SIRs process will be used, including the potential to
  disqualify a submission based on the initial review.

* All work items will need to pass a "Diameter Compatibility" and
  "RADIUS backward compatibility" review within 6 months of being
  accepted as a WG work item.

* The WG will utilize an automated issue tracking system (such as Roundup)
  in order to track ongoing issues.

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