RE: Approval for RADIUS extension working group

[Randy Bush <randy@psg.com>]

>> 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
>    WG)

there is always 'interest.'  what is hard is finding real
will-do-work interest within a clear and very tightly-scoped
charter.

> 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
       pursued.

    -- 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
       considered?

> c. Need to have drafts fitting within the charter.

yup

> d. Need to have competent, committed people signed up to do the work
>    described in the charter.

yup, both authors and reviewers.

randy


--
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/>