Re: (ASCEND) Ascend RADIUS - what now? (fwd)

[Matt Holdrege <matt@ascend.com>]

At 01:45 AM 3/29/99 -0800, MegaZone wrote:
>Once upon a time Matt Holdrege shaped the electrons to say...
>>Normally, but in the case of Radius, the IETF failed. Some of the purists
>>in the IETF really hated the direction that Radius went and all the work
>>that Ascend and other vendors wanted to do with Radius was stalled. It's
>
>Ascend is pretty much alone with most of the stuff done.  Using RADIUS as a
>configuration system?  I can't think of any other vendor doing that.  IP
>server?  Etc.

Ascend didn't come up with that. Our customers did. Take you complaints up
with the ISP's. I don't think you'll get any sympathy since their business
relies on the Radius features that we've delivered.

>>been years since any significant Radius changes have made it into RFC's. In
>
>You are aware of the recent drafts I presume.  The core drafts aren't going
>to change - their purpose is to document the protocol as is.  New things
>are in the Extensions Draft, the Tunneling Drafts, the SNMP MIB drafts, etc.
>I don't see how you could claim that RADIUshas not changed - many new
>capabilities have been added through the additional drafts.

Drafts are drafts and obviously subject to change. We have implemented some
of the drafts when customers demand it. But that doesn't change the fact
that the WG has stalled.

>>Ascend and many other vendors have had lots of ideas for improving Radius.
>
>>We've wanted to standardize all the special Radius attributes that we added
>>as result of our customers requests. But the Radius working group chair and
>
>There have been calls for support to add things like local IP, named pools,
>etc - and there hasn't been the vendor support.  You can find that right
>in the archives as well.  Some things are very specific to a vendor, hence
>the VSAs.  I have dictionaries from just about every vendor.  There are
>a few things that overlap that may make sense to standardize, but the vast
>majority of Ascend's bogons, or 3Com's VSAs, etc, are specific to that
>vendor, without equivalents in other dictionaries.
>
>>Unfortunately the IETF has not fixed the Radius working group nor have they
>>allowed any other AAA protocol to begin. They are just now starting a
>
>Sounds like sour grapes - I've been on the list and have read every post
>made to it since 1995.  Perhaps not as long as some, but pretty damn long.
>Anyone who wants to see for themselves can look inthe archives.  Most of
>the proposals died because they did not garner enough support from other
>vendors.  And if that is the case then it SHOULD DIE - if the vendor wants
>to do it, that's why VSAs were created.  If it is outside the scope of the
>entire protocol as agreed upon by the WG, then they should use something
else.

It sounds like you have a superficial understanding of what is going on.
But there is a lot more to it. I'll stand by what I originally wrote.

>Ascend proposed a lot, and did a lot, that just died when proposed.
Obviously
>it did not have the support needed to be a standard.  That's all there really
>is to it.

You couldn't be more wrong.

>>generic AAA working group, but it has a very wide scope which (IMHO) will
>>prevent any real replacement for Radius for a very long time.
>
>Are you unaware of Pat Calhoun's DIAMETER group?  The protocol is well along,
>and has input from a number of large vendors.  It is also designed to be
>backwards compatible with RADIUS (though TCP is the primary protocol there
>is a draft for optional UDP support).  It seems to be enjoying increasing
>popularity, and some other WGs have started borrowing the DIAMETER framework
>for their needs.

Diameter is not an IETF group. I like Diameter and hope that it can be
introduced in the new AAA WG. But as of now, there is no IETF Diameter group.

>Or do you write it off?
>
>>So in the meantime we added all those so called bogus attributes in
>>response to customer demand. Also due to customer demand we've now added
>>VSA support. It's there both in the 7.0 TAOS code and in our commercial
>
>About bloody time too.  There was no reason not to start using VSAs when
>first introduced, other than engineering laziness.  There was no reason
>to continue the practice of polluting the attribute space once there was
>a standard way to add vendor attributes.  First you complain that the IETF
>WG squashed vendor proposals for additions, then defend vendor pollution and
>failure to use the provided system.

You ignorance is not only making you look bad, but insulting our engineers
pretty much shuts you out of any future discussion with me on this topic.

++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>