Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks
draft-ietf-pce-pcep-extension-native-ip-40

[Ballot discuss]
In -35 a number of changes to the IANA considerations were introduced.  Specifically, various "shoulds" were replaced with "SHOULDs".  This has created ambiguity in the following:

-- Section 13.4,
  The reference for the new Error-type/value SHOULD be set to this
  document.

-- Section 13.5
  Each bit SHOULD be tracked with the following qualities:

-- Section 13.6
  Each
  value SHOULD be tracked with the following qualities: value, meaning,
  and defining RFC.

-- Section 13.7
  Each value SHOULD
  be tracked with the following qualities:

-- Section 13.8
  Each bit
  SHOULD be tracked with the following qualities:

What isn't clear when IANA would choose not to track these qualities or set the values.  Why create this ambiguity?

[Ballot comment]
Thanks for working on this document. I have not comments from transport protocol points of view.

I have following comment/question though -

- In section 6.1 it says -

              "The PCInitiate message SHOULD be sent to PCC which is acting as BGP router and/or RR."
 
  In Section 6.2 it says -

              "The PCInitiate message SHOULD be sent to every router on the path."

  To me it seems like there is not way to bypass those SHOULDs and get the route and session establishment procedure done. If that understanding is correct then what are the exceptionsthiking about to let the implementers skip that part? Also, if this understand is not true, then I would expect this document to give warnings on the effects of skiping the PCInitiate messages.

[Ballot comment]

Thanks to Magnus Nystrom for his SecDir review.  And for the authors' prompt attention to his comments.

I also think the paragraph on the experimental aspect of this is useful.  Thank you.

[Ballot comment]
The SHOULD in Section 10 and the RECOMMENDED in Section 7.3 seem to be unsupported.  Why might an implementer choose not to do what they say?  What's the impact to interoperability?

I echo Roman's question about the document's status.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-pcep-extension-native-ip-34

## Many thanks for writing this document. I found the text not easy to process, mostly due to the many many references used in the document.

## I support Roman's discuss that applies to -34

#GENERIC COMMENTS
#================
## idnits spits up few message


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

17 Abstract
18
19   This document defines the Path Computation Element Communication
20   Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
21   based applications in Native IP networks.  It describes the key
22   information that is transferred between the Path Computation Element
23   (PCE) and the Path Computation Clients (PCC) to accomplish the End-
24   to-End (E2E) traffic assurance in the Native IP network under PCE as
25   a central controller (PCECC).

[minor]
an alternate proposal for abstract easier to digest and read for people with less PCEP awareness. Please use or ignore as you find useful

"
This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support the computation of paths for native IP traffic. The proposed extensions enable a Path Computation Element (PCE) to calculate and manage paths for native IP networks, enhancing the capabilities of PCEP beyond traditional MPLS and GMPLS networks. By introducing new PCEP objects and procedures, this document allows for the efficient use of IP network resources and supports the deployment of traffic engineering in native IP environments.
"

114   Generally, Multiprotocol Label Switching Traffic Engineering (MPLS-
115   TE) requires the corresponding network devices to support Resource
116   ReSerVation Protocol (RSVP)/Label Distribution Protocol (LDP)
117   protocols to ensure the End-to-End (E2E) traffic performance.  But in

[minor]
should there be no reference to rsvp and ldp RFCs?

199   N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): If set to 1 by a PCEP
200   speaker, it indicates that the PCEP speaker is capable of TE in a
201   Native IP network as specified in this document.  The flag MUST be
202   set by both the PCC and PCE to support this extension.

[minor]
What about the folowing proposed textblob?

"
N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP speaker, this flag indicates that the PCEP speaker is capable of TE in a Native IP network, as specified in this document. Both the PCC and PCE MUST set this flag to support this extension.
"

223   If one or both speakers (PCE and PCC) have not indicated support and
224   willingness to use the PCEP extensions for Native-IP, the PCEP
225   extensions for the Native-IP MUST NOT be used.  If a Native-IP

[major]
earlier in the text i only saw the N flag, however this text seems to indicate two flags?
(1) support for Native-IP and (2) willingness to use Native-IP
Maybe i missunderstood how the willingness is signalled?

350   The error handling for missing CCI objects is as per [RFC9050].
351   Furthermore, one, and only one, object among BPI, EPR or PPA object
352   MUST be present.

[minor]
Maybe this can be rewritten more normative? what about

"
Error handling for missing CCI objects MUST be performed as specified in [RFC9050]. Additionally, exactly one object among the BPI, EPR, or PPA objects MUST be present.
"

[Ballot comment]
# Internet AD comments for draft-ietf-pce-pcep-extension-native-ip-34
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/

## Comments

### S6.4

* Why only IP-in-IP? Would it be possible/easy to cite the BGP Tunnel
  Encapsulation Attribute Tunnel Types IANA registry, plus whatever other
  mechanics/semantics that might go along with it?

  https://iana.org/assignments/bgp-tunnel-encapsulation/

[Ballot comment]
I support Roman's discuss, and note the mailing list suggestion from Dhruv that applies to -34

https://mailarchive.ietf.org/arch/msg/pce/j8b6_YwVZ4rzeewgnWVVzN2txzw/

It would be nice to see some definition around what a successful or failed experiment would look like in this context.

[Ballot discuss]
** Section 14.2.

14.2.  PCECC-CAPABILITY sub-TLV's Flag field

  [RFC9050] created a sub-registry within the "Path Computation Element
  Protocol (PCEP) Numbers" registry to manage the value of the PCECC-
  CAPABILITY sub-TLV's 32-bit Flag field.  IANA is requested to
  allocate a new bit position within this registry, as follows:

The registration policy of PCECC-CAPABILITY sub-TLV (https://www.iana.org/assignments/pcep/pcep.xhtml#pcecc-capability) is “Standards Action”.  This document has experimental status and does not qualify for registration.

[Ballot comment]
Thank you to Mallory Knodel for the GENART review.

** This document has been submitted with “experimental” status.  What is the nature of the experiment in question here?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pce-pcep-extension-native-ip-34

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Dhruv Dhody for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Abstract

s/This document describes/This document defines/ as this is an experimental document ?

## Section 1

`native IP` could be defined in a couple of words for readers not familiar to RFC 8735.

Should PCE & PCC be expanded on first use even if they are listed in https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list ? E.g., PCEP is expanded while it is on the list.

## Section 6.4

Please add a reference to `IPinIP tunnel` as there are various encapsulations defined by the IETF.

## Section 7.2

Should the local/peer addresses be qualified as unicast (as opposed to multicast) ? Can those addresses be link-local ? (possibly applicable to other sections)

## Section 7.4

Suggest making a specific "For IPv4" similar to the current "For IPv6" as opposed to common fields such as No of Prefixes, ...

## Section 12

I wonder whether an implementation section referring to implementation in preparation or simulations is really useful. See also RFC 7492.

## Section 14

Suggest adding the URI of the various registries to be super clear, e.g., https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-path-setup-types

# NITS (non-blocking / cosmetic)

Sometimes "bytes" is written capitalized as "Bytes" without any reason.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few but that is understandable for a specialized document that is applicable for Native-IP only.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a discussion about the document's status. The authors wanted the proposed standard but after discussions with AD/chairs, the track was changed to experimental. 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is a planned implementation for one vendor as listed in Section 12.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the document is closely related to IDR WG. The WG was notified at the time of WGLC as well as before. Susan Hares did a review as well - https://mailarchive.ietf.org/arch/msg/pce/Lvj2KNS6-qBA8ewiDQVF38QlR58/ and https://mailarchive.ietf.org/arch/msg/pce/0OANc4m45RIaxJ5kMankYeu9Llg/

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

Not applicable!

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable!

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The draft uses RBNF as per RFC 5511 but validation is done via manual review.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed and written well as per RFC 8735 and RFC 8821 on the experimental track.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Early RTGDIR, OPSDIR and SECDIR review done.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental track that extends PCECC to support Native-IP scenarios.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR disclosure was requested during WG adoption and WGLC

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, 5 authors!

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is 1 instance of long lines in figures/tables.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not applicable!

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Not applicable!

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Not applicable!

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

IANA section has been reviewed. This experimental RFC is requesting an allocation from a standards action registry (Section 14.2). There is an I-D that is being fast-tracked in the PCE WG to fix it quickly - draft-ietf-pce-iana-update

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No need for Designated Expert

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few but that is understandable for a specialized document that is applicable for Native-IP only.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a discussion about the document's status. The authors wanted the proposed standard but after discussions with AD/chairs, the track was changed to experimental. 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is a planned implementation for one vendor as listed in Section 12.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the document is closely related to IDR WG. The WG was notified at the time of WGLC as well as before. Susan Hares did a review as well - https://mailarchive.ietf.org/arch/msg/pce/Lvj2KNS6-qBA8ewiDQVF38QlR58/ and https://mailarchive.ietf.org/arch/msg/pce/0OANc4m45RIaxJ5kMankYeu9Llg/

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

Not applicable!

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable!

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The draft uses RBNF as per RFC 5511 but validation is done via manual review.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed and written well as per RFC 8735 and RFC 8821 on the experimental track.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Early RTGDIR, OPSDIR and SECDIR review done.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental track that extends PCECC to support Native-IP scenarios.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR disclosure was requested during WG adoption and WGLC

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, 5 authors!

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are some instances of long lines in figures/tables. I have asked authors to fix that in the next update.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not applicable!

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Not applicable!

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Not applicable!

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

IANA section has been reviewed. This experimental RFC is requesting an allocation from a standards action registry (Section 14.2). There is an I-D that is being fast-tracked in the PCE WG to fix it quickly.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No need for Designated Expert

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

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

IANA has completed its review of draft-ietf-pce-pcep-extension-native-ip-33. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are ten actions which we must complete.

First, in the PCEP Path Setup Types registry in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the existing temporary registration for

Value: 4

will be made permanent and have its reference changed as follows:

Value: 4
Description: Native IP TE Path
Reference: [ RFC-to-be ]

Second, in the PCECC-CAPABILITY sub-TLV registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the existing temporary registration for

Bit: 30

will be made permanent and have its reference changed as follows:

Bit: 30
Name: NATIVE IP
Reference: [ RFC-to-be ]

Third, in the PCEP Objects registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the existing temporary registrations for the following four PCEP Objects:

Object Class Value: 44
Object Class Value: 46
Object Class Value: 47
Object Class Value: 48

will be made permanent and have their references changed as follows:

Object-Class Value Name Reference
44 CCI Object [ RFC-to-be ]
Object-Type
2: Native IP

46 BGP Peer Info [ RFC-to-be ]
Object-Type
1: IPv4 address
2: IPv6 address

47 Explicit Peer Route [ RFC-to-be ]
Object-Type
1: IPv4 address
2: IPv6 address

48 Peer Prefix Advertisement [ RFC-to-be ]
Object-Type
1: IPv4 address
2: IPv6 address

Fourth, in the PCEP-ERROR Object Error Types and Values registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the existing temporary registration for

Error-type: 33

will be made permanent along with the following error-values and have its reference changed as follows:

Error Type Meaning Error-value
33 Native IP TE failure
1:Local IP is in use [ RFC-to-be ]
2:Remote IP is in use [ RFC-to-be ]
3:Explicit Peer Route Error [ RFC-to-be ]
4:EPR/BPI Peer Info mismatch [ RFC-to-be ]
5:BPI/PPA Address Family mismatch [ RFC-to-be ]
6:PPA/BPI Peer Info mismatch [ RFC-to-be ]

IANA Question --> Should Error-value: 0 be Unassigned for this Error-Type?

IANA Question --> The temporary registrations for Error-type: 33 do not match the requested registrations in the current draft. Should the Error-values in the draft replace all of the temporary registrations for Error-values currently in this registry for Error-type: 33?

Fifth, also in the PCEP-ERROR Object Error Types and Values registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the existing temporary registrations for the following Error-values will be made permanent and their references changed to [ RFC-to-be ] as follows:

Error-Type Meaning Error-value
6 Mandatory Object missing
19:Native IP object missing

10 Reception of an invalid object
39:PCECC NATIVE-IP-TE-CAPABILITY bit
is not set

19 Invalid Operation
22:Only one BPI, EPR or PPA object can
be included in this message

Sixth, also in the PCEP-ERROR Object Error Types and Values registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

two new registrations are to be made for Error-Type 19 as follows:

Error-Type Meaning Error-value
19 Invalid Operation
[ TBD-at-Registration ]: Attempted Native-IP operations when the capability was not advertised
[ TBD-at-Registration ]: Unknown Native-IP Info

Seventh, a new registry is to be created called the CCI Object Flag Field for Native-IP registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry group? If it needs a new group, does it also need a new category at http://www.iana.org/protocols (and if so, should the registry group and the category have the same name)?

The new registry will be managed via IETF Review as defined in RFC8126. The new registry will have the following fields:

- Bit Number
- Description
- Reference

There are no initial registrations in the new registry.

Eighth, a new registry is to be created called the BPI Object Status Code Field registry. The new registry will be placed in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

The new registry will be managed via IETF Review as defined by RFC8126.

There are initial registrations in the new registry as follows:

Value Meaning Reference
-----+--------+-----------
0 Reserved [ RFC-to-be ]
1 BGP Session Established [ RFC-to-be ]
2 BGP Session Establishment In Progress [ RFC-to-be ]
3 BGP Session Down [ RFC-to-be ]
4-255 Unassigned

Ninth, a new registry is to be created called the BPI Object Error Code Field registry. The new registry will be placed in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

The new registry will be managed via IETF Review as defined by RFC8126.

There are initial registrations in the new registry as follows:

Value Meaning Reference
-----+--------+-----------
0 Reserved [ RFC-to-be ]
1 ASes does not match, BGP Session Failure [ RFC-to-be ]
2 Peer IP can't be reached, BGP Session Failure [ RFC-to-be ]
3-255 Unassigned

Tenth, a new registry is to be created called the BPI Object Flag Field registry. The new registry will be placed in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

The new registry will be managed via IETF Review as defined by RFC8126.

There are initial registrations in the new registry as follows:

Bit Meaning Reference
--+--------+-----------
0-6 Unassigned
7 T (IPnIP) bit [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

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 2024-08-12):

From: The IESG
To: IETF-Announce
CC: dd@dhruvdhody.com, draft-ietf-pce-pcep-extension-native-ip@ietf.org, jgs@juniper.net, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks) to Experimental RFC


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Path Computation Element Communication
Protocol (PCEP) Extensions for
  Native IP Networks'
  as Experimental 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 2024-08-12. 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 defines the Path Computation Element Communication
  Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
  based applications in Native IP networks.  It describes the key
  information that is transferred between Path Computation Element
  (PCE) and Path Computation Clients (PCC) to accomplish the End-to-End
  (E2E) traffic assurance in the Native IP network under PCE as a
  central controller (PCECC).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few but that is understandable for a specialized document that is applicable for Native-IP only.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a discussion about the document's status. The authors wanted the proposed standard but after discussions with AD/chairs, the track was changed to experimental. 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is a planned implementation for one vendor as listed in Section 12.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the document is closely related to IDR WG. The WG was notified at the time of WGLC as well as before. Susan Hares did a review as well - https://mailarchive.ietf.org/arch/msg/pce/Lvj2KNS6-qBA8ewiDQVF38QlR58/ and https://mailarchive.ietf.org/arch/msg/pce/0OANc4m45RIaxJ5kMankYeu9Llg/

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

Not applicable!

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable!

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The draft uses RBNF as per RFC 5511 but validation is done via manual review.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed and written well as per RFC 8735 and RFC 8821 on the experimental track.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Early RTGDIR, OPSDIR and SECDIR review done.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental track that extends PCECC to support Native-IP scenarios.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR disclosure was requested during WG adoption and WGLC

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, 5 authors!

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are some instances of long lines in figures/tables. I have asked authors to fix that in the next update.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not applicable!

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Not applicable!

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Not applicable!

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section will need an update based on the plan to change the IANA allocation policies to the IETF review.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No need for Designated Expert

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few but that is understandable for a specialized document that is applicable for Native-IP only.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a discussion on the document's status as a proposed standard. Some suggested it should be of experimental status. Authors/WG want to proceed with the proposed standard for now. 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is a planned implementation for one vendor as listed in Section 12.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the document is closely related to IDR WG. The WG was notified at the time of WGLC as well as before. Susan Hares did a review as well - https://mailarchive.ietf.org/arch/msg/pce/Lvj2KNS6-qBA8ewiDQVF38QlR58/ and https://mailarchive.ietf.org/arch/msg/pce/0OANc4m45RIaxJ5kMankYeu9Llg/

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

Not applicable!

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable!

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable!

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed, clearly written and complete.
Based on the shepherd, the document is better suited as experimental, but they are likely in the rough.
That being said, the document is ready to be handed off! 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Early RTGDIR review done. Requested early security and ops review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard as it extends PCECC to support Native-IP scenarios.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR disclosure was requested during WG adoption and WGLC

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, 5 authors!

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are some instances of long lines in figures/tables. I have asked authors to fix that in the next update.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not applicable!

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Not applicable!

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Not applicable!

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No need for Designated Expert

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few but that is understandable for a specialized document that is applicable for Native-IP only.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a discussion on the document's status as a proposed standard. Some suggested it should be of experimental status. Authors/WG want to proceed with the proposed standard for now. 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is a planned implementation for one vendor as listed in Section 12.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the document is closely related to IDR WG. The WG was notified at the time of WGLC as well as before. Susan Hares did a review as well - https://mailarchive.ietf.org/arch/msg/pce/Lvj2KNS6-qBA8ewiDQVF38QlR58/ and https://mailarchive.ietf.org/arch/msg/pce/0OANc4m45RIaxJ5kMankYeu9Llg/

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

Not applicable!

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable!

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable!

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed, clearly written and complete.
Based on the shepherd, the document is better suited as experimental, but they are likely in the rough.
That being said, the document is ready to be handed off! 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Early RTGDIR review done. Requested early security and ops review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard as it extends PCECC to support Native-IP scenarios.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. IPR disclosure was requested during WG adoption and WGLC

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, 5 authors!

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are some instances of long lines in figures/tables. I have asked authors to fix that in the next update.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not applicable!

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Not applicable!

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Not applicable!

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No need for Designated Expert

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/