[ietf-dkim] ISSUE: dkim-overview -- normative statements

[Dave Crocker]

Eliot,


Eliot Lear wrote:
> As a general rule I believe you are better off with fewer documents with 
> normative text than more.

As a general rule, I believe the number of documents should strike a useful
balance between flexibility for later enhancement and ease of cross-reference 
while reading the specification.  These are competing constraints, since the 
former argues for more documents and the latter argues for fewer.  We have 
seen problems with too few documents and others with too many.  Both problems 
tend to be serious in the long run.

Again, this is why I suggested that this thread worry a bit less about generic
rules -- bu note that "a bit less" does not mean "not at all" -- than about 
the particulars of the current situation.

For example:

1. -base and -ssp exist.  So does -overview.  What we do not officially have
is a document that describes the integrated service.  -base and -ssp do not
seek that role, so this is hardly an matter of their being "deficient".

2.  -overview has evolved.  As you and Jim Fenton have done so diligently, 
other folk should take a careful look at it and describe what areas of 
discussion it has that they believe should be eliminated or moved elsewhere. 
(If the latter, then where? If they think it should be eliminated, then why?)

3.  -overview must not be redundant with any other normative text.  Every time 
we've had two normative documents make normative statements about the same 
thing, we've hadlong-term problems.  So I suspect no one will argue with this. 
  Where the current -overview draft does appear to be redundant, the text 
should either be eliminated or modified to sound purely pedagogical, possibly 
with a reference to the proper, external normative text. Such redundancies are 
not uncommon when developing tutorial material, since that's sort of its 
purpose.  The problem, in these cases, is with the nature of the language, not 
the topic.



 >    There is a lot of text around mailing lists
> that comes dangerously close to text in the SSP draft (see -overview 
> Section 2.5, and -ssp, Section 5.1). 

Auditing, to catch possible discrepancies and redundancies, is extremely helpful.


>  The last thing we want are two
> documents that mandate behavior in the same components in what could end 
> up being subtly different ways.

Completely agree.


> It may be useful to have a BCP or an overview, but the scope of that 
> document must be made clear, and should not overlap with standards 
> specifications.  The use of normative language in the draft today is 
> IMHO inappropriate even for a BCP, and in some cases is overly broad.  

In Section 1.1, par 3, the opening sentence is:

    "This document provides a description of DKIM's architecture, 
functionality, deployment and use. "

    That's rather terse, but I'm not understanding what additional statements 
you would like to see.  Is there more than a clear disclaimer that any 
statements that appear to conflict with DKIM specification documents are 
resolved by taking the normative portions of the specification documents as 
definitive?



> Here are two examples:
> 
>     * In section 2.1 you talk about memory models and keeping private
>       keys private.  I think that states the obvious, while at the same
>       time going way down the implementation path.  If you're going to
>       state the obvious, do so once and not at only some of numerous
>       opportunities for a key to be exposed.  Furthermore, this text
>       goes into implementation design.  That's not BCP territory, IMHO.
>     * In Section 2.2 you talk about requiring secure zone updates
>       without really defining what you mean.  Are you, for instance,
>       talking about DNS registrars needing to use SSL?  Is a login
>       password good enough or is that not strong enough?  Is DDNS useful
>       in this context?  If so, how?  If not why not?  (I'd argue the
>       latter, but there's no argument in there at all right now.)

Well, your friendly authors certainly had some discussion about the scope of 
this section.  My sense of the motivation for the section is that security 
coding and operations issues are not well-ingrained in the industry and that, 
therefore, some basic tutorial about generic issues, would be helpful.  (This, 
of course, does not mean that the current text there -- or anywhere else in 
the document -- would not benefit from revision.)


> Given these issues, how would you want to proceed?
> 
> Finally, because it's clear that a fair amount more work is needed on 
> this document, and as SSP is progressing, I think it would be prudent to 
> be mindful of SSP, and to reconsider gating this document to SSP, 
> assuming we keep moving forward on the latter.

The industry needs -overview today.  Not tomorrow.

Some of us attended a Federal Trade Commission anti-spam workshop where we 
heard a senior FTC staffer state that the only way he could familiarize 
himself with DKIM was to read -base.  This is such an unreasonable demand to 
place on him that it's not his fault that he viewed DKIM as too complicated 
and risky...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net