I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-simple-presence-rules-08 Reviewer: Pasi Eronen Review Date: 2006-11-17 IETF LC End Date: 2006-11-20 IESG Telechat date: (not known yet) Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: In general, this document looks quite good and well written. However, there is one issue that IMHO should be better highlighted in the document, preferably in the security considerations section; and one nit about references. The procedures for combining permissions (while carefully designed) can lead to consequences that might be unintuitive to a user. Thus, the actual policy being enforced is not necessarily what the user intended, and more information can be revealed. One particular case: if I understood the semantics right (which may not be the case :-), it looks like a user agent should not allow the user to create rules with sub-action "block", since they have no effect on the actual policy (the whole rule could be omitted instead, right?). If this is indeed the case, including the whole sub-action seems a bit questionable. Even without the block sub-action, misunderstandings are possible. For example, given two rules matching identities [EMAIL PROTECTED] and [EMAIL PROTECTED], respectively, certain UI designs might lead a user to assume "first match" or "most specific match" semantics for the rules. While detailed UI design guidelines are of course beyond the scope of this document, I think at least the fact that rules can have semantics that are not immediately obvious, and user agent UI design can influence the "obviousness" part, should be mentioned, along with a recommendation to pay specific attention to UI design to ensure that the actual policy is what the user intended. A more specific recommendation would be e.g. to warn users if they create rules that have no effect. One additional nit: To me it looks like the reference to RFC 3325 should be normative rather than informative (and that would be a downref, since RFC 3325 is Informational). My reasoning is that this document depends on RFC 3325 in the same sense it depends on RFC 2617 and RFC 4474, both of which are listed as Normative. Best regards, Pasi _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
