A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-deref-protocol-07

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...

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.

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.

Thanks fixing this up.

Thanks for addressing my discuss and making the requirement for TLS clear.