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

[Michael Thomas]

Dave Crocker wrote:
> 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.

I'd say that this is a poor idea as it becomes rather unclear who is 
authoritative
when you have potential conflicts as in:
>>          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 RFC4871 which sez:

   Signers SHOULD NOT remove any DKIM-Signature header fields from
   messages they are signing, even if they know that the signatures
   cannot be verified.

I really don't see why we should be setting ourselves
up for this kind of conflict. 

To my mind, this document has been ever chomping at the
bit to be a BCP. I'm all in favor of a BCP, but only when
we really know those B's, C's, and P's are. Inserting 
new normative language about how one should use DKIM beyond
what's in 4871 seems rather premature to me.

		Mike


>
> 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/
>