RE: RADEXT charter for comment...

["Nelson, David" <dnelson@enterasys.com>]

Bernard Aboba writes...

> On this subject, I think that a suggested SDO-Specific Attribute (SSA)
> format can do better than what is proposed in RFC 2865.  The suggested
VSA
> format in RFC 2865 only has a single octet Type field.  That is too
small:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           | Vendor type   | Vendor length
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Attribute-Specific...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Agreed.

> A 16-bit Vendor type field might make more sense; this is large enough
> that one might even be able to squeeze in a 'M'andatory bit, and a bit
> reserved for future use, as follows:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           |M|R|      Vendor type
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Vendor Length |       Attribute-Specific...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

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.

-- Dave




> 


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