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

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

...

As currently being discussed in this thread, the draft does not permit the
encoding of sub-attributes within an Extended RADIUS attribute format.  
[gwz] 
Actually, it does (as illustrated in the examples), it's just not very
explicit about it.

RFC
2865 permits this practice for VSAs with a non-zero Vendor-ID, i.e. non-IETF
"vendors".  RFC 2865, Section 5.26 reads, in part:

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

Should we include similar language in this draft, perhaps with a prohibition
on nested sub-attribute for the sake of simplicity, in this document?  I
thought that the presentation on this draft at IETF-69 indicated that this
capability would be available.
[gwz] 
[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.

As long the recommended structure of sub-attributes is standardized and
limited, so as to limit the variations of format that servers would be
expected to cope with, I think this would be a good feature, in support of
structured, multi-part attributes.

I understand that the tagging feature can also support structured data, in
an indirect fashion, but its design is optimized to support related groups
of individual attributes (grouped AVPs).  That's the way Diameter addresses
the issue of structured data.

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.

Discussion?




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


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