Draft:  draft-ietf-geopriv-common-policy-08.txt
Reviewer: Scott W Brim [sbrim@cisco.com]
Review Date: Thursday 3/30/2006 4:09 PM CST
IETF LC Date:  4/09/2006

Summary: It's a great start but I would like to see some changes.

- The title is simply "A Document Format for Expressing Privacy
  Preferences".  Could you make it more specific to the context?  Once
  the draft name is gone, someone picking up the RFC will have trouble
  understanding what it's about without reading several pages.  In
  the second sentence of the abstract, the draft finally notes that
  "this framework combines common location- and presence-specific
  authorization aspects", which is the first hint of specific context
  ... but then it's missing again in the introductory paragraphs.  

- Section 2: If "The terms 'authorization policy rule', 'policy rule'
  and 'rule' are used interchangeable", why not consolidate them?

- Section 3

  "The using protocol provides the identity of the requestor (or more
  precisely the authentication protocol), either at the time of the
  query or at the subscription time."

    the () isn't clear.  It looks like it's saying the using protocol
    provides the authentication protocol.  I think you want to say
    that the requestor identity may have already been provided and
    authenticated.  How about something like "The using protocol
    provides the identity of the requestor (if it has not already been
    provided by other means)"?

- 3.1 and 3.2: they are called "passive" and "active" but both appear
  active to the same degree.  A more appropriate naming might be
  something like "general" and "specific"?  If there is more implied
  by the terms passive/active, please make it explicit.

- 3.3: "Event notification adds a subscription phase to the "PS as
  client" mode of operation.".  
  
    That's the first mention of "PS as client".  Is that left over
    from a previous version's nomenclature?  Do you mean "active"?

- 4: "Versioning support: In addition to the previous goal, a RM
  should be able to determine which types of rules are supported by
  the PS."

    This is the first time "types of rules" has been mentioned.
    Please explain somewhere.

- 6.1 (identification of rules): is it possible to have more than one
  RM?  If not, please say so.  If so, is there a way for an RM to find
  out what rule identifiers are not used, or does it just keep
  guessing until it finds one?

- 10.1: "The term 'permission' stands for an action or a
  transformation."

    I've been struggling with this since the beginning of the draft.
    It feels awkward and ambiguous, perhaps confusing because I wasn't
    in the meetings.  To me, the term "permission" would be more
    likely to refer to the result of a rule match, a line in a process
    diagram as opposed to a box.  An action is the thing that is
    permitted, the thing which you have permission to execute -- but
    it is not the permission itself.

    What really matters is the actions, since without an action the
    transforms are irrelevant.  For example, in "Let n be a name of a
    permission contained in a rule r in M", is it possible to just
    talk about the actions, instead of "permissions"?  Alternatively,
    as a precedent, in the table in 10.2 you use
    "actions/transformations" which is a lot less ambiguous.