Carrying Location Objects in RADIUS and Diameter
draft-ietf-geopriv-radius-lo-24

This COMMENT is based on the AAA-Doctor review by David Nelson. 

I have cleared a previous DISCUSS that was raising a number of concerns. 

1. One of them was mentioning that this document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute.  Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.


The revised text that addresses this issue is as follows:


4.  Attributes

   It is important to note that the location specific parts of the
   attributes defined below are not meant to be processed by the RADIUS
   server.  Instead, a location server specific component used in
   combination with the RADIUS server is responsible for receiving,
   processing and further distributing location information (in
   combination with proper access control and privacy protection).  As
   such, from a RADIUS server point of view location information is
   treated as opaque data.


This text does not reference the Design Guidelines, but rather simply declares that the attributes in question are to be considered opaque.  I think this is a bit superficial, but probably suffices to address the issue.

2. A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets.  In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these
attributes) to be "location aware" i.e. to be able to parse and act
intelligently upon the content of the location information.   

The added text of Section 4 addresses this issue, too.

While I have some lingering concerns that the attribute design style of this document may be viewed as a model for future work, as there is no explicit acknowledgement that it diverges from the Design Guidelines, I think that the added text is sufficient to close the DISCUSS.

Section 4.1., paragraph 17:
>        Example: anyisp.example.com

  Suggest to move this example down to the description of the REALM
  namespace, because it's specific to it. (It confused me on first
  reading to see the example and then read about namespaces where it
  isn't valis.) It might also be good to add one example to each of the
  other namespaces.


Section 4.2., paragraph 2:
>    The Location-Information Attribute provides meta-data about the
>    location information, such as sighting time, time-to-live, location
>    determination method, etc.  Implementations SHOULD treat this
>    attribute as undistinguished octets, like the Location-Data Attribute
>    to which it refers.

  Why is this a SHOULD and not a MUST? Under what conditions may
  implementations interpret the attribute? (The same comment applies to
  other attributes below.)


Section 4.4., paragraph 19:
>      Note Well (variable):
>        This field contains a URI that points to human readable
>        privacy instructions. The data type of this field is string.

  The APP ADs should look at this. I'm not an i18n expert, but it seems
  pretty important to transport a URI here that points to something a
  user can understand.


Section 4.4., paragraph 21:
>    retransmission-allowed:
>       When the value of this field is to zero (0), then the recipient of
>       this Location Object is not permitted to share the enclosed
>       location information, or the object as a whole, with other
>       parties.

  Are there any protocol or encoding mechanisms in place to prevent this
  sharing, or do we simply trust the other end to conform to our wishes?
  (Same issue applies to "retention-expires".)


Section 4.6., paragraph 1:
>    A RADIUS server SHOULD NOT
>    challenge for location information unless the Location-Capable
>    Attribute has been sent to it.

  Why is this a SHOULD NOT? When is it permissible to challenge?


Section 6., paragraph 2:
>                                      |    |     |SHLD| MUST|    |

  s/SHLD/SHOULD/ (don't abbreviate RFC2119 terms)


Section 8.1., paragraph 3:
>   |   0x31   | REALM              | IETF O&M Area Directors            |
>   |          |                    | (ops-chairs@ietf.org)              |

  The ADs are at ops-ads@ietf.org.


Section 8.2., paragraph 6:
>    No mechanism to mark entries as "deprecated" is
>    envisioned.  Based on expert approval it is possible to delete
>    entries from the registry.

  It's usually much safer to deprecate registry entries or to make them
  historic, compared to simply removing them. Is there a particular
  reason for this choice? (Same comment applies to other registries.)


Section 9., paragraph 1:
>    We would like to thank Bernhard Aboba for the numerous contributions
>    to this document.

  It's a bit unusual to thank a co-author, but hey :-)

Section 4.4 (page 23): Text describing "String" in the Basic-Location-Policy_Rules Attribute is inconsistent: use "Flags" or "Flag" consistently; delete spurious "'" in "Flag'"; suggest (for consistency) replacing "The Flag' field" with "This field..."

Section 6 (page 37): A pointer to the rules for interpreting the table of data types and flag rules would be helpful.