Real Time Ascend Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

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

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.

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

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?

>customizing it for themselves and I believe it would be pretty easy to add
>on VSA support for yourself if you know C.

Or just run Cistron.

I still maintain hope that Lucent, to date a stickler for standards
compliance, will clean this up post-merger.

-MZ
-- 
-=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
<URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
"A little nonsense now and then, is relished by the wisest men" 781-788-0130
<URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>