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]
