[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT charter, Take 8
Bernard,
Looks OK to me.
I have two editorial comments:
- would be useful to list references for the 'equivalent facilities' in Diameter (as done for the existing RADIUS RFCs)
- the first paragraph in the Quality Control Plan - this WG will not be chartered until...' will become not relevant after the Charter is approved. I have no problem with its content, it just cannot be part of the Charter.
Regards,
Dan
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba
> Sent: 24 March, 2004 5:34 AM
> To: radiusext@ops.ietf.org
> Subject: RADEXT charter, Take 8
>
>
> RADIUS Extensions Working Group (RADEXT) Charter
> Last Modified: 2004-03-23
>
> 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.
>
> 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). This
> document will also review RADIUS data types and associated
> backwards compatibility issues.
>
> - RADIUS/Diameter translation. This document will describe the
> best current practices for RADIUS/Diameter translation.
>
> - 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.
> Dec 04 SIP authentication draft submitted as a Proposed Standard RFC.
> Feb 05 WLAN attributes submitted as a Proposed Standard RFC.
> Feb 05 RFC 2486bis submitted as a Proposed Standard.
> Dec 05 RADIUS design guidelines submitted as an Informational RFC.
> Dec 05 RADIUS/Diameter translation document submitted as a BCP.
> 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/>