A YANG Data Model for Path Computation Element Communications Protocol (PCEP)
draft-ietf-pce-pcep-yang-30

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-pce-pcep-yang and RFC 9826, changed IESG state to RFC Published)

[Ballot comment]
Thanks for addressing all my previous DISCUSS points and most of my COMMENTS (kept below for archiving)

See also https://mailarchive.ietf.org/arch/msg/pce/qBCnhFw0AaSbuJPICGf_EVZrTGc/


## COMMENTS (non-blocking)

### Section 1

I support Mahesh's DISCUSS, so I won't raise the following point to a block DISCUSS.

Penultimate paragraph writes `PCEP statistics YANG module "ietf-pcep-stats" which provides statistics, counters and telemetry data`. While the last one has `The PCEP operational state is included in the same tree as the PCEP configuration consistent with NMDA`. For me, telemetry (and statistics) are crucial for operations, i.e., for the operational state. The end of section 1 appears to be self-contradicting...

### Section 4

`oper-status` is within the configuration part, shouldn't it be in another branch of the tree ? As I am not a YANG expert, I can be really wrong.

It appears that the next sub-sections are describing part of the tree, please have some describing this approach (which I support) and have lead text per sub-section about which part(s) of the global tree is further detailed.

### Section 4.1.1

As I am not a PCEP expert, I really wonder why a PCEP speaker cannot be associated by multiple IP addresses (even if only being dual-stack)

### Section 5

As this YANG model has two modules (see above), should there be any text or consistency constraints about the future revision of one module, i.e., can one module be revised while the other is not ?

### Section 6

`Segment Routing in the IPv6 data plane is out of the scope of this document.`, this is a pity as SR-MPLS is included (see below). This makes the review and the ballot of this data model and the one for SRv6 very difficult... if the goal is to have some consistency between SR-MPLS & SRv6...

### Section 8.1


s/identity isis-area/identity is-is-area/ ?

### Section 12

s/We would like to thank/The authors would like to thank/ ?

### Appendix B

Rather than having an example with IPv4 and adding `Similarly a PCEP session with IPv6 address between PCE (2001:DB8::3) and a PCC (2001:DB8::4) could also be setup` could this happen the other way ? IPv6 example and some text about IPV4 ? After all, the RFC will be published in 2025 ;-)

Also, please use RFC 5952 for IPv6 addresses.

## NITS (non-blocking / cosmetic)

### YANG is in uppercase

There is at least one occurrence of lowercase "yang" in the section 4.1, please use uppercase everywhere.

[Ballot discuss]
Thanks for working on this specification, specially for the hard work needed to pull of such a long specifications. Thanks to Mihael for his TSVART review.

I have two points I would like to discuss so that we can clarify the specification better ( and it might be also coming from my lack of grasping the long specification )

  1. I saw QUIC (RFC9000) is mentioned to used as secure transport to PCEP communication as par with TLS. What I would like to understand why there is no special considerations posed for 0-RTT data while there is MUST not use restriction for TLS1.3 early data?
 
  2. While the capabolity leafs has entry for TCP-AO, TLS usage, it does not have any capablity to indicate the support of QUIC. How would the PCE elements discover and use QUIC as a secure transport?

Both of those above points indicates that the QUIC usage is underspecified to be used as secure transport for this protocol. I would like see that I am incorrect in my assertion in this regard.

## 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?
-> As expected for a YANG module: strong concurrence of a few with consensus on the usefulness.

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

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 discontent expressed.

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)?
-> No known implementation so far.

## 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.
-> It's a YANG module to be used through a management solution (e.g. NETCONF).
  The I-D has been reviewed by the Routing and Security directorates, as well as YANG Doctors.

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.
-> The I-D is in YANG Doctor's scope.

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]?
-> Checked using YANG Validator. There are a few warnings related to dependencies.
  The module follows NDMA.

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.
-> N/A

## 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?
-> Yes

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

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, which is consistent with the content and the datatracker.
  The document defines a management module for a deployed protocol with strong interoperability requirements between the server and the consuming management applications.

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.
-> All authors responded to the IPR poll when requested.

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.
-> The authors (former or current WG chairs) agree to be listed as such.

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.)
-> Nits were fixed after shepherd review.

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

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

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.
-> N/A

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?
-> TLS and TE YANG aren't RFC yet, but one is already with the IESG and the other one is waiting for write-up.

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.
-> N/A

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 simple and clear: registers 2 URIs and 2 modules.

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.
-> N/A

[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/

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-pce-pcep-yang-27
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Julien Meuric for the shepherd's succinct write-up including the WG consensus, *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 8.1

```
feature sr {
    description
      "Support Segment Routing (SR) for PCE.";
```

and later

```
  container sr {
        if-feature "sr";
        description
          "If segment routing for MPLS is supported at the local
          entity or a peer.";
          ...
        leaf enabled {
          type boolean;
          default "false";
          description
            "Set to true if SR-MPLS is enabled";
        }
```

The feature and container should really be renamed in sr-mpls and the description of feature sr updated to indicate SR-MPLS.

```
leaf pcc-id {
            type inet:ip-address-no-zone;
            description
              "The local internet address of the PCC, that
              generated the PLSP-ID.";
          }
```

What is a `local internet address` ?

[Ballot comment]

## COMMENTS (non-blocking)

### Section 1

I support Mahesh's DISCUSS, so I won't raise the following point to a block DISCUSS.

Penultimate paragraph writes `PCEP statistics YANG module "ietf-pcep-stats" which provides statistics, counters and telemetry data`. While the last one has `The PCEP operational state is included in the same tree as the PCEP configuration consistent with NMDA`. For me, telemetry (and statistics) are crucial for operations, i.e., for the operational state. The end of section 1 appears to be self-contradicting...

### Section 4

`oper-status` is within the configuration part, shouldn't it be in another branch of the tree ? As I am not a YANG expert, I can be really wrong.

It appears that the next sub-sections are describing part of the tree, please have some describing this approach (which I support) and have lead text per sub-section about which part(s) of the global tree is further detailed.

### Section 4.1.1

As I am not a PCEP expert, I really wonder why a PCEP speaker cannot be associated by multiple IP addresses (even if only being dual-stack)

### Section 5

As this YANG model has two modules (see above), should there be any text or consistency constraints about the future revision of one module, i.e., can one module be revised while the other is not ?

### Section 6

`Segment Routing in the IPv6 data plane is out of the scope of this document.`, this is a pity as SR-MPLS is included (see below). This makes the review and the ballot of this data model and the one for SRv6 very difficult... if the goal is to have some consistency between SR-MPLS & SRv6...

### Section 8.1


s/identity isis-area/identity is-is-area/ ?

### Section 12

s/We would like to thank/The authors would like to thank/ ?

### Appendix B

Rather than having an example with IPv4 and adding `Similarly a PCEP session with IPv6 address between PCE (2001:DB8::3) and a PCC (2001:DB8::4) could also be setup` could this happen the other way ? IPv6 example and some text about IPV4 ? After all, the RFC will be published in 2025 ;-)

Also, please use RFC 5952 for IPv6 addresses.

## NITS (non-blocking / cosmetic)

### YANG is in uppercase

There is at least one occurrence of lowercase "yang" in the section 4.1, please use uppercase everywhere.

[Ballot discuss]
Section 1, paragraph 3
>    This document contains a specification of the PCEP YANG module,
>    "ietf-pcep" which provides the PCEP [RFC5440] data model.  Further,
>    this document also includes the PCEP statistics YANG module "ietf-
>    pcep-stats" which provides statistics, counters and telemetry data.

I realize that I had provided Early Reveiw from a YANG doctors point of view for this module. And if the module had some of the same structure that I had reviewed, I must apologize for not catching this earlier.

It is fairly unusual to split the statistics into a separate module away from the rest of the module. It is also unusual to have the separate module augment the main module in the same document. Could this not have been achieved simply by having a container called 'statistics' under 'peer' and 'session'? What is achieved by having a complete separate namespace for statistics. Also, why use 'rpcs' and not the 'action' statement to clear the statistics? See Section 7.15.3 of RFC 7950 for an example and why 'action' should be used instead of 'rpcs'. Hint, rpcs have no node in the datastores tied to them. That context has to be somehow brought in. Also, how would one clear stats for a particular peer or session?

For all these reasons, I feel there must have been a strong motivation for coming up with a separate module for statistics, and that motivation along with the use of rpcs should be clearly described, otherwise it would be better for the module to be collapsed into a single module, and the rpcs converted to actions.

Section 4, paragraph 1
>    The PCEP YANG module defined in this document has all the common
>    building blocks for the PCEP protocol.

For the rest of the YANG module, I would like to thank Jan Lindblad for providing YANG doctor review on the document. But I have not seen any response to the review, or how it will be addressed. Holding a DISCUSS to make sure those comments are addressed.

[Ballot comment]
"Abstract", paragraph 1
>    This document defines a YANG data model for the management of the
>    Path Computation Element communications Protocol (PCEP) for
>    communications between a Path Computation Client (PCC) and a Path
>    Computation Element (PCE), or between two PCEs.  The data model
>    includes configuration and state data.

Maybe it is just me, but most YANG data models today have both configuration and state data, even if the state data reflects the state of any of the conifg leafs. As such, the last sentence seems redundant to me.

Section 9, paragraph 1
>    The YANG modules defined in this document are designed to be accessed
>    via a network management protocol such as NETCONF [RFC6241] or
>    RESTCONF [RFC8040].  The lowest NETCONF layer is the secure transport
>    layer and the mandatory-to-implement secure transport is SSH
>    [RFC6242].  The lowest RESTCONF layer is HTTPS, and the mandatory-to-
>    implement secure transport is TLS [RFC8446]
>    The NETCONF access control model [RFC8341] provides the means to
>    restrict access for particular NETCONF or RESTCONF users to a pre-
>    configured subset of all available NETCONF or RESTCONF protocol
>    operations and content.

Please update this template to match the recent changes in the template as described in rfc8407bis Section 3.7.1.

The IANA review of this document seems to not have concluded yet.

Check whether the "Implementation Status" section is reasonable. If there is no implementation status to report, should this section be removed?

DOWNREF [I-D.ietf-teas-yang-te] from this Proposed Standard to
draft-ietf-teas-yang-te of unknown standards level. (For IESG discussion. It
seems this DOWNREF was not mentioned in the Last Call and also seems to not
appear in the DOWNREF registry.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
  "intrinsic", "original"

Found IP block or address not inside RFC5737/RFC3849 example ranges: "0.0.0.0".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 3
>    This document defines a YANG [RFC7950] data model for the management
>    of PCEP speakers.  It is important to establish a common data model
>    for how PCEP speakers are identified, configured, and monitored.  The
>    data model includes configuration data and state data.

This is a YANG 1.1 model by virtue of the fact you are referencing RFC 7950. You might want to just say that it is a YANG 1.1 module.

Document references draft-ietf-netconf-tls-client-server, but that has been
published as RFC9645.

Document references draft-ietf-pce-pcep-srv6-yang-05, but -06 is the latest
available revision.

Reference [RFC5246] to RFC5246, which was obsoleted by RFC8446 (this may be on
purpose).

"Abstract", paragraph 1
> the state data reflects the state of any of the conifg leafs. As such, the la
>                                  ^^^^^^^^^
Consider simply using "of" instead.

[Ballot comment]
Just two observations, no changes required.

I did appreciate Section 7, and I believe it reflects the current state of play with respect to TLS 1.2 and 1.3.

I also found that the security considerations addressed issues that may actually be security related (a refreshing change for a Yang draft).  Thank you.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pce-pcep-yang-26. If any part of this review is inaccurate, please let us know.

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

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-pcep
URI: urn:ietf:params:xml:ns:yang:ietf-pcep
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-pcep-stats
URI: urn:ietf:params:xml:ns:yang:ietf-pcep-stats
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-pcep
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-pcep
Prefix: pcep
Module:
Reference: [ RFC-to-be ]

Name: ietf-pcep-stats
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-pcep-stats
Prefix: pcep-stats
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

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-11-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-pcep-yang@ietf.org, gunter@vandevelde.cc, julien.meuric@orange.com, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Path Computation Element Communications Protocol (PCEP)) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'A YANG Data Model for Path Computation
Element Communications Protocol
  (PCEP)'
  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 2024-11-19. 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 a YANG data model for the management of the
  Path Computation Element communications Protocol (PCEP) for
  communications between a Path Computation Client (PCC) and a Path
  Computation Element (PCE), or between two PCEs.  The data model
  includes configuration and state data.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-teas-yang-te: A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces (None - Internet Engineering Task Force (IETF) stream)

## 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?
-> As expected for a YANG module: strong concurrence of a few with consensus on the usefulness.

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

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 discontent expressed.

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)?
-> No known implementation so far.

## 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.
-> It's a YANG module to be used through a management solution (e.g. NETCONF).
  The I-D has been reviewed by the Routing and Security directorates, as well as YANG Doctors.

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.
-> The I-D is in YANG Doctor's scope.

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]?
-> Checked using YANG Validator. There are a few warnings related to dependencies.
  The module follows NDMA.

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.
-> N/A

## 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?
-> Yes

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

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, which is consistent with the content and the datatracker.

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.
-> All authors responded to the IPR poll when requested.

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.
-> The authors (former or current WG chairs) agree to be listed as such.

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.)
-> Nits were fixed after shepherd review.

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

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

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.
-> N/A

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?
-> TLS and TE YANG aren't RFC yet, but one is already with the IESG and the other one is waiting for write-up.

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.
-> N/A

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 simple and clear: registers 2 URIs and 2 modules.

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.
-> N/A

[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 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?
-> As expected for a YANG module: strong concurrence of a few with consensus on the usefulness.

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

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 discontent expressed.

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)?
-> No known implementation so far.

## 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.
-> It's a YANG module to be used through a management solution (e.g. NETCONF).
  The I-D has been reviewed by the Routing and Security directorates, as well as YANG Doctors.

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.
-> The I-D is in YANG Doctor's scope.

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]?
-> Checked using YANG Validator. There are a few warnings related to dependencies.
  The module follows NDMA.

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.
-> N/A

## 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?
-> Yes

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

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, which is consistent with the content and the datatracker.

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.
-> All authors responded to the IPR poll when requested.

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.
-> The authors (former or current WG chairs) agree to be listed as such.

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.)
-> Nits were fixed after shepherd review.

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

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

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.
-> N/A

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?
-> TLS and TE YANG aren't RFC yet, but one is already with the IESG and the other one is waiting for write-up.

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.
-> N/A

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 simple and clear: registers 2 URIs and 2 modules.

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.
-> N/A

[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 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?
-> As expected for a YANG module: strong concurrence of a few with consensus on the usefulness.

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

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 discontent expressed.

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)?
-> No known implementation so far.

## 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.
-> It's a YANG module to be used through a management solution (e.g. NETCONF).
  The I-D has been reviewed by the Routing and Security directorates, as well as by YANG Doctors.

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.
-> The I-D is in YANG Doctor's scope.

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]?
-> Checked using YANG Validator. There are few warnings related to dependencies.
  The module follows NDMA.

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.
-> N/A

## 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?
-> Yes

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

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, which is consistent with the content and the DT.

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.
-> All authors responded to the IPR poll when requested.

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.
-> The authors (former or current WG chairs) agree to be listed as such.

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.)
-> Nits were fixed after shepherd review.

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

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

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.
-> N/A

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?
-> TLS and TE YANG aren't RFC yet, but one is already with the IESG and the other one is waiting for write-up.

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.
-> N/A

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 simple and clear: registers 2 URIs and 2 modules.

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.
-> N/A

[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/

Changed document external resources from:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep-stats@2022-01-25.yang (Yang catalog entry for ietf-pcep-stats@2022-01-25.yang)
yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep@2022-01-25.yang (Yang catalog entry for ietf-pcep@2022-01-25.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-pcep@2022-01-25.yang&modules[]=ietf-pcep-stats@2022-01-25.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-pce-pcep-yang)

to:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep-stats.yang (Yang catalog entry for ietf-pcep-stats.yang)
yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep.yang (Yang catalog entry for ietf-pcep.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-pcep.yang&modules[]=ietf-pcep-stats.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-pce-pcep-yang)

Changed document external resources from:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep-stats@2020-10-31.yang (Yang catalog entry for ietf-pcep-stats@2020-10-31.yang)
yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep@2020-10-31.yang (Yang catalog entry for ietf-pcep@2020-10-31.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-pcep@2020-10-31.yang&modules[]=ietf-pcep-stats@2020-10-31.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-pce-pcep-yang)

to:

yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep-stats@2022-01-25.yang (Yang catalog entry for ietf-pcep-stats@2022-01-25.yang)
yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-pcep@2022-01-25.yang (Yang catalog entry for ietf-pcep@2022-01-25.yang)
yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-pcep@2022-01-25.yang&modules[]=ietf-pcep-stats@2022-01-25.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-pce-pcep-yang)