Last Call Review of draft-ietf-appsawg-sieve-duplicate-06
review-ietf-appsawg-sieve-duplicate-06-opsdir-lc-winter-2014-06-06-00

Hi,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
operational area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

The draft is ready with nits.

I should note that I usually configure my Sieve rules with a web UI, and
have never touched actual config scripts.

The draft does a thorough job of identifying corner cases, and makes
clear which constellations of configurable options should be avoided.

The sieve extension contains various configuration options, and for all
those options, sane defaults are provided in the draft.

Since the document is about a change to configuration files which is
made by humans for their personal mail box, there are no significant
operations and management considerations.

Nit: the paragraph of "3. Test 'duplicate'" has a sentence I can't make
sense of:

	"The 'duplicate' tests does not deal with this situation
	implicitly, which means that false duplicates may be detected
	in this case."

First of all there is a wrong use of plural, s/tests/test or s/does/do.
Then:
If it does not deal with it implicitly - that suggests it deals with
explicitly? But it doesn't do that either.

Maybe you just meant to say "does not deal with this situation" - adding
the word implicitly is just confusing, at least to me.

One question which the draft doesn't (and probably can't) answer is
whether sieve rules will have a deterministic behaviour regarding which
of the duplicates will get to the "right" destination. Consider the
following example:

I'm subscribed to mailing list A, my own address is B. I post something
to the mailing list, and get a reply to both A and B, A arriving first.
I've configured duplicates to be sorted into a "dupe-discard" folder.

My sieve gets the message for A, and sorts the mail into my mailing-list
folder. Then it receives the copy for B, and places it in a
"dupe-discard" folder.

Some time later, someone else responds to the same message. This time,
the copy for B arrives first, then A.

My sieve gets the message for B, and sorts the mail into my INBOX. Then
it receives the copy for A, and places it in a "dupe-discard" folder.

(This is your Example 1)

This creates an inconsistent behaviour; I don't know where I need to go
looking for the replies to my original mailing list post.

I guess this is just "tough luck" then, and I don't see how to prevent,
nor that the draft should do anything about it. It might just be
worthwhile to state that such situations may happen. This is just a Nit,
if anything at all.

This concludes my review of the document.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me



http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66


	


Attachment:


0x8A39DC66.asc




Description:

 application/pgp-keys




Attachment:


signature.asc




Description:

 OpenPGP digital signature