A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
RFC 6753
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Robert Sparks; former steering group member) (was Discuss, Yes) Yes
(Adrian Farrel; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Maybe I missed it or it is discussed in some other document, but I felt the document did not describe some basic properties of local references. For instance, if I ask for my location and then pass it on to someone else, is the resulting dereferenced location my location at the time of the request, or my current location? Devices can move...
(Pete Resnick; former steering group member) (was Discuss, No Objection, Discuss) No Objection
Thanks for addressing the rest of my comments. A great improvement. Section 4: I think a good deal of this section should be rewritten in a more subjunctive form. As far as I can tell, none of the information in this section is required for implementation, and much of it is not done. For example: In this model, possession - or knowledge - of the location URI is used to control access to location information. A location URI is constructed such that it is hard to guess (see C8 of [RFC5808]) and the set of entities that it is disclosed to is limited. I think more accurately this should say: In this model, possession - or knowledge - of the location URI can be used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]) or the set of entities that it is disclosed to can be limited. Yes, this is only stylistic, but I think it conveys the right message, that generally authorization is not done and not understood for the protocol; URIs are simply accepted and it is hoped that they are being used by only the entities you want to have them.
(Peter Saint-Andre; former steering group member) No Objection
The AppsDir review by Ted Hardie raised several minor issues, which deserve a response. The review can be found at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03941.html A number of terms are re-used from RFC 3693 and RFC 5808; it would be helpful to cite those specifications in Section 2. Although Section 3 says that "no authentication framework is provided", it's not true that authentication cannot be performed (e.g., if HTTP is used to communicate with the LIS/LS then HTTP authentication can be used). The text here is not entirely consistent with the later text in Section 3.3 ("A Location Server MAY support an authentication mechanism that enables identity-based authorization policies to be used") and similar text in Section 4. It would be appropriate to say something about leakage of location URIs (which could happen outside the TLS-protected channel between the Target and the Location Recipient -- URIs have a tendency to leak). RFC 5808 has some text about this, and perhaps you could simply point there.
(Ralph Droms; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
Thanks fixing this up.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
Thanks for addressing my discuss and making the requirement for TLS clear.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection