RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr

[Bernard Aboba <bernard_aboba@hotmail.com>]

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