Hello,

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
<http://www.apps.ietf.org/content/applications-area-review-team>).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-geopriv-policy-21
Title: Geolocation Policy: A Document Format for Expressing Privacy
        Preferences for Location Information
Reviewer: Martin Dürst
Review Date: 2010-09-26

Summary: No major issue; minor issues that may benefit from fixing

MAJOR ISSUES: None that I found. I have just read through the draft 
itself, but in no way tried to look at the long history of this draft, 
or the discusses in the datatracker, and I do in no way want to claim 
that I understand much of geopriv or the surrounding policy framework.

MINOR ISSUES (These are issues that would benefit from clarification, or 
that might be done in a somewhat better way for another spec in the 
future, unless somebody thinks they need to be escalated):

- The Copyright notice doesn't have a pre-November 10, 2008 exception
   clause. Given the age of the document, I'd have assumed it needs one,
   but it's up to the authors to know what works here.

- Section 2, Terminology: "Presentity or Target" and
   "Watcher or Location Recipient": Defining two parallel terms is
   confusing. Better define one term for use in the document, and mention
   as part of the definition that the other term is also used in some
   contexts.

- Section 4 says that a <location-condition> element evaluates to TRUE
   if any of its child elements are true, i.e., *a logical OR*.
   It would be very helpful if the explanation in terms of logical ANDs
   or ORs would be added to the other places where such logical
   operations take place.

- Section 4: "the location profile that *is* included as child
   element*s*": Singular/plural mismatch

- Section 4: lt;location>: conversion error from XML?

- Section 4: using the xml:lang to describe the language of attribute
   values is not exactly forbidden, but also not recommended, ond not
   future-proof (think about adding another attribute that might need
   different language information). Best practice is to change any
   attributes that contain natural-language content into elements.

- Section 4: Better add a reference to BCP 47 for language tags.

- Section 4: "If an extension is not understood by the entity
   evaluating the rules then this rule evaluates to FALSE.":
   Does this apply to the unknown extension element itself, or
   to the element that contains this extension element? This should
   be clarified. Also, "The <location-condition> and the <location>
   elements provide extension points." should be clarified by saying
   how these extension points are provided (e.g. via some attribute
   values, new attributes, contained elements, or whatever).

- Section 4.1: "if .. is *within* the described location.": as locations
   can be described e.g. by polygons,..., it should say either
   *fully within* or *partially within* or some such.

- Section 4.1: "If the geodetic
   location of the Target is unknown then the <location> element
   containing the information for the geodetic location profile
   evaluates to FALSE.": Does that mean that it is impossible to
   express the fact that I want 'unknown' locations to be transferred
   through? (This would allow the distinction between "I'm currently
   at a location I don't want to tell you" and "no information
   available", which in some cases may be something that the
   originator of the information wants to reveal.)

- Section 4.2: "The child element evaluates to TRUE if
   the two values are identical based on a *bit-by-bit* comparison.":
   XML doesn't transport bits, only Unicode codepoints. This should
   say "based on a *codepoint-by-codepoint comparison*".

- Section 4.2: "i.e., geocode the location": For all I'm aware,
   geocoding refers to the translation from civic location (such
   as addresses,...) to geodetic location, not the other way around
   as implied here.

- Section 6.2: "seconds are added to the current *date*": How do I add
   e.g. 5 seconds to a date such as 2010-09-29? Shouldn't this say
   "seconds are added to the current *time*"? (the fact that the Unix
   date command gives date and time, whereas the time command does
   something else altogether is irrelevant here :-)

- Section 6.2: "then the value MUST be set to the current date":
   If a date is really only a date, then this would mean that expiry
   would depend highly on the time within the day, and therefore the
   timezone. If it is a date-time, then it would mean immediate
   expiry, which could mean that there is no chance to forward this
   data to anybody assuming that forwarding takes some non-zero
   amount of time. Is this really what's intended?

- Section 6.3: "The value provided with the <set-note-well> element 
contains a
    privacy statement as a human readable text string and an 'xml:lang'
    attribute *denotes* the language of the human readable text.":
    denotes -> denoting?

- Section 6.3: If different parties involved understand different
   lanugages, what's the language to choose for the <note-well>?

- Section 6.5.1: The split into country/region/city/building/full
   may work very well for the US, but to what extent has it been
   checked that this split makes sense for other locations?

- Section 7.1: Given that address data is compared literally,
   the choice of example exposes a basic problem: How can e.g.
   <A3>Munich</A3> be matched with <A3>München</A3>,...? Is there
   some convention that the data and rules have to be in English
   (that would be very limiting)? Is there a way to write rules
   that match both Munich and München, in the logically expected
   way? Please explain.

- Section 7.4: There is a long example with three namespaces.
   In general, it is totally unnecessary to create a separate
   namepace for every minor extension and addition. For example,
   something like
   <gp:provide-location><lp:provide-geo>
   with two separate namespaces seems totally over-engineered.
   Better to make sure elements from extensions don't overlap,
   and to the extent they don't overlap, put them in the same
   namespace. This will make stuff shorter and easier to read.

- Section 10.7: "will look for all documents within http://.../foo":
   The HTTP protocol doesn't provide a way to enumerate all documents
   within a certain URI (and the URI doesn't terminate with a slash,
   so it's not even a directory). If this is XCAP-specific functionality,
   then please slightly rewrite to make it easier to understand for
   outsiders.

- Section 11.3: "Profile names are XML tokens": The XML spec talks about
   Nmtokens (name tokens). That's the closest to "tokens" that I was able
   to find. It should be clarified, also in the respect that the "are"
   should be replaced by something that makes clear that this is a
   syntax restriction, not something on a semantic level.

- Section 12: "to understand UTF-8 and UTF-16 encodings": reword,
   e.g. to "to understand UTF-8 and UTF-16" or to "to understand the
   UTF-8 and UTF-16 character encodings".

- Section 13: "a discussion of generic security threats": make clear in
   which respect these are 'generic'

- Section 13: "For example, when a transformation...": incomplete
   sentence.

- Section 13: "a random number to is added to": remove first 'to'

- Section 13, 4th paragraph: This would be much easier to understand
   with an example or two.

- Section 13: "Users might create policies that are non-sensical.":
   What does that mean? How is software supposed to perform consistency
   checks if the only thing we know is that we want to guard against
   'non-sensical'?

- [ifip07]: change to [ardanga07] for consistency?

- Appendix A: Why are there email addresses for some of the people
   listed here? So that we can complain to them (rather than the
   authors?) about errors in the document? Also, an 'and' is missing
   before the last person.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp