Re: Rationalizing the RADIUS data model

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

Hi Bernard,

I have a question about your old-mail... I'm not
sure if this was already discussed.

> a.  Using a Vendor-Id of zero (0) within the existing VSA attribute 26,
>     in order to define an extended IETF standard attribute space that
>     would mirror the VSA data model, including support for sub-attributes.
>
> b.  Creating a new attribute that would mirror the VSA data model,
>     including support for subattributes.
>
> As I understand it, the primary argument for b) over a) relates to
> potential backward compatibility issues with a).  To determine whether
> this is an issue or not we will need to survey existing implementations.

So, just for my clarification: what are the "potential
backward compatibility issues" with a)? I think we don't
have vendor=0 attributes yet, or do we? If we don't have
them, it appears that the IETF can define the contents
of the extended attribute as we please, no?

Or is the issue that when migrating, say, an SDO-defined VSA
into the IETF space we have to change not just the attribute
number, but also the format due to the M and R fields (and
maybe data type)?

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