[Geopriv] WG: gen-art review of draft-ietf-geopriv-common-policy-08.txt

[Hannes Tschofenig <[e-mail]>]

Hi Scott,

thanks for the good review. Please find my response below:

Scott W Brim wrote:
 >(For more information on gen-art, you can go to
 >http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
 >
 >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.

We used the term 'Common Policy' as a short form for the document name.

Would you be happy if we use the following title:
"
Common Policy: A Document Format for Expressing Privacy Preferences
"

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

I simplified the text as suggested.

 >
 >- 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)"?

The meaning was the following:

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

Let us pick an example: SIP.
SIP is a Geopriv using protocol but itself does not provide the 
requestor's identity. Instead, it is the authentication protocol that 
does this.

Changed the text.

 >- 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.

I am also not 100% happy with the terms here but I couldn't think of 
something better.
I don't think that "general" and "specific" better.

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

I made it more explicit. I changed the text to: "Active Request-Response 
- PS as Client (Initiator)"

 >
 >- 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.

I changed the text to:

"
Capability support:

In addition to the previous goal, a RM should be able to determine which 
extensions are supported by the PS. The mechanism used to determine the 
capability of a PS is outside the scope of this specification.
"

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

Yes, it is possible to have more than one RM.
We don't describe a mechanism how the RM would synchronize their 
identifiers. One way todo it would be to retrieve the rules by a RM and 
then the RM would chose an identifier that is not used.

 >
 >- 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.

Hmmm. You are the first person that ever complained about the usage of 
the term 'permission'. We need to use a term that refers to both 
'actions' and 'transformations'. We used the split between actions and 
transformatios because prior work on authorization policies also made a 
differentiation between the two when it comes to the modification of the 
results that are returned.

Since we only describe rules with a 'allow' action most rules might have 
a very simple action part but, in case of location information, might 
have a complex 'transformation' part. In that sense the 'transformation' 
matters a lot.

Do you think it would be less confusing if we use the term 'action' for 
the 'actions' and the 'transformations' part of a rule? I don't think so.

ciao
Hannes

 >
 >
 >swb


_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv