[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Specific comments on the draft:
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.
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.
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
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
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.