Re: [dmarc-ietf] Comment on DMARCbis, was draft-ietf-dmarc-psd

[Alessandro Vesely <[e-mail]>]

On Tue 04/Feb/2020 22:26:30 +0100 Murray S. Kucherawy wrote:
> On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman <[e-mail]> wrote:
> 
>> I agree on DMARCbis.  I don't think advancing this draft has a significant
>> effect on that.  Worst case, if DMARCbis is done before we can reach any
>> conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in
>> it.


+1, albeit I don't think DMARCbis arrives so quickly


> I think we've always been assuming that PSD DMARC would be input to
> DMARCbis, so we were planning to start the latter but not close it until
> the former was completed.  This is the first time I've seen a different
> suggestion.
> 
> I'd love to hear more opinions about ordering of the work here.  This seems
> like an ideal time to review and update our milestones.


There are quite some issues about DMARC.  Let me mention aggregate report
format first, as this brings out a third thing which can be done in parallel,
namely to publish http://dmarc.org/dmarc-xml/0.2.

Various tweaks have been proposed, I think they're well summarized in
http://bit.ly/dmarc-rpt-schema

For a second issue, consider whether report generators should track policy
changes during the day and, in case, send multiple reports with different
PolicyPublished.  Otherwise, PolicyPublished would be valid for only a part of
the reported rows, presumably the last.  Is that acceptable?

Another case for sending multiple reports at once is on hitting size limits.
Is better to increase sending frequency instead?  How to negotiate sending
frequency between report consumer's ri= and producer's conditions deserves some
discussion.

I'm sure there's a bunch of other issues, and we should start to collect them.


>> I don't see anything about PSD DMARC being inherently on the critical
>> path for DMARCbis.  I suspect the current major obstacle to DMARCbis is
>> that the question of how to take the PSL out of the equation is unsolved,
>> despite one IETF WG that was supposed to be dedicated to the question.>>
>> I don't think not publishing PSD DMARC helps move DMARCbis forward, so I 
>> think it's a false choice.>>
> 
> I think what Dave proposed about PSL separation from DMARC is entirely
> appropriate and pragmatic, and in fact probably easy enough: DMARC is
> changed so that it says the organizational domain is determined using some
> process [currently] external to DMARC, and then a second document explains
> how that process is accomplished using the PSL (and/or PSD, depending on
> when the experiment result comes in).  That's a fairly simple edit overall,
> and is actually probably minor and non-controversial compared to some of
> the other surgery that I believe is in the queue.


+1, let DMARC core define _organizational domain_ by characteristics.  A second
document present a process, possibly demonstrating how the required
characteristics are met.

Scott's I-D already outlines the characteristics of Branded and
Multi-organization PSDs, that the experimental processes are suited for.


Best
Ale
--