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

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

Glen Zorn wrote:
> [ David Nelson ]
>   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.

  VSA's can currently only contain 247 octets of data, not 253.  This is
because they must be encapsulated inside of Vendor-Specific, which holds
253 octets, MINUS the 4 byte Vendor ID, and one byte each of Type and
Length.

  The extended attribute draft allows sub-vsa's, which have no such
restriction.  I can have a sub-vsa of (say) type 1, and 253 octets of
data.  It will need 255 bytes of room in the packet, and will thus be
split across two extended attribute VSA's.  The first extended-attribute
VSA will have "F" set, and will have length 255, and extended-length of
246.  It will include the two-byte header for the sub-vsa (with sub-vsa
length 1), and 244 bytes of the sub-vsa data.

  The second extended-attribute VSA will have "F" clear, 
[gwz] 
[gwz] OK, my point is that the scope of the 'F' bit as currently defined is
_not_ the extended attribute, it is the sub-attribute.

and will
contain the rest of the sub-vsa data (9 bytes).  It will have
Vendor-Specific length of 18, and extended-length of 12.

  At least, that's the way I read it.

  Alan DeKok.


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