Subject: Re: [ietf-dkim] An alternative way forward for dkim-deployment...

From: Dave CROCKER <[email-masked]>
Date: Wed, 10 Mar 2010 15:59:02 -0800

Tim,

On 3/10/2010 3:18 PM, Polk, William T. wrote:
> Dave,
>
> First, I do think it is harmful when document content does not match the
> (explicit or implied) scope.

And since I quoted text that made clear that the scope was constrained, what is 
the problem?

Again the question:  just how much bullet-proofing against careless reading is 
required?

>    I certainly had different expectations
> based on the title and introductory material. In retrospect, I should
> have brought my discuss up another level of abstraction but I apparently
> got focused on the details (what was missing) instead of why it mattered.

And yet even your original and later notes detail lacked detail, since there was 
no way of knowing exactly what problem you were trying to address /or/ what 
would satisfy and you did not provide clarification.

> Personally, I would prefer to see this document expanded and either
> address the various topics that are covered elsewhere or explicitly
> reference the various bits of the DKIM overview and protocol specs where
> the rest of this information resides.

Since the document is loaded with citations, including the other DKIM documents, 
once again I have no idea what you mean.

> Is there a chance that I am carrying my concern for the reader too far?

Not only "too far".  As two of my earlier responses suggested, implementing 
additional text in line in response to the concern you initially stated a likely 
downside, given the intended audience.  It would have been helpful for you to 
address that point, over the last 5 weeks.

> Perhaps... If you assume that the reader has already consumed the
> protocol specs, then I am way off base. It certainly is not surprising
> that the wg members weren’t confused. I just don’t make that assumption.

Again, the text I quoted you earlier today is rather pointed in declaring the 
role of this document as being to augment, rather than replace, other documents.

> My concern for the reader is based on my perspective at NIST.  Deployment
> guidance is actually something we do here, and sometimes we may even do
> it well.

The IETF has some history here, too.  RFCs with the word "deployment" in them 
date back to 1992.  Interestingly, the first was about X.500 and X.400.

In any event, your statement here suggests that you are relying on the NIST 
culture for your concern, rather than the IETF culture.

>   However, they might use google to search on dkim and deployment
> and try to use this document.

People "might" choose to do an infinite number of unreasonable things.  Taking a 
document out of context is only one of them.  We cannot protect against every 
unreasonable action by a reader.

And, again, the document states its nature and goals explicitly.

> I don’t like holding this document up, especially when there are a
> variety of simple solutions.

To say "solution" is to take as a given that there is a problem.  You have not 
responded to the responses that critique that assumption.

 >  It
> is clear this document will not evolve into “some sort of standalone,
> complete instructional missive” so let’s be clear about the document
> scope, and move on.

The document /is/ already clear Tim, per the text that I quoted.  It merely 
needs the reader to be paying attention.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 11 Mar 2010 11:30:01 +0100

I'm getting the impression that this debate is starting to be about
proving points rather than making progress. In the interest of getting 
this document moving forward, I have entered the following RFC editor note:

   Please add a new paragraph to Section 1, after the first paragraph:

   The reader is encouraged to read the DKIM Service Overview document
   [RFC5585] before this document. More detailed guidance about DKIM
   and ADSP can also be found in the protocol specifications [RFC4871],
   [RFC5617], and [RFC5672].

Authors and Barry: if you think this is unacceptable, please yell ASAP
and propose better text.

Tim: unless you feel that the scope of this document is dangerously
unclear even with this addition, please clear.

Best regards,
Pasi

> -----Original Message-----
> From: ext Dave CROCKER [mailto:[email-masked]]
> Sent: 11 March, 2010 01:59
> To: Polk, William T.
> Cc: DKIM IETF WG; Eronen Pasi (Nokia-NRC/Helsinki); IESG; draft-ietf-
> [email-masked]; [email-masked]; Sean Turner
> Subject: Re: An alternative way forward for dkim-deployment...
> 
> Tim,
> 
> > that the wg members weren't confused. I just don't make that
> assumption.
> 
> > I don't like holding this document up, especially when there are a
> > is clear this document will not evolve into "some sort of standalone,
> > complete instructional missive" so let's be clear about the document
> > scope, and move on.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Mar 2010 13:46:37 +0000

Thanks Pasi,

FWIW, I think Pasi's suggestion moves us forward nicely so
I'd be happy to see us agree to do that.

Stephen.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 11 Mar 2010 09:15:43 -0500

I am willing to support this addition.

- Tony Hansen
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Mar 2010 10:42:41 -0800

On 3/11/2010 9:28 AM, Ellen Siegel wrote:
> I agree with Dave that that the existing document is already pretty
> clear on this positioning, but I can live with this addition.

I don't see any harm in the addition.

I also don't see any benefit.

For a change like this to be the total result of a Discuss -- other than the 
delay and extra email traffic -- should bother folks.

But this won't be the first unnecessary change to an RFC that was made to keep 
an AD happy rather than to improve the document.  So I can live with it.

d/
-- 

   Dave Crocker