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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Specific comments on the draft:

Abstract:   

   In order for the Remote Authentication Dial In User Service protocol
   to continue to support new applications, the RADIUS attribute space
   must be extended beyond the current limit of 255 possible attribute
   types.  This document defines a mechanism to extend the base RADIUS
   attribute types while maintaining backwards compatibility as well as
   compatibility with Diameter.

If this document is to address grouped attributes (AVPs) and structured
(complex or multi-part) attributes, we should so indicate in the abstract.
That description should be included in the Introduction section, as well.

Section 2.

   A need to group RADIUS attributes together has become more prevalent
   in current work.  Therefore, the proposed scheme NUST provide a
   mechanism to group attributes.

s/NUST/MUST/

Section 4.

   Up-to-date values of the RADIUS Extended-Type field
   are specified in the most recent "Assigned Numbers" IANA [RFC3575] .
   Values XXXX-YYYY are reserved.

Actually, RFC 3575 does not contain the RADIUS Registry, that is located at
the following URL: http://www.iana.org/assignments/radius-types.  RFC 3575
documents some RFC-defined and some legacy "bootlegged" assignments, and
defines a process for IANA assignment going forward from its date of
publication.  It is not the registry.  The draft text should clarify the
distinction.

As currently being discussed in this thread, the draft does not permit the
encoding of sub-attributes within an Extended RADIUS attribute format.  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.

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