Hi Amanda, The updates look good. Thank you!
Best regards, Alanna Paloma RFC Production Center > On May 15, 2026, at 9:04 PM, Amanda Baber via RT <[email protected]> wrote: > > Hi, > > These are complete: > > https://www.iana.org/assignments/xml-registry/ns/dmarc-2.0.txt > > https://www.iana.org/assignments/xml-registry/schema/dmarc-2.0.xsd > > I updated the XSD file by replacing the full text with the contents of this > document's Appendix A: > > https://www.rfc-editor.org/authors/rfc9990.txt > > 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://www.rfc-editor.org/authors/rfc9990-diff.html. >> >> 1) Please update the description of "XML" for dmarc-2.0 at >> <https://www.iana.org/assignments/xml-registry/ns/dmarc-2.0.txt> 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://www.iana.org/assignments/xml-registry/schema/dmarc- >> 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://www.rfc-editor.org/auth48/rfc9990 >>> >>> 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://www.rfc-editor.org/authors/rfc9990.xml >>> https://www.rfc-editor.org/authors/rfc9990.txt >>> https://www.rfc-editor.org/authors/rfc9990.html >>> https://www.rfc-editor.org/authors/rfc9990.pdf >>> >>> The relevant diff files have been posted here: >>> https://www.rfc-editor.org/authors/rfc9990-diff.html (comprehensive >>> diff) >>> https://www.rfc-editor.org/authors/rfc9990-auth48diff.html (AUTH48 >>> changes) >>> https://www.rfc-editor.org/authors/rfc9990-auth48rfcdiff.html (AUTH48 >>> changes side by side) >>> https://www.rfc-editor.org/authors/rfc9990-lastdiff.html (last >>> version to this one) >>> https://www.rfc-editor.org/authors/rfc9990-lastrfcdiff.html (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]
