An Architecture for Location and Location Privacy in Internet Applications
draft-ietf-geopriv-arch-03

I am balloting Yes on this document, because I think it is a good and important document. However there are some issues related to references that you should consider fixing:

1). In the Security Considerations section: informative references for IPSec and TLS are missing, RFC 4119 should be changed to a proper reference.

2). In Section 5.1: informative references to HTTP and SIP are missing

3). In Section 5.4: an informative reference to XMPP is missing.

I find the location of the text that refers to usage of 2119 keywords unusual (in a Glossary section) and contrary to the recommendations of 2119 which advises that 'Authors who follow these guidelines should incorporate this phrase near the beginning of their document'.

Good stuff. Thanks for writing this.

This is an excellent document. Herewith several minor comments.

1. In Section 1.1 (last sentence), s/provides/provide/

2. Section 1.3 uses the term "consumer" to refer to the entity that elsewhere is referred to as a "data subject".

   In the absence of a binding of rules with location information,
   consumer protection authorities would be less able to protect
   consumers whose location information has been abused.

Section 4 uses the term "consumer" in its definition of a location recipient, which earlier in the document is contrasted with a data subject: "The Location Recipient is the consumer of the Location Object."

I suggest changing "consumers" in Section 1.3 to "individuals" (besides, who wants to be thought of primarily as a "consumer" anyway?).

3. In Section 3.3.1 (first sentence), s/principle/principal/

4. Indefinite articles are inconsistent before acronyms, e.g., "When an LR receives a LO".

5. In Section 4, the clause "which is also security sensible as wrong input" is confusing; I suggest rewording it to "which is also sensible from a security perspective because wrong input"...

6. In Section 4, s/confidentility/confidentiality/

7. In Section 6, a reference to RFC 4949 might be appropriate for the security terms that are not defined in this document; for example, "Various security-related terms are to be understood in the sense defined in [RFC4949]."