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] Good point.  So the two constructs are almost (but not quite the
same)...

(David)
> I see an advantage in directly supporting sub-attributes, in terms of a
> cleaner data model, however, I also see that diverging from the Diameter
> model of grouped AVPs may lead to greater difficulty in translation and
> coexistence.

  I'll submit the edited "guidelines" document today.  It suggests that
RFC 4005 be updated, and allow Diameter attributes of type 26, which
will transport the contents of RADIUS attributes of type 26.

  Since most Diameter servers also talk RADIUS, any translation
difficulties (mostly) go away.  
[gwz] 
[gwz] If you're going to do that, you might just as well just stick the
whole RADIUS message in an AVP (as I've suggested before) & be done w/it: no
translation, period.

The server implements attribute 26
parsing once, and then it's done.

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