Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information

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

(Sam Hartman) Discuss

Discuss (2007-09-19 for -)
> Hi.
> I'm trying to think about the mechanisms in section 6 of the geopriv
> document for reducing the granularity of location.  I'm wonder though
> how effective these mechanisms are in cases where in addition to
> getting one-time location information I'm also seeing transitions in
> location information.
> As an example if I see a transition from one building to a near by
> building, I may well know much more about the civic location than
> granularity.
> Similarly, I'm wondering how much information monitoring transitions
> in geodetic location would help me in discovering where someone is in
> the best case.  I.E. where they are near a discontinuity in the
> rounding.
> If these concerns are real, I expect to see a discussion in the
> security considerations at the very least.  Depending on how serious
> they are, we may need to work on mechanisms that do better.

(Jon Peterson) Yes

Comment (2007-09-19 for -)
In section 6.5.2, does it make sense to have a practical maximum value for 'r', that is, before 'INF'?

Nit Section 1, "does not allow to control access" does not allow what to control access?

Nit Section 6.4, "allows to reference" allows what to reference?

(Dan Romascanu) Yes

(Robert Sparks) (was Discuss) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) (was Discuss) No Objection

(Stewart Bryant) No Objection

Comment (2012-04-23 for -25)
Maybe "Internationalization" is an IETF keyword for character set, but I was surprised that the section did not include a discussion on the datums use in different countries. The text only supports WGS84, but I understand that there are other datums and that WGS84 is tied to GPS but that there are other Sat Nav systems.

(Benoit Claise) No Objection

(Ralph Droms) No Objection

Comment (2012-04-25 for -25)
Minor editorial nits:

section 4:

   The 'profile' attribute allows to indicate the
   location profile that is included as child elements in the <location>
   element and each profile needs to describe under what conditions each
   <location> element evaluates to TRUE.

missing word in "allows to"? (also section 6.4)

section 6.5.2

   5.  Let P = 0.2887 (=sqrt(3)/6) and q = 0.7113 (=1-p),

lower case or upper case P?

section 7.5

   Suppose you want a to obscure

s/a// ?

section 7.5

   In his way

"In this way"?

THe document lists 6 authors; you may get pushback as the guideline is 5.

(Wesley Eddy) No Objection

(Lars Eggert) No Objection

Comment (2007-09-19 for -)
Strongly agree with Lisa's DISCUSS.

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-06-06 for -26)
abstract: "restrict access" in the abstract is ambiguous - it could mean
"restrict access to a target's actual location" or it could mean
"restrict access to something based on a target's location information."
Not sure if that needs fixing or not but this is only addressing the
former I think.

4.1: what does "within" mean here - does overlapping count or not?
Seems like that could be made more precise, but maybe its defined
elsewhere in which case a reference to the relevant section of the
relevant RFC would be good. I think that's clarified later, but 
be good to be clear here too.

6.2: It'd maybe be good to explicitly state the meaning of setting this
to the current date. I assume it means "don't retain."

6.4: CID URIs are mentioned here but not explained nor is the acronym
expanded. Be nice to do that.

- 13.2: says that "The quotient of the sizes A1/A should be, even in the
worst case, larger than a fixed known number, in order that the user
knows what is the maximal information leakage he has." Should that should
be a 2119 SHOULD? In other words, is the "maximum leakage" referred to
here really a parameter of the 6.5.2 algorithm? If so, then ought that
not be called out with 2119 terms?  

- 13.2: I don't follow how the A1/A quotient is >0.13, can you explain
that some more? (That may or may not need to be reflected in the
document, not sure.)

- 13.3: 1st para - What is an implementer supposed to do with or based on
this paragraph?

- 13.4: This seems to imply "uncertainty" is a parameter of the
algorithm, but that's not explained. This is a similar point to that made
for 13.2

13: the term "privacy region" is used but not defined 

10.4: typo s/to defined/to define/

13.2: a few typos at the end of 1st para, and more elsewhere, could do
with an editorial pass really

13.3: "further checks are performed" seems wrong if you don't say what
those are, maybe s/are/can be/?

(Brian Haberman) No Objection

(Russ Housley) (was Discuss) No Objection

(Barry Leiba) (was Discuss) No Objection

(Chris Newman) No Objection

Comment (2007-09-20 for -)
I share many of Lisa's concerns.  It is my suspicion that if the polygon
feature remains in the initial publication that it will have to be dropped
to advance to draft.  Might be better to drop it now to save time.  Is there a use case where rectangles or civic information is not sufficient?

We already have consumer map services that omit information related to military installations and similar high-security locations.  Perhaps that sort of omission will simply be built-into geopriv system and not need a standardized policy language of this complexity?

(Tim Polk) (was No Record, Discuss) No Objection

(Pete Resnick) No Objection

Comment (2012-04-25 for -25)
This document needs a great deal of editing for simplification and clarity. That said, none of these (or the other changes I suggest below) are enough for me to hold up the document. But I do wish you would address these issues before publication.

First, the strictly editorial. There's a great deal of use of the passive voice that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing, with some suggested replacements:

   This section describes the location-specific conditions of a rule.
   The <conditions> element contains zero, one or an unbounded number of
   <location-condition> child element(s).  Providing more than one
   <location-condition> element may not be useful since all child
   elements of the <conditions> element must evaluate to TRUE in order
   for the <conditions> element to be TRUE.  The <location-condition>
   element MUST contain at least one <location> child element.  The
   <location-condition> element evaluates to TRUE if any of its child
   elements is TRUE, i.e., a logical OR.

"The <conditions> element contains zero or more <location-condition> child element(s). The <conditions> element evaluates to TRUE if all of its child elements evaluate to TRUE (and therefore multiple <location-condition> elements are not normally useful). The <location-condition> element MUST contain at least one <location> child element.  The <location-condition> element evaluates to TRUE if any of its child elements evaluates to TRUE."

   The <location> element has three attributes, namely 'profile', 'xml:
   lang' and 'label'.  The 'profile' attribute allows to indicate the
   location profile that is included as child elements in the <location>
   element and each profile needs to describe under what conditions each
   <location> element evaluates to TRUE.  This document defines two
   location profiles, one civic and one geodetic location profile, see
   Section 4.1 and Section 4.2.  The 'label' attribute allows a human
   readable description to be added to each <location> element.  The
   'xml:lang' attribute contains a language tag providing further
   information for rendering of the content of the 'label' attribute.
"The three attributes of <location> element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the <location> element. Two location profiles, one geodentic and one civic, are defined in Sections 4.1 and 4.2. The 'label' attribute contains a human readable description of the location. The 'xml:lang' attribute contains a language tag indicating the language of the 'label' attribute."

I'm not going to go through and edit this entire document, but you get the idea; I hope the editors can have a proper edit of this document done, if not have the RFC Editor assist with this. These are just two examples. The entire document could use a good rewrite.

From here on, I will point only out places where I think the language obfuscates meaning.


   The <location-condition> and the <location> elements provide
   extension points.  If an extension is not understood by the entity
   evaluating the rules then this rule evaluates to FALSE.

Are you saying that if an unknown extension is used in a child of <location>, that <location> should evaluate FALSE if if another known child of <location> evaluates TRUE? That violates the logical OR of the <location> element.

4.2 "bit-by-bit comparison": No normalization of comparison is allowed? That doesn't seem necessary. If you do need this, at least make it "octet-by-octet" or "byte-by-byte" if you must.

"If the civic location of the Target is unknown": Do you mean "If the <civicAddress> element is missing"? This reads as if the <location> should evaluate to FALSE if the civic location is not understood, and I don't think that's what you mean.

6 (generally) Why does this section talk about when the PIDF-LO is first created? That has nothing to do with the transformations. That info belongs somewhere else.

6.1 (and forward) "This element asks...". The element does not "ask" anything. Please rewrite.

6.2 "<set-retention-expiry> element is an integer." I assume unsigned, yes? Probably best to say.

6.5.1 I can't get any more granular than the 6 choices? Why not?

(Martin Stiemerling) No Objection

(Mark Townsley) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2012-04-26 for -25)
I cleared my discuss based on some exchagnes with Robert.

s3.1: so maybe I'm nit picking but maybe r/privacy safe/privacy enabling ? It's not really safe it's enabling.

s3.2: r/There are two ways how the/There are two ways the 

s4: r/allows to indicate/indicates

s6.5.2: r/steps.The/steps. The

s6.5.2: I found this a little hard to parse:

 The maximal distortion of the map may
       not be too much (see notes below).


s6.5.2, step 5: r/P/p 

s6.5.2: Okay I'll bite what's the basis for picking those values for p and q?

s8/s9: I'm going with the thought that somebody verified the XML schema.

I agreed with many of the initial IESG reviews of early versions of this draft, but I think the security considerations is great big step in the right direction.  But, I had a bunch of edits on the security considerations to make it more understandable.  Not sure that all my suggestions are correct though.

s13.1, 1st para:

r/This is accomplished through the usage of
  authorization policies./This is accomplished
  using authorization policies.

r/treated in [RFC4745])./addressed in [RFC4745].

s13.1, 2nd para:

r/In addition to the authorization policies mechanisms/
  In addition to the authorization policies, mechanisms 

r/makes use of these/uses these

s13.1, 3rd para:

what does this mean:

  The requirements of location information with respect to privacy
  protection vary.

requirements on the information or requirements on giving out the information?

r/While the two obfuscation algorithm/While the two obfuscation algorithms

I think you mean to protection against unauthorized disclosure of location information:

r/protection/protecting against unauthorized disclosure of location information

This sounds odd:

 are certainly applications that require a different level of
 protection and for this purpose the ability to define and use
 additional algorithms has been envisioned. New algorithms can be
 specified via the available extension mechanism.


 Applications requirements vary widely; therefore, an extension mechanism is
 supported to allow for the definition of new algorithms.

s13.2, 1st para:

r/then it contains/it contains 

r/is danger to reveal information over time/is a danger than information will be revealed over time.

r/real/reveal ?

13.2, 3rd para: ?


   For this purpose the algorithm described in Section 6.5.2 uses a grid
   that ensures to report the same location information whenever the
   target remains in the same geographical area.


   For this purpose the algorithm described in Section 6.5.2 uses a grid
   that ensures the same location information is reported whenever the
   target remains in the same geographical area.

s13.2, 5th para:

r/measures/protections ?

 r/is visiting regularly/is regularly visiting

r/The first issue is the following:/The first concern is the ability to be followed:

The second issue is also the following?  Isn't the 3rd concern listed in the 1st sentence visiting places regularly?

r/If the reported obfuscated locations are all
   randomly different, an analysis will probably soon reveal the home
   location with high precision/
   If the reported obfuscated locations are all
   randomly chosen, an analysis can reveal the home
   location with high precision.

all randomly different/all randomly chosen (it'd be funny if they were all randomly the same) and will probably is wishy-washy - the point is you can do an analysis.

r/may render a much precise location
   information than desired./
  may render a much more precise location
   information than is desired.

once or in a regular repetitive way   can non-regular samples help leak samples?  maybe r/once or in a regular repetitive way/once or multiple times

also is it or or and at the end of that sentence?

r/An opponent,/A stalker,  ;) but probably better to say attacker

Oh and I support Stephen's discuss position.

(David Ward) No Objection

(Magnus Westerlund) No Objection

(Lisa Dusseault) (was Discuss, Abstain) Abstain

Comment (2007-09-17)
This is very complicated (too flexible) for a privacy extension.  I do not expect clients from different vendors to be able to interoperate very well over the same policy information.  I expect the end result of this to be cases where users believe they have privacy, or intend to have privacy, but do not achieve their goals due to difficulty of getting clients to interoperate with each other and with servers.

(Adrian Farrel) Abstain

Comment (2012-04-26 for -25)
I find the philosophical aspects of this work very hard to grapple
with. Had the work been presented in a more abstract way (for example,
as a policy language that could be used in a number of ways) I would
have found it easier. But the text on motivation disturbs me and,
while I can completely accept that many people are motivated in this
way, the approach and ideas seem to me to be broken.

I do not believe that I should enter a Discuss or stand in the way 
of this work because of my views, but I cannot offer a "No Objection"
ballot position.


Additionally, the authors might like to consider the following:

It is not clear to me why algorithms need to be standardised in this
case. While they do affect what is sent on the wire, and while they
provide useful examples to show that the results can be reliably
achieved, it seems to me that the results of the algorithms (i.e. the
outputs based on the inputs) are all that need to be contained in a
Technical Specification. In short, I do not believe that the
specification of the algorithms is necessary for interoperability.

(Cullen Jennings) (was Yes) No Record