Just to keep mail thread updated - version 25 submitted with changes included.
For “Reserved” vs “Unassigned” -> I renamed field in: https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-24.html#name-subobject-extension-block I’m not renaming existing “Reserved” field in: https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-24.html#name-srv6-ero-subobject Since we are just reducing size of existing field. For nit to consider adding sections numbers in Introduction - I considered it, but each part would require multiple sections to be listed, e.g. for “Signaling SR-Algorithm in ERO and RRO”, it would be 4.2, 4.3 and 5.1 and title of those sections can be already easily matched against that section, I skipped that part. Rest of proposed changes should be applied in updated version. Regards, Samuel From: Samuel Sidor (ssidor) <[email protected]> Date: Monday, 29 September 2025 at 12:36 To: Mohamed Boucadair <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [Pce] Re: Mohamed Boucadair's No Objection on draft-ietf-pce-sid-algo-24: (with COMMENT) Thanks a lot, Mohamed, One question for RFC8126 - is the text describing “Unassigned” and “Reserved” really applicable even to fields which are not tracked in IANA registry? At least my interpretation was that it is supposed to be used for example to flags tracked in specific IANA registry, but naming of currently “unused” fields inside any TLV/object is independent. At least most of recent RFCs seems to be still following naming “Reserved” in similar cases, e.g. https://www.ietf.org/rfc/rfc9843#name-ospf-generic-metric-sub-tlv https://www.rfc-editor.org/rfc/rfc9831.html#name-segment-type-e https://datatracker.ietf.org/doc/html/rfc9793#name-bier-path-attribute Anyway - I personally don’t have any other argument (besides consistency with a lot of existing RFCs), so I’ll still proceed with renaming (if other co-authors or PCE WG members does not have different opinion). Regards, Samuel From: Mohamed Boucadair via Datatracker <[email protected]> Date: Friday, 26 September 2025 at 10:50 To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Mohamed Boucadair's No Objection on draft-ietf-pce-sid-algo-24: (with COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-pce-sid-algo-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Samuel, Zoey, Shaofu, Shuping, and Andrew, Thank you for the effort put into this well-written and clear specification. Thanks to Nagendra Nainar for the OPSDIR and to the authors for considering these in -14. I only have minor comments: # Unassigend vs. Reserved I suggest to make this change (and also in the figure and similar uses in the spec): OLD: Reserved (24 bits): This field is reserved for future use and MUST be set to zero when sending and ignored when receiving, unless redefined by a future extension that is indicated by an associated SEBF and capability. NEW: Unassigned (24 bits): This field is reserved for future use and MUST be set to zero when sending and ignored when receiving, unless redefined by a future extension that is indicated by an associated SEBF and capability. to be consistent with the definitions provided in RFC8126: Unassigned: Not currently assigned, and available for assignment via documented procedures. While it's generally clear that any values that are not registered are unassigned and available for assignment, it is sometimes useful to explicitly specify that situation. Note that this is distinctly different from "Reserved". Reserved: Not assigned and not available for assignment. Reserved values are held for special uses, such as to extend the namespace when it becomes exhausted. "Reserved" is also sometimes used to designate values that had been assigned but are no longer in use, keeping them set aside as long as other unassigned values are available. Note that this is distinctly different from "Unassigned". # Default value CURRENT 6.1. Control of Function and Policy A PCE or PCC implementation MAY allow the capability of supporting PCEP extensions introduced in this document to be enabled or disabled as part of the global configuration. Can we recommend a default here? Having a default value would ensure a consistent behavior when the feature is introduced into a network. # Inappropriate use of normative language Section 6.4 OLD: An implementation SHOULD also allow the operator to view FADs, which MAY be used in Flexible Algorithm path computation defined in Section 5.2.2. NEW: An implementation SHOULD also allow the operator to view FADs, which may be used in Flexible Algorithm path computation defined in Section 5.2.2. # nits ## 1 (1) OLD: The PCEP extensions specified in this document: NEW: The PCEP extensions specified in this document are as follows: (2) CURRENT: Signaling SR-Algorithm in ERO and RRO: Mechanisms are introduced for .. SR-Algorithm Constraint for Path Computation: Mechanisms are defined .. Extensions to METRIC Object: Several new metric types are introduced Maybe point to the section where these mechanisms are introduced. ## 4.5.2 OLD: The Section 4 of [I-D.ietf-lsr-flex-algo-bw-con] NEW: Section 4 of [I-D.ietf-lsr-flex-algo-bw-con] ## 4.5.3 OLD: The Section 2 of [I-D.ietf-lsr-flex-algo-bw-con] NEW: Section 2 of [I-D.ietf-lsr-flex-algo-bw-con] OLD: The proposed metric type range was chosen ^^^^^^^^ NEW: The metric type range was chosen Cheers, Med
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
