Inline below. Not all were resolved. In particular, the zstd comment, reporting interval, and report format need a bit of conversation.
New version to be uploaded in a few minutes. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Murray S. Kucherawy <[email protected]> Sent: Wednesday, November 20, 2024 7:43 PM To: Barry Leiba via Datatracker <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [dmarc-ietf] Re: Publication has been requested for draft-ietf-dmarc-aggregate-reporting-21 On Wed, Nov 20, 2024 at 12:44 PM Barry Leiba via Datatracker <[email protected]<mailto:[email protected]>> wrote: Barry Leiba has requested publication of draft-ietf-dmarc-aggregate-reporting-21 as Proposed Standard on behalf of the DMARC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!ACk6882kLd7eHXH-sRVZl-MTJ-Q75HU-bl16jiGR2rgkszj0RQpRc5ZoQ-abNDN-vfHqy64W07yQsBaM8YW6lP1AWUA$> AD Evaluation remarks, in no particular order (nothing too terrible): * Section 1: It's sort-of there, but it might be helpful to state explicitly that definitions from DMARCbis (e.g., "Domain Owner") are imported here. Added a short paragraph. * Section 2.1 paragraph 4 says you "should" (lowercase) generate a distinct report for each policy domain, and then paragraph 7 makes this a MUST. Changed to MUST * Section 2.1 paragraph 8 talks about the first mandatory section being "the metadata section", while the next paragraph appears to call it "the data section". Clarified, I think * Section 2.1 i invokes the "RFC5321.RcptTo" syntax to identify an element in the envelope, a syntax introduced by RFC 5598, but that RFC isn't referenced. Added reference * Section 2.1 lists all the DKIM and SPF results in one long string separated by slashes. I suggest making this a bulleted list or a table, or just say "any valid result value per RFC 8601". Created reference to 8601 * What's the normative SHOULD in Section 2.4 for? When might an implementer decide to do something else? What breaks if you do? I altered to no longer be normative. I also wonder if we should remove this section as “ri” is no longer part of the core document. Or instead alter the paragraph to suggest that all reports run 24hr and use 0000UTC as the boundary. * Section 2.6 starts talking about reporting URIs, which are specified in DMARCbis rather than here. A reference might be helpful. Added * Section 2.6.2 says the message has to comply with both RFC5322 and RFC2045. What's going on here? Why is it required to be MIME? Could it not be a plain message that happens to contain XML? Or are we trying to say there has to be a text/xml part that contains the report, and maybe other parts that provide additional information for humans? This question might be answered by the next paragraph, in which case this might just need some copy editing. I feel like I’m reading this is meant to be an attachment with that specified type, but isn’t explicitly stated. I’m not sure if that’s the expectation of others on the list. * Section 2.6.2 requires gzip. What about other methods like zstd which can provide better compression? This is the first time that has been asked. I suppose it could be changed, though, it seems as though it would break existing report ingestion. Are zipped reports large enough to benefit? * Section 2.6.2: The "dmarc-subject" ABNF needs some wrapping (or at least the text rendering is kinda messy). Added some “formatting”, which should help there. * Please sort out your Acknowledgements section (which currently just says "TBD") before we send this forward. Added -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
