RE: RADEXT charter for comment...

[Bernard Aboba <aboba@internaut.com>]

> Primarily the M and R bits, but also the 14-bit length field.

Actually, I proposed a 14-bit *type* field; the length field is still 8
bits, although I suppose that could be extended as well.

> Here's why I think the extended length field is significant. While *any*
> octet string that fits within the length impositions of a VSA could be
> the "vendor data" part, the suggested format in RFC 2865 indicates that
> the existing RADIUS attribute structure is [re]used.  For VSA encodings
> that follow this recommendation, existing RADIUS implementations only
> need detect the VSA, and then "recursively" call the RADIUS attribute
> parser code to extract the vendor AVPs from within the VSA.

While I didn't propose changing the length field, your argument probably
remains valid given that the length field is now located in a different
place.

> The suggested format for SSA would defeat this "recursive AVP parsing"
> trick.  Is this an important tradeoff?  I'm not sure...  Does any one
> use this technique for parsing VSA sub-attributes?

Good question.  I think this may be an argument for allocating a special
type code for "SDO-specific attributes".  We could then define a special
format for that attribute and not have to worry about backward
compatibility issues.

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