RE: RADIUS Calling-Station-Id for WiMAX

[Avi Lior <avi@bridgewatersystems.com>]

 See inline....

> -----Original Message-----
> From: Mike Bean [mailto:bean@alcatel-lucent.com]
> Sent: September 11, 2008 10:55 AM
> To: David B. Nelson
> Cc: Avi Lior; 'Glen Zorn'; 'Ray Bell'; 'Matt Holdrege';
> 'Bernard Aboba'; 'Congdon, Paul T (ProCurve)';
> radiusext@ops.ietf.org; 'Dan Romascanu'
> Subject: Re: RADIUS Calling-Station-Id for WiMAX
>
> All,
>
> I think backwards compatibility is poor excuse to preserve 6
> octet Calling-Station-Id given Alcatel-Lucent and, according
> to ASN-GW documentation, Cisco use RFC 3580
> Calling-Station-Id format with WiMAX.

I think the poor excuse here is that you want WiMAX folks to change because you didn't read and follow the specification.  For you its not a backwards compatibility issue because you didn't follow the specification and if you followed the specification you would have been screaming it's a backwards compatibility issue.  You could have changed it to the 3580 way for more then a year now.

> I have a trace that shows Huawei ASN-GW sends
> Calling-Station-Id as 12 hex characters lowercase, not
> binary.

3580 says upper-case. So they don't follow *ANY* recommodation or standard either. Why are we writing these standards or recommendation if people don't read and follow them.

> Not sure what other vendors send but at least there
> is some confusion among some vendors.

Vendors that don't read the or any specifications for that matter.

> I think a survey of
> additional WiMAX ASN-GW vendors would show whether there is
> an actual backwards compatibility issue.

But as you state here there is no standards way we can agree to follow. In your case you want 3580 with upper case, and Huawei wants 3580 with lower case; WiMAX tossed the case issue with the HEX encoding issue; not to mention the dash vs. colon issue and stuck with the lowest common denominator which is binary.

Avi.

> BR,
>
> Mike
>
> Michael Bean (Mike)
> Alcatel-Lucent
> AAA Product Group
> 3461 Robin Ln, Ste 1
> Cameron Park, CA 95682
> Email: bean@alcatel-lucent.com
> Phone: 530 672 7577
> Fax: 530 676 3442
>
>
>
> David B. Nelson wrote:
> > Avi Lior writes...
> >
> >
> >> It seems to me that a binary representation would be a more
> >> appropriate treatment for this value.
> >>
> >
> > Perhaps, but RFC 3580 followed many years of tradition in
> choosing the
> > dashed-ASCII representation.
> >
> >
> >> So it is best to leave the presentation to a presentation
> layer and
> >> not the RADIUS layer.
> >>
> >
> > Well, no.  The syntax and semantics of RADIUS attribute are
> a matter
> > of the RADIUS protocol.  There is no presentation layer,
> and contrary
> > to commonly held belief, RADIUS is not simply a transport
> protocol.
> > :-)
> >
> >
> >> It isn't busted.
> >>
> >
> > Not within the "walled garden" of WiMAX.  On a global
> interoperability
> > scale, I claim that it is broken.
> >
> >
> >> And changing it now will break backwards compatibility.
> >>
> >
> > Yes.  The question is whether to "cowboy up" and fix it now.
> >
> >
> >
> >
>

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