Hi Dhruv
I agree with you that the level of protocol detail in Section 6 does seem inconsistent, not just with the other sections (for example the BGP section is does not go into such a level of detail), but also the intent of the document (which are more of a high level framework) . I think these PCEP details (e.g. flag values) could be specified in Section 4 of draft-ietf-pce-circuit-style-pcep-extensions, and the PCEP part of Section 6 be more descriptive, similar to the BGP section. Matthew From: Dhruv Dhody <[email protected]> Date: Thursday, 29 January 2026 at 09:55 To: Christian Schmutzer (cschmutz) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Matthew Bocci (Nokia) <[email protected]>, [email protected] <[email protected]>, <[email protected]> Subject: Re: draft-ietf-spring-cs-sr-policy-13 ietf last call Rtgdir review CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Christian & Andrew, On Thu, Jan 29, 2026 at 2:02 AM Christian Schmutzer (cschmutz) <[email protected]<mailto:[email protected]>> wrote: Hi Dhruv, Thank you for your review and comments and sorry it took so long to respond. Please see comments inline via [cs]. Mentioned changes are incorporated into the newly uploaded -14 version. On the topic of removing normative language we previously got the feedback to add normative language Matthew: "I suggest consistency in the sue of RFC2119 language (e.g. MAY vs may)" https://mailarchive.ietf.org/arch/msg/rtg-dir/55qOHVpKgazkqXD7Ab-3pjZDDQo/ Yao: "d) Key words("MUST", "SHOULD", "RECOMMENDED"...) are suggested to be added in some places" https://mailarchive.ietf.org/arch/msg/spring/jbL3W36g98An2jkbuoy9sU6mjkw/ Can you (including Matthew and Yao) please clarify on what to do here to address both this and previous comments in a non-conflicting manner? Dhruv: I guess this is a case for - Ask ten people, and you’ll get ten opinions! :) When I said -> > ## Major > > - The document makes use of BCP14 keywords to provide protocol-level guidance > in an Informational SPRING document. In several cases, this appears to restate > existing protocol behavior, while in other cases it introduces new normative > expectations on protocol behavior. For new normative protocol behavior, the > place to specify it is in the respective protocol documents standards track > document within the respective WGs. IMHO this document should focus at the > abstract architecture level in the style of RFC 9256 and not go into details > of > protocol procedures. I was mainly focused on section 6 (and few other places) where you talk about PCEP and BGP speaker behaviors. With my PCE WG chair hat on, I found that an informational SPRING document should not be defining protocol behavior with normative keywords when that can be easily done in the PCE WG standards track drafts. Personally, I think this draft has way too many protocol details for my liking! Hi Mathew, Yao, Let me know what you think? Happy to be corrected! But If we can't come to an agreement, I guess we can let the responsible AD take the call. Further, I notice the use of RECOMMENDED for single segment list per CP, but if multiple SLs per CP is allowed (even though not recommended), the document should clarify how they are to be handled to meet the stated requirements. [cs] isn’t “to avoid asymmetrical routing due to independent load balancing across segment lists on each headend” covering this? Dhruv: My comment is about how the PCC would behave if your recommendation is not followed and you get a CS-SR policy with multiple SLs. - In section 8.2.1, "The P bit may be..", you need to specify where is this P bit? I think you meant P flag in the Common Object Header, in which case you should reference RFC 9753. "The "Objective Function (OF) TLV" as defined", the correct TLV name is OF-List TLV. [cs] no this part is about the flags in the DISJOINTNESS-CONFIGURATION TLV and its P flag https://datatracker.ietf.org/doc/html/rfc8800#section-5.2-7.6.2.8 But I see that the use of “bit” can be confusing. I adopted “bit” because it was used in the list of flags described here https://datatracker.ietf.org/doc/html/rfc8800#section-5.2-5. but I now see that through the document “P flag” is used instead of “P bit”. I change to flag now. Dhruv: Add "(Shortest Path)" with P flag as per 8800 to give a hint to its meaning and to avoid confusion? Also, change the name of TLV to OF-List TLV! Thanks! Dhruv
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
