Subject: [Gen-art] Re: Gen-ART review of draft-ietf-simple-presence-rules-08

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Jan 2007 17:02:15 -0500

Sorry for the long delay in responding.

Comments inline.

[email-masked] wrote:

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

Its like a default; just because something is default, doesn't mean 
there is no merit in defining a way to be explicit about it. 
Furthermore, it allows you to do as you are describing. If a user has a 
rule that says block for [email-masked], and then creates a rule to 
allow example.com, the UI can prompt the user to be sure this is what 
they want.

> 
> Even without the block sub-action, misunderstandings are possible.
> For example, given two rules matching identities [email-masked] and
> [email-masked], respectively, certain UI designs might lead a user to
> assume "first match" or "most specific match" semantics for the rules.

Right.

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

OK. I will add some text in the security considerations section.

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

Fair point. I think one can argue that it should be normative with a 
downref, but its debatable. I'll defer to our esteemed ADs for an 
opinion on what to do here.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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