Last Call Review of draft-ietf-appsawg-sieve-duplicate-06
review-ietf-appsawg-sieve-duplicate-06-opsdir-lc-winter-2014-06-06-00
Request | Review of | draft-ietf-appsawg-sieve-duplicate |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2014-06-12 | |
Requested | 2014-06-02 | |
Authors | Stephan Bosch | |
I-D last updated | 2014-06-06 | |
Completed reviews |
Genart Last Call review of -06
by Brian E. Carpenter
(diff)
Genart Telechat review of -07 by Brian E. Carpenter (diff) Secdir Last Call review of -07 by Shaun Cooley (diff) Opsdir Last Call review of -06 by Stefan Winter (diff) |
|
Assignment | Reviewer | Stefan Winter |
State | Completed | |
Request | Last Call review on draft-ietf-appsawg-sieve-duplicate by Ops Directorate Assigned | |
Reviewed revision | 06 (document currently at 09) | |
Result | Has nits | |
Completed | 2014-06-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