On Mon, 30 Nov 2009, The IESG wrote:
> - 'DomainKeys Identified Mail (DKIM) Development, Deployment and
>   Operations '
>   <draft-ietf-dkim-deployment-09.txt> as an Informational RFC

Sorry for missing the LC DL by two days.

This is an assigned ops-dir review of draft-ietf-dkim-deployment-09.
The document describes DKIM usage scenarios and gives recommendations.
Quoting from the document:

                              This document provides practical tips for:
    those who are developing DKIM software, mailing list managers,
    filtering strategies based on the output from DKIM verification, and
    DNS servers; those who are deploying DKIM software, keys, mailing
    list software, and migrating from DomainKeys; and those who are
    responsible for the on-going operations of an email infrastructure
    that has deployed DKIM.

As such, this is very much an operations geared document.

Unfortunately, I have not looked into DKIM in detail so it's difficult to
say if these practical tips are are OK and answer the questions arising from
ops community deploying and developing DKIM.  I'd be more confident in this
if it was clear this had been thoroughly "tested" by these people.

Some comments below:

editorial
---------

In general, I found the use of UPPERCASE keywords somewhat misleading when
the advice given was to the operators and deployers, not to the developers
of the protocol.

It would be helpful to have an Abbreviations table up front.  There are many
non-spelled out abbreviations in the doc, or ones that are spelled out
later, not at the first instance of abbreviation.

Acknowledgedments is "TBD" even though we're at -09 version.  Remember that
its authors' responsibility to properly acknowledge "all Contributors,
including Indirect Contributors." (BCP78)

Some of the DKIM references listed as Informative seem to be required
reading to fully understand this document and it would be better to put them
under Normative References.

In S A.1.1.1., one of the last two paragraphs appears to be 
incorrectly indented. These seem logically similar paragraphs.

An informative reference in Appendix 1 should be inserted to point to
RFC4870.

substantial
-----------

S 3.1 Private Key Management: Deployment and Ongoing Operations

.. this document describes many practises wrt private key management, with
uppercase keywords.  I'm not sure if using them is appropriate in this
context.  Some of the suggestions also seem unnecessarily strict or
impractical; e.g. that private key must not be network-accessible.  In
practise these goals may not be worth the tradeoffs.  Even in the field of
DNSSEC, where the compromise of the key is a much bigger problem than here,
the guidelines are more flexible.  See e.g. draft-ietf-dnsop-rfc4641bis-01
(S 3.6) and its predecessor document.

S 3.2:

    Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that
    provides protection against record insertion attacks and zone
    enumeration.  In the case that NSEC3 [RFC5155] records are employed
    to prevent insertion attack, the OPT-OUT flag MUST be set clear.

.. it is not obvious why OPT-OUT is a MUST NOT.  What are the tradeoffs?
I'm not sure if this document is best placed to mandate DNSSEC signing and
delegation behaviour that appears to be irrelevant from DKIM perspective.

S 5.1 Intended Scope of Use

    DKIM requires that a message with a signature that is found to be
    invalid is to be treated as if the message had not been signed at
    all.
...
    It follows that messages with
    invalid signatures SHOULD be treated no better and no worse than
    those with no signature at all.

.. if DKIM specs require the first sentence, then the last sentence is not
valid; SHOULD should be a MUST.  But I don't like the upper case here
anyway, and I'm not sure if the last sentence is even needed, given that the
first sentence of this section already specified the behaviour.