RE: RADEXT charter for comment...

[Bernard Aboba <aboba@internaut.com>]

> I think the inclusion of the two bit fields (M, R) and a 14-bit vendor
> type field would be a good idea.  If we are to do this, I would
> recommend using a different type code than 26, in aid of backward
> compatibility.

I suppose that the issue of backward compatiblity is the presence of an
'M' bit, correct? VSAs are other-wise always assumed optional and it is
probably not appropriate for something other than an SSA to carry such a bit.
Or is there some other issue too?

> I would also be interested in hearing the debate on
> whether this ought to be open to "Extended VSA" usage or ought to be
> limited to SSA usage.  I tend to prefer the latter.

I guess the answer depends on how great the need is for grouped
attributes.  Personally, I haven't found the case compelling so far, but
on the other hand, if done in this manner it doesn't run afoul of RFC
2865 either.

> On a related subject, I am not much in favor of the notion of using a
> Vendor ID or "0" to generally extend the RADIUS attribute space, within
> the existing VSA attribute, but would be interested to hear pros and
> cons of that approach.

I guess the "pro" is that we might kill two birds with one stone: put to
rest the arguments over support for sub-attributes, and potentially extend
the RADIUS attribute space.  Since VSAs can already contain sub-attributes
one could argue that such a proposal is backward compatible with RFC 2865,
at least if one leaves aside the 'M' bit proposal.

The con, is that if the goal is to make things easy to deploy, then it's a
lot simpler to use standard data types and add values to the dictionary.

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