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

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 <dmarc-bounces@ietf.org> On Behalf Of Scott Kitterman
> Sent: Monday, March 27, 2023 3:21 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-08.txt
> 
> On Monday, March 27, 2023 12:29:03 PM EDT internet-drafts@ietf.org 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
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!H8G5uZT5a1ton4-
> AnqD6LNYhIxe47F4MTcjsmU0XzJyGBFHD3tirxEwynV-
> vaG21KThPjTN7ZDUhabSiLht-$