[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS Calling-Station-Id for WiMAX
- To: "David B. Nelson" <d.b.nelson@comcast.net>, 'Glen Zorn' <glenzorn@comcast.net>, 'Ray Bell' <ray@grid-net.com>, 'Matt Holdrege' <Matt.Holdrege@strixsystems.com>, 'Bernard Aboba' <bernard_aboba@hotmail.com>, "'Congdon, Paul T (ProCurve)'" <paul.congdon@hp.com>, 'Mike Bean' <bean@alcatel-lucent.com>, "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>, 'Dan Romascanu' <dromasca@avaya.com>
- Subject: RE: RADIUS Calling-Station-Id for WiMAX
- From: Avi Lior <avi@bridgewatersystems.com>
- Date: Thu, 11 Sep 2008 13:29:59 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- In-reply-to: <685F3FC2BA114A07BBED15A9766D544E@NEWTON603>
- References: <A0941C2137BCA349AA3D32CDA3AEBCA11868B8@tuna.grid-net.com> <000601c9136c$a48adf10$eda09d30$@net> <8A8CFE8F89C38B41A749C19328C76D6308A47A7662@exchange02.bridgewatersys.com> <685F3FC2BA114A07BBED15A9766D544E@NEWTON603>
See inline....
> -----Original Message-----
> From: David B. Nelson [mailto:d.b.nelson@comcast.net]
> Sent: September 10, 2008 3:25 PM
> To: Avi Lior; 'Glen Zorn'; 'Ray Bell'; 'Matt Holdrege';
> 'Bernard Aboba'; 'Congdon, Paul T (ProCurve)'; 'Mike Bean';
> radiusext@ops.ietf.org; 'Dan Romascanu'
> Subject: RE: RADIUS Calling-Station-Id for WiMAX
>
> 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.
And 3580 also inherited the MAC tradition that even in 802-land the MAC address is not standerdized (As per another one of my emails -- I want to hear what Paul has to say)
>
> > 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. :-)
Exactly so why are we worried about how the attribute is formatted. Specifically for humans. The dash-notation or colon-notation is used by humans or text based protocols. If RADIUS wanted to stay out of the presentation layer business it should have kept the MAC codification as it appears over the wire at the NAS. Conversion to other formats should be done as late as possible.
>
> > It isn't busted.
>
> Not within the "walled garden" of WiMAX. On a global
> interoperability scale, I claim that it is broken.
By busted I mean that it isn't breaking even the holy grounds of the IETF. No IETF AAA standard requires MAC address to be codified the way you state. The standards says that
"The actual format of the information is site or application specific."
But I do agree that aligning with the RECOMMENDATION of 3580 would have been a good start.
> > And changing it now will break backwards compatibility.
>
> Yes. The question is whether to "cowboy up" and fix it now.
Right. And that is a political discussion that is best to have in WiMAX and NOT here. I have no idea why it was brought to RADEXT since it hasn't even been discussed at WiMAX and there is no technical opposition to fixing the problem in WiMAX as far as I can tell.
>
>
--
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/>