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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html