Negative Caching of DNS Resolution Failures
draft-ietf-dnsop-caching-resolution-failures-08

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dnsop-caching-resolution-failures and RFC 9520, changed IESG state to RFC Published)

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-caching-resolution-failures-07

Thank you for the work put into this document. It should indeed be VERY useful !

Please find belowsome non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Andrew McConachie for the shepherd's write-up *but it lacks* the justification of the intended status.

Other thanks to Carlos Pignataro , the Internet directorate reviewer, please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dnsop-caching-resolution-failures-07-intdir-telechat-pignataro-2023-09-06/ (I have read Duane's reply, thanks)

Other thanks to Peter van Dijk, the DNS directorate reviewer, please consider this dns-dir review (as a follow-up of his Last Call review):
https://datatracker.ietf.org/doc/review-ietf-dnsop-caching-resolution-failures-07-dnsdir-telechat-van-dijk-2023-09-04/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Abstract

`RFC 2308 specifies requirements for DNS negative caching` should this statement only apply to (2) responses and not (1) responses (as this would be positive caching) ?

## Section 2.2 (and other places)

Is there a reason why EXAMPLE.COM is in uppercase in the text ? This is really unusual.

Please follow RFC 5952 and write IPv6 address is lower case (BTW thanks for using modern addressing)

[Ballot comment]
Thanks for working on this specification. My review does yield any TSV related issues.

I have following minor comments that I believe will improve the document quality when addressed -

  # While this specification updates RFC2308, RFC4038 and RFC4697, the Introduction section only mentions RFC2308. Would be good to give emphasis on all the updates.

  # Regarding Motivation section, I like the motivation section up front and understanding of the problem to solve before going into solution description. So I would like to keep this section where it is.

  # Section 2 says -

        If any one of the available servers provides a useful response, then it is not considered a resolution failure.

    with that I am not sure why responses in section 2.1 and 2.2 are qualified as useful responses. Please add some clarification texts in those sections.

[Ballot comment]
Thank you for the work on this document.

Many thanks to Barry Leiba for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/BjJLwKrE6OU3wpXDUbe6rq8288w/, and to the authors for addressing it.

[Ballot comment]
Thanks to Barry Leiba for his ARTART review.

I think the SHOULD in Section 3.2, paragraph 2, is not appropriate use of SHOULD as it doesn't address interoperability or operations or security recommendations.  A regular "should" is fine.

Apart from that, this looks like it's in good shape.

[Ballot comment]
Thanks for this document and my apologies for being involved/related to two
of the five outages you described :-)


        Consistent with [RFC2308], resolution failures MUST NOT be cached
        for longer than 5 minutes.

If an expired RRSIG has a TTL of 3600, what should happen? The resolution
failed because the signature is no longer valid but the individual
components of this validation failure are all successful lookups of RRs that
are now in the cache.  Wouldn't this result in a resolution failure of
3600? How would an implementation limit this to 5 minutes? By deleting
the RRSIG from its cache within 5 minutes, overriding its TTL?

If so, is there value stating this in the document?


        also known as 'lame'

I thought the WG agreed the definition of 'lame' was not agreed upon and
the term is no longer being favoured for use. Why not just remove this part?

        To prevent such unnecessary DNS traffic, security-aware resolvers
        MUST cache DNSSEC validation failures, with some restrictions.

What are these "some restrictions" ?

[Ballot comment]
Hi,

Thanks for working on this document - I'm not a DNS expert but it looks like good advice.

A couple of minor comments for your consideration:

(1) p 2, sec 1.  Introduction

  This document updates [RFC2308] to require negative caching of DNS
  resolution failures and provides additional examples of resolution
  failures.

Perhaps "caching of all DNS resolution failures"?


(2) p 2, sec 1.1.  Motivation

  RFC Editor: We'd like your thoughts on moving the Motivation and
  Related Work sections to appendices.  Is that a preferred style?

Not the RFC editor, but I would keep the motivation here, as a subsection of the introduction.

Regards,
Rob

[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-caching-resolution-failures-07
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1.2

* "only exacerbated" -> "further exacerbated"?

  Use of "only" here might be misread.

### S2.2

* s/2001:DB8:1::/2001:db8:1::/g

  in accordance with RFC 5952 section 4.3

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-caching-resolution-failures-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-08-17):

From: The IESG
To: IETF-Announce
CC: andrew@depht.com, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-caching-resolution-failures@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Negative Caching of DNS Resolution Failures) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Negative Caching of DNS
Resolution Failures'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-08-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In the DNS, resolvers employ caching to reduce both latency for end
  users and load on authoritative name servers.  The process of
  resolution may result in one of three types of responses: (1) a
  response containing the requested data; (2) a response indicating the
  requested data does not exist; or (3) a non-response due to a
  resolution failure in which the resolver does not receive any useful
  information regarding the data's existence.  This document concerns
  itself only with the third type.

  RFC 2308 specifies requirements for DNS negative caching.  There,
  caching of type (1) and (2) responses is mandatory and caching of
  type (3) responses is optional.  This document updates RFC 2308 to
  require negative caching for DNS resolution failures.

  RFC 4035 allows DNSSEC validation failure caching.  This document
  updates RFC 4035 to require caching for DNSSEC validation failures.

  RFC 4697 prohibits aggressive requerying for NS records at a failed
  zone's parent zone.  This document updates RFC 4697 to expand this
  requirement to all query types and to all ancestor zones.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards Track / Proposed Standard
It meets the requirements of a Proposed Standard described in RFC 7127 (Section 3.1).
Yes, it is indicated properly on the title page header.

 
(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
 
Technical Summary:
In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data; (2) a response indicating the requested data does not exist; or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.

Working Group Summary:
  This document proceeded through the WG without too much discussion. Where there has been discussion it has been mostly positive, and when it has not been positive the authors have modified the document in response. The document addresses a short coming of the DNS standard by clarifying resolver behavior for a specific set of resolution failures. It does not modify the DNS protocol or provide any new functionality. Resolver software might have been doing this already, but this document provides a proscribed method for handling these cases.
 
Document Quality:
  The document is of high quality and describes the requisite behavior succinctly. Both authoritative network operators and developers of DNS software offered their comments on list and the document authors incorporated their comments.

Personnel:
  Andrew McConachie is the Document Shepherd.
  Warren Kumari is the Responsible Area Director.
  Peter van Dijk is the reviewer from the DNS Directorate.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I read the review by Peter van Dijk and read all messages sent to the list on this document. I also read versions 3,4,5 of the document.

 
(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.

 
(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Peter van Dijk's review from the DNS Directorate is Completed. His review is on v3 and the document is currently at v5. Thus, his conclusion that the document is Almost Ready is possibly out of date.
https://datatracker.ietf.org/doc/review-ietf-dnsop-caching-resolution-failures-03-dnsdir-lc-van-dijk-2023-06-26/

 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
There has not been much discussion on this document on the list. However, what discussion there has been has been overwhelmingly positive and in cases where the reception has not been positive the authors have adjusted their text in response. 

 
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

No IPR

 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR
 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Very little discussion was seen on list. What was seen on list was overwhelmingly in favor of publication, but there was limited conversation. The authors responded quickly to Joe Abley's recent concerns and addressed them in version 5.

 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
I have no nits with this document.

 
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

 
(13) Have all references within this document been identified as either normative or informative?
Yes.

 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No normative references exist to unpublished RFCs or other documents in an unclear state.

 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are no downward normative references.

 
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
This I-D updates RFC 2308, RFC 4035, and RFC 4697.
RFC 2308 is mentioned in the abstract, the introduction, and it is clear what is being updated about it.
RFC 4035 is not mentioned in the abstract or the introduction, and it is not clear what is being updated about it.
RFC 4697 is not mentioned in the abstract, it is mentioned in the introduction, and it is clear what is being updated about it.

 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
N/A

 
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

 
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards Track / Proposed Standard
It meets the requirements of a Proposed Standard described in RFC 7127 (Section 3.1).
Yes, it is indicated properly on the title page header.

 
(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
 
Technical Summary:
In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data; (2) a response indicating the requested data does not exist; or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.

Working Group Summary:
  This document proceeded through the WG without too much discussion. Where there has been discussion it has been mostly positive, and when it has not been positive the authors have modified the document in response. The document addresses a short coming of the DNS standard by clarifying resolver behavior for a specific set of resolution failures. It does not modify the DNS protocol or provide any new functionality. Resolver software might have been doing this already, but this document provides a proscribed method for handling these cases.
 
Document Quality:
  The document is of high quality and describes the requisite behavior succinctly. Both authoritative network operators and developers of DNS software offered their comments on list and the document authors incorporated their comments.

Personnel:
  Andrew McConachie is the Document Shepherd.
  Warren Kumari is the Responsible Area Director.
  Peter van Dijk is the reviewer from the DNS Directorate.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I read the review by Peter van Dijk and read all messages sent to the list on this document. I also read versions 3,4,5 of the document.

 
(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.

 
(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Peter van Dijk's review from the DNS Directorate is Completed. His review is on v3 and the document is currently at v5. Thus, his conclusion that the document is Almost Ready is possibly out of date.
https://datatracker.ietf.org/doc/review-ietf-dnsop-caching-resolution-failures-03-dnsdir-lc-van-dijk-2023-06-26/

 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
There has not been much discussion on this document on the list. However, what discussion there has been has been overwhelmingly positive and in cases where the reception has not been positive the authors have adjusted their text in response. 

 
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

No IPR

 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR
 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Very little discussion was seen on list. What was seen on list was overwhelmingly in favor of publication, but there was limited conversation. The authors responded quickly to Joe Abley's recent concerns and addressed them in version 5.

 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
I have no nits with this document.

 
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

 
(13) Have all references within this document been identified as either normative or informative?
Yes.

 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No normative references exist to unpublished RFCs or other documents in an unclear state.

 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are no downward normative references.

 
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
This I-D updates RFC 2308, RFC 4035, and RFC 4697.
RFC 2308 is mentioned in the abstract, the introduction, and it is clear what is being updated about it.
RFC 4035 is not mentioned in the abstract or the introduction, and it is not clear what is being updated about it.
RFC 4697 is not mentioned in the abstract, it is mentioned in the introduction, and it is clear what is being updated about it.

 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
N/A

 
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

 
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards Track / Proposed Standard
It meets the requirements of a Proposed Standard described in RFC 7127 (Section 3.1).
Yes, it is indicated properly on the title page header.

 
(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
 
Technical Summary:
In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data; (2) a response indicating the requested data does not exist; or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.

Working Group Summary:
  This document proceeded through the WG without too much discussion. Where there has been discussion it has been mostly positive, and when it has not been positive the authors have modified the document in response. The document addresses a short coming of the DNS standard by clarifying resolver behavior for a specific set of resolution failures. It does not modify the DNS protocol or provide any new functionality. Resolver software might have been doing this already, but this document provides a proscribed method for handling these cases.
 
Document Quality:
  The document is of high quality and describes the requisite behavior succinctly. Both authoritative network operators and developers of DNS software offered their comments on list and the document authors incorporated their comments.

Personnel:
  Andrew McConachie is the Document Shepherd.
  Warren Kumari is the Responsible Area Director.
  Peter van Dijk is the reviewer from the DNS Directorate.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I read the review by Peter van Dijk and read all messages sent to the list on this document. I also read versions 3,4,5 of the document.

 
(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.

 
(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Peter van Dijk's review from the DNS Directorate is Completed. His review is on v3 and the document is currently at v5. Thus, his conclusion that the document is Almost Ready is possibly out of date.
https://datatracker.ietf.org/doc/review-ietf-dnsop-caching-resolution-failures-03-dnsdir-lc-van-dijk-2023-06-26/

 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
There has not been much discussion on this document on the list. However, what discussion there has been has been overwhelmingly positive and in cases where the reception has not been positive the authors have adjusted their text in response. 

 
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
How to find this out?

 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
How to find this out?

 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Very little discussion was seen on list. What was seen on list was overwhelmingly in favor of publication, but there was limited conversation. The authors responded quickly to Joe Abley's recent concerns and addressed them in version 5.

 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
I have no nits with this document.

 
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

 
(13) Have all references within this document been identified as either normative or informative?
Yes.

 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No normative references exist to unpublished RFCs or other documents in an unclear state.

 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are no downward normative references.

 
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
This I-D updates RFC 2308, RFC 4035, and RFC 4697.
RFC 2308 is mentioned in the abstract, the introduction, and it is clear what is being updated about it.
RFC 4035 is not mentioned in the abstract or the introduction, and it is not clear what is being updated about it.
RFC 4697 is not mentioned in the abstract, it is mentioned in the introduction, and it is clear what is being updated about it.

 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
N/A

 
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

 
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A