RE: Questions on modified Extended Attribute format?

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

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

  Yes... but strings?  Really?

[gwz] 
I know, but the point stands, no?
[/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.

  If we can get the functionality of the new extended attributes applied
to legacy RADIUS, I'm all for it.  But I don't want it to be a lot of
work... that causes bugs and interoperability issues.

  My preferences are to leave the extended attributes defined the way
they are right now.  Anything else starts to cause issues.

  e.g. legacy attributes encapsulated in a VSA.... what happens with
legacy implementations?  The only image that comes to mind is a cloud
going *boom*.

[gwz] 
;-)  Not sure why, though -- they would be easily identified & it seems like
the code we're talking about should already exist (that's why we chose these
rather modest techniques in the first place, right?).
[/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/>