Last but not least, this draft fairly universally violates several of
the guidelines given in
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, in
particular those regarding the use of tags to associate different
attributes (called "Index" in this document) and the creation of
"complex" attributes.
The issue of "complex attributes" was extensively discussed on
the RADEXT WG mailing list, and the Design Guidelines are
based on the WG consensus that was derived from the review
of this document.
In particular, Section 2.1.3 of the Design Guidelines document specifically
calls out the distinction between complex attributes which are interpreted
by RADIUS, as opposed to "opaque data" which is treated as a string
by RADIUS, and interpreted out of band:
The only other exception to the recommendation against complex types
is for types that can be treated as opaque data by the RADIUS server.
For example, the EAP-Message attribute, defined in [RFC3579] Section
3.1 contains a complex data type that is an EAP packet. Since these
complex types do not need to be parsed by the RADIUS server, the
issues arising from policy language limitations do not arise.
Similarly, since attributes of these complex types can be configured
on the server using a data type of String, dictionary limitations are
also not encountered. Section A.1 below includes a series of
checklists that may be used to analyze a design for RECOMMENDED and
NOT RECOMMENDED behavior in relation to complex types.
If the RADIUS Server simply passes the contents of an attribute to
some non-RADIUS portion of the network, then the data is opaque, and
SHOULD be defined to be of type String. A concrete way of judging
this requirement is whether or not the attribute definition in the
RADIUS document contains delineated fields for sub-parts of the data.
If those fields need to be delineated in RADIUS, then the data is not
opaque, and it SHOULD be separated into individual RADIUS attributes.
I realize that the RADIUS design guidelines
document is just an Internet-Draft, but it is a radext WG document & has
been under construction for some period of time.
The Design Guidelines document text was specifically crafted based on this
particular
draft, based on extensive discussion within the RADEXT WG.
More important than
the standardization status of the document is the question of whether
the guidelines make sense;
The Design Guidelines document has completed RADEXT WG last call with only minor
comments outstanding. If you had any concerns about whether the document "makes
sense" you should have raised them long ago -- but you did not.
if so, then it may not be such a good idea to so completely ignore them;
Far from ignoring the Design Guidelines, this document has actually been one of
the
primary motivations for creating them -- and the text in Design Guidelines has
been
specifically crafted to deal with this particular case.
If not, then maybe radext should rethink this
work item (especially since a co-chair of that WG is also a co-author of
the document under review).
Given the extensive discussion on the RADEXT WG list relating to this document
and
Design Guidelines, I have personally spent quite a bit of time with Hannes, Avi
and others
working on improving the compatibility of this document with the Design
Guidelines.
I did not ask to be named as an author -- the other authors suggested this to
me.
Given that, I have no particular interest in this document, other than ensuring
that it
does as little violence to the RADIUS protocol as possible.
So if you have particular concerns relating to the handling of this document,
or can
provide specific instances in which this document violates "Design Guidelines"
(applying
the tests in Appendix A, for example), please put them on the table.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf