[Pce] Re: Belated Gen-art LC review of draft-ietf-pce-circuit-style-pcep-extensions

["Samuel Sidor (ssidor)" <[e-mail]>]

Hi Elwyn,

Also attaching updated version of the draft. I’ll submit it as soon as submissions will be allowed (in case of no further comments).

PCE WG - this should be the final change for the directorate review (please let me know if I missed any comments).

Thanks,
Samuel

From: Samuel Sidor (ssidor) <[e-mail]>
Date: Friday, 13 March 2026 at 10:51
To: Elwyn Davies <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Belated Gen-art LC review of draft-ietf-pce-circuit-style-pcep-extensions

Hi Elwyn,

Thanks for your review and comments/nits.

Please see responses inline <S>. If there is no response for specific nit, consider it as accepted (will be updated in next version).

Regards,
Samuel

From: Elwyn Davies <[e-mail]>
Date: Thursday, 12 March 2026 at 13:57
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Belated Gen-art LC review of draft-ietf-pce-circuit-style-pcep-extensions


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ><https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-pce-circuit-style-pcep-extensions-15
Reviewer: Elwyn Davies
Review Date: 12/03/2026
IETF LC End Date: 27/02/2026
IESG Telechat date: (if known)

Summary: Ready with nits.  Apologies for this very late last call review.  It got written and then not sent due to incompetence/senior moment.  The comments were originally written against version 14 but appear to be still  applicable to version 15.

Major issues:
None

Minor issues:None

Nits/Editorial comments:

Abstract, para 2: The PCEP RFC document should be referenced  (RFC8664).

<S> I believe that it is generally not standard practice to include references to other RFCs in abstract (see other RFCs). The Abstract is intended to be a concise, standalone summary of the document.

s1, para 1: The term 'segment' in this context has a specific meaning defined in RFC 8402, Section 1.  A pointer to this definition or even a copy of it would be helpful in or after the second sentence.

<S> Added reference to RFC8402.

s1, para 2:  s/PCE Communication Protocol (PCEP)/PCE Communication Protocol (PCEP) [RFC8664]/

<S>I believe that PCEP is defined in RFC5440 and not in RFC8664, but I can add reference for that one at least (even if PCEP as a term is already described in terminology section with reference to that RFC)

s1, last para: s/Path Setup Type/Path Setup Type as introduced in [RFC8408]/, add Normative reference to RFC 8408 and pointer to RFC 8408 and this term in s2.

<S>Why normative reference since we are just saying that the change is applicable to any path setup type (so there is no explicit requirement for this draft to rely on it)? I can still add it as informative reference at least.

s2, last para: PCUpd is not defined. I assume this comes from RFC 8231. Create a list of imported for RFC 8231 and refer to PCUpd there.

s2, last para: SID is not defined. I assume this is the PCE Session ID brought over from RFC5440. Add to list of imported terms for RFC5440.

<S> SID is not referring to "PCE Session ID", but to "Segment Identifier" and it is already in the terminology (defined in RFC8402)

s3.2, last para: For consistency with the other sections here and clarity, I think this para is supposed to be a bullet point with a * label and the abbreviation letter placed in brackets after the name. Your current temporary registration of this flag has the letter O as its abbreviation. Unfortunately the font used to display drafts and RFCs on screen distinguishes letter O and digit 0 by putting a slash through the zero digit which makes it look, at first glance, that the abbreviation is digit 0 which is quite confusing. I see that this is all carried forward from RFC 5440 which has an O abbreviation for the strict/loose bit in the definition (Section 7.4.1) and elsewhere *except* the IANA instructions resulting in the abbreviation not appearing in the IANA registry. Given potential confusion with the O flag in RFC 5440, the lack of the O abbreviation in the RFC5440 RP flag registry definition and the ambiguity of O and 0 [Personally, I would not have used O as abbreviation both because I can't see how it ties to the meaning and the potential for confusion], might I suggest changing the abbreviation to S or SP as more mnemonic and to distinguish it from the other strict/loose flag? This change would then necessitate consistent changes to s3.1, s4.1 and s8.2.

<S> We selected O bit intentionally - to maintain consistency for both O bits - one used for stateless messages (RP object) and one for stateful (introduced in this document for LSP-EXTENDED-FLAG TLV) - since both are introduced for similar purpose. I can imagine changing “O bit” to “O-bit” if that would help with readability (that’s approach used in RFC8685 for example), but I can see “O bit” from other PCEP objects used already multiple times (e.g. RFC8779, RFC9050) and I don’t see it causing any potential confusion.

s3.3, para 1: s/a new/an additional/, s/whether/as to whether/, s/included in LSPA/included in an LSPA/

s5.1, para 1 and s5.2, paras 1 and 2: The capabilities described here are not requirements/options on the protocol but a suggestion for an end point implementation capability. s/SHOULD/should/

<S> Use of normative “SHOULD” is intentional in this case. Use of normative language in Manageability/Operational Considerations section is standard practice and I believe that “SHOULD” is not intended for protocol-only, but for any requirements for implementation. See similar use of SHOULD in base PCEP RFCs - e.g. RFC5440 (section 8.1), RFC8231 (section 9.1), ...

s5.2: Do these 'suggestions' imply that this document updates RFC 9826? This might also imply that RFC 9826 ought to be normative.

<S> No, we are just suggesting that future documents which will augment Yang model introduced in that RFC should include changes proposed by this document. The document is not directly augmenting Yang model or updating that RFC.

 s8: It would be useful to have the PCEP Numbers registry IANA link in the references.

<S> I believe that it is already there. Section 8 contains IANA link reference to PCEP registry and then individual sections 8.x contains links to specific registries.

s8.2: [Would S or SP be more mnemonic for flag abbreviation? See comment on s3.2 above.]

<S>Discussed above.

s8.4, Table 4: The definitions of the Permanent and Force flags are assigned abbreviations (P and F) in s3.3.  The abbreviations should be included in the IANA instructions.

<S> Added them.