Hi Christian & Andrew, On Thu, Jan 29, 2026 at 2:02 AM Christian Schmutzer (cschmutz) < [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]
