[ietf-dkim] Re: I-D ACTION: draft-ietf-dkim-overview-02.txt

[Dave Crocker]

John,

Thanks for the comments.


John Levine wrote:
> It sure does have a lot of informative info, and still needs lots of
> work.

Given your ending comment, below, you might be amused that the approach to the 
document has, so far, largely been one of "if in doubt, put it in."

This latest version is the first one to try to do any pruning, albeit 
conservatively.


> My first question is who the target audience is.  The lengthy
> discussions in sections 7, 8, and 9 leave me wondering whose questions
> they're supposed to answer.

Speaking for myself, I believe the document has multiple targets, all of whom 
are technical.  (I suppose portions of the text could be useful for management 
and even marketing, but it's clear the document is not targeting either of 
them.) So, I'd say developers, administrators, operators and technical writers. 
  Mostly developers .

The -base document does not really contain a "system" description -- ie, DKIM 
signing and validating within a context.  Hence, sections 5 & 6.

Obviously 7, 8 and 9 target developers, administrators and operators.

If you see the document as being problematic for those target readers, please 
elaborate.


> The discussion of mailing lists in 9.3 is just wrong.  (A
> parenthetical comment correctly suggests it may be controversial.)
> I'll send in some replacement language to clarify that in the usual
> case that list owners take responsibility for managing their lists,
> the list should sign the mail that passes through it, and in the
> exotic case that the list does not take responsibility and recipients
> want to evaluate list mail sender by sender rather than as list mail,
> it may in some cases be possible to pass through the incoming
> signatures.

"the usual case" is an interesting choice of language, given that there are no 
DKIM-aware mailing list packages, yet.  (See below, about making predictions.)

Happily, the thrust of your language isn't affected by simply removing the word 
'usual'.

Please explain what you think is "just wrong" with the current language.  It 
will help to understand how your proposed alternative language is an 
improvement.  (I, too, think the section needs more work, but from your brief 
description, above, I am not quite sure what particular problems you see with 
the current text.)


> In section 10, I do not think the first sentence means what you think
> it means.

Again, speaking strictly for myself, I'd prefer to eliminate all discussion 
about the future.  My experience with IETF documents that attempt to predict the 
future is that they are pretty much always wrong.  More importantly, I'm never 
quite sure what the benefit of the predictions is supposed to be.

On the other hand, explaining what types of extensions the existing system has 
provided for (e.g., multiple query services) can be help readers understand the 
design better.  So my own preference is to have that section discuss something 
like "Extensibility".

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net