Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
draft-ietf-geopriv-policy-27
Discuss
Yes
(Dan Romascanu)
(Robert Sparks)
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(David Ward)
(Jari Arkko)
(Magnus Westerlund)
(Mark Townsley)
(Martin Stiemerling)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
(Wesley Eddy)
Abstain
No Record
(Cullen Jennings)
Note: This ballot was opened for revision 25 and is now closed.
Lars Eggert
No Objection
Comment
(2007-09-19)
Unknown
Strongly agree with Lisa's DISCUSS.
Sam Hartman Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2007-09-19)
Unknown
> > > 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. >
Dan Romascanu Former IESG member
Yes
Yes
()
Unknown
Jon Peterson Former IESG member
Yes
Yes
(2007-09-19)
Unknown
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?
Robert Sparks Former IESG member
(was Discuss)
Yes
Yes
(for -25)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2012-07-30 for -26)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -25)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -25)
Unknown
Chris Newman Former IESG member
No Objection
No Objection
(2007-09-20)
Unknown
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?
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -25)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2012-04-25 for -25)
Unknown
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. 4: 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?
Ralph Droms Former IESG member
No Objection
No Objection
(2012-04-25 for -25)
Unknown
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.
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
(2012-04-23 for -25)
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2012-04-22 for -25)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2012-04-26 for -25)
Unknown
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). r/much/large? 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: There 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. Maybe: 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: ? OLD: 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. NEW: 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.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2012-06-06 for -26)
Unknown
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/?
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-04-23 for -25)
Unknown
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.
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -25)
Unknown
Adrian Farrel Former IESG member
Abstain
Abstain
(2012-04-26 for -25)
Unknown
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.
Lisa Dusseault Former IESG member
(was Discuss, Abstain)
Abstain
Abstain
(2007-09-17)
Unknown
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.
Cullen Jennings Former IESG member
(was Yes)
No Record
No Record
()
Unknown