[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS Calling-Station-Id for WiMAX
- To: "David B. Nelson" <dnelson@elbrysnetworks.com>, "'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 14:00:50 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- In-reply-to: <0BDD72D2AC7E4F53B9B5AB4AB17E5406@xpsuperdvd2>
- References: <A0941C2137BCA349AA3D32CDA3AEBCA11868B8@tuna.grid-net.com> <000601c9136c$a48adf10$eda09d30$@net> <8A8CFE8F89C38B41A749C19328C76D6308A47A7662@exchange02.bridgewatersys.com> <685F3FC2BA114A07BBED15A9766D544E@NEWTON603> <8A8CFE8F89C38B41A749C19328C76D6308A47A76AC@exchange02.bridgewatersys.com> <0BDD72D2AC7E4F53B9B5AB4AB17E5406@xpsuperdvd2>
See inline....
> -----Original Message-----
> From: David B. Nelson [mailto:dnelson@elbrysnetworks.com]
> Sent: September 11, 2008 1:44 PM
> To: Avi Lior; 'David B. Nelson'; '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
>
> > 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.
>
> Uhhh... I think you're missing a key point here. There is
> no presentation
> layer -- the "presentation" is hard-coded into the attribute
> definitions.
Fine. Call it a hard-coded into the attribute.
> If the attribute content is intended only for human
> consumption, as are most RADIUS Accounting attributes, then
> it truly doesn't matter.
I don't know of any humans that consume accounting records. Do you? ;-)
> OTOH, if the RADIUS server is going
> to make some access control policy decision, or in general
> customize the session to be delivered, based on the content
> of an attribute, then that attribute had better have a
> standardized format, if we are to have any expectation of
> multi-vendor, global interoperability.
Right. Exactly. And since a MAC address can be presented in many different ways then it is best to convert the MAC address to the format as late as possible. So if the MAC address is stored in a database using a colon notation - which is a common form. Then we should convert it to that format as late as possible.
Today we have to format the value from a binary form at the NAS to some hex form and perhaps to some other form when it is used by the RADIUS server.
And there are issues all along with text forms. Is the seperator a dash or a colon. Are the hex digits in upper or lower case.
That is why I stated that it is best to keep the format in RADIUS in its lowest common form (binary) and do the conversion to a particular format at the last moment. It is less error prone - as you can see by all of these exchanges.
>
>
>
--
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/>