Common Policy: A Document Format for Expressing Privacy Preferences
draft-ietf-geopriv-common-policy-11

No Objection based on the expected -10 version.

I'd like to see "XML" in the title.

Section 10.1 includes:


   We use the following terminology (which in parts has already been
   introduced in previous sections): The term 'permission' stands for an
   action or a transformation.  The notion 'attribute' terms a
   condition, an action, or a transformation.

Presumably 'permission' stands for an *allowed* action or transformation.
Wouldn't it be more clear to call this a 'capability'? That seems to be
a more common term in the security community. The final sentence makes
no sense as written.

The non-goals include:

   No repeat times:

      Repeat times (e.g., every day from 9am to 4pm) are difficult to
      make work correctly, due to the different time zones that PT, WR,
      PS and RM may occupy.  It appears that suggestions for including
      time intervals are often based on supporting work/non-work
      distinctions, which unfortunately are difficult to capture by time
      alone. 

I believe there is an opportunity for synergy with calendaring here,
where these problems have to be solved anyway.

(Also see earlier comments in the Gen-ART review at 
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-geopriv-common-policy-08-brim.txt)

FYI - spelling issues: "controling", "entitites", "speific", "therfore"

In the author list: "Cisco" and "Cisco Systems" are the same company (AFAIK!). Also, I count 6 authors, I believe the Editor will only allow 5 at the top of a document.

  I think that the author count is higher than the RFC Editor will
  allow.
  
  I suggest deleting the section heading for 10.1, and then renumbering
  the remaining subsections in section 10.

  Section 1.2 says:
  >
  > The combining operation will result in the largest value for an
  > Integral type, the OR operation for boolean, and union for set.
  >
  This would be useful to know before the details of the rules.
  Please move it to the begining of the subsection.

  The following comments were part of Tim Polk's SecDir Review.

  Section 2, introduces the following terms: Presentity/Target (PT);
  Rule Maker (RM); Policy Server (PS); and Watcher/Recipient (WR).
  Only the PS was related to the terminology of RFC 3693.  I strongly
  suggest following the example of the terminology section in
  draft-ietf-geopriv-policy-08.txt and link the PT and WR terminology
  to their RFC 3693 counterparts.

  Section 6.2 states:
  >
  > this schema is not expected to change excepting a revision to this
  > specification, and that no versioning procedures for this schema or
  > namespace are therfore provided.
  >
  Are the authors suggesting that they won't ever revise this schema,
  or just that a new version of the document would simply define a new
  xmlns instead of the "urn:ietf:params:xml:ns:common-policy"?  If it
  is the latter, then there is not a problem, but they should state
  this more clearly for those of us that don't know XML to the same
  level of detail.

  Section 7.1.4 concludes with a description of the name comparison
  operation for domain names.  The fourth step is not defined
  completely.  Since it is the last step, noting the final answer
  would be appropriate.  I suggest replacing the current text:
  >
  > 4.  Compare the two domain strings for ASCII equality, for each
  >     label.
  >
  with the following:
  >
  > 4.  Compare the two domain strings for ASCII equality, for each
  >     label. If the string comparison for each label indicates
  >     equality, then the comparison succeeds.  Otherwise, the
  >     domains are not equal.

  Section 7.1.4.1, in the second example defines an identity condition
  that matches *any* user, whether or not they can be authenticated.
  In this example, the identity condition is present without a "one" or
  "many" element.  This feature deserves to be highlighted in its own
  section.  It would also be interesting to understand how this
  compares with a rule that omitted the identity condition entirely.

  The example in section 7.1.4.2 includes the "sphere" element as a 
  condition, but sphere is not introduced until section 7.2.  This
  feature is not discussed in this section, and is unnecessary for the
  example.  I found this very confusing, and suggest the sphere
  condition be deleted from the example.

  Section 10.2 defines three combining rules: CR 1, CR 2, and CR 3.
  Each combining rule assumes all values are of a single type.  I did
  not find anything that says all values associated with a particular
  attribute must be of the same type.  Perhaps I missed it; or perhaps
  it is enforced by XML itself.  If not, a simple rule needs to be
  added stating that mixed types results in (an error?).

  The security considerations section covers the ramifications of the 
  combining rules, but otherwise states that security considerations
  are application data dependent and punts to "documents that extend
  the framework defined in this specification."  I would prefer to see
  the security considerations should point to RFC 3693 (Geopriv 
  Requirements) and RFC 3694 (Threat Analysis of the Geopriv Protocol)
  as an example of the analysis required by other documents and
  applications.

I am a bit concerned that the presence aspects of this work fall
outside of the current geopriv charter.  However since the presence
actions and transformations are in a simple document I will not hold a
discuss.  If there is going to be future overlap between geopriv and
presence I would strongly suggest a recharter.