An Architecture for Location and Location Privacy in Internet Applications
RFC 6280

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

(Jari Arkko) Yes

Comment (2010-09-09 for -)
Good stuff. Thanks for writing this.

Alexey Melnikov Yes

Comment (2010-09-05 for -)
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.

(Dan Romascanu) Yes

Comment (2010-09-09 for -)
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'.

(Peter Saint-Andre) Yes

Comment (2010-09-08 for -)
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]."

(Robert Sparks) (was Discuss, Yes) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2010-09-09 for -)
Thanks for this important work.

(David Harrington) (was Discuss) No Objection

Comment (2010-10-19)
I agree with others. well written. thanks.

1) the text is often inconsistent between using the spelled out terms (Location Recipient) and abbreviations. I especially noted this in the second sentence of 3.2. It would be nice to be more consistent.

2) I support the DISCUSS about using RFC2119 keywords, especially in section 3.

3) in section 3.2, "to determine whether it is authorized to fulfill these by returning location information." shouldn't it also determine whether the requester is authorized to receive the information? Aren't those two things slightly different?

4) In 3.2.1, it says "Adding a Rule can never reduce existing permissions". I found this a little difficult to understand at this point. Later in the document, it discusses that rules are always positive. That made more sense to me; I suggest carrying that text forward to this point in the text to make it clearer.

5) I agree with Tim's comment about MUST attempt to download, and what happens if the download fails.

(Russ Housley) No Objection

(Tim Polk) No Objection

Comment (2010-09-08 for -)
This is a very well written document.  Much appreciated!

I support's Sean's issues with the need for 2119 language in sections 3.1.3 and 3.2.5.

In section 3.2.4, an LS says "SHOULD attempt to download" rules that are included by reference in an LO.
The following text states how an LS handles LOs without rules of various types.  I think a sentence should
be added that extends this to situations where the referenced rules can (or were) not obtained.  I would suggest
the following sentence be appended to 3.2.4, paragraph 4:

   If the LO included Rules by reference, but these rules were not obtained for any reason, the LS MUST NOT
   transmit the LO and MUST delete it.




(Sean Turner) (was Discuss) No Objection

Comment (2010-09-08)
1) Expand GPS and AGPS on first occurrence.

2) Sec 5.2) r/defines a a/ defines a