Dear IANA, Please make the following updates to match the edited document at <https://www.rfc-editor.org/authors/rfc9857-diff.html>.
1) Under <https://www.iana.org/assignments/segment-routing>: a) Update the registry name: OLD: SR Policy Protocol Origin NEW: SR Policy Protocol-Origin b) Updates to the registry: OLD: 10 PCEP (In PCEP or when BGP-LS Producer is PCE) 20 BGP SR Policy (In PCEP or when BGP-LS Producer is PCE) 30 Configuration (CLI, YANG model via NETCONF, etc.) (In PCEP or when BGP-LS Producer is PCE) NEW: 10 PCEP (in PCEP or when BGP-LS Producer is PCE) 20 BGP SR Policy (in PCEP or when BGP-LS Producer is PCE) 30 Configuration (CLI, YANG model via NETCONF, etc. In PCEP or when BGP-LS Producer is PCE) 2) Updates to the "BGP-LS SR Segment Descriptor Types” registry <https://www.iana.org/assignments/bgp-ls-parameters/> (FYI: no changes to “Reserved” and “Unassigned”): OLD: 1 (Type A) SR-MPLS Label 2 (Type B) SRv6 SID as IPv6 address 3 (Type C) SR-MPLS Prefix SID as IPv4 Node Address 4 (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address 5 (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local Interface ID 6 (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses 7 (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface ID for Local & Remote nodes 8 (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for the Local & Remote Interface 9 (Type I) SRv6 END SID as IPv6 Node Global Address [ 10 (Type J) SRv6 END.X SID as pair of IPv6 Global Address & Interface ID for Local & Remote nodes 11 (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for the Local & Remote Interface NEW: 1 Type A Segment 2 Type B Segment 3 Type C Segment 4 Type D Segment 5 Type E Segment 6 Type F Segment 7 Type G Segment 8 Type H Segment 9 Type I Segment 10 Type J Segment 11 Type K Segment Thank you in advance! Karen Moore RFC Production Center > On Oct 27, 2025, at 12:51 PM, Karen Moore <[email protected]> wrote: > > Hi John, > > Thank you for your reply. We have noted your approval of the changes on the > AUTH48 status page <https://www.rfc-editor.org/auth48/rfc9857>. We will now > ask IANA to update their registry accordingly, and we will inform everyone > when the updates are complete. > > Best regards, > > Karen Moore > RPC Production Center > > >> On Oct 27, 2025, at 6:05 AM, John Scudder <[email protected]> wrote: >> >> Please proceed. >> >> Thanks to Sue and Ketan for checking with the WG. >> >> —John >> >>> On Oct 10, 2025, at 5:07 PM, Karen Moore <[email protected]> >>> wrote: >>> >>> [External Email. Be cautious of content] >>> >>> >>> Hi Sue and *John (AD), >>> >>> Thank you for your reply and for letting us know that the IDR chairs had no >>> objection to the changes in Table 6 or to the changes to the titles of >>> Sections 5.7.1.1.1 - 5.7.1.1.11. >>> >>> *John, as the responsible AD when this draft was approved, please let us >>> know if you also approve of the changes made to Table 6 and to the titles >>> of Sections 5.7.1.1.1 - 5.7.1.1.11. If approval is provided, we will ask >>> IANA to update the "BGP-LS SR Segment Descriptor Types” registry to match >>> the edited document. Please review the updates in this file: >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0JZdpFVA$ >>> >. >>> >>> Best regards, >>> >>> Karen Moore >>> RFC Production Center >>> >>> >>> —Files (please refresh)— >>> >>> Updated XML file: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF12NyqHWg$ >>> >>> Updated output files: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0xT5_4wQ$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0hvVn5JA$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1I3lrtpQ$ >>> >>> Diff files showing all changes made during AUTH48: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0JZdpFVA$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF2DWK3cdw$ >>> (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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1Hnl-svg$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF26Vq67Fw$ >>> >>> Diff files showing all changes: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF19ziQB-w$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF05FgWKMQ$ >>> (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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>> >>> >>>> >>>> On Oct 9, 2025, at 3:55 PM, Susan Hares <[email protected]> wrote: >>>> >>>> Karen, Ketan, and authors (Jie, Hannes, Jeff, and Stefano): >>>> The IDR chairs did a 2 week call for any objection to the Auth-48 changes, >>>> and no objection was made. >>>> (see >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/3SxFo0UK76CFb6cPLgJMVLBPvGY/__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF38SJqabg$ >>>> ) >>>> I announced the result: >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/D3OmHDe8O7Whn6kaFiWC0iW1V1s/__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF140TKW4g$ >>>> Please go ahead with the publication process. >>>> Cheerily, Sue From: Karen Moore <[email protected]> >>> >>>> From: Karen Moore <[email protected]> >>>> Sent: Friday, October 3, 2025 3:32 PM >>>> To: Ketan Talaulikar <[email protected]>; Dongjie (Jimmy) >>>> <[email protected]>; Hannes Gredler <[email protected]>; Jeff Tantsura >>>> <[email protected]>; Stefano Previdi <[email protected]> >>>> Cc: John Scudder <[email protected]>; Editor RFC >>>> <[email protected]>; [email protected]; idr-chairs >>>> <[email protected]>; Susan Hares <[email protected]>; Shawn Zandi via >>>> auth48archive <[email protected]> >>>> Subject: Re: AUTH48: RFC-to-be 9857 <draft-ietf-idr-bgp-ls-sr-policy-17> >>>> for your review >>>> Hi Ketan, >>>> Checking in to see how the reivew of this document is going with the WG. >>>> Best regards, >>>> Karen Moore >>>> RFC Production Center >>>>> On Sep 23, 2025, at 10:36 PM, Ketan Talaulikar <[email protected]> >>>>> wrote: >>>>>> Hi Karen, >>>>>> John (as the responsible AD when this draft was approved by the previous >>>>>> IESG) has already approved the rest of the AUTH48 and asked that this >>>>>> one point be taken to the WG to check their views. This is what is going >>>>>> to happen soon. >>>>>> Of course, no concerns from my side if Jim (or Gunter) needs to step in. >>>>>> Thanks, >>>>> Ketan >>>>>>> On Tue, Sep 23, 2025 at 11:39 PM Karen Moore >>>>>>> <[email protected]> wrote: >>>>> Hi Ketan, >>>>>> Thanks for letting us know the status. If there are changes as a result >>>>>> of your consultation, please let us know if we should perhaps ask >>>>>> another AD to approve the updates (perhaps Jim Guichard as he is listed >>>>>> as a Routing AD). >>>>>> Best regards, >>>>>> Karen Moore >>>>> RFC Production Center >>>>>>> On Sep 22, 2025, at 11:02 PM, Ketan Talaulikar <[email protected]> >>>>>>> wrote: >>>>>>>> Hi Karen, >>>>>>>> With my current role as the responsible AD for IDR WG, I find myself a >>>>>>>> bit conflicted to take this to the WG myself and would prefer if one >>>>>>>> of the IDR chairs does this. >>>>>>>> However, the shepherding co-chair Sue may be away on personal >>>>>>>> exigencies and Jeff is also on PTO. So, I will take it to the WG with >>>>>>>> my "editor of this document" hat, in case the IDR chairs are unable to >>>>>>>> get to this in the next couple of days. >>>>>>>> Thanks, >>>>>> Ketan >>>>>>>>>> On Tue, Sep 23, 2025 at 12:06 AM Karen Moore >>>>>>>>>> <[email protected]> wrote: >>>>>> Hello Stefano and Jie, >>>>>>>> We have noted your approval of the document on the AUTH48 status page >>>>>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>>>>>>> ). We will assume your assent to any further changes proposed by your >>>>>>>> coauthor(s) unless we hear otherwise at that time. >>>>>>>> We now await potential updates to the document per the recent >>>>>>>> discussion on this thread prior to moving forward with publication. >>>>>>>> Best regards, >>>>>>>> Karen Moore >>>>>> RFC Production Center >>>>>>>>>>> On Sep 22, 2025, at 2:22 AM, Dongjie (Jimmy) via auth48archive >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Hi Karen, > > > > > > I approve the publication of this document >>>>>>>>>> once the discussion about the segment types description is resolved. >>>>>>>>>> Best regards, >>>>>>> Jie >>>>>>>>> On Sep 19, 2025, at 4:21 AM, Stefano Previdi <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> I approve. >>>>>>>>>> Thanks. >>>>>>> s. >>>>>>>>>> On Thu, Sep 18, 2025, 20:18 Karen Moore >>>>>>>>>> <[email protected]> wrote: >>>>>>> Hi Hannes, Jeff, Ketan, and John, >>>>>>>>>> Thank you for your replies. We have noted approval of the document >>>>>>>>>> for Hannes and Jeff on the AUTH48 status page. Hannes and Jeff, we >>>>>>>>>> will assume your assent to any further changes proposed by your >>>>>>>>>> coauthors unless we hear otherwise. >>>>>>>>>> We will stand by as Ketan consults with the WG per the discussion >>>>>>>>>> with John. >>>>>>>>>> Best regards, >>>>>>>>>> Karen Moore >>>>>>> RPC Production Center >>>>>>>>>>>>>> On Sep 16, 2025, at 12:07 PM, Hannes Gredler >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> Hi Karen, >>>>>>>>>>>> approved. >>>>>>>>>>>> thanks. >>>>>>>>>>>> /hannes >>>>>>>>>>>> On Tue, Sep 16, 2025 at 8:21 PM Karen Moore >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>>>>>>>>>>> >. 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0JZdpFVA$ >>>>>>>>>>>> >. >>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3KeFJKcw$ >>>>>>>> >) >>>>>>>> 4) Updates to the titles of Sections 5.7.1.1.1 - 5.7.1.1.11 to more >>>>>>>> closely match Table 6 >>>>>>>>>>>>>>>>>>> On Sep 16, 2025, at 7:56 AM, Jeff Tantsura >>>>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> Hi Karen, >>>>>>>>>>>> Approved. >>>>>>>> Thanks! >>>>>>>>>>>> Cheers, >>>>>>>> Jeff >>>>>>>>>>>>>>>>>> —Files (please refresh)— >>>>>>>>>>>> Updated XML file: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF12NyqHWg$ >>>>>>>>>>>> Updated output files: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0xT5_4wQ$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0hvVn5JA$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1I3lrtpQ$ >>>>>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0JZdpFVA$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF2DWK3cdw$ >>>>>>>> (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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1Hnl-svg$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF26Vq67Fw$ >>>>>>>>>>>> Diff files showing all changes: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF19ziQB-w$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF05FgWKMQ$ >>>>>>>> (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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF12NyqHWg$ >>>>>>>>>>>>>>>> Updated output files: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0xT5_4wQ$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0hvVn5JA$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1I3lrtpQ$ >>>>>>>>>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0JZdpFVA$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF2DWK3cdw$ >>>>>>>>>> (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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1Hnl-svg$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF26Vq67Fw$ >>>>>>>>>>>>>>>> Diff files showing all changes: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF19ziQB-w$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF05FgWKMQ$ >>>>>>>>>> (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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3fNV8ZZw$ >>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3L6lKrIQ$ >>>>>>>>>>> - 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3L6lKrIQ$ >>>>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0oBzs7WQ$ >>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3VT2XOwA$ >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9831*section-2__;Iw!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3P_3ET0w$ >>>>>>>>>>>>>>>> - 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF12NyqHWg$ >>>>>>>>>>>>>>>> Updated output files: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0xT5_4wQ$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0hvVn5JA$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1I3lrtpQ$ >>>>>>>>>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0JZdpFVA$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF2DWK3cdw$ >>>>>>>>>> (side by side) >>>>>>>>>>>>>>>> Diff files showing all changes: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF19ziQB-w$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF05FgWKMQ$ >>>>>>>>>> (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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3fNV8ZZw$ >>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3L6lKrIQ$ >>>>>>>>>>> - 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3L6lKrIQ$ >>>>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3KeFJKcw$ >>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3KeFJKcw$ >>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3KeFJKcw$ >>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3KeFJKcw$ >>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0N4aMWMQ$ >>>>>>>>>>> > >>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0-QleVyA$ >>>>>>>>>>> ). >>>>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF35YFsfrA$ >>>>>>>>>>> ). >>>>>>>>>>>>>>>>>> * 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF2wyGsBhQ$ >>>>>>>>>>> >. >>>>>>>>>>>>>>>>>> * 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF177QcAhw$ >>>>>>>>>>>>>>>>>> * The archive itself: >>>>>>>>>>> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF38EEL4nw$ >>>>>>>>>>>>>>>>>> * 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF12NyqHWg$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF1I3lrtpQ$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0hvVn5JA$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0xT5_4wQ$ >>>>>>>>>>>>>>>>>> Diff file of the text: >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF19ziQB-w$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF05FgWKMQ$ >>>>>>>>>>> (side by side) >>>>>>>>>>>>>>>>>> Diff of the XML: >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-xmldiff1.html__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3ksjOQ6Q$ >>>>>>>>>>>>>>>>>>>>>>>>> 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!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3cOm0T5g$ >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NOTICE TO RECIPIENT This e-mail >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> message and any attachments are >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> confidential and may be privileged. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you received this e-mail in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error, any review, use, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dissemination, distribution, or >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> copying of this e-mail is strictly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prohibited. Please notify us >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> immediately of the error by return >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e-mail and please delete this >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> message from your system. For more >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> information about Rtbrick, please >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> visit us at >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://urldefense.com/v3/__http://www.rtbrick.com__;!!NEt6yMaO-gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ-n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF37vaN7-A$ >>>>>>>>>>>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
