re: RADIUS STOP packet. (Was Re: (ASCEND) Radius: stop use... (fwd)

[MegaZone <megazone@megazone.org>]

Once upon a time Mitchell Arnone shaped the electrons to say...
>as if they are the only Remote Access vendor with unique (non standard) 
>RADIUS attributes.  They are not!  As a matter of fact, SHIVA also has a 
>list of unique RADIUS attributes equal to or greater than those of Ascend.

They had a number, but not as many as Ascend in any dictionary I've seen.

Also, Shiva jumped onto VSAs quickly.  Once the standard supported a way
to encapsulate vendor attributes they took it, Ascend waited years.  Also,
Shiva had a rather clever way of doing VSAs before VSAs were official.  You
could pick an attribute number, add a special attribute to RADIUS and set
the same number on the Shiva - then use that to encapsulate other strings
as VSAs.  Pretty close to what VSA ended up being officially.  They also
used a standard RADIUS server and have been good about complying with the
standard and using official attributes whenever possible.

>standards but in my experience, if every NAS vendor limits their use of 
>technology to only that which is written to a draft standard, we would be 
>complaining to these same vendors complaining why they cannot meet our 
>needs in areas not covered in these standards.  I am happy that Ascend 

I don't argue with this - my beef, crusade some would say, is when the
standard offers a way to do something and the vendor creates their own
non-standard alternative to do exactly the same thing.  This is NOT good
for interoperability, and makes life hell for 3rd party vendors.  It is
Microsoftish at best.  And if you develop a way to do something that the
standard later provides a method for, why persist, for years, in NOT
supporting the standard?  This is not a service for anyone at all.  Ascend
users can't take advantage of emerging features in RADIUS servers because
TAOS doesn't listen to some standard attributes, preferring Ascend specific
attribs that do the same thing.  It limits choices.

It also galls me when a standards body concurs that a protocol is not
designed to be, say, a configuration or resource management protocol.  Then
one vendor decides they're going to do it anyway.  There is no reason for
that.  Even if they like the protocol that much, you can easily just run it
on another port and hack the hell out of it to your heart's content.  That
would give you even more freedom and control to boot.

Over the years I've worked with so many people who have had to fight with
interoperability issues caused by vendors doing their own thing.  Anyone in
a mixed environment may run into trouble just trying to get their RADIUS to
talk happily to all of their boxes.  And, by far, the biggest thorn is Ascend.
Cisco, 3Com, Lucent, Nortel...  They all interoperate fairly well with a
plain vanilla server.  Vendor additions have either always been as VSAs or
were migrated there well back.  Add a MAX and you need to start changing 
things.  I guess I finally got so sick of it that I just want to hear one
good explanation for the decisions made.

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