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
