Carrying Location Objects in RADIUS and Diameter
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' **)
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 message. 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
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
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 | > | | | (firstname.lastname@example.org) | The ADs are at email@example.com. 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
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.