Note: This ballot was opened for revision 12 and is now closed.
Summary: Needs a YES. Has enough positions to pass.
Comment (2012-04-26) 
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.
Comment (2012-04-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.
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?
Comment (2012-04-26)
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.
Comment (2012-06-06)
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/?
Comment (2012-04-23)
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.
Comment (2007-09-20)
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?
Comment (2007-09-19)
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?
Comment (2007-09-19)
Strongly agree with Lisa's DISCUSS.
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.
Comment (2012-04-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.
Discuss (2007-09-19)
>
>
> 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.
>
datatracker.ietf.org