RE: RADIUS V2

["Nelson, David" <dnelson@enterasys.com>]

Avi Lior writes...

> > > What happened between Charter 3,4 etc. (no new attribute types)
and
> > > now? We should be asking these questions as well no?
> >
> >   This is a good point.  I can see a proposed
> > Diameter-Message attribute carrying diameter attributes, and
> > not much more.  It can then be an opaque type to everyone who
> > doesn't use it.
> 
> As you would recall, I took a lot of heat for proposing an attribute
that
> was opaque to someone who doesn't use it.
> 
> In this case though "base RADIUS" does "break".  All end-points (final
> RADIUS servers and clients) will have to parse this new attribute
type.
> No?

Yes.  The charter has evolved, and the original desire to not "break"
existing RADIUS implementations (in particular data dictionary driven
implementations) has yielded to the desire to obtain better
interoperability with Diameter, simplify RADIUS/Diameter translation
requirements, and to unify the IETF standard, SDO-Specific and
Vendor-Specific attribute data models.  The charter includes finding
ways to accommodate complex data types, while maintaining backwards
compatibility with RADIUS RFCs and forward compatibility with Diameter
RFCs, as part of the Design Guidelines document.

It seems clear to me that finding an acceptable solution for complex
data types, given the constraints, will require changes to any RADIUS
implementation that wishes to use that new attribute format.  The
current goal is to find a *single*, *standard* way to accomplish this,
so that existing implementations would only need to perform such an
upgrade once.

The charter does not embrace other "improvements" to RADIUS, or any
notion of creating a RADIUS V2 or RADIUS+ protocol.


-- Dave

   

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