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]
