ietf-dkim
[Top] [All Lists]

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

2010-03-10 18:02:01
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