Hi Samuel, On Thu, Feb 26, 2026 at 4:20 PM Samuel Sidor (ssidor) <[email protected]> wrote:
> Thanks a lot, Med. > > See responses inline <S2> (responded only to those without conclusion). > > Regards, > Samuel > > *From: *[email protected] <[email protected]> > *Date: *Wednesday, 25 February 2026 at 10:15 > *To: *Samuel Sidor (ssidor) <[email protected]>, The IESG <[email protected]> > *Cc: *[email protected] <[email protected]>, > [email protected] < > [email protected]>, > [email protected] <[email protected]>, [email protected] <[email protected]> > *Subject: *RE: Mohamed Boucadair's Discuss on > draft-ietf-pce-circuit-style-pcep-extensions-13: (with DISCUSS and COMMENT) > > Hi Samuel, > > > > Thank you for the follow-up. > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Samuel Sidor (ssidor) <[email protected]> > *Envoyé :* mardi 24 février 2026 15:55 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]>; The > IESG <[email protected]> > *Cc :* [email protected]; > [email protected]; [email protected]; > [email protected] > *Objet :* Re: Mohamed Boucadair's Discuss on > draft-ietf-pce-circuit-style-pcep-extensions-13: (with DISCUSS and COMMENT) > > > > > > Thanks a lot, Med for review. > > > > Please find inline responses marked with <S>. > > > > Regards, > > Samuel > > > > *From: *Mohamed Boucadair via Datatracker <*[email protected] > <[email protected]>*> > *Date: *Tuesday, 24 February 2026 at 09:56 > *To: *The IESG <*[email protected] <[email protected]>*> > *Cc: **[email protected] <[email protected]>* <*[email protected] > <[email protected]>*>, > *[email protected] > <[email protected]>* > <*[email protected] > <[email protected]>*>, > *[email protected] > <[email protected]>* <*[email protected] <[email protected]>*>, > *[email protected] > <[email protected]>* <*[email protected] <[email protected]>*> > *Subject: *Mohamed Boucadair's Discuss on > draft-ietf-pce-circuit-style-pcep-extensions-13: (with DISCUSS and COMMENT) > > Mohamed Boucadair has entered the following ballot position for > draft-ietf-pce-circuit-style-pcep-extensions-13: 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/ > <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/ > <https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions/>* > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi Samuel, Praveen, Andy, Luay, and Shuping, > > Thank you for the effort put into this specification. The document is > well-written, especially operational considerations are well-articulated. > That’s exemplar. Congrats for such a high quality document. > > Thanks to Luis Contreras for the detailed OPSDIR review. I appreciate that > the > authors engaged and implemented the outcome of the discussion with Luis. > Much > appreciated. > > > > <S> Thanks a lot, Med and thanks to those who contributed to the draft in > any way (discussions, reviews, proposed texts,...). > > Please find below one easy-to-fix point for DISCUSSion: > > # Circuit Style > > CURRENT: > This document uses the following term described in > [I-D.ietf-spring-cs-sr-policy]: > > * Circuit Style (CS) SR Policy > > ## That notion is important to digest as these extensions are defined for > that > case. > > ## Unless you want to add this as normative, and as this is only one term, > you > may mirror that definition here to avoid normative dependency. > > ## BTW, note that this term is not used as such Circuit Style SR Policy > > <S> Even if mirroring that definition is not ideal, but I think that it is > stable enough and we can possibly still reference spring document like this: > > > > This document defines the following terms: > > - Circuit Style (CS) SR Policy: An SR Policy designed to satisfy > requirements for connection-oriented transport services. CS SR Policies are > characterized by path persistency (where the path should remain stable > unless explicitly changed or becomes invalid) and may require strict > hop-by-hop path construction. Further details on CS SR Policies are > described in <xref target="I-D.ietf-spring-cs-sr-policy"/>. > - Path Modification: Refers to the PCE instructing the PCC, via a > PCUpd message, to use a path whose set of traversed network hops differs > from the current path. A PCUpd message that changes only the attributes or > re-encodes the same hop sequence (e.g., alternative SID representation) is > not considered a path modification. > > > > Would that work for you? > > *[Med] Yes, it does. I see that I-D.ietf-spring-cs-sr-policy is scheduled > for this telechat as well.* > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Flags > > ## > > CURRENT: > This document defines the following new flags in that > TLV: > > Maybe better to point to > *https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-capability-tlv-flag-field > <https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-capability-tlv-flag-field>* > where the up to date set of flags are maintained. This is better than the > sole > RFC8231 pointer. > > <S> That IANA registry is referenced in IANA section by registry name > already (instead of using direct link, which does not seem to be common > practice in other existing RFCs). What about just adding reference to > section 8.1 and indicate that has more details about IANA registry with > existing values? > > *[Med] The reflex I had when reading that part is whether we are tracking > the flags and that guards are there to avoid flag conflicts, etc. I have to > look in the IANA registry for that check. I would save other readers like > me by providing the IANA registry near that text.* > > <S2> But isn’t a “flag conflict,” for example, a problem while the draft > is still "evolving," but not something that should happen in the RFC once > it is published (so it should become less important soon)? I tried to check > if using a direct link to the IANA registry is common practice in a few > selected RFCs (not just from the PCEP WG), but I don’t see them being used, > even though most PCEP RFCs introduce some sort of capabilities, so they > might have similar “issue". Are you aware about any existing RFCs > pointing to IANA registry directly? > > > I understand your concern and agree that it would be easier for readers to > use a direct link, but I’m a bit worried that there might be a good reason > why just registry names are preferred over URLs (e.g. guaranteed liveness > of those links) in most RFCs. I’ll ask the chairs or AD to chime in if they > have any preference or if they have any context. > > > Dhruv: For the IANA Consideration section, the advice is to include a URL, but it is not mandated. https://www.ietf.org/archive/id/draft-ietf-ianabis-rfc8126bis-01.html#section-3.1 But this text is outside of the IANA consideration section. I like Samuel's suggestion to add some text pointing to the IANA consideration section and adding a direct URL to the registry there as suggested by 8126bis. Thanks! Dhruv > That would maintain consistency and still at least partially simplify > lookup for those values without introducing any risk - e.g. if liveness of > those URLs is not guaranteed. > > ## > > CURRENT: > This document specifies the new Strict-Path flag in the LSP-EXTENDED- > FLAG TLV. > > Maybe point to > *https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags > <https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags>* > as > well. > > <S> Same as above. > > *[Med] Idem as well.* > > > > # Section 3.3 > > I would make this change: > > OLD: When F is set to 1, the P flag value is ignored. > > NEW: When F is set to 1, the P flag value MUST be ignored. > > <S> Ack, I'll change it. > > *[Med] ACK* > > > > # Avoid Geocoordinate interfaces > > OLD: > or northbound Application Programming Interface > (API) on the PCE). > > NEW: > or a dedicated Application Programming Interface > (API) on the PCE). > > <S> It seems to be standard term used in other RFCs, e.g. > > *https://datatracker.ietf.org/doc/html/rfc7426#section-4 > <https://datatracker.ietf.org/doc/html/rfc7426#section-4>* > > But I can still change it (no harm). > > *[Med] Putting aside that 7426 is not an IETF doc, the reason why I’m in > favor for geocoordinate interfaces is that there are relative, confusing, > break when recursing is in place, etc. Anyway, thanks for accommodating and > making the change.* > > # Clarity of flag checks > > OLD: > P flag set (P=1): > > NEW: > P flag set (P=1) and F=0: > > <S> Even if I agree with you that combination is the only one valid, but > that paragraph is really describing P=1 with both cases - F=0 and F=1. > Originally we tracked all combinations of flags and we explicitly tried to > define each flag separately now to simplify extensibility in the future. > > *[Med] The reason why I made this comments is that we do say under the > description “When F is set to 1, the P flag value is ignored”. So for me, > P=1, F=1 is still a valid (as this does not trigger any error message), but > that P is simply ignored.* > > *BTW, intuitively, I would put F before P in Figure 1, but I didn’t made > that suggestion as I don’t want to alter any implementation out there.* > > <S2>I’ll change it (original proposal, not the order of flags), even if I’m > a bit concerned that this will re-open original discussion about dependency > between those flags and each of them not defined independently potentially > leading to more complex introducing of new flags in the future. > > I know the context of that naming in PCE, but the considerations are beyond > management. Also, in order to be consistent with latest discussion in OPS, > I > suggest the following change: > > OLD: 8. Manageability Considerations > > NEW: 8. Operational Considerations > > <S> I'm not sure if that would not create even more confusion, especially > since this draft is really not introducing any new considerations and just > referring to existing "Manageability Considerations" sections in existing > RFCs. But I was not following discussion which you mentioned, can you > please point me that "latest discussion in OPS"? > > *[Med] This is related to RFC5706bis mentioned in Luis review. I don’t see > any issue out there. Please see the change proposed by Rakesh to address > this similar point at > **https://mailarchive.ietf.org/arch/msg/pce/4Sy0SrTXoeD4UCTf9946IsmRhlE/ > <https://mailarchive.ietf.org/arch/msg/pce/4Sy0SrTXoeD4UCTf9946IsmRhlE/>**. > Thanks.* > > <S2> SI’ll change it. > > > # nits > > ## paradigm > > Source routing was there before SR. Can we please consider this change > through > the doc: > > OLD: source routing paradigm > > NEW: source routing > > ## One term > > OLD: This document uses the following terms defined in [RFC9256]: > > NEW: This document uses the following term defined in [RFC9256]: > > ## Section 3 > > OLD: > * Indicate the requirement for strict hop-by-hop paths, > > * Signal path persistency by disabling path modification for > specific paths, > > * Identify and control behavior specific to CS SR policies. > > NEW: > * Indicate the requirement for strict hop-by-hop paths, > > * Signal path persistency by disabling path modification for > specific paths, and > > * Identify and control behavior specific to CS SR policies. > > ## draft > > OLD: Circuit-Style Policy draft [I-D.ietf-spring-cs-sr-policy] > > NEW: Circuit-Style Policy [I-D.ietf-spring-cs-sr-policy] > > <S> Ack, updated all of them. > > *[Med] Thank you Samuel.* > > > Cheers, > Med > > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
