Re: Questions on modified Extended Attribute format?

[Alan DeKok <aland@nitros9.org>]

Glen Zorn wrote:
> [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.

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

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