Operational Implications of IPv6 Packets with Extension Headers
draft-ietf-v6ops-ipv6-ehs-packet-drops-08

Received changes through RFC Editor sync (created alias RFC 9098, changed abstract to 'This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.', changed pages to 17, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-09-15, changed IESG state to RFC Published)

[Ballot comment]
Thanks for an easy read on an interesting topic.

I presume the sponsoring AD has affirmed that exceeding the recommended author limit is appropriate here.

[Ballot comment]
** Section 1.
However, common implementation limitations suggest
  that EHs present a challenge for IPv6 packet routing equipment and
  middle-boxes, and evidence exists that IPv6 packets with EHs are
  intentionally dropped in the public Internet in some network
  deployments.

Can you clarify a “common implementation limitations” -- is that the same as saying vendors aren’t supporting EHs?

** Section 4.  Are there more updated references for the trends identified in[PMTUD-Blackholes], [Linkova-Gont-IEPG90] and [RFC7892] as the freshest of these is 6 year old data?

** Sections 6.1 and 6.2 don’t have clear text like Section 6.4 and 6.5 that explains how layer-4 inspections leads to dropped packets.

** Section 6.4
Use of extension headers can be problematic for NIDS/IPS, since:

  o  Extension headers increase the complexity of resulting traffic,
      and the associated work and system requirements to process it.

  o  Use of unknown extension headers can prevent an NIDS/IPS from
      processing layer-4 information.

  o  Use of IPv6 fragmentation requires a stateful fragment-reassembly
      operation, even for decoy traffic employing forged source
      addresses (see e.g., [nmap]).

-- Per (1), this seems analogous to the argumentation in Section 5 but in that section there were details around the limitation of hardware support.  Is there an analogous reference here?  That is, asserting that computation requirements to process EH is a significant additional load?

-- How is the core issue of (3) different than handling fragments in IPv4 (i.e., operators dropping them at the border and NIPS/NIDS also have to reassembly them to avoid evasion)?

** Section 6.5.  Thanks for including the reference to [Zack-FW-Benchmark].  Due to the age of the benchmark, another sentence explaining how 2013-era firewalls are still quite similar to those used now would be helpful

[Ballot comment]
Thank you for the work put into this document. The authors know my deep interest in this kind of work on the IPv6 extensibility.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit.

Special thanks to Loganaden Velvindron and Tim Winters for the IoT/INT directorates reviews:
https://datatracker.ietf.org/doc/review-ietf-v6ops-ipv6-ehs-packet-drops-06-iotdir-telechat-velvindron-2021-04-19/
https://datatracker.ietf.org/doc/review-ietf-v6ops-ipv6-ehs-packet-drops-06-intdir-telechat-winters-2021-04-20/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment: does the word "carrier-grade router" represent the 'core' and/or 'edge' routers ?

-- Section 1 --
  "evidence exists that IPv6 packets with EHs are
  intentionally dropped in the public Internet in some network
  deployments."
The above strong assertion is really generic... Did the authors check about "intentionally" (by the network operator) ? I also fail to understand the mix of "public Internet", which is global, and "in some network deployments", which is quite specific. Should there be a comma ? Or is it about my generic question on whether it is edge / core ?

Also, a fresh reference to "evidence" would be welcome.

In the set of goal, is it on purpose that both bullets 1 and 3 are about "operational ... implications " and "operational issues" ? Should those bullet be merged ?

-- Section 4 --
It appears to me that "Some of the operational implications of IPv6 Extension Headers " is also about security implications.

Does RFC 7112 still apply for RFC 8200 ? As the first fragment MUST contain all header up-to and including the upper-layer one? (in this case the ICMPv6). So, this reference should perhaps be in the second list ?

-- Section 5 --
BTW, I think that NPU have no real problem to parse deep in the EH chain (except for some performance hit) as opposed to ASIC/TCAM/... Please also note that many high speed routers are now VMs with normal generic processors in a data center (of course not in the public Internet).

Please add a reference to the NOTE.

-- Section 5.1 --
Can you add a reference to routers doing recirculation ? Honestly, I have never heard of this for EH parsing. Now, let's hope that this is not my employer ;-)

-- Section 6 --
I like the term "intermediate system" to represent router and middle box. May I suggest to use this term from the beginning of the document through the end and introduce it in the terminology?

-- Section 6.2 --
Suggest to reword "Infrastructure ACLs (iACLs) drop unwanted packets destined to a network's infrastructure IP addresses" since the rest of the section is not limited to 'IP addresses'.

Should "management plane" be added to "against router control planes" ?

-- Sections 6.4 and 6.5 --
If NIDS/NIPS/firewalls are unable to understand EH chain, then they have no excuse and simply are buggy or unfit for their job. Is there a need to cite this kind of buggy devices in an IETF document ?

-- Section 7.2 --
Please add a reference to the statement "many operators currently drop IPv6 packets containing this extension header"

-- Section 7.3 --
Any reason why this section is only about "router" and not the usual "router and middle boxes" or even "intermediate systems".

-- Section 7.4 --
Please consider to promote sub-section 7.4 to its own section or at least add "security" to the section 7 title.

The text repeats some elements, which were previously discussed. Please consider trimming the text :-)

The penultieme paragraph appears to present some 2013 references as fairly recent. Please consider removing this part.

-- Section 10 --
The authors know me deep interest in getting fresh measurements, so, I am puzzled by
  "thank Jan Zorz / Go6 Lab
  , Jared Mauch, and Sander Steffann
  , for providing access to systems and networks
  that were employed to perform experiments and measurements involving
  packets with IPv6 Extension Headers."
 
as there is no indication in this document whether those measurements are fresh and interesting when compared to RFC 7872 ? If so, is there a plan to make them public 

== NITS ==

-- Section 5 --
Please expand "NPU" and "CAM" at first use.

-- Section 6.1 --
"ECMP (equal cost multi path) load sharing", the usual way it to use "balancing" rather than sharing ? Also, please use the usual way "equal cost multi-path (ECMP)"

[Ballot comment]
[[ comments ]]

[ section 7.1 ]

* It seems to me that this also applies to IP fragments of any family,
  particularly if the first fragment is delayed or lost.

  I can't tell from the text whether handling fragments (even in IPv4)
  is considered "process[ing] the packet outside the normal forwarding path"
  or not.


[[ nits ]]

[ section 3 ]

* s/IPv6 IPv6/IPv6/?

[ section 6.1 ]

* "the router on the sending side of the link needs to..."?

  This phrasing seems a little odd to me.  How about just
  "the (or a) forwarding router needs to...", since the rest of the sentence
  does make the described situation clear?

[Ballot comment]
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

These reference issues exist in the document:
* Obsolete reference to RFC2460, obsoleted by RFC8200
* Obsolete reference to RFC5575, obsoleted by RFC8955

These URLs in the document did not return content:
* https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis-Attacking_IPv6-Slides.pdf

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

The IANA Functions Operator has reviewed draft-ietf-v6ops-ipv6-ehs-packet-drops-05, 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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-v6ops-ipv6-ehs-packet-drops@ietf.org, rbonica@juniper.net, rwilton@cisco.com, v6ops-chairs@ietf.org, v6ops@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Operational Implications of IPv6 Packets with Extension Headers) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Operational Implications of IPv6 Packets
with Extension Headers'
  as Informational RFC

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 2021-02-25. 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


  This document summarizes the operational implications of IPv6
  extension headers specified in the IPv6 protocol specification
  (RFC8200), and attempts to analyze reasons why packets with IPv6
  extension headers are often dropped in the public Internet.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/



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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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?

INFORMATIONAL. Neither BCP nor Standards track are required because this draft does not define bits-on-the-wire and does not use RFC 2119 language.

(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:

This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.

Working Group Summary:

This document was reviewed by at least 12 WG participants.

Document Quality:

The document reviews existing work and makes a few statement about current practice. These statements are easily verifiable.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ron Bonica is the document shepherd.

Rob Wilton

(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 have read and commented on the draft. IMO, it is ready for publication

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

The responsible AD may want to request OPSDIR or INTDIR review before the telechat.

(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.

No.

(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.

No

(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?

Yes

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

No

(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?

Consensus was strong.

(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.

The following NITS were found:

- Weird spacing in a figure (This can be fixed by the RFC editor)
- An intentional reference to an obsolete draft [RFC 2460]  (This doesn't need to be fixed)
- An unintentional reference to an obsolete draft [RFC 5575] (This can be fixed by the RFC editor)

(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

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

No

(16) Will publication of this document change the status of any existing RFCs?

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

There are no IANA registries within this document.  The RFC-Editor can remove this section before publication of this document as an RFC.

(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.

No

(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.

None

(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?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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?

INFORMATIONAL. Neither BCP nor Standards track are required because this draft does not define bits-on-the-wire and does not use RFC 2119 language.

(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:

This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.

Working Group Summary:

This document was reviewed by at least 12 WG participants.

Document Quality:

The document reviews existing work and makes a few statement about current practice. These statements are easily verifiable.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ron Bonica is the document shepherd.

It is not clear who the responsible AD will be. Normally, it would be Warren Kumari, but he is a co-author.

(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 have read and commented on the draft. IMO, it is ready for publication

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

The responsible AD may want to request OPSDIR or INTDIR review before the telechat.

(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.

No.

(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.

No

(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?

Yes

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

No

(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?

Consensus was strong.

(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.

The following NITS were found:

- Weird spacing in a figure (This can be fixed by the RFC editor)
- An intentional reference to an obsolete draft [RFC 2460]  (This doesn't need to be fixed)
- An unintentional reference to an obsolete draft [RFC 5575] (This can be fixed by the RFC editor)

(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

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

No

(16) Will publication of this document change the status of any existing RFCs?

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

There are no IANA registries within this document.  The RFC-Editor can remove this section before publication of this document as an RFC.

(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.

No

(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.

None

(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?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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?

INFORMATIONAL. Neither BCP nor Standards track are required because this draft does not define bits-on-the-wire and does not use RFC 2119 language.

(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:

This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.

Working Group Summary:

This document was reviewed by at least 12 WG participants.

Document Quality:

The document reviews existing work and makes a few statement about current practice. These statements are easily verifiable.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ron Bonica is the document shepherd.

It is not clear who the responsible AD will be. Normally, it would be Warren Kumari, but he is a co-author.

(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 have read and commented on the draft. IMO, it is ready for publication

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

The responsible AD may want to request OPSDIR or INTDIR review before the telechat.

(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.

No.

(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.

No

(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?

Yes

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

No

(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?

Consensus was strong.

(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.

The following NITS were found:

- Weird spacing in a figure (This can be fixed by the RFC editor)
- An intentional reference to an obsolete draft [RFC 2460]  (This doesn't need to be fixed)
- An unintentional reference to an obsolete draft [RFC 5575] (This can be fixed by the RFC editor)

(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

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

No

(16) Will publication of this document change the status of any existing RFCs?

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

There are no IANA registries within this document.  The RFC-Editor can remove this section before publication of this document as an RFC.

(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.

No

(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.

None

(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?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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?

INFORMATIONAL. Neither BCP nor Standards track are required because this draft does not define bits-on-the-wire and does not use RFC 2119 language.

(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:

This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.

Working Group Summary:

This document was reviewed by at least 12 WG participants.

Document Quality:

The document reviews existing work and makes a few statement about current practice. These statements are easily verifiable.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ron Bonica is the document shepherd.

It is not clear who the responsible AD will be. Normally, it would be Warren Kumari, but he is a co-author.

(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 have read and commented on the draft. IMO, it is ready for publication

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

The responsible AD may want to request OPSDIR or INTDIR review before the telechat.

(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.

No.

(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.

No

(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?

TBD

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

No

(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?

Consensus was strong.

(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.

The following NITS were found:

- Weird spacing in a figure (This can be fixed by the RFC editor)
- An intentional reference to an obsolete draft [RFC 2460]  (This doesn't need to be fixed)
- An unintentional reference to an obsolete draft [RFC 5575] (This can be fixed by the RFC editor)

(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

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

No

(16) Will publication of this document change the status of any existing RFCs?

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

There are no IANA registries within this document.  The RFC-Editor can remove this section before publication of this document as an RFC.

(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.

No

(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.

None

(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?

NA

Request for posting confirmation emailed  to submitter and authors: Fernando Gont , Will LIU , Geoff Huston , Gert Doering , Warren Kumari , Nick Hilliard