A couple of points before I drop for the night from all these edits. I'll pick
it up tomorrow, probably after posting an -02 incorporating the editorial
feedback so far. Since Dave suggests a fissioning of this document into two or
more, I'll hold off applying his until after that's done and some discussion
about it has been had.
-----Original Message-----
From: Dave CROCKER [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Monday, August 09, 2010 3:40 PM
To: Murray S. Kucherawy; DKIM IETF WG
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
When should an author, or its organization, use DKIM for mail sent
to mailing lists?
The word "should" implies an intent to make a normative statement.
This
conflicts with the stated goal of Informational status. So does the
distinction
between Normative and Informative references.
Either the goal should be BCP (or even Proposed) or perhaps the
language for
this type of statement needs to be softened to something like "Under
what
circumstances does..."
My own guess is that this document should target BCP. However on
further
reading I came to the conclusion that this might be two documents, one
BCP per
its original goal and one Proposed, defining value-added semantics.
See below.
Some time ago we discussed this and the consensus seemed to be (to me, at
least) to produce an Informational document on our first pass through this
process with an eye towards doing a BCP (in the formal IETF sense) afterwards.
I think some people have been calling this a BCP because it generally espouses
what we think of as best practices, but that term has some special status
meanings in the IETF so perhaps that caused some confusion.
This is why I have been avoiding use of the RFC2119 words in this document to
date. So I'm inclined to change it to "Under what circumstances..." as you
suggested.
If we have changed our consensus and want to take a run at a full BCP document,
I'll happily go through and start using RFC2119 language. Finding ways to
avoid using those magic words, even in all-lowercase, can be a little
time-consuming.
What are the tradeoffs regarding having an MLM verify and use DKIM
identifiers?
This might not need "fixing" but I found myself asking what it means
for an MLM
to "use DKIM identifiers"? Perhaps in an Introduction it's ok to say
this
without prior setup. Dunno.
The document goes into what that means, particularly in terms of verifying
signatures inbound to the MLM and then signing mail outbound from the MLM. And
it seems to me "use DKIM" means exactly the same thing as "use DKIM
identifiers", since the carrying of a verified identifier is precisely the
point of applying DKIM.
> 2.4. Message Streams
The concept of streams is discussed in the Deployment doc (RFC 5863):
<http://tools.ietf.org/html/rfc5863>
and the DKIM Wikipedia article:
<http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail>
I suggest citing them. We should make sure this doc conforms to their
definition of explains its variation.
Naturally I'm fine citing RFC5863 and ensuring this document's definitions
match the ones found there, but do we really want to cite a Wikipedia article?
(cf:
http://www.theonion.com/articles/wikipedia-celebrates-750-years-of-american-indepen,2007/)
> There is currently no header field proposed for relaying general
list
> policy details, apart from what [LIST-URLS] already supports.
This
> sort of information is what is commonly included in appended
footer
> text or prepended header text. Rather than anticipating or
proposing
> a new field here for that purpose, the working group recommends
List policy details? Huh?
1) I don't really know what that means
2) I'm not sure why this is being mentioned here
3) Any use of the word "policy" usually works against doing
productive work
in these groups.
Seriously. Show me an IETF "policy" specification that's been
successful. Show
me a second one.
It's not an effort at talking about any policy stuff in the IETF normative
sense. I'm talking about MLM configuration features, which are themselves
expressions of the list admin's policies. It's way outside of what I think
you're talking about.
> 4.2. Verification Outcomes at Receivers
I think everything said in this section is probably correct, but I am
not sure
what it is referring to, within the scope of DKIM. What technical
actions do
"Verification Outcomes" refer to?
Weren't you the one that suggested this title? :-)
This is off-topic, but I keep wondering whether there isn't an
opportunity for a
value-added function in the form of a header-field, which says
something like
"the presence of this header field, when signed by DKIM, means that the
contents
cited in this header field are asserted to be 'valid'...
So, for example:
DKIM-Valid: From, Date, Subject, Body
could mean that the signer claims all of that information is "correct",
not just
carried correctly. Of course, the signer's DKIM h= also have to cite
those
fields, as well as DKIM-Valid.
Didn't we toss out that argument when debating whether "i=" had any practical
use, because any assertion it claimed by the signer couldn't be independently
verified?
> A recipient that trusts signatures from an MLM may wish to extend
> that trust to an [AUTH-RESULTS] header field signed by that MLM.
The
"Trust"??? What does that mean, exactly, here? It needs to be
defined. Seriously.
[AUTH-RESULTS] talks extensively about trusting (or not) the content of the
header field. As it's a normative reference, is the term used unreasonably
here?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html