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

[Scott Kitterman <[e-mail]>]

On Monday, May 20, 2019 4:39:39 AM EDT Dotzero wrote:
> I also lean towards Seth's perspective. Additional comments in-line.
> 
> 
> On Mon, May 20, 2019 at 1:32 AM Murray S. Kucherawy <[e-mail]>
> 
> wrote:
> > 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 agree with avoiding MUST NOT in this case for the reasons given (policy
> vs interoperability). I think SHOULD NOT with explanation of why might be
> acceptable.
> 
> > 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.
> 
> Michael Hammer

Having read the feedback from a number of people, I am inclined to revert the 
MUST NOT that I added in the last revision.  "Don't unless you know what you 
are doing" pretty generally applies to RUF, so I can see it being reasonable 
to not special case it here.

I'll wait to see if anyone else has any other changes we should make before 
posting an updated draft.

Scott K