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

The RFC Editor note on this has become fairly long and I would really appreciate it if one of the authors could make a new revision that incorporates these changes (and check they agree with them).

Thanks, Cullen

The current changes are:


1)
  OLD:
  This specification requests the registration of a new MIME type
  according to the procedures of RFC 2048 [4]

  NEW:
  This specification requests the registration of a new MIME type
  according to the procedures of RFC 4228 [4]

  Please change reference 4 accordingly.

2)
  OLD:
      Author/Change controller:

      This specification is a work item of the IETF GEOPRIV working
      group, with mailing list address .

  NEW:
      Author:

      This specification is a work item of the IETF GEOPRIV working
      group, with mailing list address .

      Change controller:

      The IESG

In 7.

OLD

  The access to data items needs to be matched with the rule set stored
  at the PS.  Each instance of a request has different attributes
  (e.g., the identity of the requestor) that are used for
  authorization.  A rule in a rule set might have a number of
  conditions that need to be met before executing the remaining parts
  of a rule (i.e., actions and transformations).  Details about rule
  matching are described in Section 10.  This document specifies only a
  few conditions (i.e., identity, sphere, and validity).  Further
  condition elements can be added via extensions to this document.

NEW

  The access to data items needs to be matched with the rule set stored
  at the PS.  Each instance of a request has different attributes
  (e.g., the identity of the requestor) that are used for
  authorization.  A rule in a rule set might have a number of
  conditions that need to be met before executing the remaining parts
  of a rule (i.e., actions and transformations).  Details about rule
  matching are described in Section 10.  This document specifies only a
  few conditions (i.e., identity, sphere, and validity).  Further
  condition elements can be added via extensions to this document.

  As noted above in section five, conditions are matched on equality
  or "greater than" style comparisons, rather than regular expressions.
  Equality is determined according to the rules for the data type associated
  with the element in the schema given in section 13 below, unless explicit
    comparison steps are included in this document.  For xs:anyURI types,
    readers may wish to consult [RFC 3987] for its discussion xs:anyURI, as
    well as the text in [XML Schema].


In 7.1.3

OLD:

  1.  If the values of the 'domain' attribute and the value of the
      protocol domain identifier does not begin with xn--, attempt a
      string comparison.  If the string comparison indicates equality,
      the comparison succeeds and the remaining steps are skipped.

  2.  Translate percent-encoding for either string and repeat (1).

  3.  Convert both domain strings using the toASCII operation described
      in RFC 3490 [2].  (Naturally, if one of the strings already
      begins with the ACE prefix xn--, the conversion operation has
      already been performed.)

  4.  Compare the two domain strings for ASCII equality, for each
      label.  If the string comparison for each label indicates
      equality, the comparison succeeds.  Otherwise, the domains are
      not equal.

  If the conversion fails in step (3), the domains are not equal.


NEW:

  1.  Translate percent-encoding for either string.

  2.  Convert both domain strings using the toASCII operation described
      in RFC 3490 [2].

  3.  Compare the two domain strings for ASCII equality, for each
      label.  If the string comparison for each label indicates
      equality, the comparison succeeds.  Otherwise, the domains are
      not equal.

  If the conversion fails in step (2), the domains are not equal.

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

Paul Hoffman did I18n review to address Sam's discuss.

On May 26, 2006, at 10:22 AM, Paul Hoffman wrote: Ted and I spoke on the phone and I discovered some things that I misunderstood. He said he would take the token for what changes should be made.

IANA Comments:

Upon approval of this document, the IANA will register the following:

XML namespace for urn:ietf:params:xml:ns:common-policy in the following registry:
http://www.iana.org/assignments/xml-registry/ns.html

XML schema for urn:ietf:params:xml:schema:common-policy in the following registry:
http://www.iana.org/assignments/xml-registry/schema.html

MIME-type for 'application/auth-policy+xml' in the following registry:
http://www.iana.org/assignments/media-types/application/

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

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

[Ballot discuss]
This document needs more internationalization review.  I've noticed
two problems, but I would rather hold the discuss until the document
has received an explicit i18n review because I'm not confident that I
would spot everything.  First, the IDN handling in 7.1. is wrong.  It
assumes that an IDN will always start with xn- .  It's true that a
label containing non-ascii characters in a IDN that has gone through
toascii() will start with xn- but the first label may not always have
non-ldh characters. 
You need to think about IDNs in terms of labels not in terms of
strings.

Also, there is discussion of case insensitive comparison without
sufficient guidance to make this implementable for Unicode.


I will be happy to remove this discuss after I18N review.

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

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

[Ballot comment]
This document represents a lot of wordsmithing and coordination among groups.  Questioning titles, word choice, etc. in the face of that does not seem likely to improve the results of implementation.

[Ballot comment]
The title is misleading.
"A Document Format for Expressing Privacy Preferences" sounds
much more general and ambitious than the actual scope. Could
we have something like "XML authorization framework for specific
privacy preferences."

Which raises the question of whether SAML was considered and if
so, why can't the SAML authorization framework be re-used?

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.

Well, yes, but this is actually a problem set solved by several well
known calendaring solutions; in a joined-up world I would expect this
issue to be solved by re-using the user's calendar info.

See additional comments in the Gen-ART review at
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-geopriv-common-policy-08-brim.txt

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

Andy tells me that this needs a respin to clear some edits in Hannes's queue.  It will go to the IESG with cullen as sponsor once that is done.

Andy tells me that this needs a respin to clear some edits in Hannes's queue.  It will go to the IESG with cullen as sponsor once that is done.