Hi, These changes are complete:
https://www.iana.org/assignments/segment-routing https://www.iana.org/assignments/bgp-ls-parameters thanks, Amanda Baber IANA On Mon Oct 27 20:39:12 2025, [email protected] wrote: > 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] > > editor.org> 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] > >>> editor.org> 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 <rfc-editor@rfc- > >>>> editor.org>; [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] > >>>>>>> editor.org> 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] > >>>>>>>>>> editor.org> 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, > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>> KT> https://urldefense.com/v3/__https://www.rfc- > >>>>>>>>>>>>>>>> KT> editor.org/rfc/rfc9256.html*table- > >>>>>>>>>>>>>>>> KT> 2__;Iw!!NEt6yMaO- > >>>>>>>>>>>>>>>> KT> gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ- > >>>>>>>>>>>>>>>> KT> n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF0oBzs7WQ$ > >>>>>>>>>>>>>>>> KT> and so, we should try to make things consistent > >>>>>>>>>>>>>>>> KT> with that. The same is there in > >>>>>>>>>>>>>>>> KT> https://urldefense.com/v3/__https://www.rfc- > >>>>>>>>>>>>>>>> KT> editor.org/rfc/rfc9830*section- > >>>>>>>>>>>>>>>> KT> 2.4.4.2__;Iw!!NEt6yMaO- > >>>>>>>>>>>>>>>> KT> gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ- > >>>>>>>>>>>>>>>> KT> n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3VT2XOwA$ > >>>>>>>>>>>>>>>> KT> and https://urldefense.com/v3/__https://www.rfc- > >>>>>>>>>>>>>>>> KT> editor.org/rfc/rfc9831*section-2__;Iw!!NEt6yMaO- > >>>>>>>>>>>>>>>> KT> gk!BMbSxKWl46rdB1StAoV7xKCy6HNHzLLQ- > >>>>>>>>>>>>>>>> KT> n4ZYJ1tVM7VArj9klq0D5QyVYC_mq0cJdxGtNB_u_C6iF3P_3ET0w$ > >>>>>>>>>>>>>>>> KT> - therefore, the Table 1 descriptions should be > >>>>>>>>>>>>>>>> KT> the same. The only exception is that the > >>>>>>>>>>>>>>>> KT> alphabetical Type is indicated in brackets to > >>>>>>>>>>>>>>>> KT> provide the necessary correlation between the two > >>>>>>>>>>>>>>>> KT> separate code point spaces. I hope this also > >>>>>>>>>>>>>>>> KT> 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 <rfc- > >>>>>>>>>>>>>>>>>>>>>>>>> [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 > >>>>>>>>>>>>>>>>>> KT> registry is for TLV codepoints but they can also > >>>>>>>>>>>>>>>>>> KT> be used as sub-TLVs. So, I agree that your > >>>>>>>>>>>>>>>>>> KT> suggestion is better, but how about "IGP Router- > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> is to signal the Specified-BSID value. Whether > >>>>>>>>>>>>>>>>>> KT> or not the Specified-BSID-only is to be used is > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> section 5.6.6 with referencine Table 1 has > >>>>>>>>>>>>>>>>>> KT> caused a confusion between metric types and > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> 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, > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> in Table 6. But please refer to the previous > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> that impacts this. With that in mind, I would > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> 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 > >>>>>>>>>>>>>>>>>> KT> 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, rfc-editor@rfc- > >>>>>>>>>>>>>>>>>>>>>>>>> editor.org 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]
