[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADEXT WG Charter, Take 10
Bernard Aboba wrote:
Just thought I'd post the most recent charter text, so that folks could
have a last look at it. Based on the previous discussion, it did not
appear that there was a concensus to change the focus to handling both
RADIUS & Diameter in a single charter.
I hate to be the one who complains all the time,
but... I think the question was more complex than
changing the focus to handle both protocols. I
think the question you asked from the group was
whether there needs to be a re-orient to handle
both protocols. But the original proposal from
me was not exactly that. It was a group of things:
a. Have the name reflect the already agreed scope.
b. Reword the intro too.
c. Delete separate item for R/D compatibility and
handle that per application, in the work items.
Add specific text to this effect.
d. Add a requirement that when plain attributes are
added (as in LAN), they should be directly R/D
compatible.
e. Change the description of 2486bis a bit to
include fixing errors and handling privacy.
f. Specify what the Digest work has to be compatible
with (RFC 2617/3261/3310).
Note that there's no "merge with AAA WG" or
"add a lot of Diameter work into the charter".
Now, in the discussion on the list the following
comments were made:
o Suggestion was supported by John, Greg, David
(and me of course).
o Parviz and Farid said that the set of work
items should stay roughly the same, that
the name change is a different issue (they
didn't say what they thought of it), and
that R/D compatibility issues can be considered.
o Richard, Kuntal and Avi didn't want to have
a common focus. (Though I judging from Avi's
e-mail he seemed to be responding to a proposal
to merge the AAA and RADEXT WGs, which I don't
think anyone was proposing.)
o Wolfgang seemed to be OK with my suggested
formulation of Digest charter entry.
o Lionel had a question on what my proposal was.
Not sure if he got an answer to it.
Its kind of hard to determine what the consensus for
all of my items was based on this information. I think
it is clear that everyone, including me, agreed that the
set of work items should stay the same (with the
possible exception of the R/D compatibility item).
I think there was support for doing the R/D compatibility
stuff the way that I proposed (my points c and d).
Wolfgang seemed to be OK with point f. No one responded
about point e, but I'm the current document author for
that, so can we assume that the if there were no complaints
then its acceptable?
Points a and b are harder. Its kind of hard to tell
whether the people who said no said so because they
didn't want to add new work items or because they
didn't agree that the current set of items justifies
the name.
So where does that leave us? None of my proposals
got into version 10 of the charter, except point
c sort of half-way: R/D item was deleted from the
charter but not replaced by a requirement to have
a Diameter Translation Considerations section :-(
I still do believe points c through f are important
technical requirements to state in the charter, and
I did not see an opposition for these points -- can
we include at least them in the version 11?
Regarding points a and b I don't know what to
do. I still think its important, but I'm getting
tired of arguing. Would it help to ask the issue
again, making it clearer what the proposal is
(i.e. no scope extension)?
--Jari
---------------------------------------------------------------------
RADIUS Extensions Working Group (RADEXT) Charter
Last Modified: 2004-04-12
Chair(s):
David Nelson <dnelson@enterasys.com>
Bernard Aboba <aboba@internaut.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 existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter, the
following restrictions are imposed on extensions considered by the RADEXT
WG:
- All RADIUS work MUST be backward compatible with existing RADIUS RFCs,
including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All RADIUS 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 RADEXT 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, and may address common
RADIUS implementation errors and fixes.
- 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.
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
authentication, authorization and accounting in wired and
wireless LANs. Standardization of these attributes will enable
improved interoperability.
- RADIUS 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 RADIUS design guidelines submitted as an Informational RFC.
Dec 04 SIP RADIUS authentication draft submitted as a Proposed Standard
RFC.
Feb 05 WLAN attributes draft submitted as a Proposed Standard RFC.
Feb 05 RFC 2486bis submitted as a Proposed Standard.
Dec 05 LAN attributes draft submitted as a Proposed Standard RFC.
Dec 05 RADIUS 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/>