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

[Eliot Lear]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20070715/14bac3fa/attachment.html