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]
