Dave,
I agree with Mike Thomas.
As a general rule I believe you are better off with fewer documents with
normative text than more. 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). 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.
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.)
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.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html