Skip to main content

A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
RFC 6753

Yes

(Robert Sparks)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)

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

(Robert Sparks; former steering group member) (was Discuss, Yes) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -04)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2011-12-15 for -04)
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

No Objection (2012-06-09 for -05)
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

No Objection (2011-12-13)
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

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2012-07-12 for -06)
Thanks fixing this up.

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2012-07-11 for -06)
Thanks for addressing my discuss and making the requirement for TLS clear.

(Stewart Bryant; former steering group member) No Objection

No Objection ()

                            

(Wesley Eddy; former steering group member) No Objection

No Objection ()