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 - - 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? - Guidance of local storage of the XML file - Logs when reporting cannot be done (size limitations etc), DNS issues, duplicate received. ## 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? - 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. - 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? ## 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. - Section 2.1.1.5, 'p', 'sp', and 'np' all have the same description in the table. - Section 2.1.1.7, "One record per (IP, result, IDs Auths) tuples"; what is IDs Auths is unclear. - Section 2.1.1.14, Add forward reference to section 2.1.5 for 'pre-defined override type'. - Section 2.2, maybe add a forward reference to section 4? - 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. - Section 2.5.1, add some text to explain ridfmt and ridtxt as you have done in other subsections. - 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. - 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." - Section 9, I don't think [I-D.ietf-dmarc-dmarcbis] can be listed as an Informative reference, it ought to be normative. ## Nits - Expand these terms on first use - SPF, DKIM, PSO, PSD, rua, - I don't see a hyperlink to section 2.1.2 when you say '...explanation in "Handling Domains in Reports". - Please fix the Unicode handling in the Acknowledgement section. Thanks! Dhruv -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
