Hi Carlos,
Thanks for your review!
On Thu, Oct 24, 2024 at 12:09 AM Carlos Pignataro via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Carlos Pignataro
Review result: Has Issues
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.
Dhruv: Moved to the end of table 1.
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."
Dhruv: Thanks for the nits! All fixed in the working copy [2]!
Thanks!
Dhruv
Thanks!
Carlos.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
