Carrying Location Objects in RADIUS and Diameter
RFC 5580

Note: This ballot was opened for revision 24 and is now closed.

(Jari Arkko) Yes

Comment (2008-07-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I have reviewed the specification and the last call discussion,
and I believe the document is ready to be approved. I think the
authors have struck the right balance between keeping the location
information opaque vs. allowing servers to make authorization
decisions IF they need to do it.

A few minor comments. Section 4.7:

   The numerical value representing FUTURE_REQUESTS indicates that
   the RADIUS client MUST provide future Access-Requests with the
   same information as returned in the initial Access-Request

To avoid confusion, please change s/future Access-Requests/future
Access-Requests for the same session/

Security Considerations say:

   Confidentiality protection is not only a property
   required by this document, it is also required for the transport
   of keying material in the context of EAP authentication and
   authorization.  Hence, this requirement is, in many environments,
   already fulfilled.

Heh. Or at least the requirement is already present for other reasons
in many environments. Fulfillment is another question...

I'm not asking for any change here.

(Cullen Jennings) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2009-04-22)
No email
send info
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.

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2008-07-11)
No email
send info
Section 4.1., paragraph 17:
>        Example:

  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:
>    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            |
>   |          |                    | (              |

  The ADs are at

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 :-)

(Adrian Farrel) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2008-11-07)
No email
send info
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.

(Robert Sparks) No Objection

Magnus Westerlund No Objection