Sorry for the long delay in responding.
Comments inline.
[EMAIL PROTECTED] 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 PROTECTED], 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 PROTECTED] and
[EMAIL PROTECTED], 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 PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
