RE: The RADIUS attribute space: an assessment

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alan DeKok <> supposedly scribbled:

> "Nelson, David" <dnelson@enterasys.com> wrote:
>> Let me ask if this is different for RADIUS?  I can't imagine all of
>> the enhancements to RADIUS you've mentioned -- those that mitigate
>> the need to migrate to Diameter -- are included in those 5-year old
>> versions of system FW?
> 
>   Nope.  But that doesn't matter.  See below.
> 
>> Why is it more attractive to add new features to, and ship new
>> versions of, RADIUS client and server software, than it is to ship a
>> Diameter implementation?
> 
>   It's not.  The choice for a site admin is usually one of the
> following: 
> 
>   a) upgrade the AAA server to Diameter, and learn a whole new way to
>      configure & administer things (assuming that it includes a RADIUS
>      to Diameter gateway for legacy devices), and assuming it has the
>      feature set you've come to rely on.
> 
>   b) upgrade the RADIUS AAA server to version X + 1, which just
>      happens to include whiz-bang new features.  He doesn't have to
>      learn any new configuration, unless he uses those new features,
>      in which case it's a simple delta over what he has today.
> 
>   Not much of problem making that decision, is it?  

This is a red herring: any vendor that can't keep the same interfaces for RADIUS while supporting Diameter doesn't deserve to be in business.  In fact, any reasonable Diameter "server" would look much more like b) than a) -- the "whiz-bang" new features being Diameter Base + NASREQ.

...

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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