RE: Approval for RADIUS extension working group

[Avi Lior <avi@bridgewatersystems.com>]

Thanx Randy for the clarification.

Are we going to have a BOF in MN?


Regarding Prepaid (Note I am not the official voice of 3GPP2)

We (the authors of the Prepaid Draft) wanted to describe how 3GPP2 does
prepaid so that others wont re-invent RADIUS based prepaid and so that 3GPP2
would have some interoperability.  Since the prepaid scheme has already been
standardized in IS-835C it would never appear in the 3GPP2 dependency list.
Driven by WLAN 3GPP2 Interoperability work,  in the next few months 3GPP2
*may* have some dependency on RADIUS prepaid solution.

Regarding the subtypes that is used.  I am not wedded to subtypes and if we
have to change them so be it.

Regarding prepaid for WLAN.  There is interest in that.  It was expressed by
IEEE at the meeting in Wein, by customers that we are talking too and by a
handfull of vendors and operators that we are talking with.   As I said
before a bunch of us are working on this very issue.  We are looking at the
various models of prepaid that are appropriate for WLAN and to see which
one's make sense etc...

Avi




> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com] 
> Sent: Wednesday, September 24, 2003 5:06 PM
> To: Bernard Aboba
> Cc: radiusext@ops.ietf.org
> Subject: 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
> >    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/>
> 

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