I'm supportive of John's comment here. -- Jeff (who regrets remembering what OSPF LSA numbers are for similar reasons.)
> On Sep 16, 2025, at 2:45 PM, John Scudder <[email protected]> wrote: > > Hi Karen, all, > > I have one concern to discuss. I’ve tried to suss out the answer by looking > through the email thread quickly, but am still puzzled; perhaps one of you > has the answer at their fingertips. > > Table 6 in the approved document included both a short name (“Type K”, for > example) and a prose description (“IPv6 Addresses for link endpoints as > Local, Remote pair for SRv6” would be the current version, per the Table 1 > update). The new version of Table 6 gives only the short name ("Type K > Segment”). > > It seems to me that the table is a more useful reference for human beings if > it includes a prose description for each item. I acknowledge that this > introduces some redundancy with Table 1, and I see that the RFC Editor raised > this as a concern — but Table 6 is part of the IANA registry and Table 1 is > not, and the work to align the descriptions in the two tables is a one-time > effort and doesn’t seem onerous. > > Can someone explain to me what the rationale was for making this change? If > there is not a strong preference for the current format, I would favor > restoring the long descriptions to Table 6. > > A similar point applies to the changes to the titles of Sections 5.7.1.1.1 - > 5.7.1.1.11. In my experience, while some (many?) implementors end up > memorizing “Type K means mumble foo”, more casual users of the spec are often > unnecessarily hampered by excessive brevity of this kind. (Honest, it’s not > just me; other people have complained to me about this.) > > The other changes look fine to me. > > $0.02, > > —John > >> On Sep 16, 2025, at 2:21 PM, Karen Moore <[email protected]> wrote: >> >> [External Email. Be cautious of content] >> >> >> Hi Jeff and *John (AD), >> >> Thank you for providing your approval of the document; we have noted it here >> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$ >> >. We now await approvals from Hannes, Jie, and Stefano. >> >> *John, please review the following updates and let us know if you approve. >> The changes can be reviewed here: >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$ >> >. >> >> 1) Update to the description of “V-Flag” in Section 5.3 (added “MUST”) >> 2) Updates to Table 1 in Section 5.7.1.1 to match the descriptions in RFCs >> 9256, 9830, and 9831 >> 3) Updates to Table 6 in Section 8.5 (FYI: updates will be needed to the >> "BGP-LS SR >> Segment Descriptor Types” IANA registry at >> <https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$ >> >) >> 4) Updates to the titles of Sections 5.7.1.1.1 - 5.7.1.1.11 to more closely >> match Table 6 >> >> >> —Files (please refresh)— >> >> Updated XML file: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$ >> >> Updated output files: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$ >> >> Diff files showing all changes made during AUTH48: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW_WrJjiA$ >> (side by side) >> >> Diff files showing only changes made during the last editing round: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX_hYqEJQ$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyV2Omod4w$ >> >> Diff files showing all changes: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$ >> (side by side) >> >> For the AUTH48 status of this document, please see: >> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$ >> >> Best regards, >> >> Karen Moore >> RFC Production Center >> >> >>> On Sep 16, 2025, at 7:56 AM, Jeff Tantsura <[email protected]> wrote: >>> >>> Hi Karen, >>> >>> Approved. >>> Thanks! >>> >>> Cheers, >>> Jeff >>> >>>> On Sep 15, 2025, at 13:00, Karen Moore <[email protected]> wrote: >>>> >>>> Hi Ketan, >>>> >>>> Thank you for the clarifications. We have updated 2 instances of >>>> “RESERVED” as advised in Section 5.7 and have updated Table 1 to match the >>>> descriptions in RFCs 9256, 9830, and 9831. Please review. We have also >>>> noted your approval of the document. >>>> >>>> If any further updates are needed in Sections 5.7.1.1.1 - 5.7.1.1.11 to >>>> more closely match the wording/changes in Table 1, please let us know. >>>> >>>> Note that we await approvals of the document from all coauthors listed at >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$ >>>> prior to moving forward with publicaiton. >>>> >>>> —Files (please refresh)— >>>> >>>> Updated XML file: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$ >>>> >>>> Updated output files: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$ >>>> >>>> Diff files showing all changes made during AUTH48: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW_WrJjiA$ >>>> (side by side) >>>> >>>> Diff files showing only changes made during the last editing round: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX_hYqEJQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyV2Omod4w$ >>>> >>>> Diff files showing all changes: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$ >>>> (side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$ >>>> >>>> Best regards, >>>> >>>> Karen Moore >>>> RFC Production Center >>>> >>>> >>>> >>>> On Sep 14, 2025, at 8:18 PM, Ketan Talaulikar <[email protected]> >>>> wrote: >>>> >>>> Hi Karen, >>>> >>>> Please check inline below for responses. >>>> >>>> Besides the comment below about Table 1, there is only one minor update >>>> needed: For the fields that were marked as RESERVED1 and 2 in the figures, >>>> please make the same change in the individual field descriptions below >>>> those figures as well. >>>> >>>> Once these are taken care of, please consider this email as my approval >>>> for publication. >>>> >>>> >>>> On Sat, Sep 13, 2025 at 5:35 AM Karen Moore <[email protected]> >>>> wrote: >>>> Hi Ketan, >>>> >>>> Thank you for your comment and close review of the questions/document. We >>>> have updated our files per your suggestions. Please note that we have a >>>> few additional questions. >>>> >>>> 1) Regarding the comments below, we updated the titles of Sections >>>> 5.7.1.1.1 - 5.7.1.1.11 accordingly. We also updated the descriptions in >>>> Table 6, which we agree will align better with RFCs-to-be 9830 and 9831. >>>> Please review to ensure the changes are correct. >>>> >>>> KT> Ack >>>> >>>>> Comparing this to RFC9830/1, the Table 1 is what is listed >>>>> in >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9830.html*section-2.4.4.2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyUhEMEjGg$ >>>>> and Table 6 is what is listed in >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$ >>>>> - more specifically, I would prefer >>>>> that we have alignment for the Table 1 column Segment Description with >>>>> the other two RFCs >>>>> with one change that we want to keep the (Type X) as a prefix in this >>>>> document. >>>>> >>>>> KT> There is no change required for Table 1, however, we can and perhaps >>>>> should >>>> >>>>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect RFC9830 >>>>> sections >>>>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. >>>>> >>>>> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment Type A >>>>> >>>>> This will make the section headings short and align with the other two >>>>> RFCs that specify >>>>> the southbound BGP signaling while this document specifies its northbound >>>>> reporting. >>>>> >>>>> The titles for figures are ok. >>>>> >>>>> The descriptions can then be changed along the lines of >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$ >>>>> >>>>> As an example: (Type A) SR-MPLS Label -> Type A Segment >>>>> >>>>> Please let me know your views from the perspective of readability and >>>>> alignment across RFC9256 and >>>>> the 3 BGP RFCs under RFC Editor currently including this document. >>>> >>>> 2) It was mentioned that no changes were required for Table 1 - want to >>>> clarify if that is still the case or if any further updates are needed for >>>> consistency with the wording/style in Table 2 of RFC 9256. >>>> >>>> KT> The descriptions originate from >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9256.html*table-2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVy0twDtg$ >>>> and so, we should try to make things consistent with that. The same is >>>> there in >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9830*section-2.4.4.2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVCaIBrBg$ >>>> and >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9831*section-2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVZzeoH8g$ >>>> - therefore, the Table 1 descriptions should be the same. The only >>>> exception is that the alphabetical Type is indicated in brackets to >>>> provide the necessary correlation between the two separate code point >>>> spaces. I hope this also covers the queries below. >>>> >>>> Thanks, >>>> Ketan >>>> >>>> >>>> >>>> Please also consider the following. >>>> >>>> a) Section 5.7.1.1.6 describes the IPv4 Local & Remote Interface Addresses >>>> as a “pair”; is “pair" correct to add to the description of Type F in >>>> Table 1? >>>> >>>> Current: >>>> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses >>>> >>>> Perhaps A: >>>> (Type F) SR-MPLS Adjacency SID as pair of IPv4 Local & Remote Interface >>>> Addresses >>>> >>>> Perhaps B (in attempt to follow the style of RFC 9256): >>>> (Type F) IPv4 Interface Addresses for SR-MPLS Adjacency SID as Local, >>>> Remote pair >>>> >>>> b) Does the pair consist of one IPv6 global address and one interface ID? >>>> Please let us know if any clarifcation is needed. This applies to Types G >>>> (Section 5.7.1.1.7) and J (Section 5.7.1.1.10). >>>> >>>> Table 1: >>>> Current: >>>> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface >>>> ID for >>>> Local & Remote nodes >>>> >>>> Perhaps A: >>>> (Type G) SR-MPLS Adjacency SID as pair of an IPv6 Global Address & >>>> Interface ID for Local & Remote Nodes >>>> >>>> Perhaps B (in attempt to follow the style of RFC 9256): >>>> (Type G) IPv6 Global Address & Interface ID for SR-MPLS Adjacency SID as >>>> Local, Remote Node pair >>>> >>>> Section 5.7.1.1.7 >>>> Current: >>>> The Segment is an SR-MPLS Adjacency SID type and is specified as a >>>> pair of IPv6 global address and interface ID for local and remote >>>> nodes. >>>> >>>> Perhaps: >>>> The Segment is an SR-MPLS Adjacency SID type and is specified as a >>>> pair of one IPv6 global address and one interface ID for local and remote >>>> nodes. >>>> >>>> --Files-- >>>> Note that it may be necessary for you to refresh your browser to view the >>>> most recent version. Please review the document carefully to ensure >>>> satisfaction as we do not make changes once it has been published as an >>>> RFC. >>>> >>>> We will await approvals from each author prior to moving forward in the >>>> publication process. >>>> >>>> Updated XML file: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$ >>>> >>>> Updated output files: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$ >>>> >>>> Diff files showing all changes made during AUTH48: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW_WrJjiA$ >>>> (side by side) >>>> >>>> Diff files showing all changes: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$ >>>> (side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$ >>>> >>>> Best regards, >>>> >>>> Karen Moore >>>> RFC Production Center >>>> >>>> >>>>> On Sep 11, 2025, at 5:14 AM, Ketan Talaulikar <[email protected]> >>>>> wrote: >>>>> >>>>> Hi Karen & Allana, >>>>> >>>>> Thanks for your help with this document. I realize it was challenging >>>>> given the inconsistent use of terms within the document and across its >>>>> related documents. Appreciate your tidying it up for publication. >>>>> >>>>> Please check inline below for responses. >>>>> >>>>> >>>>> On Thu, Sep 11, 2025 at 3:39 AM <[email protected]> wrote: >>>>> Authors, >>>>> >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) the following questions, which are also in the source file. >>>>> >>>>> 1) <!--[rfced] May we update "PCEP protocol" to simply read "PCEP" to >>>>> avoid redundancy? If expanded, "PCEP protocol" would read as "Path >>>>> Computation Element Communication Protocol protocol". >>>>> >>>>> Original: >>>>> As illustrated in the figure below, the >>>>> PCC is not an LSR in the routing domain, thus the head-end nodes of >>>>> the SR Policies may not implement the PCEP protocol. >>>>> >>>>> Perhaps: >>>>> As illustrated in the figure below, the >>>>> PCC is not an LSR in the routing domain, thus the head-end nodes of >>>>> the SR Policies may not implement the PCEP. >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 2) <!--[rfced] In Section 3, should the list be formatted as a definition >>>>> list for ease of reading and consistency with other sections? >>>>> >>>>> Original: >>>>> Where: >>>>> >>>>> * Protocol-ID field specifies the component that owns the SR Policy >>>>> state in the advertising node. An additional Protocol-ID "Segment >>>>> Routing" (value 9) is introduced by this document that MUST be >>>>> used for advertisement of SR Policies. >>>>> >>>>> * "Identifier" is an 8 octet value as defined in section 5.2 of >>>>> [RFC9552]. >>>>> >>>>> * "Local Node Descriptor" (TLV 256) [RFC9552] is used as specified >>>>> further in this section. >>>>> >>>>> * The SR Policy Candidate Path Descriptor TLV is specified in >>>>> Section 4. >>>>> >>>>> Perhaps: >>>>> Where: >>>>> >>>>> * Protocol-ID field: Specifies the component that owns the SR Policy >>>>> state in the advertising node. An additional Protocol-ID "Segment >>>>> Routing" (value 9) is introduced by this document that MUST be >>>>> used for the advertisement of SR Policies. >>>>> >>>>> * Identifier: 8-octet value as defined in Section 5.2 of [RFC9552]. >>>>> >>>>> * Local Node Descriptors (TLV 256): Defined in [RFC9552] and used as >>>>> specified further in this section. >>>>> >>>>> * SR Policy Candidate Path Descriptor TLV: Specified in Section 4. >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 3) <!--[rfced] As shown below, we removed "Number" from "Autonomous >>>>> System Number (TLV 512)" per RFC 9552, and we removed "ASN" >>>>> following "AS Confederation Identifier" as it is not present in >>>>> RFC 5065. Note that this change was also applied to similar text >>>>> in Section 3.2. Please let us know of any objections. >>>>> >>>>> Note that "ASN" was expanded only on the first mention. >>>>> >>>>> Original: >>>>> * Autonomous System Number (TLV 512) [RFC9552], which contains the >>>>> ASN (or AS Confederation Identifier (ASN) [RFC5065], if >>>>> confederations are used) of the headend node of the SR Policy. >>>>> >>>>> Current: >>>>> * Autonomous System (TLV 512) [RFC9552], which contains the >>>>> Autonomous System Number (ASN) (or AS Confederation Identifier >>>>> [RFC5065], if confederations are used) of the headend node of >>>>> the SR Policy. >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 4) <!--[rfced] In RFC 9552, we note that "IGP Router-ID" is listed as >>>>> both a sub-TLV and a TLV code point. As "sub-TLV" and "TLV" are >>>>> not included in the description, how may we update "IGP Router-ID >>>>> sub-TLV (TLV 515)" for conciseness? Would "IGP Router-ID >>>>> (sub-TLV/TLV 515)" be correct? Note that there are two instances >>>>> in the document. >>>>> >>>>> Original: >>>>> The determination of whether the >>>>> IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID >>>>> or a 6-octet ISO System-ID is to be done based on the length of >>>>> that sub-TLV since the Protocol-ID in the NLRI is always going to >>>>> be "Segment Routing". >>>>> >>>>> Perhaps: >>>>> The determination of whether the >>>>> IGP Router-ID (sub-TLV/TLV 515) contains a 4-octet OSPF Router-ID >>>>> or a 6-octet ISO System-ID is to be done based on the length of >>>>> that sub-TLV because the Protocol-ID in the NLRI is always going >>>>> to be "Segment Routing". >>>>> --> >>>>> >>>>> KT> The reference here is to the TLV and the IANA registry is for TLV >>>>> codepoints but they can also be used as sub-TLVs. So, I agree that your >>>>> suggestion is better, but how about "IGP Router-ID (TLV 515)" ? >>>>> >>>>> >>>>> >>>>> 5) <!-- [rfced] We note that Section 6.2.3 of RFC 9256 uses >>>>> "Specified-BSID-only". Given this, should "Specified BSID" be >>>>> updated for consistency? >>>>> >>>>> Original: >>>>> The TLV MAY also optionally contain the Specified BSID value for >>>>> reporting as described in section 6.2.3 of [RFC9256]. >>>>> >>>>> Perhaps: >>>>> The TLV MAY also optionally contain the Specified-BSID-only value >>>>> for reporting as described in Section 6.2.3 of [RFC9256]. >>>>> --> >>>>> >>>>> KT> This change is not appropriate. Here, the idea is to signal the >>>>> Specified-BSID value. Whether or not the Specified-BSID-only is to be >>>>> used is indicated by a different flag. >>>>> >>>>> >>>>> >>>>> 6) <!--[rfced] Please clarify if "BSID" should be singular (option A) or >>>>> plural (option B) in the following: >>>>> >>>>> Original: >>>>> D-Flag: Indicates the dataplane for the BSIDs and if they are >>>>> 16 octet SRv6 SID (when set) or are 4 octet SR/MPLS >>>>> label value (when clear). >>>>> >>>>> Perhaps A: >>>>> D-Flag: Indicates the data plane for the BSIDs and if a BSID is >>>>> a 16-octet SRv6 SID (when set) or a 4-octet SR/MPLS >>>>> label value (when clear). >>>>> >>>>> Perhaps B: >>>>> D-Flag: Indicates the data plane for the BSIDs and if the BSIDs >>>>> are 16-octet SRv6 SIDs (when set) or 4-octet SR/MPLS >>>>> label values (when clear). >>>>> --> >>>>> >>>>> KT> A is better. >>>>> >>>>> >>>>> >>>>> 7) <!--[rfced] We note that Figures 7 and 19 use "Sub-TLVs" (capitalized), >>>>> while Figures 11 and 18 use "sub-TLVs" (lowercased). Should these be >>>>> consistent? If yes, which form is preferred? >>>>> --> >>>>> >>>>> KT> Here "sub-TLVs" is appropriate as it is not referring to a specific >>>>> sub-TLV name. >>>>> >>>>> >>>>> >>>>> >>>>> 8) <!--[rfced] We note multiple instances of "MUST be set to 0 by the >>>>> originator and MUST be ignored by a receiver". Should the one >>>>> instance below that contains only one "MUST" be updated >>>>> accordingly (see Section 5.3)? >>>>> >>>>> Original: >>>>> V-Flag: Indicates the candidate path has at least one valid SID-List >>>>> when set and indicates no valid SID-List is available or evaluated >>>>> when clear. When the E-Flag is clear (i.e. the candidate path has not >>>>> been evaluated), then this flag MUST be set to 0 by the originator and >>>>> ignored by the receiver. >>>>> >>>>> Perhaps: >>>>> V-Flag: Indicates that the candidate path has at least one valid SID-List >>>>> when set and that no valid SID-List is available or evaluated when clear. >>>>> When the E-Flag is clear (i.e., the candidate path has not been >>>>> evaluated), >>>>> then this flag MUST be set to 0 by the originator and MUST be ignored by a >>>>> receiver. >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 9) <!--[rfced] Please review 2 instances of the term "NULL" in this >>>>> document. Should "NULL terminator" be "NUL terminator" or "null >>>>> terminator" for correctness? We ask per guidance received from a >>>>> Gen Art reviewer. Note that RFC 9256 uses "null endpoint", >>>>> "Explicit Null Label Policy", and "IPv6 Explicit NULL Label". >>>>> >>>>> Current: >>>>> SR Policy Name: Symbolic name for the SR Policy without a NULL >>>>> terminator as specified in Section 2.1 of [RFC9256]. >>>>> >>>>> Candidate Path Name: Symbolic name for the SR Policy candidate path >>>>> without a NULL terminator as specified in Section 2.6 of >>>>> [RFC9256]. >>>>> --> >>>>> >>>>> KT> It should be the NUL - which is what I believe it is called in ASCII. >>>>> >>>>> >>>>> >>>>> 10) <!--[rfced] How may we clarify this "either" sentence. Is the intended >>>>> meaning that the dynamic path is computed by the headend or >>>>> delegated to a controller (option A)? Or that the dynamic path is >>>>> computed by the headend or by delegation to a controller (option B)? >>>>> >>>>> Original: >>>>> The constraints are generally applied to a dynamic candidate path which is >>>>> computed either by the headend or may be delegated to a controller. >>>>> >>>>> Perhaps A: >>>>> The constraints are generally applied to a dynamic candidate path that is >>>>> either computed by the headend or delegated to a controller. >>>>> >>>>> Perhaps B: >>>>> The constraints are generally applied to a dynamic candidate path that is >>>>> computed by either the headend or delegation to a controller. >>>>> --> >>>>> >>>>> KT> A is correct. >>>>> >>>>> >>>>> >>>>> 11) <!--[rfced] We note that Figure 15 uses "Request-Flags" and >>>>> "Status-Flags" >>>>> (hyphenated), while the definitions of these fields use "Request Flags" >>>>> and "Status Flags" (unhyphenated). To make these consistent, which form is >>>>> preferred? >>>>> --> >>>>> >>>>> KT> the unhyphenated please >>>>> >>>>> >>>>> >>>>> 12) <!-- [rfced] For consistency, should "Association Object" be updated >>>>> to "ASSOCIATION object" per use in Section 6.1 of [RFC8697]? Note >>>>> that there are four instances. >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 13) <!--[rfced] How may we rephrase the text in Section 5.6.6 for clarity? >>>>> >>>>> KT> I think a copy/paste error from my side in section 5.6.6 with >>>>> referencine Table 1 has caused a confusion between metric types and >>>>> segment types. >>>>> >>>>> In the first sentence, we note that Table 1 (Section 5.7.1.1) >>>>> does not list references for the types. Should the term >>>>> "reference" be replaced with "Segment Descriptor" or other for >>>>> conciseness? And may we rephrase the second sentence as shown >>>>> below for clarity and to make it parallel? >>>>> >>>>> We also note that Tables 1 and 6 contain the same information. Should >>>>> Table 1 be removed and references to Table 1 (in Sections 5.6.6 and >>>>> 5.7.1.1) be updated to point to Table 6? >>>>> >>>>> KT> The two tables have different purposes. The Table 1 provides the >>>>> mapping between the >>>>> segment types (A to K) defined in RFC 9256 with the code points of the >>>>> types defined in >>>>> this document. While table 6 represents the initial allocations for the >>>>> codepoints >>>>> for the segment types for IANA. Comparing this to RFC9830/1, the Table 1 >>>>> is what is listed >>>>> in >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9830.html*section-2.4.4.2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyUhEMEjGg$ >>>>> and Table 6 is what is listed in >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$ >>>>> - more specifically, I would prefer >>>>> that we have alignment for the Table 1 column Segment Description with >>>>> the other two RFCs >>>>> with one change that we want to keep the (Type X) as a prefix in this >>>>> document. >>>>> >>>>> KT> There is no change required for Table 1, however, we can and perhaps >>>>> should >>>>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect RFC9830 >>>>> sections >>>>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. >>>>> >>>>> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment Type A >>>>> >>>>> This will make the section headings short and align with the other two >>>>> RFCs that specify >>>>> the southbound BGP signaling while this document specifies its northbound >>>>> reporting. >>>>> >>>>> The titles for figures are ok. >>>>> >>>>> The descriptions can then be changed along the lines of >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$ >>>>> >>>>> As an example: (Type A) SR-MPLS Label -> Type A Segment >>>>> >>>>> Please let me know your views from the perspective of readability and >>>>> alignment across RFC9256 and >>>>> the 3 BGP RFCs under RFC Editor currently including this document. >>>>> >>>>> >>>>> Original (Section 5.6.6): >>>>> The Table 1 below lists the metric types introduced by this document >>>>> along with reference for each. Where the references are for IS-IS >>>>> and OSPF specifications, those metric types are defined for a link >>>>> while in the SR Policy context those relate to the candidate path >>>>> or the segment list. >>>>> >>>>> Perhaps: >>>>> Table 6 lists the metric types introduced by this document along >>>>> with a Segment Descriptor for each. Where the Segment Descriptors >>>>> relate to IS-IS and OSPF specifications, the metric types are defined >>>>> for a link. Where the Segment Descriptors relate to the SR Policy, >>>>> the metric types are defined for a candidate path or a segment list. >>>>> >>>>> >>>>> KT> Can you please fix/update this blob as below? >>>>> >>>>> Below is a list of metric types introduced by this document >>>>> along with references for each. Where the references are for IS-IS >>>>> and OSPF specifications, those metric types are defined for a link >>>>> while in the SR Policy context those relate to the candidate path >>>>> or the segment list. >>>>> >>>>> The "list" is actually right after the paragraph with this text and the >>>>> reference to Table 1 >>>>> was an error. I hope this clarifies. >>>>> >>>>> ... >>>>> Original (Section 5.7.1.1) >>>>> The following types are currently defined and their mapping to the >>>>> respective segment types defined in [RFC9256]: >>>>> >>>>> Perhaps: >>>>> See Table 6 for the type definitions and their mappings to the >>>>> respective segment types defined in [RFC9256]. >>>>> --> >>>>> >>>>> KT> The above change is now not necessary. >>>>> >>>>> >>>>> >>>>> 14) <!--[rfced] For clarity, should the registry that the metric types are >>>>> taken from be listed here instead of only the registry that they are >>>>> not listed in? >>>>> >>>>> Original: >>>>> Note that the metric type in this field is not taken from the "IGP >>>>> Metric Type" registry from IANA "IGP Parameters" and is a separate >>>>> registry that includes IGP Metric Types as well as metric types >>>>> specific to SR Policy path computation. >>>>> >>>>> Perhaps: >>>>> Note that the metric types in this field are taken from the >>>>> "BGP-LS SR Policy Metric Types" IANA registry, which includes >>>>> IGP Metric Types as well as metric types specific to SR Policy >>>>> path computation (i.e., the metric types are not from the >>>>> "IGP Metric-Type" registry). >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 15) <!--[rfced] In Section 5.6.6, we updated "Average" to "Avg" to >>>>> match use in Table 7 and the "BGP-LS SR Policy Metric Types" >>>>> registry. If you prefer to update the registry to reflect >>>>> "Average" instead of "Avg", please let us know. >>>>> >>>>> Link to registry: >>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$ >>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>. >>>>> >>>>> Original: >>>>> Type 6: Average Unidirectional Delay: >>>>> >>>>> Current: >>>>> Type 6: Avg Unidirectional Delay: >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 16) <!--[rfced] We note that Figure 18 contains two "RESERVED" fields. >>>>> As these are two distinctly different fields, should they be updated >>>>> as "RESERVED1" and "RESERVED2", which would reflect Figure 11? >>>>> --> >>>>> >>>>> KT> Yes, please do the same for Figure 11 >>>>> >>>>> >>>>> >>>>> >>>>> 17) <!--[rfced] Table 6 (Section 8.5) specifies the SRv6 SID as an "IPv6 >>>>> address", but Section 5.7.1.1.2 specifies it as an "SRv6 SID address". >>>>> Is an update needed in Section 5.7.1.1.2 for consistency with Table 6? >>>>> >>>>> Original: >>>>> The Segment is SRv6 type and is specified simply as the SRv6 SID address. >>>>> >>>>> Perhaps: >>>>> The Segment is an SRv6 type and is specified simply as the IPv6 address. >>>>> --> >>>>> >>>>> KT> It should just say "SRv6 SID" in 7.7.1.1.2 and in Table 6. But please >>>>> refer to the previous suggestion on Table 6. >>>>> >>>>> >>>>> >>>>> 18) <!--[rfced] In Section 5.7.1.1.6, should "interface" be added to more >>>>> closely match Table 6 (the "BGP-LS SR Segment Descriptor Types" >>>>> registry)? >>>>> >>>>> Link to registry: >>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$ >>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types >>>>> >>>>> Original: >>>>> IPv4 Local Address: >>>>> IPv4 Remote Address: >>>>> >>>>> Perhaps: >>>>> IPv4 Local Interface Address: >>>>> IPv4 Remote Interface Address: >>>>> >>>>> ... >>>>> Original (Figure 25): >>>>> IPv4 Local Address (4 octets) >>>>> IPv4 Remote Address (4 octets) >>>>> >>>>> Perhaps: >>>>> IPv4 Local Interface Address (4 octets) >>>>> IPv4 Remote Interface Address (4 octets) >>>>> --> >>>>> >>>>> KT> Ack for both >>>>> >>>>> >>>>> >>>>> 19) <!--[rfced] In Sections 5.7.1.1.8 and 5.7.1.1.11, should the following >>>>> be updated for consistency with the descriptions in Table 6 (the >>>>> "BGP-LS SR Segment Descriptor Types" registry)? >>>>> >>>>> Link to registry: >>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$ >>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types? >>>>> >>>>> Original: >>>>> IPv6 Local Address: >>>>> IPv6 Remote Address: >>>>> >>>>> Perhaps: >>>>> IPv6 Local Global Address: >>>>> IPv6 Remote Global Address: >>>>> >>>>> ... >>>>> Original (Figures 27 and 30): >>>>> Global IPv6 Local Interface Address (16 octets) >>>>> Global IPv6 Remote Interface Address (16 octets) >>>>> >>>>> Perhaps: >>>>> IPv6 Local Interface Global Address (16 octets) >>>>> IPv6 Remote Interface Global Address (16 octets) >>>>> --> >>>>> >>>>> KT> Ack for both. >>>>> >>>>> >>>>> >>>>> 20) <!-- [rfced] Section 4 of this document as well as RFC 9256 uses >>>>> "Protocol-Origin" rather than "Protocol Origin". Are any updates >>>>> needed to the "SR Policy Protocol Origin" registry name, two >>>>> instances of "SR Protocol Origin", or "Protocol Origin field"? >>>>> >>>>> Original: >>>>> Per this document, IANA has created and maintains a new registry >>>>> called "SR Policy Protocol Origin" under the "Segment Routing" >>>>> registry group with the allocation policy of Expert Review [RFC8126] >>>>> using the guidelines for designated experts as specified in >>>>> [RFC9256]. This registry contains the code points allocated to the >>>>> "Protocol Origin" field defined in Section 4. >>>>> --> >>>>> >>>>> KT> Lets use "Protocol-Origin" to be consistent with RFC9256 >>>>> >>>>> >>>>> >>>>> 21) <!--[rfced] Under the "Segment Descriptor" column in the "BGP-LS SR >>>>> Segment Descriptor Types" registry, should the following changes >>>>> be made to the code point descriptions? That is, add articles, >>>>> make names following "pair" plural, and capitalize instances of >>>>> "address" and "node", accordingly. >>>>> >>>>> The form to the right of the arrow is suggested. If changes are made, >>>>> we will update the running text accordingly (namely the subsections >>>>> under Section 5.7.1.1) as well as the IANA registry. >>>>> >>>>> Link to registry: >>>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$ >>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types> >>>>> >>>>> (Type B) SRv6 SID as IPv6 address -> (Type B) SRv6 SID as an IPv6 Address >>>>> >>>>> >>>>> (Type C) SR-MPLS Prefix SID as IPv4 Node Address -> >>>>> (Type C) SR-MPLS Prefix SID as an IPv4 Node Address >>>>> >>>>> (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address -> >>>>> (Type D) SR-MPLS Prefix SID as an IPv6 Node Global Address >>>>> >>>>> (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local Interface ID >>>>> -> >>>>> (Type E) SR-MPLS Adjacency SID as an IPv4 Node Address & a Local >>>>> Interface ID >>>>> >>>>> (Note: Section 5.7.1.1.6 describes Type F as a "pair"; is that correct to >>>>> add?) >>>>> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses >>>>> -> >>>>> (Type F) SR-MPLS Adjacency SID as a pair of IPv4 Local & Remote >>>>> Interface Addresses >>>>> >>>>> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface >>>>> ID for >>>>> Local & Remote nodes -> >>>>> (Type G) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses & >>>>> Interface IDs for Local & Remote Nodes >>>>> >>>>> (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for the >>>>> Local & Remote Interface -> >>>>> (Type H) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses for >>>>> Local & Remote Interface Addresses >>>>> >>>>> (Type I) SRv6 END SID as IPv6 Node Global Address -> >>>>> (Type I) SRv6 END SID as an IPv6 Node Global Address >>>>> >>>>> (Type J) SRv6 END.X SID as pair of IPv6 Global Address & Interface ID >>>>> for Local & Remote nodes -> >>>>> (Type J) SRv6 END.X SID as a pair of IPv6 Global Addresses & Interface >>>>> IDs >>>>> for Local & Remote Nodes >>>>> >>>>> (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for the Local & >>>>> Remote Interface -> >>>>> (Type K) SRv6 END.X SID as a pair of IPv6 Global Addresses for Local & >>>>> Remote Interface Addresses >>>>> --> >>>>> >>>>> KT> Please refer to my response to your point 13 that impacts this. With >>>>> that in mind, I would think >>>>> that these queries are no longer relevant? >>>>> >>>>> >>>>> >>>>> 22) <!--[rfced] FYI: In the Contributors section, we updated the lead-in >>>>> text as follows to indicate that the individuals listed are >>>>> coauthors. >>>>> >>>>> Original: >>>>> The following people have substantially contributed to the editing of >>>>> this document: >>>>> >>>>> Current: >>>>> The following people have contributed substantially to the >>>>> content of this document and should be considered coauthors: >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 23) <!-- [rfced] Terminology >>>>> >>>>> a) Throughout the text, the following terminology appears to be used >>>>> inconsistently. Please review these occurrences and let us know if/how >>>>> they >>>>> may be made consistent. >>>>> >>>>> -Flag vs. -flag >>>>> (e.g., "D-Flag" vs. "A-flag" in the running text) >>>>> >>>>> KT> -flag >>>>> >>>>> Metric Type field vs. "metric type" field >>>>> (Note: the companion document uses "metric type field" with no quote >>>>> marks) >>>>> >>>>> KT> metric type field - without the quotes >>>>> >>>>> Segment Descriptor vs. Segment descriptor >>>>> >>>>> KT> segment descriptor (except when used in titles where capitalization >>>>> is used) >>>>> >>>>> Segment List vs. segment list >>>>> >>>>> KT> 2nd >>>>> >>>>> SID-List vs. SID-list vs. SID-LIST vs. SID List >>>>> >>>>> KT> SID list to be consistent with a single usage in RFC9256 >>>>> >>>>> SR Policy Candidate Path NLRI Type vs. SR Policy Candidate Path NLRI type >>>>> >>>>> KT> 2nd >>>>> >>>>> >>>>> SR Policy Candidate Path vs. SR Policy Candidate path vs. SR Policy >>>>> candidate path >>>>> >>>>> KT> Capitalization when used in name (1st) and otherwise (3rd) >>>>> >>>>> >>>>> >>>>> b) We updated the following terms for consistency. Please let us know of >>>>> any objections. >>>>> >>>>> codepoint -> code point (per IANA registries) >>>>> dataplane -> data plane >>>>> drop upon invalid -> Drop-Upon-Invalid (per RFC 9256) >>>>> Global address -> global address (2 instances in the running text) >>>>> head-end -> headend >>>>> nexthop -> next hop >>>>> traffic engineering -> Traffic Engineering (per RFC 9552 and the >>>>> companion document) >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> c) FYI: We made "Constraints" in the following sub-TLV names singular for >>>>> consistency >>>>> with Table 4. >>>>> >>>>> SR Affinity Constraints Sub-TLV -> SR Affinity Constraint Sub-TLV (Figure >>>>> 12) >>>>> SR Bandwidth Constraints Sub-TLV -> SR Bandwidth Constraint Sub-TLV >>>>> (Figure 14) >>>>> >>>>> SR Bidirectional Group Constraints Sub-TLV -> >>>>> SR Bidirectional Group Constraint Sub-TLV (Figure 16) >>>>> >>>>> SR Disjoint Group Constraints Sub-TLV -> SR Disjoint Group Constraint >>>>> Sub-TLV (Figure 15) >>>>> SR Metric Constraints Sub-TLV -> SR Metric Constraint Sub-TLV (Figure 17 >>>>> and Section 5.7.2) >>>>> SR SRLG Constraints Sub-TLV -> SR SRLG Constraint Sub-TLV (Figure 13) >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> d) FYI: We updated 7 instances of "Descriptor" to "Descriptors" >>>>> for TLV 256 per RFC 9552. >>>>> >>>>> Local Node Descriptor (TLV 256) -> Local Node Descriptors (TLV 256) >>>>> --> >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> 24) <!-- [rfced] Abbreviations >>>>> >>>>> a) FYI - We have added expansions for the following abbreviations >>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>> expansion in the document carefully to ensure correctness. >>>>> >>>>> Autonomous System Number (ASN) >>>>> Bidirectional Forwarding Detection (BFD) >>>>> External BGP (EBGP) >>>>> Label Edge Routers (LERs) >>>>> Label Switched Path (LSP) >>>>> Label Switching Router (LSR) >>>>> Network Layer Reachability Information (NLRI) >>>>> Path Computation Element Communication Protocol (PCEP) >>>>> >>>>> KT> Ack >>>>> >>>>> >>>>> >>>>> b) To reflect more common usage in previously published RFCs, may we >>>>> update >>>>> the expansion of "BGP-LS" from "BGP Link-State" to "BGP - Link State"? If >>>>> yes, >>>>> note that the title of this document would also be updated accordingly. >>>>> >>>>> Original: >>>>> Advertisement of Segment Routing Policies using BGP Link-State >>>>> ... >>>>> This document describes a mechanism to collect the Segment Routing >>>>> Policy information that is locally available in a node and advertise >>>>> it into BGP Link-State (BGP-LS) updates. >>>>> >>>>> Perhaps: >>>>> Advertisement of Segment Routing Policies using BGP - Link State >>>>> ... >>>>> This document describes a mechanism to collect the Segment Routing >>>>> Policy information that is locally available in a node and advertise >>>>> it into BGP - Link State (BGP-LS) updates. >>>>> --> >>>>> >>>>> KT> ack >>>>> >>>>> >>>>> >>>>> 25) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>> online >>>>> Style Guide >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyV_9i0NgA$ >>>>> > >>>>> and let us know if any changes are needed. Updates of this nature >>>>> typically >>>>> result in more precise language, which is helpful for readers. >>>>> >>>>> Note that our script did not flag any words in particular, but this should >>>>> still be reviewed as a best practice. >>>>> --> >>>>> >>>>> KT> Looks good to me. >>>>> >>>>> Thanks, >>>>> Ketan >>>>> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> Karen Moore and Alanna Paloma >>>>> RFC Production Center >>>>> >>>>> >>>>> On Sep 10, 2025, at 3:08 PM, [email protected] wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2025/09/10 >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Instructions for Completing AUTH48 >>>>> >>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>> approved by you and all coauthors, it will be published as an RFC. >>>>> If an author is no longer available, there are several remedies >>>>> available as listed in the FAQ >>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXvctUK_g$ >>>>> ). >>>>> >>>>> You and you coauthors are responsible for engaging other parties >>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>> your approval. >>>>> >>>>> Planning your review >>>>> --------------------- >>>>> >>>>> Please review the following aspects of your document: >>>>> >>>>> * RFC Editor questions >>>>> >>>>> Please review and resolve any questions raised by the RFC Editor >>>>> that have been included in the XML file as comments marked as >>>>> follows: >>>>> >>>>> <!-- [rfced] ... --> >>>>> >>>>> These questions will also be sent in a subsequent email. >>>>> >>>>> * Changes submitted by coauthors >>>>> >>>>> Please ensure that you review any changes submitted by your >>>>> coauthors. We assume that if you do not speak up that you >>>>> agree to changes submitted by your coauthors. >>>>> >>>>> * Content >>>>> >>>>> Please review the full content of the document, as this cannot >>>>> change once the RFC is published. Please pay particular attention to: >>>>> - IANA considerations updates (if applicable) >>>>> - contact information >>>>> - references >>>>> >>>>> * Copyright notices and legends >>>>> >>>>> Please review the copyright notice and legends as defined in >>>>> RFC 5378 and the Trust Legal Provisions >>>>> (TLP – >>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWFTQ7lZA$ >>>>> ). >>>>> >>>>> * Semantic markup >>>>> >>>>> Please review the markup in the XML file to ensure that elements of >>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>> and <artwork> are set correctly. See details at >>>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVFxynzPA$ >>>>> >. >>>>> >>>>> * Formatted output >>>>> >>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>> formatted output, as generated from the markup in the XML file, is >>>>> reasonable. Please note that the TXT will have formatting >>>>> limitations compared to the PDF and HTML. >>>>> >>>>> >>>>> Submitting changes >>>>> ------------------ >>>>> >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>> the parties CCed on this message need to see your changes. The parties >>>>> include: >>>>> >>>>> * your coauthors >>>>> >>>>> * [email protected] (the RPC team) >>>>> >>>>> * other document participants, depending on the stream (e.g., >>>>> IETF Stream participants are your working group chairs, the >>>>> responsible ADs, and the document shepherd). >>>>> >>>>> * [email protected], which is a new archival mailing list >>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>> list: >>>>> >>>>> * More info: >>>>> >>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWTvQQngw$ >>>>> >>>>> * The archive itself: >>>>> >>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXGlj5uPw$ >>>>> >>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>> If needed, please add a note at the top of the message that you >>>>> have dropped the address. When the discussion is concluded, >>>>> [email protected] will be re-added to the CC list and >>>>> its addition will be noted at the top of the message. >>>>> >>>>> You may submit your changes in one of two ways: >>>>> >>>>> An update to the provided XML file >>>>> — OR — >>>>> An explicit list of changes in this format >>>>> >>>>> Section # (or indicate Global) >>>>> >>>>> OLD: >>>>> old text >>>>> >>>>> NEW: >>>>> new text >>>>> >>>>> You do not need to reply with both an updated XML file and an explicit >>>>> list of changes, as either form is sufficient. >>>>> >>>>> We will ask a stream manager to review and approve any changes that seem >>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>> and technical changes. Information about stream managers can be found in >>>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>>> >>>>> >>>>> Approving for publication >>>>> -------------------------- >>>>> >>>>> To approve your RFC for publication, please reply to this email stating >>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>> as all the parties CCed on this message need to see your approval. >>>>> >>>>> >>>>> Files >>>>> ----- >>>>> >>>>> The files are available here: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$ >>>>> >>>>> Diff file of the text: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$ >>>>> (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-xmldiff1.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyUsHTfAmg$ >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$ >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9857 (draft-ietf-idr-bgp-ls-sr-policy-17) >>>>> >>>>> Title : Advertisement of Segment Routing Policies using BGP >>>>> Link-State >>>>> Author(s) : S. Previdi, K. Talaulikar, Ed., J. Dong, H. Gredler, >>>>> J. Tantsura >>>>> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas >>>>> >>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >>>>> >>>>> >>>> >>>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
