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

[Ballot comment]
I agree with others. well written. thanks.
I cleared the DISCUSS.

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

[Ballot discuss]
updated for -03-

1) I still have concerns about the predictability of rule precedence. At a minimum, I think there should be one standard default behavior, and it should favor strong security, plus a mechanism to tell which policy is applied by default. As a RM, I would want to know whether the implementation would pay more attention to my rules than those provided by somebody else.

[Ballot comment]
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.

[Ballot discuss]
updated for -03-

1) I still have concerns about the predictability of rule precedence. At a minimum, I think there should be one standard default behavior, and it should favor strong security, plus a mechanism to tell which policy is applied by default. As a RM, I would want to know whether the implementation would pay more attention to my rules than those provided by somebody else.

2) a third-party  IPR disclosure has been filed: . The WG might want to look at it.

[Ballot comment]
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'.

[Ballot comment]
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.

6) "security sensible" - is this supposed to be "security sensitive"?
s/information information/information/

7) in 5.2, it talks about "exposing position" - should this be "exposing location"?

s/a a/a/

[Ballot discuss]
1) I have concerns about the predictability of 3.2.4 rules. At a minimum, I think there should be standard default behaviors, and a mechanism to tell which policy is applied by default. As a RM, I would want to know whether the implementation would pay more attention to my rules than those provided by somebody else.

2) The example given after "Conversely" seems a bad example; the user is the rulemaker, but you trust the rulemaker's employer more - why? If the company wanted to have more weight than the user, why wouldn't it declare itself the rule-maker? In what real instances should my employer be able to specify that it can override my personal privacy rights, expressly stated as the RM? Certainly my employer should be able to stop me from being able to distribute the company's intellectual property, but I don't think the LS should make a decision about whos rules to folow when they are in conflict; if there is a conflict in rules, they should not distribute.

3) in 3.3, the discussion of automatic compliance "will comply with any set of rules possible" seems like a bad thing to put into a standard,since we cannot foresee all possible cases in the future. This seems to invite abuse - what if I derive some information about you based on where you've been (e.g., you went to an AIDs clinic), then discard the LO. I might be able to derive some info about you which when put together with something else allows you be identified, even though I don't retain your identification from the LO, or the specific clinic's location from the LO.

4) in section 4, there is some "positive marketing" for location by reference, but where is the discussion of the privacy/security vulnerabilites of location by reference? what happens if a MIM modifies the URI to point elsewhere, to deliberately mislead about a user's whereabouts, for example?

5) section 5.1 says the server, as LR, does not need to read the rules. Doesn't this contradict 3.3.1 which says "When an LR receives an LO, it is REQUIRED to examine the rules included with that LO."?

6) section 5.3 says "The LO format within LoST does not allow rules ..."; Section 3.2.4 says "If the LO includes no Rules ... the LS MUST NOT transmit the LO." and "If the LO contains no rules at all, ... the LS MUST delete it". Aren't section 5.3 and 3.2.4 in conflict?

[Ballot comment]
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]."

[Ballot comment]
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.

[Ballot discuss]
An extremely well written document.    I have two things I'd like to discuss before changing my ballot position:

1) I read Sec 3.1.3 as providing security requirements for positioning.  If that's how I'm supposed to read it, then I think requirements language needs to be used: a) in bullet #1: r/should/SHOULD for authentication and authorization; and b) r/must/MUST for confidentiality and integrity.

2) Sec 3.2.5 (same as #1): r/Ideally, Location Objects should be/Ideally, Location Objects SHOULD be

[Ballot discuss]
An extremely well written document.    I have two things I'd like to discuss before approval:

1) I read Sec 3.1.3 as providing security requirements for positioning.  If that's how I'm supposed to read it, then I think requirements language needs to be used: a) in bullet #1: r/should/SHOULD for authentication and authorization; and b) r/must/MUST for confidentiality and integrity.

2) Sec 3.2.5 (same as #1): r/Ideally, Location Objects should be/Ideally, Location Objects SHOULD be

[Ballot comment]
These are just a draft...

1) I read Sec 3.1.3 as providing security requirements for positioning.  If that's how I'm supposed to read it, then I think requirements language needs to be used: a) in bullet #1: r/should/SHOULD for authentication and authorization; and b) r/must/MUST for confidentiality and integrity.

2) Sec 3.2.5 (same as #1): r/Ideally, Location Objects should be/Ideally, Location Objects SHOULD be

comment: 1) Expand GPS and AGPS on first occurrence.

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

[Ballot comment]
These are just a draft...

1) I read Sec 3.1.3 as providing security requirements for positioning.  If that's how I'm supposed to read it, then I think requirements language needs to be used: a) in bullet #1: r/should/SHOULD for authentication and authorization; and b) r/must/MUST for confidentiality and integrity.

2) Sec 3.2.5 (same as #1): r/Ideally, Location Objects should be/Ideally, Location Objects SHOULD be

3) As noted by Alexey please consider informative references to IPsec and TLS.

[Ballot comment]
1) I read Sec 3.1.3 as providing security requirements for positioning.  If that's how I'm supposed to read it, then I think requirements language needs to be used: a) in bullet #1: r/should/SHOULD for authentication and authorization; and b) r/must/MUST for confidentiality and integrity.

2) Sec 3.2.5 (same as #1): r/Ideally, Location Objects should be/Ideally, Location Objects SHOULD be

3) As noted by Alexey please consider informative references to IPsec and TLS.

[Ballot discuss]
An IPR disclosure was filed referencing this draft on Aug31. See
Additional information has been requested. No action is required from the authors at this time.

[Ballot comment]
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.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Alissa Cooper. The Shepherd
has personally reviewed this version of the document, and believes it
is ready for publication. Note: The Shepherd is also one of the
document authors. Given the uncontroversial nature of this document,
the Responsible Area Director (Robert Sparks) has given permission in
this instance for an author to also be the Shepherd.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has had a thorough review in the WG and has also been
discussed at times in ECRIT. As it is merely updating and clarifying
foundational GEOPRIV documents, I do not have concerns about the depth
or breadth of reviews performed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document is largely an attempt to reflect how internal WG thinking
has evolved in recent years, and thus does not need further review
from outside the WG.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no special concerns about this document. The WG has struggled
with inconsistent terminology and architectural perspectives, and the
process of creating this document allowed the WG to thoroughly discuss
and resolve these issues.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus behind this document among core WG members.
Recent calls for approval have yielded neither loud approval nor loud
objections.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of any extreme discontent or potential appeals related
to this document.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document contains a number of small nits that can be easily fixed:
--There is a minor ASCII art formatting error.
--References [19] and [20] are unused and should be removed.
--References to draft-ietf-geopriv-l7-lcp-ps, draft-ietf-geopriv-lbyr-
requirements, and draft-ietf-ecrit-mapping-arch need to be updated to
the appropriate RFCs (5687, 5808, and 5582, respectively).

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative, and the majority
are informative. There are no downward references or references to
documents with unclear status.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This document makes no request of IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

This document contains no formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes an architecture for privacy-preserving
location-based services in the Internet, focusing on authorization,
security, and privacy requirements for the data formats and protocols
used by these services. It updates RFCs 3693 and 3694, the GEOPRIV
Requirements and Threat Analysis, to reflect current WG thinking and
terminology usage.

Working Group Summary

As location-based services have proliferated, the WG has found the
need for a single document that clearly articulates the GEOPRIV
architecture and terminology. This document was drafted to suit that
need, and the process of revising it allowed the WG as a whole to
crystallize its thinking about the architecture in practice and how
terminology has changed since the WG's early days.

Document Quality

Other than being a little on the long side, this document is easy to
digest.