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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
