Hi all, below some replies, agreed with Steve Jones.
On Fri 09/Jan/2026 23:04:36 +0100 Sarah Tarrant wrote:
[...] 1) As there may have been multiple updates made to the document during Last Call, please review the current version of the document: * Is the text in the Abstract still accurate?
Yes
* Are the Authors' Addresses, Contributors, and Acknowledgments sections current?
Well, we miss an Acknowledgment section. Since both of the other documents in the cluster have one, perhaps we should add one too.
2) Please share any style information that could help us with editing your document. For example: * Is your document's format or its terminology based on another document? If so, please provide a pointer to that document (e.g., this document's terminology should match DNS terminology in RFC 9499). * Is there a pattern of capitalization or formatting of terms? (e.g., field names should have initial capitalization; parameter names should be in double quotes; <tt/> should be used for token names; etc.)
I'd recommend to keep the same style of the other two documents in the cluster, where possible. The WG never discussed style questions, but there is an attempt to use the same term to refer to the same thing, with the same capitalization and quoting.
3) Please review the entries in the References section carefully with the following in mind. Note that we will update as follows unless we hear otherwise at this time: * References to obsoleted RFCs will be updated to point to the current RFC on the topic in accordance with Section 4.8.6 of RFC 7322 (RFC Style Guide). * References to I-Ds that have been replaced by another I-D will be updated to point to the replacement I-D. * References to documents from other organizations that have been superseded will be updated to their superseding version. Note: To check for outdated RFC and I-D references, you can use idnits <https://author-tools.ietf.org/idnits>. You can also help the IETF Tools Team by testing idnits3 <https://author-tools.ietf.org/idnits3/> with your document and reporting any issues to them.
All references are current.
4) Is there any text that should be handled extra cautiously? For example, are there any sections that were contentious when the document was drafted?
No.
5) Is there anything else that the RPC should be aware of while editing this document?
None AFAIK.
6) This document contains sourcecode: * Does the sourcecode validate? * Some sourcecode types (e.g., YANG) require certain references and/or text in the Security Considerations section. Is this information correct? * Is the sourcecode type indicated in the XML? (See information about types: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) * Note that type "RFC5322" is not on that list. Please review
The report sample's tag is <sourcecode type="RFC5322">. Please replace it with <sourcecode type="message/rfc822">
7) This document is part of Cluster 539: https://www.rfc-editor.org/cluster_info.php?cid=C539 * To help the reader understand the content of the cluster, is there a document in the cluster that should be read first? Next? If so, please provide the order and we will provide RFC numbers for the documents accordingly. If order is not important, please let us know. * Is there any text that has been repeated within the cluster document that should be edited in the same way (for instance, parallel introductory text or Security Considerations)? * For more information about clusters, see https://www.rfc-editor.org/about/clusters/ * For a list of all current clusters, see: http://www.rfc-editor.org/all_clusters.php
The correct order of the documents is: 1. draft-ietf-dmarc-dmarcbis-41 2. draft-ietf-dmarc-aggregate-reporting-32 3. draft-ietf-dmarc-failure-reporting-24
8) Because this document updates RFC 6591 and obsoletes RFC 7489, please review the reported errata and confirm whether they have been addressed in this document or are not relevant: * RFC 7489 (https://www.rfc-editor.org/errata/rfc7489)
None of those errata is about failure reporting.
9) Would you like to participate in the RPC Pilot Test for editing in kramdown-rfc? If so, please let us know and provide a self-contained kramdown-rfc file. For more information about this experiment, see: https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc.
We used the Mmark flavor of markdown (https://mmark.miek.nl/). As its syntax is quite different from that of kramdown-rfc, we're not interested to change at this point.
10) Would you like to participate in the RPC Pilot Test for completing AUTH48 in GitHub? If so, please let us know. For more information about this experiment, see: https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test.
Yes, we'd participate, as this allows to share the process. However, I'm unable to create a repository under https://github.com/rfc-editor/. Couldn't you fork https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting?
Best Ale -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
