[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on modified Extended Attribute format?
...
> [gwz] I don't know where the "from scratch" comes from; there is a format
> defined in
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00
> .txt. I am suggesting adding a single octet to the format which
Opens it up for change again, after a long discussion, where everyone
had agreed that the format in -00 was acceptable.
> Interesting definition of "incompatible". If that is in fact the standard
> to be met we may as well just fold up our tents and go home since there is
> _no_ change that could be made which would have "*zero* impact on
> implementations that don't understand".
It's not about changes, it's about *compatible* changes to the
*standard* attributes. Let me re-phrase:
- standard RADIUS attributes in a VSA MUST be compatible with existing
implementations that only understand standard RADIUS attributes
Put that way, it's obviously impossible. Since RADIUS has no
capability negotiation, there's no way for the NAS to tell the server it
is capable of that new functionality.
Therefore, the proposed change is incompatible with existing deployments.
[gwz]
As I said, put that way or any other way you like, ANY change is
incompatible with existing deployments. If one were to add a new "standard"
attribute (in the old format or the proposed VSA-like format or any other)
it would be incompatible with existing deployments. The whole idea of
extended attributes REQUIRES that existing deployment be updated, no matter
how they are formatted.
[/gwz]
> If we can't put standard attributes into the new format, then we
> should just pick a better format, and ideally one that's been deployed.
> The WiMAX format (plus grouping) seems to fit that definition fairly
well.
>
> [gwz]
> Can you tell us what it looks like?
> [/gwz]
The format in -00, which achieved WG consensus after long and
protracted discussion.
[gwz]
Actually, while the timeframe was long, the discussion wasn't: I've only
received a couple of comments on it in the last months. It _did_ take an
inordinate amount of time to reject the 'Diameterization' of RADIUS,
though...
[/gwz]
Alan DeKok.
--
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/>