Last Call Review of draft-ietf-pce-iana-update-02
review-ietf-pce-iana-update-02-opsdir-lc-pignataro-2024-10-23-00

Hi,

Please find below the Ops Directorate (opsdir) review for
draft-ietf-pce-iana-update-02.

Review of   draft-ietf-pce-iana-update-02
Type        Last Call Review
Team        Ops Directorate (opsdir)
Reviewer    Carlos Pignataro

Summary:

This is a useful and easy-to-understand document. Its simplicity does not take
away from its value. This broad cleanup of registrations would prevent future
mistakes.

It mostly 'downgrades' registration policies from Std Action to IETF review,
which makes it easier to have numbers assigned.

It also adds an Experimental range, which is also useful and welcome!

More Substantive:

None.

Minor:

Appendix B.  Rationale for updating all registries with Standards Action

CMP: Should this be part of the document or deleted and kept in the list
archives? Not sure of the value as an appendix.

CMP: Further, the "Future registries" paragraph ought to be moved up on the
document, and outside the Appendix, in my opinion.

More Editorial:

1.  Introduction

   The IANA "Path Computation Element Protocol (PCEP) Numbers" registry
   group was populated by several RFCs produced by the Path Computation
   Element (PCE) working group.  Most of the registries include the
   "IETF Review" [RFC8126] as registration procedures.  There are a few
   registries that use "Standards Action".  Thus the values in those

CMP: "Thus, "

3.2.  Handling of Unknown Experimentation

   A PCEP implementation that receives an experimental Error-Type in a
   PCEP message and does not recognize the Error-Type (i.e., is not part
   of the experiment) will treat the error as it would treat any other
   unknown Error-Type (such as from a new protocol extension).  An
   implementation that is notified of a PCEP error will normally close
   the PCEP session (see [RFC5440]).  In general, PCEP implementations
   are not required to take specific action based on Error-Types, but
   may log the errors for diagnostic purposes.

CMP: "... on Error-Types but may log..."

   As with unknown Error-Types, an implementation receiving an unknown
   Error-value is not expected to do more than log the received error,
   and may close the PCEP session.

CMP: "...received error and may close...""

Appendix C.  Consideration of RFC 8356

   It is worth noting that [RFC8356] deliberately chose to make
   experimental codepoints available only in the PCEP messages, objects,
   and TLV types registries.  Appendix A of that document gives a brief

CMP: "... and TLV type registries."

Thanks!

Carlos.