Hi Roman, An update with this text (plus changes to address comments from other ADs) has now been posted: https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-15.html
Can you please review and let us know if this addresses your DISCUSS & comments? Thanks, Ketan On Wed, Mar 4, 2026 at 6:30 PM Samuel Sidor (ssidor) <ssidor= [email protected]> wrote: > 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]
