Subject: [ietf-dkim] Working Group Last Call on mailinglists

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Apr 2011 16:18:47 -0400

Murray does not have any further changes queued for
draft-ietf-dkim-mailinglists, and we think the -06 version is ready
for last call in the working group.  You can get the current version
here: http://tools.ietf.org/html/draft-ietf-dkim-mailinglists/

Please post minor editorial things to this thread.  If you find
substantive issues, please start a new thread for each, and prefix the
subject with "Issue:".  As we discuss those, if any come up, let's
keep the discussion focused on the issue.

I will also appreciate posts to THIS thread that say "I've reviewed
it, and it's ready to go."

Barry, as chair
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Apr 2011 14:22:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, April 12, 2011 1:19 PM
> To: DKIM Mailing List
> Subject: [ietf-dkim] Working Group Last Call on mailinglists
> 

Just to be clear: Does this one also end on 4/30?

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Apr 2011 17:40:56 -0400

> Just to be clear: Does this one also end on 4/30?

Durn.  I forgot to put that in the second message.  Yes, this last
call is also through 30 April.

Barry, as chair

---

From: "John R. Levine" <[email-masked]>
Date: 12 Apr 2011 21:17:49 -0400

If it were up to me, I'd take out all the ADSP stuff, but since that ain't 
gonna happen, it's ready to go.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 13 Apr 2011 10:16:24 -0700

> keep the discussion focused on the issue.

The abstract and introduction both talk about an ADMD, but I'm not sure that's right.  The ADMD is /often/ equivalent to the DNS domain, but not always.  And actually, lists are a pretty good example of when they're separate: all my lists are on a Mailman installation that's configured as lists.disgruntled.net, but some of the lists' addresses are in other domains -- and they're all signed with d=disgruntled.net on the way out.  So, I think "allows a DNS domain to assume some responsibility" would be more accurate.

The background section refers to "an agent of the email architecture" instead, which may also be more accurate.

(Or maybe it allows an ADMD to /assign/ responsibility to a DNS domain?  But that's a more confusing concept, and I don't think this document is the place to wrestle with those issues.)

Last paragraph of the introduction: "As each type has..." (not types)

Section 1.3 feels out of place, but I'm not sure how to improve it.  Maybe move all of the FBL-related text (currently 1.3, 5.9, and 6) to a single section?

Section 3.3, "Major body changes": "insert" should be "inserting"

First paragraph of 4.1 reads oddly; perhaps: "...the author SHOULD be cautious when deciding whether or not to send a signed message to the list."

Final paragraph of section 5.1 reads oddly as well; perhaps "Expressions of list-specific policy (e.g., rules for participation, small advertisements, etc.) are often added to outgoing messages by MLM operators." ... "This sort of information is commonly included in footer text appended to the body of the message, or header text prepended above the original body."

The first "[ADSP]" in 5.2 isn't an xref.  Later in that paragraph: "...a resending MLM SHOULD reject outright any mail from an author whose domain posts such a policy, as those messages are likely to be discarded by any ADSP-aware recipients..."

In that same paragraph, it may not be necessary to talk about discouraging subscribers -- that's covered in 5.3.

In 5.5, suggest removing "although this is not yet formally documented" because this document is documenting it.  *grin*

When mentioning FBLs in 5.7, it'd be helpful to have a reference to section 1.3.

Later in 5.7, should we stipulate that a DKIM-aware resending MLM SHOULD NOT use the l= tag?

In 5.10, third paragraph: replace "deliverability" with "delivery" (or just "other issues.")

Should the security considerations section also explicitly refer to (see also...) the security considerations from [DKIM], [ADSP], et cetera?

Appendix A: I prefer "J.D." rather than "JD", though neither is technically accurate.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions