Hi Roman, Please see responses inline <S>.
Thanks, Samuel From: Roman Danyliw via Datatracker <[email protected]> Date: Tuesday, 3 March 2026 at 23:20 To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Roman Danyliw's Discuss on draft-ietf-pce-circuit-style-pcep-extensions-14: (with DISCUSS and COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-pce-circuit-style-pcep-extensions-14: Discuss 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-circuit-style-pcep-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Section 5.2 5.2. Information and Data Models An implementation SHOULD allow an operator to view the PCEP peer capability defined in this document. Section 4.1 and 4.1.1 of [RFC9826] should be extended to include that capability for PCEP peer. Section 4.2 of [RFC9826] module SHOULD be extended to add notification for blocked path modification that satisfies specified constraints if path modification is blocked using the PATH- MODIFICATION TLV. -- Per “Section 4.1 and 4.1.1 of [RFC9826] should be extended to include that capability for PCEP peer”, who is this guidance for? What does it mean to say that a given section of an RFC “should be extended”? Is this extended the model in RFC9826? <S> The guidance was mostly for other PCE IETF drafts, which will extend/augment Yang model introduced as part of RFC9826 (possibly draft-ietf-pce-pcep-srv6-yang, but it can be other draft as well in the future). My understanding is that we are following similar approach in other PCEP RFCs. Would following updated text work for you? An implementation SHOULD allow an operator to view the PCEP peer capability defined in this document. A YANG data model specification augmenting the model defined in Sections 4.1 and 4.1.1 of [RFC9826] SHOULD include that capability for the PCEP peer. -- Per “Section 4.2 of [RFC9826] module SHOULD be extended to add notification for blocked path modification that satisfies specified constraints if path modification is blocked using the PATH-MODIFICATION TLV”, same questions. Additionally, this text says the "module SHOULD be extended", upper case "SHOULD", does that mean anything different than the lower case in the previous sentence? <S> Similar to above. Updated text (also with solved inconsistency for “SHOULD”): A YANG data model specification augmenting the module defined in Section 4.2 of [RFC9826] SHOULD add a notification for blocked path modification that satisfies specified constraints if path modification is blocked using the PATH-MODIFICATION TLV. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 5.4 A PCE implementation SHOULD notify the operator in case of blocked path modification for an LSP that no longer satisfies specified constraints. It SHOULD also allow the operator to view LSPs on the PCE that does not satisfy specified constraints. Is there some interoperable way that the operator should be notified? Is there some interoperable way about how an operator should “view LSPs”? <S> That text was mostly pointing to notification described in section 5.2 (so Yang model augmentation, which is supposed to be interoperable). Is following text better? A PCE implementation SHOULD allow the operator to monitor LSPs for which the PCE has determined that the current path no longer satisfies the specified constraints but path modification is blocked by the PATH-MODIFICATION TLV, for example via YANG notifications or the YANG data model described in Section 5.2.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
