Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
draft-ietf-geopriv-policy-27

[Ballot discuss]
[Updated on 20 June]

-- IANA Considerations --

[*** This part is resolved by version -26; thanks. ***]
To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name.  It would be nice to include the URL as well, to be absolutely sure.  I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5.  The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct?  I note that IANA has questions about the registrations for this document, which need to be resolved.

[*** This part is still pending, after Martin's note of 5 June; see below. ***]
For the new registry in 11.3, I would like to see a rationale for the choice of registration policy.  (See draft-leiba-iana-policy-update, if you want to see where I'm coming from here.)  Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option.

[5 June]
> [MT] I don't have any information on the rationale behind Standards
> Action.  I'm asking the working group on this one.  Specification
> Required is better (in my onion) and I've changed the draft to that.
> I'll revert it (probably with a RFC Editors note) if this doesn't work
> out with the working group.

[6 June] Thanks.  I'll watch for that, and clear the DISCUSS when it's resolved.

[20 June] I haven't heard anything further yet.

[Ballot comment]
[6 June] I'm happy with Martin's responses to these; thanks!
+++++++++++++++++++++++++++++++++++++++++++++

-- Introduction --

   This document does not describe the protocol used to convey location
   information from the Location Server to the Location Recipient.

What document does?  Should it be noted here, with a citation?
----
OLD (unclear what part is "for example")
   Transformations regulate in a location information
   context how a Location Server modifies the information elements that
   are returned to the requestor, for example, by reducing the
   granularity of returned location information.
NEW (I think you mean...)
   Transformations regulate in a location information
   context how a Location Server modifies the information elements that
   are returned to the requestor by, for example, reducing the
   granularity of returned location information.
----
   Both algorithms come with limitations, i.e. they
   provide location obfuscation under certain conditions and may
   therefore not be appropriate for all application domains.

It's not clear exactly what this means.  Is the only limitation the one related to the obfuscation?  If there are other limitations, then it should be "e.g.", not "i.e."  If that's the only limitation, I suggest replacing "limitations, i.e." with "limitations:".  Also, it doesn't make sense that providing location obfuscation would be a limitation; perhaps you mean *only* under certain conditions?  So maybe this is what you mean?:
NEW
   Both algorithms come with limitations: they
   provide location obfuscation only under certain conditions,
   and may  therefore not be appropriate for all application domains.

-- Section 3.1 --

The preferred term now is "media type", not "MIME type"; please change it. Also in Section 10.4.

-- Section 3.2 --

URL, not URI ?

-- Section 6.2 --

   The value provided with the  element indicates
   seconds and these seconds are added to the current date.

   If the  element is absent then the value of the
    element in the PIDF-LO is kept unchanged or, if
   the PIDF-LO is created for the first time, then the value MUST be set
   to the current date.

It looks like "current date" means "current date and time"; should you not say that?  Also, I guess absence then means that the retention expiry is immediate... and I presume that's OK.

-- Section 6.4 --

   If the  element is absent, then the value of the
    element in the PIDF-LO is kept unchanged when
   available or, if the PIDF-LO is created for the first time then the
    element MUST NOT be included.

This creates an interesting situation, in which the absence of a value has a meaning that cannot be conveyed by any value that might be present.  That's odd, and possible troublesome, so I want to be sure you've thought about that.

-- Internationaliztion Considerations --

   The content of the
   element is meant to be provided by a human (the Rule Maker) and also
   displayed to a human.

Does this also mean that the information might need to be language-tagged and/or translated (in addition to perhaps being in non-ASCII characters?

-- Section 13.3 --

The first paragraph is confusing,  and doesn't seem to reach a reasonable conclusion.  It purports to talk about usability, but then seems to get into information leakage, and never makes a point that seems to me to be clear and useful.  Please try to re-work that paragraph.

-- Section 13.4 --

   Location obscuring attempts to remove information about the location
   of a Target.  The effectiveness of location obscuring is determined
   by how much uncertainty a Location Recipient has about the location
   of the Target.

As you note earlier (and later, two paragraphs down), this is oversimplified: the effectiveness is not determined just by that, but is also strongly influenced by what can be revealed by repeated queries over time -- how aggregating responses can reveal more than a single response will.

   Obscured locations can still serve a purpose where a Location
   Recipient is willing to respect privacy.

It's not clear what value that paragraph has.  It seems to say, basically, "If the LR doesn't want to attack you, then whatever you've done will be fine."  It's true, but not very useful as a security consideration.  You might just want to remove this paragraph, and take the word "more" out of the subsequent one.

This is an old document; please double-check the references to make sure they're accurate, current, and correctly classified.  The reference to RFC 2434 is obsolete, replaced by 5226, for example.

========
Editorial suggestions.  No need to respond to these; take them, leave them, or modify them as you please.  There are also numerous errors in punctuation, number agreement, and the like; it would be good for one of the native English speaking editors to go through the document source code and fix those... or I guess we can let the RFC Editor deal with them.

-- Introduction --

(clarity)
Not all terminology is in one place, and Target isn't specifically defined.  I suggest the following structure for the introduction (and if you do this, you can remove the second paragraph from section 2):
   -----
   1. Introduction
       First sentence as written.  Second sentence.

   1.1 Terminology for the model, as in RFC 3693
       Location Generator (LG), [explain].
       Location Server (LS), ...
       Location Recipient (LR), ...
       Rule Maker (RM), ...
       Authorization Policy, ...
       Location Object (LO), ...
       Target, ...

   1.2 Overview
       The basic rule set defined [...]
   -----

OLD (sounds awkward)
   The basic rule set,
   however, does not allow to control access to location information
   based on specific Location Recipients.
NEW
   The basic rule set,
   however, does not allow access control for location information
   based on specific Location Recipients.

OLD (clarity)
   The rule set allows the entity that uses the rules defined in this
   document to restrict the retention
NEW
   The enhanced rule set allows the entity that uses the rules
   defined in this document to restrict the retention

OLD (sounds awkward)
   or that the resolution of parts of the Location Object is
   reduced.
NEW
   or that the resolution is reduced for parts of the Location
   Object.

OLD (to read more smoothly)
   The typical sequence of operations is as follows.  A Location Server
   receives a query
NEW
   In the typical sequence of operations, a Location Server
   receives a query

OLD (awkward usage)
   determine under which circumstances the entity executing the rules,
   for example a Location Server,
NEW
   determine under which circumstances the entity executing the rules,
   such as a Location Server,

-- Section 2 --
OLD (setting off defined terms)
      The term permission refers to the action and transformation
      components of a rule.
NEW
      The term "permission" refers to the action and transformation
      components of a rule.
OR
      The term Permission refers to the action and transformation
      components of a rule.

In general, please be consistent with how you set off defined terms, and avoid using a term in a definition while making it look like it's just part of the sentence.

OLD (bad usage)
      as motivated in RFC 4079

This usage of "motivated" is made-up business jargon and will be difficult for many non-native speakers (and quite some native speakers) to understand.
NEW
      as explained in RFC 4079
[or "described in", or something like that]

-- Section 4.1 --

OLD (repetition)
   reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the
   European Petroleum Survey Group
NEW
Can you re-word this to avoid the "based on... based on" repetition?

-- Section 7.5 --

OLD
      We will set up a grid not only for the continental US, but for the
      whole earth between latitudes 25 and 50 degrees

You're not including Alaska.  This is a total nit, but in order to avoid arguments about whether "continental" U.S. includes Alaska, you might switch to "contiguous US".

-- Section 13.1 --

First paragraph has a spurious ")" at the end.

OLD (unclear antecedent)
   This algorithm for
   geodetic location information obfuscation makes use of these
   techniques.
NEW
   The algorithm defined in this document for
   geodetic location information obfuscation makes use of these
   techniques.

-- Section 13.2 --

OLD
   For example, when a transformation indicates that civic location is
   provided at a 'building' level of granularity.  Consequently, floor
   levels, room numbers, etc. would be hidden.

The first sentence is not a complete sentence, and the second is not a very good one.  Merge these, and make a proper sentence.  Maybe (assuming I understand what you mean to say) something like this?:

NEW
   For example, when a transformation indicates that civic location is
   provided at a 'building' level of granularity, floor levels, room
   numbers, and other detailed information would be hidden.

The paragraph that begins thus:
   The algorithm presented in Section 6.5.2 has some measures against
   leaking information when moving, switching from one privacy region to
   another one
...is very long, and has quite a number of grammatical errors.  I suggest getting one of the native-English-speaking editors to fix this and to split it into at least three paragraphs.

-- IANA Considerations --
I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address.  Should you perhaps be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual?  (I notice that Hannes's other document on this telechat has his old Siemens address, and discussion mail is bouncing as a result... that's the sort of thing I mean.)

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

[Ballot discuss]
[Updated after telechat]

-- IANA Considerations --
To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name.  It would be nice to include the URL as well, to be absolutely sure.  I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5.  The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct?  I note that IANA has questions about the registrations for this document, which need to be resolved.

For the new registry in 11.3, I would like to see a rationale for the choice of registration policy.  (See draft-leiba-iana-policy-update, if you want to see where I'm coming from here.)  Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option.

[Ballot comment]
Substantive suggestions; please adopt or respond to these:

-- Introduction --

   This document does not describe the protocol used to convey location
   information from the Location Server to the Location Recipient.

What document does?  Should it be noted here, with a citation?
----
OLD (unclear what part is "for example")
   Transformations regulate in a location information
   context how a Location Server modifies the information elements that
   are returned to the requestor, for example, by reducing the
   granularity of returned location information.
NEW (I think you mean...)
   Transformations regulate in a location information
   context how a Location Server modifies the information elements that
   are returned to the requestor by, for example, reducing the
   granularity of returned location information.
----
   Both algorithms come with limitations, i.e. they
   provide location obfuscation under certain conditions and may
   therefore not be appropriate for all application domains.

It's not clear exactly what this means.  Is the only limitation the one related to the obfuscation?  If there are other limitations, then it should be "e.g.", not "i.e."  If that's the only limitation, I suggest replacing "limitations, i.e." with "limitations:".  Also, it doesn't make sense that providing location obfuscation would be a limitation; perhaps you mean *only* under certain conditions?  So maybe this is what you mean?:
NEW
   Both algorithms come with limitations: they
   provide location obfuscation only under certain conditions,
   and may  therefore not be appropriate for all application domains.

-- Section 3.1 --

The preferred term now is "media type", not "MIME type"; please change it. Also in Section 10.4.

-- Section 3.2 --

URL, not URI ?

-- Section 6.2 --

   The value provided with the  element indicates
   seconds and these seconds are added to the current date.

   If the  element is absent then the value of the
    element in the PIDF-LO is kept unchanged or, if
   the PIDF-LO is created for the first time, then the value MUST be set
   to the current date.

It looks like "current date" means "current date and time"; should you not say that?  Also, I guess absence then means that the retention expiry is immediate... and I presume that's OK.

-- Section 6.4 --

   If the  element is absent, then the value of the
    element in the PIDF-LO is kept unchanged when
   available or, if the PIDF-LO is created for the first time then the
    element MUST NOT be included.

This creates an interesting situation, in which the absence of a value has a meaning that cannot be conveyed by any value that might be present.  That's odd, and possible troublesome, so I want to be sure you've thought about that.

-- Internationaliztion Considerations --

   The content of the
   element is meant to be provided by a human (the Rule Maker) and also
   displayed to a human.

Does this also mean that the information might need to be language-tagged and/or translated (in addition to perhaps being in non-ASCII characters?

-- Section 13.3 --

The first paragraph is confusing,  and doesn't seem to reach a reasonable conclusion.  It purports to talk about usability, but then seems to get into information leakage, and never makes a point that seems to me to be clear and useful.  Please try to re-work that paragraph.

-- Section 13.4 --

   Location obscuring attempts to remove information about the location
   of a Target.  The effectiveness of location obscuring is determined
   by how much uncertainty a Location Recipient has about the location
   of the Target.

As you note earlier (and later, two paragraphs down), this is oversimplified: the effectiveness is not determined just by that, but is also strongly influenced by what can be revealed by repeated queries over time -- how aggregating responses can reveal more than a single response will.

   Obscured locations can still serve a purpose where a Location
   Recipient is willing to respect privacy.

It's not clear what value that paragraph has.  It seems to say, basically, "If the LR doesn't want to attack you, then whatever you've done will be fine."  It's true, but not very useful as a security consideration.  You might just want to remove this paragraph, and take the word "more" out of the subsequent one.

This is an old document; please double-check the references to make sure they're accurate, current, and correctly classified.  The reference to RFC 2434 is obsolete, replaced by 5226, for example.

========
Editorial suggestions.  No need to respond to these; take them, leave them, or modify them as you please.  There are also numerous errors in punctuation, number agreement, and the like; it would be good for one of the native English speaking editors to go through the document source code and fix those... or I guess we can let the RFC Editor deal with them.

-- Introduction --

(clarity)
Not all terminology is in one place, and Target isn't specifically defined.  I suggest the following structure for the introduction (and if you do this, you can remove the second paragraph from section 2):
   -----
   1. Introduction
       First sentence as written.  Second sentence.

   1.1 Terminology for the model, as in RFC 3693
       Location Generator (LG), [explain].
       Location Server (LS), ...
       Location Recipient (LR), ...
       Rule Maker (RM), ...
       Authorization Policy, ...
       Location Object (LO), ...
       Target, ...

   1.2 Overview
       The basic rule set defined [...]
   -----

OLD (sounds awkward)
   The basic rule set,
   however, does not allow to control access to location information
   based on specific Location Recipients.
NEW
   The basic rule set,
   however, does not allow access control for location information
   based on specific Location Recipients.

OLD (clarity)
   The rule set allows the entity that uses the rules defined in this
   document to restrict the retention
NEW
   The enhanced rule set allows the entity that uses the rules
   defined in this document to restrict the retention

OLD (sounds awkward)
   or that the resolution of parts of the Location Object is
   reduced.
NEW
   or that the resolution is reduced for parts of the Location
   Object.

OLD (to read more smoothly)
   The typical sequence of operations is as follows.  A Location Server
   receives a query
NEW
   In the typical sequence of operations, a Location Server
   receives a query

OLD (awkward usage)
   determine under which circumstances the entity executing the rules,
   for example a Location Server,
NEW
   determine under which circumstances the entity executing the rules,
   such as a Location Server,

-- Section 2 --
OLD (setting off defined terms)
      The term permission refers to the action and transformation
      components of a rule.
NEW
      The term "permission" refers to the action and transformation
      components of a rule.
OR
      The term Permission refers to the action and transformation
      components of a rule.

In general, please be consistent with how you set off defined terms, and avoid using a term in a definition while making it look like it's just part of the sentence.

OLD (bad usage)
      as motivated in RFC 4079

This usage of "motivated" is made-up business jargon and will be difficult for many non-native speakers (and quite some native speakers) to understand.
NEW
      as explained in RFC 4079
[or "described in", or something like that]

-- Section 4.1 --

OLD (repetition)
   reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the
   European Petroleum Survey Group
NEW
Can you re-word this to avoid the "based on... based on" repetition?

-- Section 7.5 --

OLD
      We will set up a grid not only for the continental US, but for the
      whole earth between latitudes 25 and 50 degrees

You're not including Alaska.  This is a total nit, but in order to avoid arguments about whether "continental" U.S. includes Alaska, you might switch to "contiguous US".

-- Section 13.1 --

First paragraph has a spurious ")" at the end.

OLD (unclear antecedent)
   This algorithm for
   geodetic location information obfuscation makes use of these
   techniques.
NEW
   The algorithm defined in this document for
   geodetic location information obfuscation makes use of these
   techniques.

-- Section 13.2 --

OLD
   For example, when a transformation indicates that civic location is
   provided at a 'building' level of granularity.  Consequently, floor
   levels, room numbers, etc. would be hidden.

The first sentence is not a complete sentence, and the second is not a very good one.  Merge these, and make a proper sentence.  Maybe (assuming I understand what you mean to say) something like this?:

NEW
   For example, when a transformation indicates that civic location is
   provided at a 'building' level of granularity, floor levels, room
   numbers, and other detailed information would be hidden.

The paragraph that begins thus:
   The algorithm presented in Section 6.5.2 has some measures against
   leaking information when moving, switching from one privacy region to
   another one
...is very long, and has quite a number of grammatical errors.  I suggest getting one of the native-English-speaking editors to fix this and to split it into at least three paragraphs.

-- IANA Considerations --
I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address.  Should you perhaps be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual?  (I notice that Hannes's other document on this telechat has his old Siemens address, and discussion mail is bouncing as a result... that's the sort of thing I mean.)

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

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

[Ballot comment]
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  element contains zero, one or an unbounded number of
    child element(s).  Providing more than one
    element may not be useful since all child
  elements of the  element must evaluate to TRUE in order
  for the  element to be TRUE.  The
  element MUST contain at least one  child element.  The
    element evaluates to TRUE if any of its child
  elements is TRUE, i.e., a logical OR.

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

  The  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
  element and each profile needs to describe under what conditions each
    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  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  element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the  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  and the  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 , that  should evaluate FALSE if if another known child of  evaluates TRUE? That violates the logical OR of the  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  element is missing"? This reads as if the  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 " 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?

[Ballot comment]
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  element contains zero, one or an unbounded number of
    child element(s).  Providing more than one
    element may not be useful since all child
  elements of the  element must evaluate to TRUE in order
  for the  element to be TRUE.  The
  element MUST contain at least one  child element.  The
    element evaluates to TRUE if any of its child
  elements is TRUE, i.e., a logical OR.

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

  The  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
  element and each profile needs to describe under what conditions each
    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  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  element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the  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  and the  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 , that  should evaluate FALSE if if another known child of  evaluates TRUE? That violates the logical OR of the  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  element is missing"? This reads as if the  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 " 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?

[Ballot comment]
[Not done with my comments yet. Not recording my position yet.]

This document needs a great deal of editing for simplification and clarity. There's a great deal of use of the passive voice with verbs that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing:

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

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

  The  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
  element and each profile needs to describe under what conditions each
    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  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  element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the  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. From here on, I will point only out places where the language obfuscates meaning.

4:

  The  and the  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 , that  should evaluate FALSE if if another known child of  evaluates TRUE? That violates the logical OR of the  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  element is missing"? This reads as if the  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 " 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?

[Ballot comment]
[Not done with my comments yet. Not recording my position yet.]

This document needs a great deal of editing for simplification and clarity. There's a great deal of use of the passive voice with verbs that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing:

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

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

  The  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
  element and each profile needs to describe under what conditions each
    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  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  element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the  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. From here on, I will point only out places where the language obfuscates meaning.

4:

  The  and the  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 , that  should evaluate FALSE if if another known child of  evaluates TRUE? That violates the logical OR of the  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  element is missing"? This reads as if the  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 " element is an integer." I assume unsigned, yes? Probably best to say.

[Ballot comment]
Minor editorial nits:

section 4:

  The 'profile' attribute allows to indicate the
  location profile that is included as child elements in the
  element and each profile needs to describe under what conditions each
    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.

[Ballot discuss]
Just trying to make this actionable (I understand this parenthetical bit isn't so much: the rest of the section needs a good editorial pass to make sure it makes sense -see my comments):

The last paragraph in s13.2 seems like it might be missing a discussion about one of the three things listed in the 1st sentence.  There's a discussion about the 1st and 2nd issue but not the 3rd and the 1st and 2nd issue both "the following", which I assume has something to do with Jack Torrance/Nicholson.  Maybe it's just editorial, but I'd like to make sure nothing got dropped.

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

[Ballot discuss]
-- IANA Considerations --
To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name.  It would be nice to include the URL as well, to be absolutely sure.  I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5.  The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct?

For the new registry in 11.3, I would like to see a rationale for the choice of registration policy.  See draft-leiba-iana-policy-update, if you want to see where I'm coming from here.  Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option.

I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address.  Discussion: should you be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual?

[Ballot comment]
Substantive suggestions; please adopt or respond to these:

-- Introduction --

   This document does not describe the protocol used to convey location
   information from the Location Server to the Location Recipient.

What document does?  Should it be noted here, with a citation?
----
OLD (unclear what part is "for example")
   Transformations regulate in a location information
   context how a Location Server modifies the information elements that
   are returned to the requestor, for example, by reducing the
   granularity of returned location information.
NEW (I think you mean...)
   Transformations regulate in a location information
   context how a Location Server modifies the information elements that
   are returned to the requestor by, for example, reducing the
   granularity of returned location information.
----
   Both algorithms come with limitations, i.e. they
   provide location obfuscation under certain conditions and may
   therefore not be appropriate for all application domains.

It's not clear exactly what this means.  Is the only limitation the one related to the obfuscation?  If there are other limitations, then it should be "e.g.", not "i.e."  If that's the only limitation, I suggest replacing "limitations, i.e." with "limitations:".  Also, it doesn't make sense that providing location obfuscation would be a limitation; perhaps you mean *only* under certain conditions?  So maybe this is what you mean?:
NEW
   Both algorithms come with limitations: they
   provide location obfuscation only under certain conditions,
   and may  therefore not be appropriate for all application domains.

-- Section 3.1 --

The preferred term now is "media type", not "MIME type"; please change it. Also in Section 10.4.

-- Section 3.2 --

URL, not URI ?

-- Section 6.2 --

   The value provided with the  element indicates
   seconds and these seconds are added to the current date.

   If the  element is absent then the value of the
    element in the PIDF-LO is kept unchanged or, if
   the PIDF-LO is created for the first time, then the value MUST be set
   to the current date.

It looks like "current date" means "current date and time"; should you not say that?  Also, I guess absence then means that the retention expiry is immediate... and I presume that's OK.

-- Section 6.4 --

   If the  element is absent, then the value of the
    element in the PIDF-LO is kept unchanged when
   available or, if the PIDF-LO is created for the first time then the
    element MUST NOT be included.

This creates an interesting situation, in which the absence of a value has a meaning that cannot be conveyed by any value that might be present.  That's odd, and possible troublesome, so I want to be sure you've thought about that.

-- Internationaliztion Considerations --

   The content of the
   element is meant to be provided by a human (the Rule Maker) and also
   displayed to a human.

Does this also mean that the information might need to be language-tagged and/or translated (in addition to perhaps being in non-ASCII characters?

-- Section 13.3 --

The first paragraph is confusing,  and doesn't seem to reach a reasonable conclusion.  It purports to talk about usability, but then seems to get into information leakage, and never makes a point that seems to me to be clear and useful.  Please try to re-work that paragraph.

-- Section 13.4 --

   Location obscuring attempts to remove information about the location
   of a Target.  The effectiveness of location obscuring is determined
   by how much uncertainty a Location Recipient has about the location
   of the Target.

As you note earlier (and later, two paragraphs down), this is oversimplified: the effectiveness is not determined just by that, but is also strongly influenced by what can be revealed by repeated queries over time -- how aggregating responses can reveal more than a single response will.

   Obscured locations can still serve a purpose where a Location
   Recipient is willing to respect privacy.

It's not clear what value that paragraph has.  It seems to say, basically, "If the LR doesn't want to attack you, then whatever you've done will be fine."  It's true, but not very useful as a security consideration.  You might just want to remove this paragraph, and take the word "more" out of the subsequent one.

This is an old document; please double-check the references to make sure they're accurate, current, and correctly classified.  The reference to RFC 2434 is obsolete, replaced by 5226, for example.

========
Editorial suggestions.  No need to respond to these; take them, leave them, or modify them as you please.  There are also numerous errors in punctuation, number agreement, and the like; it would be good for one of the native English speaking editors to go through the document source code and fix those... or I guess we can let the RFC Editor deal with them.

-- Introduction --

(clarity)
Not all terminology is in one place, and Target isn't specifically defined.  I suggest the following structure for the introduction (and if you do this, you can remove the second paragraph from section 2):
   -----
   1. Introduction
       First sentence as written.  Second sentence.

   1.1 Terminology for the model, as in RFC 3693
       Location Generator (LG), [explain].
       Location Server (LS), ...
       Location Recipient (LR), ...
       Rule Maker (RM), ...
       Authorization Policy, ...
       Location Object (LO), ...
       Target, ...

   1.2 Overview
       The basic rule set defined [...]
   -----

OLD (sounds awkward)
   The basic rule set,
   however, does not allow to control access to location information
   based on specific Location Recipients.
NEW
   The basic rule set,
   however, does not allow access control for location information
   based on specific Location Recipients.

OLD (clarity)
   The rule set allows the entity that uses the rules defined in this
   document to restrict the retention
NEW
   The enhanced rule set allows the entity that uses the rules
   defined in this document to restrict the retention

OLD (sounds awkward)
   or that the resolution of parts of the Location Object is
   reduced.
NEW
   or that the resolution is reduced for parts of the Location
   Object.

OLD (to read more smoothly)
   The typical sequence of operations is as follows.  A Location Server
   receives a query
NEW
   In the typical sequence of operations, a Location Server
   receives a query

OLD (awkward usage)
   determine under which circumstances the entity executing the rules,
   for example a Location Server,
NEW
   determine under which circumstances the entity executing the rules,
   such as a Location Server,

-- Section 2 --
OLD (setting off defined terms)
      The term permission refers to the action and transformation
      components of a rule.
NEW
      The term "permission" refers to the action and transformation
      components of a rule.
OR
      The term Permission refers to the action and transformation
      components of a rule.

In general, please be consistent with how you set off defined terms, and avoid using a term in a definition while making it look like it's just part of the sentence.

OLD (bad usage)
      as motivated in RFC 4079

This usage of "motivated" is made-up business jargon and will be difficult for many non-native speakers (and quite some native speakers) to understand.
NEW
      as explained in RFC 4079
[or "described in", or something like that]

-- Section 4.1 --

OLD (repetition)
   reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the
   European Petroleum Survey Group
NEW
Can you re-word this to avoid the "based on... based on" repetition?

-- Section 7.5 --

OLD
      We will set up a grid not only for the continental US, but for the
      whole earth between latitudes 25 and 50 degrees

You're not including Alaska.  This is a total nit, but in order to avoid arguments about whether "continental" U.S. includes Alaska, you might switch to "contiguous US".

-- Section 13.1 --

First paragraph has a spurious ")" at the end.

OLD (unclear antecedent)
   This algorithm for
   geodetic location information obfuscation makes use of these
   techniques.
NEW
   The algorithm defined in this document for
   geodetic location information obfuscation makes use of these
   techniques.

-- Section 13.2 --

OLD
   For example, when a transformation indicates that civic location is
   provided at a 'building' level of granularity.  Consequently, floor
   levels, room numbers, etc. would be hidden.

The first sentence is not a complete sentence, and the second is not a very good one.  Merge these, and make a proper sentence.  Maybe (assuming I understand what you mean to say) something like this?:

NEW
   For example, when a transformation indicates that civic location is
   provided at a 'building' level of granularity, floor levels, room
   numbers, and other detailed information would be hidden.

The paragraph that begins thus:
   The algorithm presented in Section 6.5.2 has some measures against
   leaking information when moving, switching from one privacy region to
   another one
...is very long, and has quite a number of grammatical errors.  I suggest getting one of the native-English-speaking editors to fix this and to split it into at least three paragraphs.

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

[Ballot discuss]
Since the previous iesg discussions on this document pre-date me as an AD
I might be commenting here on things that have already been discussed.
If so, just send me a pointer if you can to the earlier discussion.

- general: repeated queries are a threat here and are recognised as such
in a number of places. I would like to have seen some guidanace to
implementers as to when such repeated queries might be considered to be
an attack, and when not, and if there's something you can do about that.
Can such guidance be offered?  If so, why not include it in the document?
If not, perhaps saying why that's the case would be worthwhile?

- 13.4: The last sentence is too vague IMO. I think you mean that if
location is only obscured e.g. around the home, then the lack of location
implies that I'm at home. You should say that more clearly.

[Ballot comment]

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/?

IANA has a question about one of the actions requested in this document.

IANA understands that, upon approval of this document, there are six
IANA actions which must be completed.

First, in the XML Schemas subregistry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new schema will be registered as follows:

ID: geolocation-policy
URI: urn:ietf:params:xml:schema:geolocation-policy
Filename: As provided in Section 9 of the approved document
Reference: [ RFC-to-be ]

Second, in the XML Namesspaces subregistry of the IETF XML registry
located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new namespace will be registered as follows:

ID: geolocation-policy
URI: urn:ietf:params:xml:ns:geolocation-policy
Registry template: As provided in section 11.2 of the approved document
Reference: [ RFC-to-be ]

Third, IANA will create a new registry called the "Geolocation Policy
Location Profiles" registry.

Each profile name will be an XML token.

Maintenance of the registry will be through Standards Action.

There are initial values for the registry:

IANA QUESTION -> Is this the only information that the new registry
should contain?

Policy Location Profile Reference
-------------------------------|--------------|
geodetic-condition [ RFC-to-be ]
civic-condition [ RFC-to-be ]
geodetic-transformation [ RFC-to-be ]
civic-transformation [ RFC-to-be ]

Fourth, in the XML Schemas subregistry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new schema will be registered as follows:

ID: basic-location-profiles
URI: urn:ietf:params:xml:schema:basic-location-profiles
Filename: As provided in Section 8 of the approved document
Reference: [ RFC-to-be ]

Fifth, in the XML Namesspaces subregistry of the IETF XML registry
located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new namespace will be registered as follows:

ID: basic-location-profiles
URI: urn:ietf:params:xml:ns:basic-location-profiles
Registry template: As provided in section 11.5 of the approved document
Reference: [ RFC-to-be ]

Sixth, in the XCAP Application Unique IDs subregistry in the Extensible
Markup Language (XML) Configuration Access Protocol (XCAP) Parameters
registry located at:

http://www.iana.org/assignments/xcap-parameters/xcap-parameters.xml

a new XCAP Application Usage ID will be registered as follows:

Application Unique ID: geolocation-policy
Description: Geolocation privacy rules are documents that describe the
permissions that a Target has granted to Location Recipients that access
information about his/her geographic location.
Reference: [ RFC-to-be ]

IANA understands that these six actions are the only actions required to
be completed upon approval of the document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC. This
message is only to confirm what actions will be performed.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information) to Proposed Standard





The IESG has received a request from the Geographic Location/Privacy WG

(geopriv) to consider the following document:

- 'Geolocation Policy: A Document Format for Expressing Privacy

  Preferences for Location Information'

  as a Proposed Standard



This last call focuses on the changes related to location obfuscation (fuzzing)

resulting from additional working group attention resulting from a prior IESG review.

Please focus the review on the difference between versions -21 and -25 of this draft.



Version -21 of this document was IETF LCed in Jun 2010. Subsequent

IESG review identified an issue with location obfuscation that required

additional working group attention.



Version -11 of this document was IETF LCed in Feb 2007 -  subsequent

IESG review identified several issues. The resulting working group

discussion resulted in significant changes to the document.





The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-03. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This document defines an authorization policy language for

  controlling access to location information.  It extends the Common

  Policy authorization framework to provide location-specific access

  control.  More specifically, this document defines condition elements

  specific to location information in order to restrict access based on

  the current location of the Target.



  Furthermore, this document defines two algorithms for reducing the

  granularity of returned location information.  The first algorithm is

  defined for usage with civic location information while the other one

  applies to geodetic location information.  Both algorithms come with

  limitations, i.e. they provide location obfuscation under certain

  conditions and may therefore not be appropriate for all application

  domains.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy/ballot/





No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

A Standards Track RFC is being requested. This is appropriate because the document defines a uniform protocol for expressing privacy rules. This is the type of RFC indicated in the title page header.


(2) 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 defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location-specific transformation elements to reduce the granularity of the returned location information.

Working Group Summary

There is strong, long-standing consensus in the working group that the policies described this document are a useful way to transmit geolocation-based privacy policies. The main point of discussion in the working group was over which "fuzzing" algorithm(s) should be mandatory to implement, given that all known algorithms have failings. In the end, there was strong consensus that the current approach, with an extensive discussion of risks associated with fuzzing, is the most appropriate.

Document Quality

The document has been reviewed by key participants from the GEOPRIV working group. In the process of analyzing fuzzing algorithms, there were several experimental implementations.


Personnel

The document shepherd is Richard Barnes. The responsible AD is Robert Sparks.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed this document, and think it is r easy for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the depth or breadth of review. Over the several years it has been in discussion, this document has received very thorough review from several perspectives.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I do not believe that this document requires any special review. It does contain XML schemas, but the structures it defines are simple and have been reviewed by members of the working group with XML expertise.


(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

I do not have any special concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.


(9) 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?

WG consensus behind this document is very strong. There was robust debate over the issue of location fuzzing, with contributions from many participants. All parties agreed to the current approach.


(10) 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 publicly available.)

I am not aware of any threats of appeal or other extreme discontent.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document may require some minor changes to copyright boilerplate: The idnits tool warns of pre-RFC5378 work, but to my knowledge, there are no RFC5378 concerns for this document.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document does not contain MIBs or other data types that require formal review.


(13) Have all references within this document been identified as
either normative or informative?

The references are split into normative and informative.


(14) 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 plan for their completion?

All normative references are either Standards Track RFCs or external documents in a similar state of maturity.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

There are no downward normative references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations are consistent with the body of the document, and provide clear instructions to IANA.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The document creates one registry, which requires Standards Action for modification.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The document contains two XML schemas and several example XML documents. I have validated that these XML structures are well-formed using the W3C automated validator ().

State changed to AD is watching from Waiting for AD Go-Ahead.
The GEOPRIV working group is going to rework the location obscuring algorithm section and re-request publication when they achieve consensus on the revision.

IANA questions/comments:

- In Section 11.3 you ask for the creation of the Geolocation Policy
Location Profile Registry, but you don't define the information you
want in the registry. Is the only information required the Profile
Name (and document reference)? Or do you need additional
information as well, such as the profile definition?

Action 1 (Sections 11.1, 11.4):

Upon approval of this document, IANA will make the following assignments
in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
-- ---------------- -------- ---------
geolocation-policy urn:ietf:params:xml:schema:geolocation-policy
geolocation-policy [RFC-geopriv-policy-21]
basic-location-profiles urn:ietf:params:xml:schema:basic-location-profiles
basic-location-profiles [RFC-geopriv-policy-21]

Action 2 (Section 11.2, 11.5):

Upon approval of this document, IANA will make the following assignments
in the "ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration Template Reference
-- ---------------- --------------------- ---------
geolocation-policy urn:ietf:params:xml:ns:geolocation-policy
geolocation-policy
[RFC-geopriv-policy-21]
basic-location-profiles urn:ietf:params:xml:ns:basic-location-profiles
basic-location-profiles [RFC-geopriv-policy-21]


Action 3 (Section 11.3):

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: Geolocation Policy Location Profiles
Registration Procedures: Standards Action
Initial contents of this registry will be:

Profile Name Reference
------------ ---------
geodetic-condition [RFC-geopriv-policy-21]
civic-condition [RFC-geopriv-policy-21]
geodetic-transformation [RFC-geopriv-policy-21]
civic-transformation [RFC-geopriv-policy-21]


Action 4 (Section 11.6):

Upon approval of this document, IANA will make the following assignments
in the "Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) Parameters" registry located at
http://www.iana.org/assignments/xcap-parameters/xcap-parameters.xhtml
"XCAP Application Unique IDs"

Application Unique ID (AUID): geolocation-policy
Description: Geolocation privacy rules are documents that describe the
permissions that a Target has granted to Location
Recipients that access information about his/her
geographic location.
Reference: [RFC-geopriv-policy-21]

The GEOPRIV working group requests publication of draft-ietf-geopriv-
policy-21 as Proposed Standard.

(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 Richard Barnes. The
Shepherd has personally reviewed this version of the document, and
believes it is ready for publication.

(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 been the subject of thorough discussion within the
GEOPRIV working group. I have no concerns about the level of review
this document has received.

(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?

I do not believe that this document requires any special review. It
does contain XML schemas, but the structures it defines are simple and
have been reviewed by members of the working group with XML expertise.

(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. There have been no
IPR disclosures related to the document.

(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 strong, broad-based, and long-standing consensus in the
working group that this document is a useful and usable way to encode
geolocation-based privacy rules.

(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?

I have verified that the the document satisfies all ID nits, though it
contains a few out-of-date references (which can be fixed as last-call
and IESG comments are addressed). The document does not contain MIBs
or other content that requires special review.

(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. There is one
normative reference to a non-IETF document, the Open Geospatial
Consortium standard for the Geospatial Markup Language (GML). This
reference is stable, and GML is generally considered to have an
equivalent level of maturity to a standards-track RFC.

(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?

The IANA considerations section exists, and provides instructions for
IANA to (1) register two new XML schemas and namespaces, and a new
XCAP Application Unique ID; and (2) create a registry of "location
profiles" (operating under the Standards Action policy).

(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?

The document contains two XML schemas and several example XML
documents. I have validated that these XML structures are well-formed
using the W3C automated validator ().

(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 defines an authorization policy language for controlling
access to location information. It extends the Common Policy
authorization framework to provide location-specific access control.
More specifically, this document defines condition elements specific
to location information in order to restrict access based on the
current location of the Target. Furthermore, it offers location-
specific transformation elements to reduce the granularity of the
returned location information.


Working Group Summary

There is strong, long-standing consensus in the working group that the
policies described this document are a useful way to transmit
geolocation-based privacy policies.


Document Quality

The document has been reviewed by key participants from the GEOPRIV
working group.

I believe that some of the issues raised in discuss will need to go back to the working group for discussion. I am glad to work with people to help figure out resolution to all of these.

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

[Ballot comment]
Consider a the four corners of Colorado.  (Colorado is a rectangle.)
  Call the northeast corner A.  Call the northwest corner B.  Call the
  southwest corner C.  Call the southeast corner D.  It is pretty clear
  that ABCDA is a valid polygon.  Is ACBDA a valid polygon?  I do not
  see text that would tell me that such a polygon is not allowed, but
  such text could be in EPSG 4326 or EPSG 4979.  I did not go look.  I
  have writen algorithms to find a polygon that includes all of the
  provided coordinates, but that does not seem like the right thing
  to do here. 

  The formula:
      n'=FLOOR(n*r + 0.5) * 1/r
  Can be simplified to:
      n'=FLOOR(n*r + 0.5)/r

[Ballot discuss]
In section 6.5.2, the values in the table for n=38.89868 do not seem
  right.  Working through the most simple case, where r=1.0, I get:
 
    39.39868 = n*r + 0.5
    39.00000 = FLOOR(n*r + 0.5)
    39.00000 = FLOOR(n*r + 0.5) * 1/r

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

[Ballot discuss]
Interdependencies between the civic and geodetic location information adds complexity that
should be addressed in the Security Considerations section.  I am specifically worried about
situations where differences in precision between the two location forms results in information
leakage.  I also see opportunities for error in the specification of rulesets in the two location
formats, but it is unclear whether choosing a single form for rulesets is a practical alternative.

[Ballot discuss]
> However,
> implementations SHOULD be prepared to accept small variations that
> might occur depending on whether the the polygon is specified on a
> plane in space, or only relative to the ellipsoid.

I do not understand how to implement this. Please clarify.

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

[Ballot discuss]
These mechanisms are too complicated and don't give enough thought to how different user-agents are going to interact.  In particular, one should imagine setting a privacy policy with one user agent and then trying to edit it with another.

It seems that geo-spatial policy creation requires some kind of user interface that includes a map.  Is that correct?  Are devices without maps then unable to modify or even read policies?

I am not sure that the polygons are as cut-and-dried as they appear.  I'd like to understand better:
- how one knows what is the inside of the polygon, and what is the outside
- ... how that interacts with poles and other problems mapping 2D to a sphere
- how the altitude stuff works at all with client GUIs
- when is altitude known and unknown, independent of knowing a rough long/lat position
- whether you can define a polygon for "Alberta" and one for "Saskatchewan" and have any point be in one or the other or completely outside both -- but not *inside* both, and not stuck in-between

When it comes to users viewing policies created in the past, the lack of human-readable labels and comments is going to be a real usability problem.

What happens when a user or user-agent creates a non-sensical geo-political or geo-spatial location? 

Are all geo-political elements *really* allowed in conditions?  One possible non-sensical policy would be "Show my location unless I'm in seat 32A".  Aren't there any restrictions here?

How are user agents supposed to handle mixed geo-spatial and civic location conditions? How would that be displayed or represented in a list of policy elements?

With the dependency on geopriv-revised-civic-lo, this can't complete yet anyway.

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

State Change Notice email list have been change to jmpolk@cisco.com, Hannes.Tschofenig@siemens.com, schulzrinne@cs.columbia.edu, rjsparks@nostrum.com from mankin@psg.com, jmpolk@cisco.com, rg+ietf@qualcomm.com, Hannes.Tschofenig@siemens.com, andy@hxr.us, schulzrinne@cs.columbia.edu

IANA Additional comments:

> Extract section 9 for action #1. Section 8 for action #4.
>
> NOTE: document in section 11.4 (action #4) says Section 9 but the
> corresponding XML schema looks like it is in Section 9.


It should read:

document in section 11.4 (action #4) says Section 9 but the
corresponding XML schema looks like it is in Section 8.

IANA Additional Comments:

> Action #2: (see section 11.2)
> Upon approval of this document, the IANA will make the following
> assignments in the "NS" registry located at
>
> http://www.iana.org/assignments/xml-registry/ns.html
> ID URI Template Reference
> geolocation-policy urn:ietf:params:xml:ns:geolocation-policy
>  [RFC-geopriv-policy-11]
>
> The XML schema to be linked to this entry is in section 11.2 of this
> document.


The XML schema corresponding to the namespace is in Section 9 and is
registered by the IANA consideration section in Section 11.2.

-----

> Action #4: (see section 11.4)
> Upon approval of this document, the IANA will make the following
> assignments in the "schema" registry located at
>
> http://www.iana.org/assignments/xml-registry/schema.html
>
> basic-location-profiles
> urn:ietf:params:xml:schema:basic-location-profiles
>
[RFC-geopriv-policy-11]
>
> The XML schema to be linked to this entry is in section 9 of this
> document,
>
>

HERE IS A BUG: The reference should go to Section 8.
The schema in Section 9 is already registered with Action #1.

----

> Action #5: (see section 11.5)
> Upon approval of this document, the IANA will make the following
> assignments in the "NS" registry located at
>
> http://www.iana.org/assignments/xml-registry/ns.html
> ID URI Template Reference
> basic-location-profiles
> urn:ietf:params:xml:ns:basic-location-profiles
>
[RFC-geopriv-policy-11]
>
> The XML schema to be linked to this entry is in section 11.4 of this
> document.
>

The XML schema corresponding to the namespace is in Section 8 and is
registered by the IANA consideration section in Section 11.4.


---

IANA Additional Comments:

IANA has a QUESTION.
-------------------

Extract section 9 for action #1.  Section 8 for action #4.

NOTE: document in section 11.4 (action #4) says Section 9 but the
corresponding XML schema looks like it is in Section 9.

IANA would like to ask editors if this is correct.

IANA Last Call Comments:

Action #1: (see section 11.1)
Upon approval of this document, the IANA will make the following
assignments in the "schema" registry located at

http://www.iana.org/assignments/xml-registry/schema.html

geolocation-policy urn:ietf:params:xml:schema:geolocation-policy
  [RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 9 of this
document.

Action #2: (see section 11.2)
Upon approval of this document, the IANA will make the following
assignments in the "NS" registry located at

http://www.iana.org/assignments/xml-registry/ns.html
ID URI Template Reference
geolocation-policy urn:ietf:params:xml:ns:geolocation-policy

  [RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 11.2 of this
document.

Action #3: (see section 11.3)
Upon approval of this document, the IANA will create the following
registry "Geolocation Policy Location Profile" located at
http://www.iana.org/assignments/TDB
Initial contents of this registry will be:

Token description Reference
geodetic-condition: Section 4.1. [RFC-geopriv-policy-11]
civic-condition: Section 4.2. [RFC-geopriv-policy-11]
geodetic-transformation: Section 6.5.2. [RFC-geopriv-policy-11]
civic-transformation: Section 6.5.1. [RFC-geopriv-policy-11]


Action #4: (see section 11.4)
Upon approval of this document, the IANA will make the following
assignments in the "schema" registry located at

http://www.iana.org/assignments/xml-registry/schema.html

basic-location-profiles urn:ietf:params:xml:schema:basic-location-profiles

[RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 9 of this
document,



Action #5: (see section 11.5)
Upon approval of this document, the IANA will make the following
assignments in the "NS" registry located at

http://www.iana.org/assignments/xml-registry/ns.html
ID URI Template Reference
basic-location-profiles urn:ietf:params:xml:ns:basic-location-profiles

[RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 11.4 of this
document.


Action #6: (see section 11.6)
Upon approval of this document, the IANA will make the following
assignments in the "Extensible Markup Language (XML) Configuration
Access Protocol (XCAP)  Parameters" registry located at

http://www.iana.org/assignments/xcap-parameters

ID Description Reference
geolocation-policy Geolocation privacy rules are documents
[RFC-geopriv-policy-11]
that describe the permissions that a Target
has granted to Location Recipients that
access information about his/her geographic
location.


We understand the above to be the only IANA Action for this
document.

IANA Last Call Comments:

Action #1: (see section 11.1)
Upon approval of this document, the IANA will make the following
assignments in the "schema" registry located at

http://www.iana.org/assignments/xml-registry/schema.html

geolocation-policy urn:ietf:params:xml:schema:geolocation-policy
  [RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 9 of this
document.

Action #2: (see section 11.2)
Upon approval of this document, the IANA will make the following
assignments in the "NS" registry located at

http://www.iana.org/assignments/xml-registry/ns.html
ID URI Template Reference
geolocation-policy urn:ietf:params:xml:ns:geolocation-policy

  [RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 11.2 of this
document.

Action #3: (see section 11.3)
Upon approval of this document, the IANA will create the following
registry "Geolocation Policy Location Profile" located at
http://www.iana.org/assignments/TDB
Initial contents of this registry will be:

Token description Reference
geodetic-condition: Section 4.1. [RFC-geopriv-policy-11]
civic-condition: Section 4.2. [RFC-geopriv-policy-11]
geodetic-transformation: Section 6.5.2. [RFC-geopriv-policy-11]
civic-transformation: Section 6.5.1. [RFC-geopriv-policy-11]


Action #4: (see section 11.4)
Upon approval of this document, the IANA will make the following
assignments in the "schema" registry located at

http://www.iana.org/assignments/xml-registry/schema.html

basic-location-profiles urn:ietf:params:xml:schema:basic-location-profiles

[RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 9 of this
document,



Action #5: (see section 11.5)
Upon approval of this document, the IANA will make the following
assignments in the "NS" registry located at

http://www.iana.org/assignments/xml-registry/ns.html
ID URI Template Reference
basic-location-profiles urn:ietf:params:xml:ns:basic-location-profiles

[RFC-geopriv-policy-11]

The XML schema to be linked to this entry is in section 11.4 of this
document.


Action #6: (see section 11.6)
Upon approval of this document, the IANA will make the following
assignments in the "Extensible Markup Language (XML) Configuration
Access Protocol (XCAP)  Parameters" registry located at

http://www.iana.org/assignments/xcap-parameters

ID Description Reference
geolocation-policy Geolocation privacy rules are documents
[RFC-geopriv-policy-11]
that describe the permissions that a Target
has granted to Location Recipients that
access information about his/her geographic
location.


We understand the above to be the only IANA Action for this
document.

I'm still working on this but had some initial questions that came up when reading it.....


When the draft says
  The  is of the 'civicAddress'
  complex type defined in [RFC4119].  It includes a number of fields,
  including the country, expressed as a two-letter ISO 3166 code, and
  the administrative units A1 through A6 of [I-D.ietf-geopriv-dhcp-
  civil]. 
I'm a bit confused about where the A1 to A6 were defined. I thought they were in 4119 and not sure why the dhcp-civil ref is here.

Section 8.2

Is the retention time in seconds?

Section 8.4

It seems like in the figure, at the city level, the set should include A3

Is this extensible such that we could add in some other level? I'm not implying it needs more - I'm just asking if people have though about the level of extensibility here and are happy with it.


Section 6.1

Do we need to specify any sort of particular rules for matching the strings here? I'm wondering about i18n type stuff. This may be find but give it some thought.

Section 6.2.1

First of all, I like the general way you have gone about doing the polygon.

I think you need to add the the edge of the polygon are the great circle arcs between the vertexes.

The term polygon is confusing in that Polygon is a type in GML but is not the same as a polygon here. Might want to point that out.

A Ring is an abstract class in GML, and the term LinearRing might be better for what we want. Might want to change this but it is not a huge deal.

I suspect the algorithm for point in polygon that is specified here does not work for some polygons in spherical geometries but I'm not sure. Certainly it would need better definition of what "go right" means in the spherical sense. It you just use the planar version of it with lat, lon, it clearly won't work on polygons spanning the date line.

I don't see why you need to have the last vertex repeated - i understand GML does that but that was largely historical and this is not GML any more so I think you should consider not doing this. Either way, be keep it explicit about it is repeated or not.

The schema for polygon has min occurrence of 3 points but if you stay with the requirement that the first needs vertex to be repeated as the last, this should be 4.

When doing a point in polygon test, we need more definition about what happens to points that are on the edge or vertex of the polygon.

Altitude assumes WGS84 coordinate system but polygon allow others to be specified. Is this really what you want?



References

Move geopriv-common-policy to normative references

Decide if you need the deopriv-dhcp-civil reference

Remove xcap, webdav, and 3825 references

Add an IANA section that says there are no IANA considerations.

Technical Summary

    This document defines the specific usage for controlling
    access to location information, given the framework for
    authorization policies controlling access to application
    data provided in the already approved document
    draft-ietf-geopriv-common-policy.

    Access control authorization is specified using XML Schema
    in which policy rules are expressed.

Work Group Summary

    This document represents the consensus of the GEOPRIV working
    group. 

Protocol Quality

  The document received careful review by geolocation application
  specialists participating in the working group.

  is the WG Chair shepherd and Cullen Jennings is the
  Responsible Area Director.

  o  We have found one nit, the absence of a blank IANA considerations
    section.

  o [I-D.ietf-geopriv-common-policy] needs to be a normative reference

  o [I-D.ietf-geopriv-dhcp-civil] probably needs to be a normative reference

  Note to RFC Editor:

  Change the References section to 13, and add a new Section 12:

    12. IANA Considerations

    This document contains no actions for the IANA.

State Change Notice email list have been change to mankin@psg.com, jmpolk@cisco.com, rg+ietf@qualcomm.com, Hannes.Tschofenig@siemens.com, andy@hxr.us, schulzrinne@cs.columbia.edu from mankin@psg.com, rg+ietf@qualcomm.com, andy@hxr.us