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

[Scott Kitterman <[e-mail]>]

On Tuesday, May 7, 2019 10:30:25 PM EDT Seth Blank wrote:
> Thanks, Scott!
> 
> To me (as an individual) this seems ready for last call.
> 
> A few items:
> 
> 1. In the new paragraph in section 1 clarifying requirements, you have an
> open parens that is never closed.

Fixed locally for the next revision.

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

In theory, I agree, but in practice, I think the new MUST NOT is a great 
change to promote implementation simplicity.  Recall that the failure reports 
we are discussing are not commonly sent even for regular DMARC due to privacy 
concerns, so there's almost no loss of feedback as a practical matter defining 
it this way.

Consider what implementers would have to do in the alternative.  In order to 
treat failure reports differently for single and multi-organizational PSDs, one 
would need to know which is which.  While some, like .google are relatively 
obvious, other are much less so.  It is much better to give clear guidance 
than to be handwavy.

> I really think the guidance in 4.1 is the best way to approach this.
> 
> Speaking of which, with the normative MUST NOT that's been added, now 4.1
> no longer makes any sense.

Only if you assume that there are no privacy risks associated with aggregate 
reports, which I don't believe is accurate.  I certainly wrote 4.1 on the 
assumption that it was mostly about aggregate reports, since failure reports 
are not commonly sent.

> My recommendation would be to roll this change back, and perhaps replace it
> with a reference to 4.1 and a "if you're a PSD, don't ask for RUF unless
> you really really know what you're doing."

I disagree.  That puts the (potential) fox in charge of the hen house.

> 3. psddmarc.org - I think we need a brief paragraph outlining the
> experiment, and in it need to explicitly call out that a permanent solution
> needs to be determined for answering the "what's a PSD" question - which
> may or may not be psddmarc.org.

I thought I'd done that in Appendix A.  Please review and provide specific 
recommendations as I don't really know how to address this general comment.

Other than the typo, I'm going to leave my local copy as is while we wait and 
see what others think.

Scott K