Re: [auth48] [Ext] AUTH48: RFC-to-be 9567 <draft-ietf-dnsop-dns-error-reporting-08> for your review

[Roy Arends <[e-mail]>]

> On 9 Apr 2024, at 23:14, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML 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__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTHm_07ZA$ [rfc-editor[.]org]. -->

monitoring 
agent
RFC8914
8914

> 2) <!-- [rfced] Would replacing "where" with "to which" improve readability of
> this sentence? 
> 
> Original:
>   It allows an authoritative server to announce a monitoring agent
>   where validating resolvers can report issues if those resolvers are
>   configured to do so.
> 
> Perhaps: 
>   It allows an authoritative server to announce a monitoring agent
>   to which validating resolvers can report issues if those resolvers are
>   configured to do so.
> -->

It would improve readability. Thanks for the suggestion. Please replace.

> 3) <!-- [rfced] We updated the first two definitions below to have a consistent
> style with the last two definitions. Please review and let us know any
> concerns.
> 
> Original:
>   Reporting resolver:  In the context of this document, "reporting
>      resolver" is used as a shorthand for a validating resolver that
>      supports DNS error reporting.
> 
>   Report query:  The DNS query used to report an error is called a
>      report query.  A report query is for a DNS TXT resource record
>      type.  The content of the error report is encoded in the QNAME of
>      a DNS request to the monitoring agent.
> 
>   Monitoring agent:  An authoritative server that receives and responds
>      to report queries.  This facility is indicated by a domain name,
>      referred to as the agent domain.
> 
>   Agent domain:  A domain name which is returned in the DNS Error
>      Reporting EDNS0 option that indicates where DNS resolvers can send
>      error reports.
> 
> Updated (first two entries): 
>   Reporting resolver:  A validating resolver that
>      supports DNS error reporting.
> 
>   Report query:  The DNS query used to report an error.
>      A report query is for a DNS TXT resource record
>      type.  The content of the error report is encoded in the QNAME of
>      a DNS request to the monitoring agent.
> 
>   Monitoring agent:  An authoritative server that receives and responds
>      to report queries.  This facility is indicated by a domain name,
>      referred to as the "agent domain".
> 
>   Agent domain:  A domain name that is returned in the DNS Error
>      Reporting EDNS0 option that indicates where DNS resolvers can send
>      error reports.
> -->

Much better. Please use the suggestion.

> 4) <!-- [rfced] Will "DNS Error Reporting EDNS0 option" be clear to readers?
> Also, may we update "that indicates" to "and indicates"?
> 
> Original:
>   Agent domain:  A domain name which is returned in the DNS Error
>      Reporting EDNS0 option that indicates where DNS resolvers can send
>      error reports.
> 
> Perhaps: 
>   Agent domain:  A domain name that is returned in the 
>      EDNS0 Report-Channel option and indicates where DNS resolvers can send
>      error reports.
> -->

Much better. Please use the suggestion.

> 5) <!-- [rfced] The following text in Section 4 seems similar to (but not exactly
> the same as) the bulleted list in Section 6.1.1. Please review and let us
> know if any updates would be helpful. For example, should these lists be
> exactly the the same? Would it be helpful to include a pointer to
> Section 6.1.1 here instead of the similar text?
> 
> Original:
>   The reporting resolver builds this QNAME by
>   concatenating the _er label, the QTYPE, the QNAME that resulted in
>   failure, the extended error code (as described in [RFC8914]), the
>   label "_er" again, and the agent domain.
> -->

Section 4 is an overview with an example, and uses informal language to help understand the concept. It'd like to leave the text as is, but change the following:

Original:
  See the example in Section 4.1. 

Perhaps:
  See the example in Section 4.1 and the specification in Section 6.1.1.

Does that work for you?

> 6) <!-- [rfced] Please review "that is, once per TTL" here. Will this be clear to
> readers?
> 
> Original:
>   This caching is essential.  It
>   dampens the number of report queries sent by a reporting resolver for
>   the same problem, that is, once per TTL.  
> 
> Perhaps:
>   This caching is essential.  It
>   dampens the number of report queries sent by a reporting resolver for
>   the same problem (that is, with caching, one report query per TTL is sent).  
> -->

Better. Thanks.

> 
> 7) <!-- [rfced] We updated "such as [RFC8020] and [RFC8198]" as shown
> below. Would it be helpful to further clarify by mentioning the
> mechanisms?
> 
> Original:
>   However, certain
>   optimizations such as [RFC8020] and [RFC8198] may reduce the number
>   of error report queries as well.
> 
> Current:
>   However, certain
>   optimizations, such as those described in [RFC8020] and [RFC8198], may reduce the number
>   of error report queries as well.
> 
> Perhaps:
>   However, certain
>   optimizations, such as NXDOMAIN [RFC8020] and NSEC/NSEC3 [RFC8198], may reduce the number
>   of error report queries as well.
> -->

Using the NXDOMAIN and NSEC/NSEC3 terms does not make it clearer. I do think the "Current" version is better than the original.

> 
> 
> 8) <!-- [rfced] In Section 4.1, we see both "type A" and "type 1". Are these the
> same thing? If so, should they be consistent?
> -->

To make it consistent, maybe use:
Original:
  The reporting resolver is unable to validate the "broken.test" RRset for type 1 (an A record), due to an RRSIG record with an expired signature.

Perhaps:
    The reporting resolver is unable to validate the "broken.test" RRset for type A (an RR type with value 1), due to an RRSIG record with an expired signature.


> 
> 
> 9) <!-- [rfced] Should "type 1 record" here be updated to "for a type 1 record"?
> 
> Original:
>   This QNAME indicates extended DNS error 7 occurred while trying to
>   validate "broken.test." type 1 record.
> 
> Perhaps: 
>   This QNAME indicates extended DNS error 7 occurred while trying to
>   validate "broken.test." for a type 1 record.
> -->

Yes. better, thanks.

> 
> 
> 10) <!-- [rfced] Please review "error reporting QNAME" and "another error
> reporting" here and let us know if updates like the following would
> improve clarity.
> 
> Original:
>   Care should be taken when more DNS resolving is needed to resolve the
>   error reporting QNAME.  This resolving itself could trigger another
>   error reporting to be created.
> 
> Perhaps: 
>   Care should be taken when more DNS resolving is needed to resolve the
>   error reported by the QNAME.  This resolving itself could trigger another
>   error report to be created.  
> -->

No. This reads like we're resolving the error (as in trying to fix the error). We're resolving the QNAME that contains the error report.

Perhaps:
  Care should be taken when more DNS resolving is needed to resolve the QNAME that contains the error report.

> 
> 
> 11) <!-- [rfced] We updated "agent domain field" to "AGENT DOMAIN field" to match
> the field name in the figure in Section 5. Are any other instances of
> "agent domain" referring to the field?

There are no other instances. Good catch, Thanks!
> 
> Original:
>   The reporting resolver MUST NOT use DNS error reporting if the
>   authoritative server returned an empty agent domain field in the
>   EDNS0 Report-Channel option.
> 
> Updated:
>   The reporting resolver MUST NOT use DNS error reporting if the
>   authoritative server returned an empty AGENT DOMAIN field in the
>   EDNS0 Report-Channel option.
> -->

Perfect, thanks.

> 
> 
> 12) <!-- [rfced] To improve readability, may we update "For the benefit of the
> monitoring agent to get more confidence" as follows?
> 
> Original:
>   For the benefit of the monitoring agent to get more confidence that
>   the report is not spoofed, the reporting resolver SHOULD send error
>   reports over TCP [RFC7766] or other connection oriented protocols or
>   SHOULD use DNS COOKIEs [RFC7873]. 
> 
> Perhaps: 
>   For the monitoring agent to gain more confidence that
>   the report is not spoofed, the reporting resolver SHOULD send error
>   reports over TCP [RFC7766] or other connection-oriented protocols or
>   SHOULD use DNS COOKIEs [RFC7873]. 
> -->

Yes please, thanks.

> 
> 
> 13) <!-- [rfced] This list is Section 6.1.1 contains two instances of "A label
> containing the string "_er".'. Would be it be helpful to add "(again)" or
> something similar to the second instance?

No, that wouldn't be helpful. I think the current text is clear.

> 
> Original:
>   *  A label containing the string "_er".
> 
>   *  The QTYPE that was used in the query that resulted in the extended
>      DNS error, presented as a decimal value, in a single DNS label.
>      If additional QTYPEs were present in the query, such as described
>      in [I-D.ietf-dnssd-multi-qtypes], they are represented as unique,
>      ordered decimal values separated by a hyphen.  As an example, if
>      both QTYPE A and AAAA were present in the query, they are
>      presented as the label "1-28".
> 
>   *  The list of non-null labels representing the query name which is
>      the subject of the DNS error report.
> 
>   *  The extended DNS error, presented as a decimal value, in a single
>      DNS label.
> 
>   *  A label containing the string "_er".
> 
>   *  The agent domain.  The agent domain as received in the EDNS0
>      Report-Channel option set by the authoritative server.
> -->
> 
> 
> 14) <!-- [rfced] Will "as a result and not the original query" be clear to readers?
> 
> Original:
>   The "_er" labels allow the monitoring agent to differentiate between
>   the agent domain and the faulty query name.  When the specified agent
>   domain is empty, or a null label (despite being not allowed in this
>   specification), the report query will have "_er" as a top-level
>   domain as a result and not the original query.
> 
> Perhaps:
>   The "_er" labels allow the monitoring agent to differentiate between
>   the agent domain and the faulty query name.  When the specified agent
>   domain is empty, or is a null label (despite being not allowed in this
>   specification), the report query will have "_er" as a top-level
>   domain as a result, but the original query will not.

No, this doesn't make sense. Maybe the following:

,the report query will have "_er" as a top-level domain, and not the top level domain from the query name that was the subject of this error report.

> -->
> 
> 
> 15) <!-- [rfced] We note that this sentence appears in both Section 6.3 and
> Section 9. Please review and let us know if any updates are needed.
> 
> Original:
>   The monitoring agent SHOULD respond to queries received over UDP that
>   have no DNS COOKIE set with a response that has the truncation bit
>   (TC bit) set to challenge the resolver to re-query over TCP.
> -->

Lets leave it in both places.

> 16) <!-- [rfced] Please review "TXT resource record RDATA for this record" in
> these two sentences. Will this be clear to readers? Also, will readers
> know what "it" refers to in the second sentence?
> 
> Original:
>   This document gives no guidance on the content of the TXT resource
>   record RDATA for this record.
>   ...
>   Though this document gives no guidance on the content of the TXT
>   resource record RDATA for this record, if the RDATA content is
>   logged, it MUST assume the content can be malicious and take
>   appropriate meassures to avoid exploitation. 
> 
> Perhaps:
>   This document gives no guidance on the content of the RDATA in the TXT resource
>   record.
>   ...
>   Though this document gives no guidance on the content of the RDATA in the TXT
>   resource record, if the RDATA content is
>   logged, the monitoring agent MUST assume the content can be malicious and take
>   appropriate measures to avoid exploitation.

Much better. Thanks!

> -->
> 
> 
> 17) <!-- [rfced] How may we update "such as [CVE-2021-44228]" for clarity?
> 
> Original:
>   This would avoid remote code execution
>   through logging string attacks such as [CVE-2021-44228].
> 
> Perhaps:
>   This would avoid remote code execution
>   through logging string attacks, such as the vulnerability desribed in [CVE-2021-44228].

Better.

> 
> Or:
>   This would avoid remote code execution
>   through logging string attacks, such as the scenario desribed in [CVE-2021-44228].
> -->

No, I like "vulnerability" over "scenario". 

> 
> 
> 18) <!-- [rfced] FYI - RFC 8499 has been obsoleted by RFC 9499. We have updated
> instances of 8499 to 9499. Please review and let us know any objections.
> -->

Perfect, thanks!

> 19) <!-- [rfced] FYI - We see a date of November 26, 2021 in the URL for this
> reference. We have updated accordingly. Please let us know any concerns.

Perfect, thanks!

> 
> Original:
>   [CVE-2021-44228]
>              Common Vulnerabilities and Exposures, "CVE-2021-44228", 10
>              December 2021, <https://urldefense.com/v3/__https://cve.mitre.org/cgi-bin/__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTjEb54f0$ [cve[.]mitre[.]org]
>              cvename.cgi?name=CVE-2021-44228>.
>      
> Updated:
>   [CVE-2021-44228]
>              CVE, "CVE-2021-44228", 
>              26 November 2021, <https://urldefense.com/v3/__https://cve.mitre.org/cgi-bin/__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTjEb54f0$ [cve[.]mitre[.]org]
>              cvename.cgi?name=CVE-2021-44228>.
> -->

Yes, better.

> 
> 
> 20) <!-- [rfced] Terminology
> 
> a) We note inconsistencies in the terms below throughout the text. Should
> these be uniform? If so, please let us know which form is preferred.
> 
> "a01.agent-domain.example." vs. a01.agent-domain.example

All 3 occurances should be in quotes. I think I missed the last one,
 	
> 
> "broken.test." vs. "broken.test"

It should all be "broken.test."

> b) We see one instance of "report query QNAME". Should this be updated to "QNAME
> of the report query" (or similar)?

> 
> Original:
>   If the report query QNAME exceeds 255 octets, it MUST NOT be sent.
> 
> Perhaps:
>   If the QNAME of the report query exceeds 255 octets, it MUST NOT be sent.

Yes, better.

> 
> 
> c) FYI - We made the following update for consistency with other usage in the
> document and in RFC 8914.
> 
> extended error > extended DNS error

Ok!

> d) Should any instances of "extended DNS error" be updated to "extended DNS
> error code" (with "code")? For example:
> 
> Original:
>   *  The extended DNS error, presented as a decimal value, in a single
>      DNS label.
> 
> Perhaps:
>   *  The extended DNS error code, presented as a decimal value, in a single
>      DNS label.

Yes please.

> e) This document uses "COOKIE". In RFC 7873, we see both "Cookie" and "COOKIE
> option". Please review and let us know if any updates are needed.
> 
> Original:
>   For the benefit of the monitoring agent to get more confidence that
>   the report is not spoofed, the reporting resolver SHOULD send error
>   reports over TCP [RFC7766] or other connection oriented protocols or
>   SHOULD use DNS COOKIEs [RFC7873].
>   ...
>   The monitoring agent SHOULD respond to queries received over UDP that
>   have no DNS COOKIE set with a response that has the truncation bit
>   (TC bit) set to challenge the resolver to re-query over TCP.
>   ...
>   Resolvers that send error reports SHOULD send these over TCP
>   [RFC7766] or SHOULD use DNS COOKIEs [RFC7873].
>   ...
>   The monitoring agent SHOULD respond to
>   queries received over UDP that have no DNS COOKIE set with a response
>   that has the truncation bit (TC bit) set to challenge the resolver to
>   re-query over TCP.
> -->

Good catch. They chould all be Cookie or Cookies instead of COOKIE or COOKIEs.

Thanks!.

> 
> 21) <!-- [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!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqToglVfiI$ [rfc-editor[.]org]>
> and let us know if any changes are needed.
> 
> Note that our script did not flag any words in particular, but this should 
> still be reviewed as a best practice.
> -->

Reviewed. I did not find any issue.

Thanks,

Let me know if you need more!


Warmly,

Roy


> 
> 
> Thank you.
> 
> RFC Editor/rv
> 
> 
> 
> On Apr 9, 2024, at 3:09 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2024/04/09
> 
> 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/__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTx1TghJA$ [rfc-editor[.]org]).
> 
> 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/__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqT2x05NoU$ [trustee[.]ietf[.]org]).
> 
> *  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__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTlZlhosc$ [authors[.]ietf[.]org]>.
> 
> *  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
> 
>  *  [e-mail] (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).
> 
>  *  [e-mail], 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__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTn_2b_Bk$ [mailarchive[.]ietf[.]org]
> 
>    *  The archive itself:
>       https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTQFKKM0g$ [mailarchive[.]ietf[.]org]
> 
>    *  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, 
>       [e-mail] 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/rfc9567.xml__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTHvkVMS4$ [rfc-editor[.]org]
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567.html__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTftz9L-M$ [rfc-editor[.]org]
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567.pdf__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTtv1T580$ [rfc-editor[.]org]
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567.txt__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTX5a4f48$ [rfc-editor[.]org]
> 
> Diff file of the text:
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567-diff.html__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTgDp1dYs$ [rfc-editor[.]org]
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567-rfcdiff.html__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTZTEN2y4$ [rfc-editor[.]org] (side by side)
> 
> Alt-diff of the text (allows you to more easily view changes 
> where text has been deleted or moved): 
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567-alt-diff.html__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTCjMRGko$ [rfc-editor[.]org]
> 
> Diff of the XML: 
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567-xmldiff1.html__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTYFP0lts$ [rfc-editor[.]org]
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.  
> 
> Initial XMLv3 created using XMLv2 as input:
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567.original.v2v3.xml__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTTH_dm8A$ [rfc-editor[.]org] 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567.form.xml__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqTDZp1s6I$ [rfc-editor[.]org]
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9567__;!!PtGJab4!9rpkOfp9uereWBsjeLnnTnVlFkNUzjc5xJpyf4C1jifFWOidwJ5rPqYyZc0_Z5tXsMsnoDaZk-LrxWClfuelFGqT0p1igaE$ [rfc-editor[.]org]
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9567 (draft-ietf-dnsop-dns-error-reporting-08)
> 
> Title            : DNS Error Reporting
> Author(s)        : R. Arends, M. Larson
> WG Chair(s)      : Suzanne Woolf, Benno Overeinder, Tim Wicinski
> 
> Area Director(s) : Warren Kumari, Mahesh Jethanandani