This document updates the DKIM specification to clarify the roles of
two DKIM identifier tag values that a consumer of DKIM verification
may use.  The Security Considerations section states that the
clarifications in this document should improve the security
characteristics of the protocol.  I find this statement to be
reasonably accurate.

Section 12, which adds a new Section 3.9 to RFC 4871, contains a
number of statements giving guidance about assessor policy.  A summary
of these statements, along with a pointer to the full text, should
probably appear in an amendment to the RFC 4871 Security
Considerations.

The following are editorial comments.

In Section 1, delete the spurious "and" following "specifies".

old:

   This update resolves this confusion.  It defines new labels for the
   two values, clarifies their nature, and specifies and their
   relationship.

new:

   This update resolves this confusion.  It defines new labels for the
   two values, clarifies their nature, and specifies their
   relationship.

In Section 8, the text:

      The name of the module that consumes DKIM's mandatory payload, the
      responsible Signing Domain Identifier (SDID).  The module is
      dedicated to the assessment of the delivered identifier.  Other
      DKIM (and non-DKIM) values can also be delivered to this module as
      well as to a more general message evaluation filtering engine.
      However this additional activity is outside the scope of the DKIM
      signature specification.

might be better written as:

      A module that consumes DKIM's mandatory payload, which is the
      responsible Signing Domain Identifier (SDID).  The module is
      dedicated to the assessment of the delivered identifier.  Other
      DKIM (and non-DKIM) values can also be delivered to this module
      as well as to a more general message evaluation filtering
      engine.  However, this additional activity is outside the scope
      of the DKIM signature specification.

in order to align with the form of other definitions added in this
document.

In Sections 9 and 10, the ABNF in the new text looks misformatted.

In Section 10, the sentence:

         However, the signer SHOULD use the same AUID for each message
         intended to be evaluated as being within the same sphere of
         responsibility, if it wishes to offer receivers the option of
         using the AUID as a finer grained, stable identifier than the
         SDID.

might be better written as:

         However, the signer SHOULD use the same AUID for each message
         intended to be evaluated as being within the same sphere of
         responsibility, if it wishes to offer receivers the option of
         using the AUID as a stable identifier that is finer grained
         than the SDID.