Apologies, verifying there are no outstanding tasks for the authors at this point?
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast -----Original Message----- From: Amanda Baber via RT <[email protected]> Sent: Saturday, May 16, 2026 12:05 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Brotman, Alex <[email protected]> Subject: [EXTERNAL] [IANA #1452348] [IANA] Re: AUTH48: RFC-to-be 9990 <draft-ietf-dmarc-aggregate-reporting-32> for your review Hi, These are complete: https://urldefense.com/v3/__https://www.iana.org/assignments/xml-registry/ns/dmarc-2.0.txt__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH0LLQEON$ https://urldefense.com/v3/__https://www.iana.org/assignments/xml-registry/schema/dmarc-2.0.xsd__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltHwumrD9W$ I updated the XSD file by replacing the full text with the contents of this document's Appendix A: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9990.txt__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltHznVEPtP$ thanks, Amanda On Fri May 15 18:16:28 2026, [email protected] wrote: > IANA, > > Please update your registries as follows to match the edited document > at > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9990-diff.html__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH7RN6Klx$ > . > > 1) Please update the description of "XML" for dmarc-2.0 at > <https://urldefense.com/v3/__https://www.iana.org/assignments/xml-regi > stry/ns/dmarc-2.0.txt__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH0LLQEON$ > > in the “IETF XML Registry” as follows. > > Old: > XML: None. Namespace URIs do not represent an XML specification. > > New: > XML: N/A; the requested URI is an XML namespace. > > > 2) Please update the following comments in the template for dmarc-2.0 > at > <https://urldefense.com/v3/__https://www.iana.org/assignments/xml-regi > stry/schema/dmarc-__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVx > sFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltHzU1lWfz$ > 2.0.xsd> in the “IETF XML Registry” as follows. > > a) add a comma > Old: > The policy actions specified by p, sp and np in the > DMARC Policy Record. > > New: > The policy actions specified by p, sp, and np in the > DMARC Policy Record. > > b) update the citations and remove “the" > Old: > The method used to discover the DMARC Policy Record used during > evaluation. The available values are "psl" and "treewalk", > where "psl" is the method from [@?RFC7489] and the "treewalk" > is described in [@I-D.ietf-dmarc-dmarcbis]. > > New: > The method used to discover the DMARC Policy Record used during > evaluation. The available values are "psl" and "treewalk", > where "psl" is the method from RFC 7489 and "treewalk" > is described in RFC 9989. > > c) add periods > Old: > Method used to find/obtain DMARC policy > … > Whether testing mode was declared in the DMARC Record > … > Values for Testing mode attached to policy > … > Taking into account everything else in the record, > the results of applying DMARC. If alignment fails > and the policy applied does not match the domain's > configured policy, the reason element MUST be specified > … > The RFC5321.MailFrom domain > > New: > Method used to find/obtain DMARC policy. > … > Whether testing mode was declared in the DMARC Record. > … > Values for Testing mode attached to policy. > … > Taking into account everything else in the record, > the results of applying DMARC. If alignment fails > and the policy applied does not match the domain's > configured policy, the reason element MUST be specified. > … > The RFC5321.MailFrom domain. > > d) update the punctuation and capitalization around the citation > Old: > The connecting IP. IPv4address or IPv6address > as defined in RFC 3986 section 3.2.2 > > New: > The connecting IP. IPv4address or IPv6address > as defined in RFC 3986, Section 3.2.2. > > e) update the punctuation around the citations > Old: > DKIM verification result, see RFC 8601 Section 2.7.1. > … > SPF verification result, see RFC 8601 Section 2.7.2. > > New: > DKIM verification result; see RFC 8601. Section 2.7.1. > … > SPF verification result; see RFC 8601, Section 2.7.2. > > f) update the text > Old: > One record per (IP, result, IDs Auths) tuples > > New: > One record (IP, result, IDs Auths) per tuple > > Best regards, > Alanna Paloma > RFC Production Center > > > On May 15, 2026, at 11:05 AM, Alanna Paloma <[email protected] > > editor.org> wrote: > > > > Hi Alex, > > > > We have removed the extra declaration to match your XML file and > > noted your approval on the AUTH48 status page: > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc999 > > 0__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQimVaoa5 > > cc8r_TuJ9wq0_65JUzUXJdx-BzeltHx2FQLmg$ > > > > We will now ask IANA to update their registry accordingly. After the > > IANA updates are complete, we will move forward with the publication > > process. > > > > —Files— > > > > The files have been posted here (please refresh): > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90.xml__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQim > > Vaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH4KE7gKg$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90.txt__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQim > > Vaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltHznVEPtP$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90.html__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQi > > mVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH9GUlCrc$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90.pdf__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFksYzuQim > > Vaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltHxMQzf6F$ > > > > The relevant diff files have been posted here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90-diff.html__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVxsFks > > YzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH7RN6Klx$ (comprehensive > > diff) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90-auth48diff.html__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuO > > VxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltHwdqPxT6$ (AUTH48 > > changes) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90-auth48rfcdiff.html__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQq > > CuOVxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH9KZ3s9g$ (AUTH48 > > changes side by side) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90-lastdiff.html__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCuOVx > > sFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltHzuJmtPt$ (last version > > to this one) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc99 > > 90-lastrfcdiff.html__;!!CQl3mcHX2A!BsDdYxQHsnd4GuxBlP6-PD_cvuY9JQqCu > > OVxsFksYzuQimVaoa5cc8r_TuJ9wq0_65JUzUXJdx-BzeltH60yrS6v$ (rfcdiff > > between last version and this) > > > > > > Thank you, > > Alanna Paloma > > RFC Production Center > > > >> On May 15, 2026, at 9:25 AM, Brotman, Alex > >> <[email protected]> wrote: > >> > >> See attached. There was an extra declaration in the XML samples in > >> Section 5. That is meant to illustrate two portions of the same > >> report, so the extra declaration shouldn't be there. > >> > >> Otherwise, I think that's it. > >> > >> -- > >> Alex Brotman > >> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > >> > >> > >> -----Original Message----- > >> From: Alanna Paloma <[email protected]> > >> Sent: Thursday, May 14, 2026 4:28 PM > >> To: Brotman, Alex <[email protected]> > >> Cc: [email protected]; [email protected]; dmarc- > >> [email protected]; [email protected]; [email protected]; > >> [email protected] > >> Subject: Re: AUTH48: RFC-to-be 9990 <draft-ietf-dmarc-aggregate- > >> reporting-32> for your review > >> > >> Hi Alex, > >> > >> Thank you for your reply with the updated XML file. We have updated > >> the other files accordingly. > >> > >> The files have been posted here (please refresh): > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9990.xml__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR523GWzgg$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9990.txt__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR6PAGPCrw$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9990.html__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR7tRC8wag$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9990.pdf__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR4byW0_qA$ > >> > >> The relevant diff files have been posted here: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9990- > >> diff.html__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR6NPXGfgg$ (comprehensive diff) > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9990- > >> auth48diff.html__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR6dCeMS6Q$ (AUTH48 changes) > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9990- > >> auth48rfcdiff.html__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR5KthP8qQ$ (AUTH48 changes side by > >> side) > >> > >> Please review the document carefully and contact us with any further > >> updates you may have. Note that we do not make changes once a > >> document is published as an RFC. > >> > >> We will await approvals from each party listed on the AUTH48 status > >> page below prior to moving this document forward in the publication > >> process. > >> > >> For the AUTH48 status of this document, please see: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/auth48/rfc9990__;!!CQl3mcHX2A!EN_l50OxNwfIKFaZNMkLM2kV1A3bmtH6ZOIzng0hRIROsGXniDKysl1- > >> e2TWwIqG6511VV9ERqjR1Opaw_RAzR4u6LRgCg$ > >> > >> Thank you, > >> Alanna Paloma > >> RFC Production Center > >> > >> > >>> On May 13, 2026, at 5:52 PM, Brotman, Alex > >>> <[email protected]> wrote: > >>> > >>> Inline below, and XML attached. > >>> > >>> NOTE: My corporate mail system may have mangled the outbound > >>> message content with a URL-wrapper. If this has happened, let me > >>> know, and I will figure out another method. > >>> -- > >>> Alex Brotman > >>> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > >>> > >>> > >>> -----Original Message----- > >>> From: [email protected] <[email protected]> > >>> Sent: Wednesday, May 13, 2026 5:25 PM > >>> To: Brotman, Alex <[email protected]> > >>> Cc: [email protected]; [email protected]; dmarc- > >>> [email protected]; [email protected]; [email protected]; > >>> [email protected] > >>> Subject: Re: AUTH48: RFC-to-be 9990 <draft-ietf-dmarc-aggregate- > >>> reporting-32> for your review > >>> > >>> Authors, > >>> > >>> While reviewing this document during AUTH48, please resolve (as > >>> necessary) the following questions, which are also in the source > >>> file. > >>> > >>> 1) <!-- [rfced] Please insert any keywords (beyond those that > >>> appear in the title) for use on > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/search__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi16Z6NSI$ > >>> . --> > >>> > >>> ATB: Added, replicated RFC7489 > >>> > >>> 2) <!--[rfced] FYI: We added the following sentence to the end of > >>> the Abstract as the Obsolete status was absent (this is now > >>> consistent with the companion documents). > >>> > >>> Current: > >>> This document obsoletes RFC 7489. > >>> --> > >>> > >>> ATB: Accepted > >>> > >>> 3) <!--[rfced] We note that the errata for this document is > >>> addressed in RFC-to-be 9989. May we add a sentence in Section 2 > >>> ("Document > >>> Status") that mentions the errata has been addressed in the > >>> companion document? > >>> > >>> Original: > >>> This document, in part, along with RFCs 9989 and 9991, obsoletes > >>> and replaces DMARC [RFC7489]. > >>> > >>> Perhaps: > >>> This document, in part, along with [RFC9989] and [RFC9991], > >>> obsoletes > >>> and replaces DMARC [RFC7489]. Note that errata for this document > >>> has been addressed as described in [RFC9989]. > >>> --> > >>> > >>> ATB: Added > >>> > >>> 4) <!-- [rfced] We note that "psl" is not used in RFC 7489. Please > >>> review the citation below and let us know how it may be updated. > >>> > >>> Current: > >>> * "discovery_method" can have the value "psl" or "treewalk", where > >>> "psl" is the method from [RFC7489] and "treewalk" is described > >>> in > >>> [RFC9989]. > >>> --> > >>> > >>> ATB: In RFC7489, Section A.6.1 describes the Public Suffix List. > >>> Section 3.2 describes how to use it. Would you like me to add a > >>> reference to that section in the discovery_method, or some other > >>> reference? > >>> > >>> 5) <!--[rfced] The following text is not a complete sentence. > >>> Please review and let us know how it may be updated. > >>> > >>> Original: > >>> One record per (IP, result, authentication identifiers) tuples. > >>> > >>> Perhaps: > >>> There is one record (IP, result, authentication identifiers) > >>> per tuples. > >>> --> > >>> > >>> ATB: XML adjusted > >>> > >>> 6) <!--[rfced] Please clarify the use of "extensibly". Is the > >>> intended meaning perhaps "potentially" or "by extension"? > >>> > >>> Current: > >>> The second report will be for example.com and contain multiple > >>> "record" elements, one for example.com and one for foo.example.com > >>> (and extensibly, other "record" elements for subdomains that > >>> likewise did not have an explicit DMARC Policy Record). > >>> --> > >>> > >>> ATB: "by extension", adjusted in XML. > >>> > >>> 7) <!--[rfced] How may we rephrase "a [RFC5322] message" to avoid > >>> using RFC 5322 as an adjective? > >>> > >>> Original: > >>> The message generated by the Mail Receiver MUST be a [RFC5322] > >>> message formatted per [RFC2045]. > >>> > >>> Perhaps A: > >>> The message generated by the Mail Receiver MUST be as > >>> described in [RFC5322] and formatted per [RFC2045]. > >>> > >>> or > >>> Perhaps B: > >>> The message generated by the Mail Receiver MUST be a message that > >>> contains subaddressing [RFC5322] and is formatted per [RFC2045]. > >>> --> > >>> > >>> ATB: Option A, XML adjusted. > >>> > >>> 8) <!--[rfced] To improve readability, may we update this sentence > >>> as follows? > >>> > >>> Original: > >>> When accepting the data, that's likely in a situation where it's > >>> not > >>> yet noticed, or a one-off experience. > >>> > >>> Perhaps: > >>> When accepting the data, it's likely that the duplicate data has > >>> not > >>> yet been noticed and is a one-off experience. > >>> --> > >>> > >>> ATB: XML adjusted > >>> > >>> 9) <!--[rfced] Would it be correct to say that the Domain Owner > >>> should consider using a shorter "domain name" for clarity? > >>> > >>> Current: > >>> If the length of the DNS query is excessively long (Step 4 above), > >>> the Domain Owner may need to reconsider the domain being used to be > >>> shorter or reach out to another party that may allow for a > >>> shorter DNS label. > >>> > >>> Perhaps: > >>> If the DNS query length is excessively long (see Step 4), the > >>> Domain Owner may need to consider using a shorter domain name or > >>> coordinate with another party that may allow for a shorter DNS > >>> label. > >>> --> > >>> > >>> ATB: Adjusted in XML > >>> > >>> 10) <!--[rfced] XML snippets > >>> > >>> a) Should the "</feedback>" closing tag be added after > >>> "</extension>" > >>> in the first XML example in Section 5 so that the XML parses, or is > >>> this meant to be a continuing example? > >>> > >>> Original: > >>> <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" > >>> xmlns:ext="URI for an extension-supplied name space"> > >>> ... > >>> <policy_published> > >>> <domain>example.com</domain> > >>> <p>quarantine</p> > >>> <sp>none</sp> > >>> <testing>n</testing> > >>> </policy_published> > >>> <extension> > >>> <ext:arc-override>never</ext:arc-override> > >>> </extension> > >>> > >>> Perhaps: > >>> <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" > >>> xmlns:ext="URI for an extension-supplied name space"> > >>> ... > >>> <policy_published> > >>> <domain>example.com</domain> > >>> <p>quarantine</p> > >>> <sp>none</sp> > >>> <testing>n</testing> > >>> </policy_published> > >>> <extension> > >>> <ext:arc-override>never</ext:arc-override> > >>> </extension> > >>> </feedback> > >>> > >>> b) Should "<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" > >>> xmlns:ext="URI for an extension-supplied name space">" be added to > >>> the following XML snippet? Is a closing tag unnecessary because > >>> this is a continuing example, or should one be added? > >>> > >>> Current: > >>> <record> > >>> <row> > >>> ... > >>> </row> > >>> <identifiers> > >>> ... > >>> </identifiers> > >>> <auth_results> > >>> ... > >>> </auth_results> > >>> <ext:arc-results> > >>> ... > >>> </ext:arc-results> > >>> </record> > >>> <record> > >>> ... > >>> > >>> Perhaps: > >>> <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" > >>> xmlns:ext="URI for an extension-supplied name space"> > >>> ... > >>> <record> > >>> <row> > >>> ... > >>> </row> > >>> <identifiers> > >>> ... > >>> </identifiers> > >>> <auth_results> > >>> ... > >>> </auth_results> > >>> <ext:arc-results> > >>> ... > >>> </ext:arc-results> > >>> </record> > >>> --> > >>> > >>> ATB: This is meant to be a partial report, no need to add extra > >>> tags. > >>> > >>> 11) <!--[rfced] FYI: Per IANA's note, we have updated the > >>> registrant contact from "IETF" to "IESG" in Sections 6.1 and 6.2. > >>> > >>> Original: > >>> Registrant Contact: Internet Engineering Task Force > >>> ([email protected]) > >>> > >>> Current: > >>> Registrant Contact: The IESG ([email protected]) > >>> --> > >>> > >>> ATB: Appreciated > >>> > >>> 12) <!-- [rfced] FYI: We updated the dates for the W3C reference > >>> entries from "2 May 2001" to "28 October 2004" to match the most > >>> current version of the two W3C Recommendations. > >>> --> > >>> > >>> ATB: Thank you > >>> > >>> 13) <!--[rfced] In the XML schema in Appendix A, we updated > >>> "[@?RFC7489]" > >>> to "RFC 7489" and "[@I-D.ietf-dmarc-dmarcbis]" to "RFC 9989". We > >>> also made a few punctuation updates for consistency. Please let us > >>> know of any objections. > >>> --> > >>> > >>> ATB: Looks good, thank you > >>> > >>> 14) <!--[rfced] FYI - We have alphabetized the names listed in the > >>> Acknowledgements section. We believe that was the intent as only > >>> two were out of order. Let us know if you prefer the original > >>> order. > >>> --> > >>> > >>> ATB: Thank you > >>> > >>> 15) <!-- [rfced] FYI - We have added expansions for the following > >>> abbreviation per Section 3.6 of RFC 7322 ("RFC Style > >>> Guide"). Please review each expansion in the document carefully > >>> to ensure correctness. > >>> > >>> UUID = Universally Unique Identifier (UUID) > >>> --> > >>> > >>> ATB: Thank you > >>> > >>> 16) <!-- [rfced] Please review the "Inclusive Language" portion of > >>> the online > >>> Style Guide <https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/styleguide/part2/*inclusive_language__;Iw!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi_j4tw6Q$ > >>> > > >>> and let us know if any changes are needed. Updates of this nature > >>> typically > >>> result in more precise language, which is helpful for readers. > >>> > >>> Note that our script did not flag any words in particular, but this > >>> should > >>> still be reviewed as a best practice. > >>> --> > >>> > >>> ATB: Noted > >>> > >>> Thank you. > >>> > >>> Alanna Paloma and Karen Moore > >>> RFC Production Center > >>> > >>> > >>> On May 13, 2026, at 2:23 PM, RFC Editor via auth48archive > >>> <[email protected]> wrote: > >>> > >>> *****IMPORTANT***** > >>> > >>> Updated 2026/05/13 > >>> > >>> RFC Author(s): > >>> -------------- > >>> > >>> Instructions for Completing AUTH48 > >>> > >>> Your document has now entered AUTH48. Once it has been reviewed > >>> and > >>> approved by you and all coauthors, it will be published as an RFC. > >>> If an author is no longer available, there are several remedies > >>> available as listed in the FAQ > >>> (https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/faq/__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi0DWiY2Z$ > >>> ). > >>> > >>> You and you coauthors are responsible for engaging other parties > >>> (e.g., Contributors or Working Group) as necessary before providing > >>> your approval. > >>> > >>> Planning your review > >>> --------------------- > >>> > >>> Please review the following aspects of your document: > >>> > >>> * RFC Editor questions > >>> > >>> Please review and resolve any questions raised by the RFC Editor > >>> that have been included in the XML file as comments marked as > >>> follows: > >>> > >>> <!-- [rfced] ... --> > >>> > >>> These questions will also be sent in a subsequent email. > >>> > >>> * Changes submitted by coauthors > >>> > >>> Please ensure that you review any changes submitted by your > >>> coauthors. We assume that if you do not speak up that you > >>> agree to changes submitted by your coauthors. > >>> > >>> * Content > >>> > >>> Please review the full content of the document, as this cannot > >>> change once the RFC is published. Please pay particular attention > >>> to: > >>> - IANA considerations updates (if applicable) > >>> - contact information > >>> - references > >>> > >>> * Copyright notices and legends > >>> > >>> Please review the copyright notice and legends as defined in > >>> RFC 5378 and the Trust Legal Provisions > >>> (TLP – > >>> https://urldefense.com/v3/__https://trustee.ietf.org/license- > >>> info__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi7rj_Psj$ > >>> ). > >>> > >>> * Semantic markup > >>> > >>> Please review the markup in the XML file to ensure that elements of > >>> content are correctly tagged. For example, ensure that > >>> <sourcecode> > >>> and <artwork> are set correctly. See details at > >>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml- > >>> vocabulary__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi86jJHt2$ > >>> >. > >>> > >>> * Formatted output > >>> > >>> Please review the PDF, HTML, and TXT files to ensure that the > >>> formatted output, as generated from the markup in the XML file, is > >>> reasonable. Please note that the TXT will have formatting > >>> limitations compared to the PDF and HTML. > >>> > >>> > >>> Submitting changes > >>> ------------------ > >>> > >>> To submit changes, please reply to this email using ‘REPLY ALL’ as > >>> all > >>> the parties CCed on this message need to see your changes. The > >>> parties > >>> include: > >>> > >>> * your coauthors > >>> > >>> * [email protected] (the RPC team) > >>> > >>> * other document participants, depending on the stream (e.g., > >>> IETF Stream participants are your working group chairs, the > >>> responsible ADs, and the document shepherd). > >>> > >>> * [email protected], which is a new archival mailing > >>> list > >>> to preserve AUTH48 conversations; it is not an active discussion > >>> list: > >>> > >>> * More info: > >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf- > >>> announce/yb6lpIGh- > >>> 4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi5B3Oaax$ > >>> > >>> * The archive itself: > >>> > >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi8CgSMB_$ > >>> > >>> * Note: If only absolutely necessary, you may temporarily opt out > >>> of the archiving of messages (e.g., to discuss a sensitive > >>> matter). > >>> If needed, please add a note at the top of the message that you > >>> have dropped the address. When the discussion is concluded, > >>> [email protected] will be re-added to the CC list and > >>> its addition will be noted at the top of the message. > >>> > >>> You may submit your changes in one of two ways: > >>> > >>> An update to the provided XML file > >>> — OR — > >>> An explicit list of changes in this format > >>> > >>> Section # (or indicate Global) > >>> > >>> OLD: > >>> old text > >>> > >>> NEW: > >>> new text > >>> > >>> You do not need to reply with both an updated XML file and an > >>> explicit > >>> list of changes, as either form is sufficient. > >>> > >>> We will ask a stream manager to review and approve any changes that > >>> seem > >>> beyond editorial in nature, e.g., addition of new text, deletion > >>> of text, > >>> and technical changes. Information about stream managers can be > >>> found in > >>> the FAQ. Editorial changes do not require approval from a stream > >>> manager. > >>> > >>> > >>> Approving for publication > >>> -------------------------- > >>> > >>> To approve your RFC for publication, please reply to this email > >>> stating > >>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>> as all the parties CCed on this message need to see your approval. > >>> > >>> > >>> Files > >>> ----- > >>> > >>> The files are available here: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9990.xml__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGiypzt3fh$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9990.html__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi7iaikwp$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9990.pdf__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGix9fXmyI$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9990.txt__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi68AOGVY$ > >>> > >>> Diff file of the text: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9990- > >>> diff.html__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi0PlWrIB$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9990- > >>> rfcdiff.html__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGix0igvda$ > >>> (side by side) > >>> > >>> Diff of the XML: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9990- > >>> xmldiff1.html__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi53Wubok$ > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/auth48/rfc9990__;!!CQl3mcHX2A!BS5MOD0ZHlii7PntyZRIxqqdTFNAsl7YDHwMxjGHKrqhTz3QFEAN9h9EJ8WbAV1LLhx8DohCBAS0Ua1mEBMGi- > >>> 213V2Z$ > >>> > >>> Please let us know if you have any questions. > >>> > >>> Thank you for your cooperation, > >>> > >>> RFC Editor > >>> > >>> -------------------------------------- > >>> RFC9990 (draft-ietf-dmarc-aggregate-reporting-32) > >>> > >>> Title : Domain-based Message Authentication, Reporting, > >>> and Conformance (DMARC) Aggregate Reporting > >>> Author(s) : A. Brotman, Ed. > >>> WG Chair(s) : Barry Leiba, Seth Blank > >>> Area Director(s) : Andy Newton, Charles Eckel > >>> > >>> > >>> -- > >>> auth48archive mailing list -- [email protected] > >>> To unsubscribe send an email to [email protected] > >>> > >>> <rfc9990.xml> > >> > >> <rfc9990.xml> > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
