Skip to main content

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


(Robert Sparks)

No Objection

Lars Eggert
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

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

Lars Eggert
No Objection
Alexey Melnikov Former IESG member
Yes (2010-09-05)
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 Former IESG member
Yes (2010-09-09)
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'.
Jari Arkko Former IESG member
Yes (2010-09-09)
Good stuff. Thanks for writing this.
Peter Saint-Andre Former IESG member
Yes (2010-09-08)
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 Former IESG member
(was Discuss, Yes) Yes
Yes ()

Adrian Farrel Former IESG member
No Objection
No Objection (2010-09-09)
Thanks for this important work.
David Harrington Former IESG member
(was Discuss) No Objection
No Objection (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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

Ralph Droms Former IESG member
No Objection
No Objection ()

Ron Bonica Former IESG member
No Objection
No Objection ()

Russ Housley Former IESG member
No Objection
No Objection ()

Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2010-09-08)
1) Expand GPS and AGPS on first occurrence.

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

Stewart Bryant Former IESG member
No Objection
No Objection ()

Tim Polk Former IESG member
No Objection
No Objection (2010-09-08)
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.