Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-08.txt

[Scott Kitterman <[e-mail]>]

On Monday, March 27, 2023 12:29:03 PM EDT [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Domain-based Message
> Authentication, Reporting & Conformance (DMARC) WG of the IETF.
> 
>    Title           : DMARC Aggregate Reporting
>    Author          : Alex Brotman
>    Filename        : draft-ietf-dmarc-aggregate-reporting-08.txt
>    Pages           : 29
>    Date            : 2023-03-27

I'm not convinced we entirely made progress on this revision.

It's likely I missed or have forgotten the list discussion on some of these 
items, sorry for any repetition.

This revision removes the optional version field, adds a new optional field for 
discovery method, and adds a paragraph on data consistency in reporting.  
There are other changes that look to be editorial.

I agree with the removal of the version field.  It never made any sense to me.

I see though that the version element is only removed from the text, not from 
Appendix A and Appendix B.  Is it intended to be removed?  Now I'm confused.

I don't understand who is expected to implement DMRCbis and report using the 
PSL.  If you want to keep using RFC 7489, nothing stops you, but it would be 
odd to decide not to upgrade your DMARC processing, but still expend 
engineering resources to upgrade your reporting.

Also, this revision correctly drops the reference to RFC 7489 because it was 
no longer referenced in Section 2.1, but now it's referenced in the schema, so 
doesn't it need to be added back?  Also, this is presumably published with 
DMARCbis, which will obsolete RFC 7489.  Is it good IETF practice to reference 
historic documents?

I'm not sure this really adds much.  If we do keep it, I think it's in the 
wrong section.  How you found the policy isn't the policy that was published.  
I think this goes in the metadata section.

Regarding "Data Consistency in Reporting", I don't see the point.  Who is 
going to read this section and do something different?  Are we suggesting that 
recording the results and reporting them is not sufficient?  Do receivers need 
to run a second DMARC check on the data before sending feedback to make sure 
it's consistent?  I reads like a plea not to use buggy software.  Who do we 
expect to read an RFC and then realize they should test before deploying to 
avoid sending inconsistent data?  Seriously, what behavior are we trying to 
motivate here that fits within an RFC's scope?

Scott K