Re: Object identifier and type spaces in a rationalized RADIUS data model

[Jari Arkko <jari.arkko@piuha.net>]

john.loughney@nokia.com wrote:
> Jari,
>
> Quick question - have you looked at the backwards compatibility-ness
> of this proposal?  If new implementations support it its important
> that they don't break older implementations.

Good question. Lets see: from the point of view of
nodes that do not support this proposed new attribute,
this looks like yet another unknown attribute. It
would be passed on by proxies, ignored by receivers.
I think it would be echoed back from Access-Accept
to Accounting-Requests, and dumped as hex in accounting
records. Nodes that want to send an attribute in
this new format should be able to do that, assuming
they can be configured with a new dictionary entry
and allow a binary string as a configured value for
the attribute.

Nodes that actually want *do* something with this
new attribute would need new code. Say, if a new
attribute were defined on top of this and it would
control IP address assignment, a NAS would need
new code but probably the home AAA server could
generate this based on a dictionary and a fixed
value given to it in a configuration file.

--Jari

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