RE: Questions on modified Extended Attribute format?

["Glen Zorn" <glenzorn@comcast.net>]

>  WiMAX uses the same attribute format as proposed here.  Changes that
> are incompatible with WiMAX should be discouraged.

I would agree.   If the extensions remain compatible with WiMAX then
the amount of code duplication will be minimized.

[gwz] 
If we're suddenly worried about the size of code for processing VSAs, it
would seem to make much more sense to be compatible with cisco's VSAs since
they are far more widely deployed than WiMax's (and probably always will
be).
[/gwz]

>  If it's just stealing a bit (which WiMAX doesn't use), that sounds
> fine.  The ability to group legacy RADIUS attributes via a method other
> than tags would be good.
>
>  One question: If we DO permit this for legacy RADIUS attributes, what
> does the "C" bit mean?  Do we use the WiMAX method for splitting
> attributes encrypted with the "Tunnel-Password" method?

We need to be careful about feature creep here.  The original purpose of
the Extended Attributes document was to extend the RADIUS attribute space.

If the document is now taking on new problems (extending capabilities of the
RADIUS protocol or changing the semantics of existing attributes) then that
problem needs to be clearly stated, and justification needs to be provided. 

[gwz] 
I'm not suggesting anything of the sort: the capabilities for sending large
attributes & grouping them already exist (although in limited ways); I'm
talking about standardizing these existing capabilies, not adding new ones.
[/gwz]


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