Hi Carlos, Thanks for your review!
On Thu, Oct 24, 2024 at 12:09 AM Carlos Pignataro via Datatracker < nore...@ietf.org> 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. > > Dhruv: In general, I might agree, but in this specific instance, previous RFCs have provided similar justifications for IANA considerations within the appendix (refer to RFC 8356). Therefore, it makes sense to include it in this case as well as it is closely related. The shepherd review [1] noted that it was useful. > 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 [1] https://mailarchive.ietf.org/arch/msg/pce/5LA9bM-d_ek8Ya3Gjrd_jLO_3tg/ [2] https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.html and https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-pce-iana-update&url_2=https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.txt > Thanks! > > Carlos. > > > >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
