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

[Warren Kumari <[e-mail]>]

On Mon, Apr 15, 2024 at 7:01 AM, Rebecca VanRheenen <[e-mail]>
wrote:

> Hi Roy, Matt, and Warren*,
>
> Roy and Matt - We have updated the document per Roy’s responses to our
> followup questions. All of our questions have now been addressed. Please
> review the document carefully to ensure satisfaction as we do not make
> changes once it has been published as an RFC. Contact us with any further
> updates or with your approval of the document in its current form. We will
> await approvals from each author prior to moving forward in the publication
> process.
>
> *Warren, as AD, please review and approve the change in the last paragraph
> in Section 6.1.1. This change Is best viewed in this diff file: https://
> www.rfc-editor.org/authors/rfc9567-auth48diff.html.
>

<voice="American Political Advert">
My name is Warren Kumari, Operations AD, and I approve of this change.
</voice>

While looking at this, I read Sec 6.1, and have a small editorial
suggestion:
O: "Care should be taken when more DNS resolving is needed to resolve
the QNAME that contains the error report.  This resolving itself could
trigger another error reporting to be created."
P: "Care should be taken when additional DNS resolution is needed to
resolve the QNAME that contains the error report.  This resolution itself
could trigger another error reporting to be created."
C: 2 proposed changes — 1: s/more/additional/  2: s/resolving/resolution/

Please note: This is just a suggestion — feel free to incorporate it or
ignore it, I don't really care. Also, no need to reply either way.

Thanks,
W



> FILES (please refresh):
>
> Updated XML file:
> https://www.rfc-editor.org/authors/rfc9567.xml
>
> Updated output files:
> https://www.rfc-editor.org/authors/rfc9567.txt
> https://www.rfc-editor.org/authors/rfc9567.pdf
> https://www.rfc-editor.org/authors/rfc9567.html
>
> Diff file showing all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9567-auth48diff.html
>
> Diff files showing all changes:
> https://www.rfc-editor.org/authors/rfc9567-diff.html https://www.
> rfc-editor.org/authors/rfc9567-rfcdiff.html (side-by-side diff) https://
> www.rfc-editor.org/authors/rfc9567-alt-diff.html (diff showing changes
> where text is moved or deleted)
>
> For the AUTH48 status of this document, please see: https://www.
> rfc-editor.org/auth48/rfc9567
>
> Thank you,
> RFC Editor/rv
>
> On Apr 11, 2024, at 2:13 PM, Roy Arends <[e-mail]> wrote:
>
> Hi Rebecca,
>
> On 10 Apr 2024, at 22:16, Rebecca VanRheenen <[e-mail]>
> wrote:
>
> Hi Roy,
>
> Thank you for the quick reply! We have updated the document accordingly
> (see list of files below).
>
> Thanks for that.
>
> We have a few followup questions:
>
> 1)
>
> 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.
>
> We updated the sentence above as you suggest. Are any further updates
> needed? The following sentences in Section 4.1 use either “type A” or “type
> 1” (the updated sentence is included). The sentences are listed in the
> order in which they appear in the text.
>
> Current:
> A query for "broken.test.", type A, is sent by a reporting resolver.
> ...
> 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.
> ...
> This QNAME indicates extended DNS error 7 occurred while trying to
> validate "broken.test." for a type 1 record.
>
> That neads to be:
>
> for a type A (an RR type with value 1) record.
>
> ...
> When this query is received at the monitoring agent (the operators of the
> authoritative server for "a01.agent-domain.example."), the agent can
> determine the "test." zone contained an expired signature record
> (extended DNS error 7) for type A for the domain name "broken.test.".
>
> 2)
>
> 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.
>
> We updated as you indicate above. Should the second sentence
> (specifically, "another error reporting to be created”) also be updated?
>
> Original:
> This resolving itself could trigger another error reporting to be created.
>
> Perhaps:
> This resolving itself could trigger another error report to be created.
>
> This is better, thanks.
>
> Or:
> This resolving itself could trigger creation of additional error
> reporting.
>
> 3)
>
> 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,
>
> We also added the ending period to the one instance that did not have
> quotes (last paragraph of Section 4.1). Now, all instances appear as:
>
> "a01.agent-domain.example.”
>
> Ack. Happy with that.
>
> Thanks Rebecca!
>
> Warmly,
>
> Roy
>
> FILES (please refresh):
>
> Updated XML file:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567.
> xml__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFY6poLhLA$
> [rfc-editor[.]org]
>
> Updated output files:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9567.
> txt__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFYaebwa4Q$
> [rfc-editor[.]org] https://urldefense.com/v3/__https://www.rfc-editor.org/
> authors/rfc9567.
> pdf__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFbsgSg1eQ$
> [rfc-editor[.]org] https://urldefense.com/v3/__https://www.rfc-editor.org/
> authors/rfc9567.
> html__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFa5831sew$
> [rfc-editor[.]org]
>
> Diff file showing all changes made during AUTH48:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/
> rfc9567-auth48diff.
> html__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFb48-XDYg$
> [rfc-editor[.]org]
>
> Diff files showing all changes:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/
> rfc9567-diff.
> html__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFYuTJoC0Q$
> [rfc-editor[.]org] https://urldefense.com/v3/__https://www.rfc-editor.org/
> authors/rfc9567-rfcdiff.
> html__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFYMkq6Aow$
> [rfc-editor[.]org] (side-by-side diff) https://urldefense.com/v3/__https:/
> /www.rfc-editor.org/authors/rfc9567-alt-diff.
> html__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFZzMHrPiw$
> [rfc-editor[.]org] (diff showing changes where text is moved or deleted)
>
> For the AUTH48 status of this document, please see: https://urldefense.
> com/v3/__https://www.rfc-editor.org/auth48/
> rfc9567__;!!PtGJab4!4qAbtBH8ZybPlMqq5TsPKXNhCqu2WrVLDcR29JeMcazEQBB_DSPSihXcIEwEKqZsR7ABnh6NB6AokUkTRFY18JGWeg$
> [rfc-editor[.]org]
>
> Thank you,
> RFC Editor/rv
>
> On Apr 10, 2024, at 5:09 AM, Roy Arends <[e-mail]> wrote:
>
> 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
>
>