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

[Dave Crocker]

Folks,

The overview document states that it is seeking Informational RFC status. 
Further, it does not include the usual citation and statement that normative 
vocabulary is used to assert normative requirements.

Nonetheless, the document has quite a number of apparently normative 
statements -- including some in uppercase -- such as:


> 2.2.  Email Infrastructure Agents
> 
>    It is expected that the most common venue for a DKIM implementation
>    will be within the infrastructure of an organization's email service,
>    such as a department or a boundary MTA.
...
>       Outbound:   An MSA or Outbound MTA should allow for the automatic
>          verification of the MTA configuration such that the MTA can
...
>          An outbound MTA should be aware that users may employ MUAs that
>          add their own signatures and be prepared to take steps
...
>       Intermediaries:   An email intermediary is both an inbound and
>          outbound MTA.  Each of the requirements outlined in the
>          sections relating to MTAs apply.  If the intermediary modifies
>          a message in a way that breaks the signature, the intermediary
> 
>          +  SHOULD deploy abuse filtering measures on the inbound mail,
>             and
> 
>          +  MAY remove all signatures that will be broken

and

> 2.5.3.3.  Boundary Enforcement
> 
>    In order for an assessment module to trust the information it
>    receives about verification (e.g., Authentication-Results headers),
>    it MUST eliminate verification information originating from outside
>    the ADMD in which the assessment mechanism operates.  As a matter of


This seems anomalous and raises a line of questions:

    If the apparently normative statements are actually trying to be normative 
and are reasonable, has the intent of the document changed?

    Even though I've written some portion of the language in the document, I 
have mixed feelings about this issue.  Some of the apparently-normative 
statements I like and some I don't -- and I don't know which ones I wrote, so 
that's not the issue.

    Beyond being a summary of DKIM, the document also has become something of 
a  higher-level "system specification".  As such, some of the normative 
language really pertains to the higher-level integration of DKIM into an 
operational email service and well could be extremely useful for guiding 
design, implementation and deployment of DKIM.  I think that's a good thing, 
but I think we need to resolve whether this document is making architectural, 
normative specification or whether it is providing tutorial exemplars.

Unfortunately I don't think this can be resolved by a simple assertion of an 
underlying principle.

I think we need to look at the actual language in the document and decide what 
is important for the current work.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net