On Monday, March 27, 2023 12:29:03 PM EDT [email protected] 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
