Common Policy: A Document Format for Expressing Privacy Preferences
RFC 4745
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Lars Eggert No Objection
(Cullen Jennings; former steering group member) Yes
(Jon Peterson; former steering group member) Yes
(Ted Hardie; former steering group member) Yes
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.
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
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)
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
FYI - spelling issues: "controling", "entitites", "speific", "therfore"
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Mark Townsley; former steering group member) No Objection
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.
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
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.
(Sam Hartman; former steering group member) (was Discuss) No Objection
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.