[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT charter, Take 8
Hi all,
> Based on the above comments, I'd like to suggest the
> following text as the charter:
For what its worth, I agree with Jari's suggested modified charter.
I have more interest in the converged view of supporting both RADIUS
& Diameter, so I'm motivated by Jari's charter to be involved.
John
> AAA Extensions Working Group (AAAEXT) Charter
> Last Modified: 2004-03-24
>
> 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 AAA Extensions Working Group will focus on maintaining
> AAA related specifications, adding support for the use of
> AAA protocols (RADIUS, Diameter) for Local Area Network
> authentication, authorization, and accounting, and adding
> support to the RADIUS porocol for IP telephony and prepaid
> applications.
>
> In order to ensure backward compatibility with RADIUS as well as
> Diameter, the following restrictions are imposed on extensions
> considered by the WG:
>
> - All work MUST be backward compatible with existing RADIUS RFCs,
> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579,
> and 3580.
>
> - All extensions consisting of carrying additional information
> attributes MUST be defined in a manner suitable for the use
> of the same attributes in both RADIUS and Diameter.
>
> - All other work MUST be compatible with equivalent facilities in
> Diameter, if such facilities already exist. A Diameter Translation
> Considerations section MUST be provided to describe the mapping
> that a RADIUS-Diameter translation gateway would have to implement.
>
> - The RADIUS maximum packet size (4K) will not be increased.
>
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
>
> Work Items
>
> The immediate goals of the AAAEXT 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). This
> document will also review RADIUS data types and associated
> backwards compatibility issues.
>
> - Revised NAI specification. This document, known as "RFC 2486bis"
> will revise the NAI specification to correct known errors,
> provide more details on routing, add support for privacy,
> 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.
>
> This document will be compatible with existing IETF RFCs
> on HTTP Digest, including RFC 2617, 3261, and 3310.
>
> This document will be compatible with Diameter SIP application,
> but not necessarily vice versa, as the Diameter SIP application
> supports additional functionality such as routing.
>
> - LAN attributes. New attributes have been proposed to enable use of
> authentication, authorization and accounting in wired and
> wireless LANs.
> Standardization of these attributes will enable improved
> interoperability. These attributes are defined in a manner where
> their use in both RADIUS and Diameter is possible through the
> same document.
>
> - 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.
> Dec 04 SIP authentication draft submitted as a Proposed Standard RFC.
> Dec 04 RFC 2486bis submitted as a Proposed Standard.
> Feb 05 WLAN attributes submitted as a Proposed Standard RFC.
> Dec 05 RADIUS design guidelines submitted as an Informational RFC.
> Dec 05 LAN attributes 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. Given the backwards compatibility
> issues, no
> document including sub-attributes will be considered for
> publication as
> an RFC before the RADIUS design guidelines and RADIUS/Diameter
> translation work items are completed, analyzing the issues in
> a comprehensive way.
>
> * The WG will utilize an automated 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/>
>
--
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/>