DHCPv6 Prefix Delegating Relay Requirements
draft-ietf-dhc-dhcpv6-pd-relay-requirements-05

[Ballot comment]
I support Ben and Erik's question as to the category of this document.  It isn't immediately obvious to me why this is standard track and perhaps BCP or Informational might be a better classification.

[Ballot comment]
I support Ben's and Erik's question as to the standard of this document.  It isn't immediately obvious to me why this is standard track and perhaps BCP or Informational might be a better classification.

[Ballot comment]
[[ questions ]]

[ general ]

* Should this aim for BCP?

[ section 4.2 ]

* Seems like the MUST in R-4 is contingent upon implementation of
  the MAY that precedes it.  It might worth sneaking in some condition
  phrase like, "If such a mechanism is implemented ... MUST ...".

* It seems to me that R-5 would prevent a client from monitoring the
  CMTS/BNG for correctly installed routes by sending it a packet with
  a destination address in its delegated prefix and checking that it gets
  reflected back (similar to other checks done for tunnels).  (I recognize
  this is not guaranteed to work in all environments.)

  What should a client wishing to keep an eye on this stuff do?  Just ping
  a public service with an address in each source prefix of interest?


[[ nits ]]

[ section 2.1 ]

* "This document serves" -> "This document discusses", or
  "This document is concerned with", or something, perhaps?

[Ballot comment]
I was going to suggest that this should “update” 8415, and then I saw Roman’s comment.  So, yes: it really seems that this should update 8415, if, indeed, this adds interoperability requirements to an aspect of what 8415 defines.

[Ballot comment]
Thanks to Christian Huitema for the secdir review and to all for the
ensuing discussion (even though this draft is agreed to not be the right
place to address the topic of securing the DHCP client/DHCP relay
communications).

Thanks for this document; it's good to see this type of functional
requirements get written out clearly.  That said, I'm not sure I
understand why this document is aiming for Proposed Standard status.  It
seems to make normative requirements for DHCPv6 relay behavior, but does
not have an "Updates:" relationship with RFC 8415 to indicate that
additional requirements are present.  On the other hand, there are no
new protocol mechanisms to indicate that it is a protocol that would be
implemented on its own.  Is it intended to play the role of an
Applicability Statement?

Section 1

  The mechanisms for a relay to inject routes (including aggregated
  ones), on its network-facing interface based on prefixes learned from
  a server via DHCP-PD are out of scope of the document.

Just to check my understanding: the context suggests that the
"network-facing interface" here is the one on the DHCPv6 client side of
the relay, vs the server side.  Is that correct?  (Is the
"network-facing" terminology a term of art?)

  Delegating relay A delegating relay acts as an intermediate device,
                    forwarding DHCPv6 messages containing IA_PD/IAPREFIX

(I agree with Murray that clarification is in order here.)

Section 3.4

  It is an operational reality that client devices with duplicate MAC
  addresses and/or DUIDs exist and have been deployed.  In this
  situation, the operational costs of locating and swapping out such
  devices are prohibitive.
  [...]
  It should be noted that in some access networks, the MAC address and/
  or DUID are used as part of device identification and authentication.
  In such networks, enforcing MAC address/DUID uniqueness is a
  necessary function and not considered a problem.

It's not entirely clear to me that these two statements are entirely
consistent with each other -- are the costs prohibitive, or not a
problem?  (Putting a caveat on the first statement that it also only
applies to "some" networks, would resolve the apparent disparity.)

Section 3.5

[that loop sounds pretty nasty; I look forward to seeing how it's
resolved]

Section 4.1

  G-6:    The relay MUST implement a mechanism to limit the maximum
          number of active prefix delegations on a single port for all
          client identifiers and IA_PDs.  This value MUST be
          configurable.

This mechanism is important as a security/anti-DoS mechanism; I hope we
note that somewhere.

  G-8:    The delegating relay MUST update the lease lifetimes based on
          the Client Reply messages it forwards to the client and only
          expire the delegated prefixes when the valid lifetime has
          elapsed.

(The string "Client Reply" does not appear in RFC 8415; I'm not sure why
it's capitalized as if it's a term of art.)

Section 4.2

  R-2:    The delegating relay's routing entry MUST use the same prefix
          length for the delegated prefix as given in the IA_PD.

Could this requirement ever interfere with an aggregation scenario?
(What is it trying to prevent?)

  R-3:    The relay MUST provide a mechanism to dynamically update
          ingress filters permitting ingress traffic sourced from
          client delegated leases and blocking packets from invalid
          source prefixes.  This is to implement anti-spoofing as
          described in [BCP38].  The delegating relay's ingress filter
          entry MUST use the same prefix length for the delegated
          prefix as given in the IA_PD.

Is this imposing a more stringent requirement than BCP38 itself (which,
as far as I can tell, restricts itself to "all providers of Internet
connectivity are urged to implement filtering described in this
document" with no normative requirement.  (To be clear, I'm not opposed
to this trend, just wondering if we should note the change more
prominently.)

Section 4.4

  O-1:    The relay SHOULD implement an interface allowing the operator
          to view the active delegated prefixes.  This SHOULD provide
          information about the delegated lease and client details such
          as client identifier, next-hop address, connected interface,
          and remaining lifetimes.

Is this something that draft-ietf-dhc-dhcpv6-yang would provide (and
thus merit an informative reference)?

Section 7

  This document does not add any new security considerations beyond
  those mentioned in Section 22 of [RFC8213].

Thanks for queuing up the reference fix per the secdir review.
I guess both Section 22 of RFC 8415 and all of RFC 8213 are relevant?
Though perhaps the las paragraph of the section is intended to provide
the needed RFC 8213 reference...

  [RFC8213] describes a method for securing traffic between the relay
  agent and server by sending DHCP messages over an IPsec tunnel.  In
  this case the IPsec tunnel is functionally the server-facing
  interface and DHCPv6 message snooping can be carried out as
  described.  It is RECOMMENDED that this is implemented by the
  delegating relay.

I do not see any reference to message snooping in RFC 8213; please
clearify.

Section 8.2

The discussion at
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
combined with the way in which RFC 4443 is referenced ("An ICMPv6 Type
1, Code 6 (Destination Unreachable, reject route to destination) error
message MAY be sent as per [RFC4443], section 3.1." suggest that RFC
4443 would be more properly classified as a normative reference.

[Ballot comment]
"...error message MAY be sent as per [RFC4443], section 3.1."

"[RFC8213]... It is RECOMMENDED that this is implemented by the delegating relay."


Because of the normative context in which rfc4443/rfc8213 are used, their references should be normative.

[Ballot comment]
In the Abstract the term "memo" is used, but everywhere else it's called a "document".  I suggest updating the Abstract to conform.

In Section 2.1: "... forwarding DHCPv6 messages containing IA_PD/IAPREFIX ..." -- Just to confirm, does that "/" mean "or"?

[Ballot comment]
Thanks to Christian Huitema for the SECDIR review and for the follow-up conversation.

* Please fix the reference noted by the SECDIR review

* Should this document update RFC8415?

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

The IANA Functions Operator has reviewed draft-ietf-dhc-dhcpv6-pd-relay-requirements-04, 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 2020-12-14):

From: The IESG
To: IETF-Announce
CC: volz@cisco.com, dhc-chairs@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org, Bernie Volz , evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DHCPv6 Prefix Delegating Relay Requirements) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'DHCPv6 Prefix Delegating Relay
Requirements'
  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 2020-12-14. 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 memo describes operational problems that are known to occur when
  using DHCPv6 relays with Prefix Delegation.  These problems can
  prevent successful delegation and result in routing failures.  To
  address these problems, this memo provides necessary functional
  requirements for operating DHCPv6 relays with Prefix Delegation.

  It is recommended that any network operator that is using DHCPv6
  prefix delegation with relays should ensure that these requirements
  are followed on their networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/



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.

    This write-up is based on draft-ietf-dhc-dhcpv6-pd-relay-requirements-03.

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

    The RFC requested is Proposed Standard. And, this is appropriate for this
    document as the document is trying to assure proper behavior of  relays
    where DHCPv6 Prefix Delegation is involved.

(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 memo describes operational problems that are known to occur when
  using DHCPv6 relays with Prefix Delegation.  These problems can
  prevent successful delegation and result in routing failures.  To
  address these problems, this memo provides necessary functional
  requirements for operating DHCPv6 relays with Prefix Delegation.

Working Group Summary:

  This document had extensive review for the dhc as well as v6ops (and
  6man) working group or its participants. While a few issues took a bit of
  debate to resolve the best wording in the document, the basic concepts
  has quick consensus.

Document Quality:

  The document has extensive review and is based on some operational
  issues seen (and hopefully mostly resolved) in devices. There are no
  special mention reviews done or needed.

Personnel:

    Bernie Volz is the Document Shepherd, Éric Vyncke is the Responsible
    Area Director.

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

    As document shepherd, I reviewed this document (or updated sections) many
    times to assure that it is following the WG consensus and discussions and is
    of good quality. In my opinion, the document is ready for publication.

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

    No. The document had good review in multiple WGs (primarily in dhc and
    v6ops). There was a lot of good discussion and debate on several issues to
    assure the requirements were correct and clearly communicated.

(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. It had the DHCP and IPv6 review based on the working groups involved
    in reviews and discussions.

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

    I have no concerns or issues with any of the material.

(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, I have received confirmation from each if the 4 authors.

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

    No, there is no IPR filed against this document and hence there was no IPR
    discussion in the WG.

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

    This document has consensus from many, and many that tend to most
    active. There were no indications that anyone disagrees with any of its
    material.

(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 ID nits tool (in verbose mode) did not find any issues. My review of the
    document did not find any issues.

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

    There is no need for any formal review of this kind for this document.

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

    Yes. And, I agree with how the references were categorized.

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

  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.

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

    This document has an IANA considerations section, but it states that
    it makes no requests to IANA - which is correct.

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

    There were none and none are applicable.

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

    It does not contain any YANG module.

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.

    This write-up is based on draft-ietf-dhc-dhcpv6-pd-relay-requirements-03.

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

    The RFC requested is Proposed Standard. And, this is appropriate for this
    document as the document is trying to assure proper behavior of  relays
    where DHCPv6 Prefix Delegation is involved.

(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 memo describes operational problems that are known to occur when
  using DHCPv6 relays with Prefix Delegation.  These problems can
  prevent successful delegation and result in routing failures.  To
  address these problems, this memo provides necessary functional
  requirements for operating DHCPv6 relays with Prefix Delegation.

Working Group Summary:

  This document had extensive review for the dhc as well as v6ops (and
  6man) working group or its participants. While a few issues took a bit of
  debate to resolve the best wording in the document, the basic concepts
  has quick consensus.

Document Quality:

  The document has extensive review and is based on some operational
  issues seen (and hopefully mostly resolved) in devices. There are no
  special mention reviews done or needed.

Personnel:

    Bernie Volz is the Document Shepherd, Éric Vyncke is the Responsible
    Area Director.

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

    As document shepherd, I reviewed this document (or updated sections) many
    times to assure that it is following the WG consensus and discussions and is
    of good quality. In my opinion, the document is ready for publication.

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

    No. The document had good review in multiple WGs (primarily in dhc and
    v6ops). There was a lot of good discussion and debate on several issues to
    assure the requirements were correct and clearly communicated.

(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. It had the DHCP and IPv6 review based on the working groups involved
    in reviews and discussions.

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

    I have no concerns or issues with any of the material.

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

  Almost, I have received confirmation (as of this writing, 11/20/2020) confirmation
  from 3 of the 4 authors; I should receive confirmation from the 4th shortly and
  will update this document when I do.

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

    No, there is no IPR filed against this document and hence there was no IPR
    discussion in the WG.

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

    This document has consensus from many, and many that tend to most
    active. There were no indications that anyone disagrees with any of its
    material.

(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 ID nits tool (in verbose mode) did not find any issues. My review of the
    document did not find any issues.

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

    There is no need for any formal review of this kind for this document.

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

    Yes. And, I agree with how the references were categorized.

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

  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.

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

    This document has an IANA considerations section, but it states that
    it makes no requests to IANA - which is correct.

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

    There were none and none are applicable.

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

    It does not contain any YANG module.

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.

    This write-up is based on draft-ietf-dhc-dhcpv6-pd-relay-requirements-03.

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

    The RFC requested is Proposed Standard. And, this is appropriate for this
    document as the document is trying to assure proper behavior of  relays
    where DHCPv6 Prefix Delegation is involved.

(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 memo describes operational problems that are known to occur when
  using DHCPv6 relays with Prefix Delegation.  These problems can
  prevent successful delegation and result in routing failures.  To
  address these problems, this memo provides necessary functional
  requirements for operating DHCPv6 relays with Prefix Delegation.

Working Group Summary:

  This document had extensive review for the dhc as well as v6ops (and
  6man) working group or its participants. While a few issues took a bit of
  debate to resolve the best wording in the document, the basic concepts
  has quick consensus.

Document Quality:

  The document has extensive review and is based on some operational
  issues seen (and hopefully mostly resolved) in devices. There are no
  special mention reviews done or needed.

Personnel:

    Bernie Volz is the Document Shepherd, Éric Vyncke is the Responsible
    Area Director.

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

    As document shepherd, I reviewed this document (or updated sections) many
    times to assure that it is following the WG consensus and discussions and is
    of good quality. In my opinion, the document is ready for publication.

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

    No. The document had good review in multiple WGs (primarily in dhc and
    v6ops). There was a lot of good discussion and debate on several issues to
    assure the requirements were correct and clearly communicated.

(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. It had the DHCP and IPv6 review based on the working groups involved
    in reviews and discussions.

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

    I have no concerns or issues with any of the material.

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

  Almost, I have received confirmation (as of this writing, 11/20/2020) confirmation
  from 3 of the 4 authors; I should receive confirmation from the 4th shortly and
  will update this document when I do.

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

    No, there is no IPR filed against this document and hence there was no IPR
    discussion in the WG.

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

    This document has consensus from many, and many that tend to most
    active. There were no indications that anyone disagrees with any of its
    material.

(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 ID nits tool (in verbose mode) did not find any issues. My review of the
    document did not find any issues.

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

    There is no need for any formal review of this kind for this document.

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

    Yes. And, I agree with how the references were categorized.

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

  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.

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

    This document has an IANA considerations section, but it states that
    it makes no requests to IANA - which is correct.

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

    There were none and none are applicable.

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

    It does not contain any YANG module.