RE: Questions on RADIUS Extended attributes

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <mailto:bernard_aboba@hotmail.com> supposedly scribbled:

...

> RFC 2865 states that more than one vendor-specific attribute can be
> included within a RADIUS attribute of Type 26.  However, I don't
> think it describes how vendor-specific attributes can be split across
> RADIUS attributes of Type 26.  

I don't think it does, but I don't know why it would be any different than the way normal attributes work.

> One way to address this is via a tagging scheme.  

Not sure why this would be necessary.  If you think of the Vendor-Type field as just an extension :-) of the standard Type field, then on reception just cat all attributes w/the same "type" (in this case 26 + Vendor-Type) together in order, creating one massive attribute.  Where this scheme falls apart is if there are more than one XXL attribute of the same type in a message.  I think that tags can fix this, though, as well as providing a rudimentary attribute grouping capability.  With tags, the algorithm becomes "cat all the attributes w/the same (Type+ExtType) and Tag together in order"; again, this only allows one XXL attribute of a given (Type+ExtType) per attribute group, but I suspect that that is probably adequate.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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