DomainKeys Identified Mail (DKIM) and Mailing Lists
RFC 6377

Note: This ballot was opened for revision 12 and is now closed.

(Stephen Farrell) Yes

Comment (2011-06-15 for -)
No email
send info
(1) I think section 5.2 is the "meat" of this basically, so would
suggest a forward reference to there from last paragraph of the 
intro.

(2) In 2.5 should the 1st "i.e.," really be "e.g.," - that is, are
you saying "d=" is the *only* way to identify message streams? 
If so, then perhaps make that clear. (I just don't recall if there
were other good ways. I do recall there being other bad ways:-)
  
(3) 5.4 is a bit unclear to me. I suggest just adding an example.

(Pete Resnick) Yes

Comment (2011-06-22 for -)
No email
send info
3.1:

   originator:  The agent that accepts a message from the author,
      ensures it conforms to the relevant standards such as [MAIL], and
      then sends it toward its destination(s).  This is often referred
      to as the Mail Submission Agent (MSA).

That definition is incorrect. The originator is not identical to the MSA. My secretary (whose address appears in the "Sender:" field of a message authored by me) is at least part of the "originator", but he is by no means part of the MSA. The MSA is a servce, in MAIL-ARCH terms. The originator is an actor role. I suspect in all of the definitions in this section, there is a conflation of these going on, but originator is the one that is most egrigeous.

5.1

   However, the practice of applying headers and footers to message
   bodies is common and not expected to fade regardless of what
   documents this or any standards body might produce.  This sort of
   change will invalidate the signature on a message where the body hash
   covers the entire message.  Thus, the following sections also discuss
   and suggest other processing alternatives.

I think the document ought to explicitly say something stronger along the lines of, "MLMs that are DKIM-aware ought to stick to header field additions only and not make changes to headers and footers."

(Note to IESG: Personally, I wish this document were part of the AS experiment and had even more MUSTs and SHOULDs. I will weep silently in my beer that it is not.)

(Sean Turner) Yes

(Jari Arkko) No Objection

Comment (2011-06-22 for -)
No email
send info
This is a complex topic full of difficult tradeoffs, but the document was a pleasure to read. Thank you for writing it in such a clear manner that it is understandable even by non-email experts.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2011-06-22 for -)
No email
send info
One quite minor editorial comment; the rest of the document was well-written and this bit of text stuck out.  In Section 3.3:

   List-specific header fields:  [...]
      Therefore not seen as a concern.

Was the sentence fragment intended?



(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-06-22 for -)
No email
send info
I also dithered over the BCP/Informational issue. 
However, the document seems to involve issues of end-to-end service provision where the service is improved by adherence to the guidelines. This takes it over the line into a BCP, IMHO.
If the impact of the document was entirely limited to within a single domain, I would say that it should be Informational.

I did not find the use of RFC 2119 language helpful, and would suggest writing guidelines in English, reserving 2119 language for normative protocol specifications or for emphasis in requirements specs.

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2011-06-22 for -)
No email
send info
  Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 6-Jun-2011.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-06-22 for -)
No email
send info
This is a fine document. One nit: in Section 1.2, please expand "ADSP" on first use or change "ADSP policies" to something like "DKIM author domain signing practices [ADSP]".

(Robert Sparks) No Objection

Comment (2011-06-21 for -)
No email
send info
The 4th paragraph of section 1.2 (beginning "Some MLM behaviors") reads like motivation for starting a draft, rather than documenting the resulting discussion. Please consider updating its perspective or removing the paragraph.