[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADEXT charter, Take 8
Hi Bernard, and thanks for posting the updated
charters. Comments inline, followed by a suggested
modified charter text at the end.
Bernard Aboba wrote:
RADIUS Extensions Working Group (RADEXT) Charter
Last Modified: 2004-03-23
I still think the name is misleading. Three out of
your seven work items are generic items not necessarily
tied to just RADIUS (NAIbis, translation, and LAN
attributes).
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.
Where new facilities are being defined as attributes, these should
be designed in a manner that makes it possible to use the same
attribute definitions in both protocols. I'll volunteer to
contribute...
- 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.
Hmm... unfortunately I tend to think that beyond what Diameter
NASREQ says, this is quite application specific.
Basically, your problem is that the minute someone brings another
application to the table, the translation document suddenly needs
another revision. Also, if the translation issues were handled
per application, it would be easier to ensure that the design
of the applications makes the translation easy.
So I would prefer seeing a "Diameter Translation Considerations"
section in the RADIUS SIP extension, for instance. I'll volunteer
again...
- 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.
Add something about fixing errors, that is an important part
of the revision. What about privacy support, or did you include
that under "routing"?
- 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.
Question to prepaid experts: how compatible? 100%, or is there
some function in RADIUS prepaid or Diameter prepaid that is
not being planned for the other? I hope the basic models are
compatible at least.
- SIP support. RADIUS is currently used for SIP authentication,
authorization and accounting. Standardization of these attributes
will enable improved interoperability.
I'd like to add something about compatibility with existing
IETF RFCs on HTTP Digest on this...
Also, add something about compatibility. I think the functionality
of Diameter SIP is bigger than in RADIUS SIP, so maybe a note
about not necessarily being able to translate from Diameter to
RADIUS in all cases is appropriate.
- 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.
I'd prefer seeing this work ready sooner but I consistently surprise
myself how long everything takes, especially for my own drafts ;-)
OTOH, the charter does not prevent work being finished sooner...
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
The IESG will (unfortunately) strip the QC plan from the
charter when they approve it, I have recent experience
from this... nevertheless, I believe its valuable to keep
it in the proposed charter and it should be followed later
in the work.
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.
I think this approach to subattributes makes sense.
* 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.
Based on the above comments, I'd like to suggest the
following text as the charter:
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/>