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

[MegaZone <megazone@megazone.org>]

Once upon a time Matt Holdrege shaped the electrons to say...
>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.

The same functionality could have easily been delivered in another way -
as other vendors did.  There was no -need- to corrupt RADIUS.

>Drafts are drafts and obviously subject to change. We have implemented some

And RFCs are subject to updates and sometimes changes.  Though the only
real changes in recent drafts were caused by the need to renumber some
attributes.  And what was the main cause there?  Ascend grabbing attribute
numbers for an early implementation that didn't match what was assigned by
the WG - causing a conflict in numbering.  There have not been many changes
that would impact an implementation, nearly all changes have been additions
of new attributes or attribute values.

>of the drafts when customers demand it. But that doesn't change the fact
>that the WG has stalled.

This is an *OPINION*.  I'm sure you are aware that opinion != fact.  Not
everyone would agree with you, obviously.

>You couldn't be more wrong.

You have not presented any factual basis to your claims.  I've seen 
everything on the WG list for a number of years, I regularly correspond 
with RADIUS implementors, engineers with a number of NAS vendors, many ISPs,
etc.  I have never seen evidence that supports your claims either from a
public source or from my private contacts.  If you are going to claim the
IETF WG is a failure I would expect you to back up such a strong claim.
It may be a failure in your eyes, or in Ascend's eyes, because they failed
to adopt most of Ascend's 'extensions' to RADIUS.

In fact the number one bitch I hear from RADIUS implementors is the "bullshit"
(that's the most common descriptive word used) Ascend has shoveled into
RADIUS that they now have to code into their products to work with the
Ascend installed base.  No other vendor engenders such a negative response.
Some minor grousing over 3Com's wacky VSA format, but that's to be expected.
If you work on a server you have to keep making exceptions for Ascend
compatibility.  I've heard from a number of vendors that that is their
biggest headache - you implement the RFC and it works for pretty much 
everyone except Ascend.

Why does Ascend still persist in using proprietary attributes for things
that have had RFC equivalents for years now?

Why did it take Ascend approximately 2 years to introduce VSA support,
in the meantime they continued to add bogus attributes?

These should be simple questions.  I haven't seen Ascend answer them.
Surely you can't claim implementing VSA support in TAOS or RADIUS is too
complex.  In fact, I think it was you who recently stated that the it
should be easy for someone who knows C to add it to the free server.

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

I know it is not an official IETF group at this time.  THough some IETF
WGs have started to borrow from DIAMETER.  It is probably the most evolved
next-generation AAA protocol at this point.  There seem to be good odds it
will be adopted by the AAA WG, at least as an option to be considered.  When
first introduced I thought 'RADIUS 2' was a bit silly, but a lot of things
have been ironed out and DIAMETER is shaping up into a nice framework.  My
real concern there is seeing it bloat too much since everyone wants it to
do everything.

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

This sounds like a cop out.  You accuse the IETF WG of being stalled and
failing.  You duck all questions about Ascend's practices, or give hollow
answers about how users demanded the functionality - does this mean it had
to be via RADIUS?  Could not have Ascend taken RADIUS and made 'ascendd' to
handle all of the non-AAA junk that doesn't belong in RADIUS?  You could have
used the same framework and run it on a different port and avoided the whole
mess.  Livingston/Lucent based ChoiceNet on RADIUS and did just this to 
avoid polluting the RADIUS space.  Doing this would have given Ascend even
more freedom to modify the server.

I'm asking direct questions.  I help folks with RADIUS constantly, and 
Ascend's bogons have been a thorn in my side for years.  I've tried to
understand why they persist, but I can't see any logical reason for it.
It wasn't my intention to insult anyone, my statement of engineering laziness
was overly harsh - engineers unfortunately are not always free to make the
best choices.  So perhaps it was management ignorance or just bad management
telling the engineers to take the ugly path.  But *someone* made the 
decisions that led to this.  And to persist in this course of action.

I have repeatedly brought this up in the online communities and when I do
talks.  I hold Ascend up as an example of what not to do, because they make
a good example, far and above anyone else.  No one from Ascend has ever
presented a logical argument for their decisions regarding RADIUS.  I can
even see adding things before VSA - but VSA is not hard.  VSA has existed for
a few years now - why did Ascend keep creating bogons when there was a clean,
official option?  There has to be some reason.  Why does Ascend still use
things like Ascend-Max-Session-Time instead of Session-Timeout?  I believe
they also still don't do Access-Challenge but return an Ascend-Third-Prompt,
or something like that (not worth checking the dictionary).  Simple question -
what is the reason for Ascend's serious lag in implementing the standard?
For continuing to rely on proprietary systems in lieu of them?  

If the WG was indeed stalled as you claim, would not that provide Ascend
a long period with no major changes that they could use to catch up on 
their implementation?

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