Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt

["Murray S. Kucherawy" <[e-mail]>]

Hatless:

On Tue, May 7, 2019 at 7:30 PM Seth Blank <[e-mail]> wrote:

> 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would
> mean .example couldn't receive failure reports the way example.com does.
> For something like .bank or .com, this is a feature. But for a .google,
> this is a bug. I really think this MUST NOT is, while well advised, delving
> into policy and not interop.
>

I've read Scott's replies to this as well.  The question I have is whether
we have consensus to include this change, but that's hard to gauge when
there's been so few names offering comments.

I'm partial to using MUST NOT only where it goes to interoperability, so
I'm inclined to agree with Seth.  However, I've been nudged away from that
position on this in the past, i.e., that it can be used to encourage best
practices and there's ample precedent for such.  Still, given other replies
on the topic, especially the presence of "unless you know what you're
doing" in some of the dialog, I'm wondering why this isn't a SHOULD NOT
with an explanation of why, and in what circumstances one would deviate
from that advice.  There are aspects of the discussion in this thread that
would be valuable to implementers (summarized, of course).

I'm also inclined to agree with Seth on his points of complexity, and on
moving contrary to DMARC's tenets.

Having said all of that, I'm not firmly resisting given that the plan is to
send this up as Experimental, as its deployment and results could usefully
inform our choices with respect to standards track DMARC.

While you all stew on that, I owe the group a top-down review of it
and the start of a shepherd write-up, so I'll do both this week.

-MSK