[ietf-dkim] ISSUE: dkim-overview -- normative statements
dhc at dcrocker.net
Mon Jul 23 07:59:20 PDT 2007
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.
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
> 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.
> 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
> 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
More information about the ietf-dkim