Ale, Thanks for the notes, I'll try to get those sorted out. I'll check RE the 7405/5234 to see what I can find. I only made one minor modification there based on a ticket JohnL had submitted.
Scott, There were two version fields in this document at one point. The second originally came about when there was a thought that there might be a "DMARC2' in the DNS record. I'm happy to remove all references to a "version", as I agree with you that it doesn't have much utility at this point. As for who would switch to BIS and use PSL, that was a separate discussion perhaps three weeks ago (https://mailarchive.ietf.org/arch/msg/dmarc/4jyF_FytKZ1tR7bknkMi23cLQYw/). Trent's point was that the reporter should not leave the policy domain being discovered left to interpretation, and instead cleanly state which method was used. I can change those references. I agree that it's probably more of a RefNeeded sort of thing. The Data Consistency section was added based on a fairly old ticket (from a conversation between Tomki and Seth IIRC). Do you believe it completely unnecessary, or that it needs to elaborate a bit more? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <[email protected]> On Behalf Of Scott Kitterman > Sent: Monday, March 27, 2023 3:21 PM > To: [email protected] > Subject: Re: [dmarc-ietf] I-D Action: > draft-ietf-dmarc-aggregate-reporting-08.txt > > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!H8G5uZT5a1ton4- > AnqD6LNYhIxe47F4MTcjsmU0XzJyGBFHD3tirxEwynV- > vaG21KThPjTN7ZDUhabSiLht-$ _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
