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

[Ted Hardie <[e-mail]>]

This will actually be managed in RAI, by Cullen.  He' should be cc'ed on future emails
as Area Advisor.  I'm happy to continue to follow this, but I am no longer the responsible
AD.
		regards,
				Ted



At 5:08 PM -0500 3/30/06, 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. 
>
>- 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.
>
>
>swb


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art