On Fri, Apr 23, 2021 at 11:21 AM <[email protected]> wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : DMARC Aggregate Reporting > Author : Alex Brotman > Filename : draft-ietf-dmarc-aggregate-reporting-02.txt > Pages : 23 > Date : 2021-04-23 > > Abstract: > DMARC allows for domain holders to request aggregate reports from > receivers. This report is an XML document, and contains extensible > elements that allow for other types of data to be specified later. > The aggregate reports can be submitted to the domain holder's > specified destination as supported by the receiver. > > This document (along with others) obsoletes RFC7489. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ > [...] >
I've done only a cursory review so far. (This is *not* an official AD review; I'm just participating here.) First, thanks for the work put into this. It was clearly not a trivial undertaking. Two quick comments, with something more detailed to follow: RFC2119 used to be all there was to BCP 14, but BCP 14 now includes RFC 8174, which changed the boilerplate you need to include if you want to use MUSTard language in IETF documents. Please update the references and boilerplate accordingly. You'll find it in RFC 8174 itself. Second, a pet peeve of mine when reviewing documents across all areas (and you can thank Pete Resnick for this part of my personality): There are many "naked" SHOULDs in here. By that, I mean: "SHOULD [NOT]" presents the implementer with advice but also a choice; an implementation is technically compliant if it doesn't do what the SHOULD [NOT] says. It strengthens the document to provide the reader with some guidance as to when one might make the informed decision to choose not to follow that advice; or, perhaps more importantly, the SHOULD [NOT] feels like it's dangling or unjustified without such guidance. For instance, the first SHOULD in this draft is this one: A single report SHOULD contain data for one policy configuration. Why might an implementer not do this? If there's no good answer to this question, maybe this ought to be a MUST or a MAY, not a SHOULD. Sometimes the answer here is backward compatibility. Maybe you really want this to be a MUST, but existing implementations didn't do it, so to grandfather them in, you made it a SHOULD. In such cases, I think you should either say this, or say something like new implementations MUST do this, but acknowledge that legacy implementations might not comply, and consumers need to be prepared to deal with that. Also worth considering: You can be normative without saying MUST. Continuing with this example, you could just as easily say: "A single report contains data for exactly one policy configuration." That's normative without using any BCP 14 language. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
