[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Approval for RADIUS extension working group
>> What are the hurdles that keep us from having a RADIUS Extension WG?
> a. Need to demonstrate interest (e.g. a BOF with consensus on forming a
there is always 'interest.' what is hard is finding real
will-do-work interest within a clear and very tightly-scoped
> b. Need to have a charter acceptable to the ADs.
i think we have been pretty clear on this. i believe it has been
summed up in the following (plagarized):
-- Complete the specification of the Diameter/RADIUS gateway.
This is part of the NASREQ specification, which is on the
verge of being sent off to the IESG. If this specification
is very important to 3GPP/3GPP2, which is not clear, it
would be helpful if we could get input from those
organizations to make sure it is right. This is being
-- Define new RADIUS attributes for WLAN. Several
organizations are now involved in this (IEEE 802.1, IEEE
802.11, WFA, etc.) and there is the potential for
fragmentation. Since this effort is happening anyway, it
makes sense to me to do it in the IETF where an
interoperable standard can be created. Diameter AVPs can
be defined at the same time, so that RADIUS/Diameter
interoperation can be maintained.
-- Define better RADIUS transport behavior. Retransmission
behavior is undefined in [RFC2865], and this has caused
problems in deployed implementations. Achieving more
reasonable behavior makes sense. However, this goal does
NOT extend to attempting to achieve Diameter-level
reliability in RADIUS; that is out of scope.
Things not yet clear include:
-- Pre-Paid. This work item is being considered largely
because of a possible, but not completely clear, request
from 3GPP2. But, the draft on the table does not conform
to the RADIUS dictionary types defined in RFC 2865. For
example, it creates a new RADIUS attribute format including
support for "sub-attributes," supposedly because the draft
would otherwise require so many attributes that it would
exhaust the entire RADIUS attribute space. Therefore if
the "sub-type" approach is not permitted, the claim is that
an expanded RADIUS attribute space is required. We are in
the process of finding out if there really is a requirement
for this work in 3GPP2. If so, has the impact of this
draft on RADIUS/Diameter compatibility/transition been
> c. Need to have drafts fitting within the charter.
> d. Need to have competent, committed people signed up to do the work
> described in the charter.
yup, both authors and reviewers.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.