I missed the deadline by a bit, and I can't upload from the form. I'll send over to Murray and see if he can help with that. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Brotman, Alex <Alex_Brotman@xxxxxxxxxxx> > Sent: Monday, March 3, 2025 9:42 PM > To: Dhruv Dhody <dd@xxxxxxxxxxxxxx>; ops-dir@xxxxxxxx > Cc: dmarc@xxxxxxxx; draft-ietf-dmarc-aggregate-reporting.all@xxxxxxxx; last- > call@xxxxxxxx > Subject: RE: Opsdir telechat review of draft-ietf-dmarc-aggregate-reporting-28 > > Thank you for your response. Inline below. > > I'll upload a new version shortly > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > > > > -----Original Message----- > > From: Dhruv Dhody via Datatracker <noreply@xxxxxxxx> > > Sent: Tuesday, February 18, 2025 1:46 AM > > To: ops-dir@xxxxxxxx > > Cc: dmarc@xxxxxxxx; draft-ietf-dmarc-aggregate-reporting.all@xxxxxxxx; last- > > call@xxxxxxxx > > Subject: Opsdir telechat review of draft-ietf-dmarc-aggregate-reporting-28 > > > > Reviewer: Dhruv Dhody > > Review result: Has Nits > > > > # OPSDIR review of draft-ietf-dmarc-aggregate-reporting > > > > I have reviewed this document as part of the Operational directorate's > > ongoing effort to review all IETF documents being processed by the IESG. > > These comments were written to improve the operational aspects of the IETF > > drafts. Comments that are not addressed in the last call may be included in AD > > reviews during the IESG review. Document editors and WG chairs should treat > > these comments just like any other last-call comments. > > > > The document lacks a dedicated Manageability or Operational Considerations > > section. Authors should consider if adding such a section could help (see RFC > > 5706). Some high-level thoughts - > > > > I added a small section about operational considerations. > > > - Perhaps text on parsing XML and ways to integrate with the monitoring > > system. > > > > - Error are free-flowing strings and thus some operational guidance around > > their use. > > > > - While providing aggregate reports itself is a monitoring technique, should > > there also be some discussion on the frequency and amount of such > > reporting? > > > > This is a bit tricky. It's entirely possible that the lack of reports is not the Domain > Owner's fault. Or maybe you just didn't send any email that day, etc. > > > - Guidance of local storage of the XML file > > > > Added a bit > > > - Logs when reporting cannot be done (size limitations etc), DNS issues, > > duplicate received. > > Added a small part > > > > > ## General > > > > - The document is clear and well-written but hard to read for a non-expert in > > the field > > > > - Have the XML, XSD, and ABNF verified via tools? The shepherd report says > > no. > > Was there a reason for only manual checks? > > I believe the XSD was validated (by someone else). I'll double check the ABNF > and XML. > > > > > - The Abstract says - "This document, in part, obsoletes and replaces > > [RFC7489], along with [I-D.ietf-dmarc-dmarcbis] and [I-D.ietf-dmarc-failure- > > reporting]."; this should be expanded on how these document set are related. > > Appendix C might be a good place to expand on it. > > > > Added > > > - There are various MUST elements for the XML elements but no guidance on > > what should happen if those MUST are not satisfied. On the receiving side, > > should the whole XML be discarded? Should the parsing error be ignored and > > every attempt to extract information attempted? > > > > IMO, I'd discard the report. If it's discarded, you don't know where there may be > an error in the format/data, and it makes the data more questionable. I've added > a SHOULD discard if the format does not match the specification. > > > ## Minor > > > > - Section 2.1.1, Remove the "Otherwise" in the note to the RFC EDITOR, the > > note needs to be removed irrespective of the clause before. > > Done > > > > > - Section 2.1.1.5, 'p', 'sp', and 'np' all have the same description in the table. > > That's correct. If others feel otherwise, it can be changed. > > > > > - Section 2.1.1.7, "One record per (IP, result, IDs Auths) tuples"; what is IDs > > Auths is unclear. > > > > I'm going to have to ask Daniel, he created that bit. -- I think I figured it out with a > nudge from him. > > > - Section 2.1.1.14, Add forward reference to section 2.1.5 for 'pre-defined > > override type'. > > > Done > > > - Section 2.2, maybe add a forward reference to section 4? > > Done > > > > > - Section 2.5, "a feedback report SHOULD employ a secure transport > > mechanism"; maybe we need a reference or some more text on what exactly > > the secure mechanism is. > > Added > > > > > - Section 2.5.1, add some text to explain ridfmt and ridtxt as you have done in > > other subsections. > > > > Added a small example > > > - Section 2.5.3, "The specification as written allows for the addition of other > > registered URI schemes to be supported in later versions." -> would this be a > > version upgrade via the XML "version" element? Note that you currently say > > "MUST have the value 1.0"; perhaps this could be rephrased to allow version > > upgrades in future. > > We considered this, even incrementing for this document. In the end, we decided > against it, and decided the contents of the report are a better indicator. > > > > > - Section 5, the Registrant Contact is set to "See the "Author's Address" > > section of this document."; doesn't this ought to be the IESG? As per RFC > > 3688 where the registry was created - "In the case of IETF developed > > standards, the Registrant will be the IESG." > > Amanda commented the same. Updated > > > > > - Section 9, I don't think [I-D.ietf-dmarc-dmarcbis] can be listed as an > > Informative reference, it ought to be normative. > > > > Typo, resolved > > > ## Nits > > > > - Expand these terms on first use - SPF, DKIM, PSO, PSD, rua, > > Updated > > > > > - I don't see a hyperlink to section 2.1.2 when you say '...explanation in > > "Handling Domains in Reports". > > > > Done > > > - Please fix the Unicode handling in the Acknowledgement section. > > > > I think this is an artifact of mmark and xml2rfc. In my local markdown file, the > characters have the proper diacritics. If I fix the XML manually, it seems okay in > the TXT file. > > > Thanks! > > Dhruv > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
