RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt

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

Glen Zorn wrote:
> [gwz] It is -- the problem with "subattributes" as described in RFC 2865
is
> that they must fit in a single VSA.  With this draft, we open up the
> possibility (with the "continuation" bit) of having really huge attributes
> containing subattributes that themselves are larger than a single VSA.  It
> seems like we either need to restrict the usage of subattributes or decide
> on one or the other.

  The *extended* attributes can be larger than 256 octets, due to the
continuation flag.  Inside of the extended attributes, any
sub-attributes do not have a continuation flag, and their "length" field
is still 8 bits.  So they can be a few octets longer than an RFC 2865 VSA.
[gwz] 
[gwz] I'm not sure where you got that idea, but I don't think it's really
accurate.  Here's a picture of the extended attributes as they stand right
now:

   +---------------------------------------------------------------+
   |                    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 (26)   |  Length       |      Vendor-Id (0)            |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value
   +---------------+---------------

[gwz] As you can see, both the Fragment flag and the Tag are included in the
sub-attribute if we follow the convention established in RFC 2865 that
sub-attributes include everything after the Vendor-/Extended-Type field.

...


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