Hi John, This is a reminder that we are awaiting your reply (if you are unable to reivew this, please let us know).
As the responsible AD when this draft was approved, please let us know if you approve 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://www.rfc-editor.org/authors/rfc9857-auth48diff.html>. Note that the IDR chairs did a 2-week call for any objection to the changes, and no objection was made. Best regards, Karen Moore RFC Production Center —Files— (please refresh) Updated XML file: https://www.rfc-editor.org/authors/rfc9857.xml Updated output files: https://www.rfc-editor.org/authors/rfc9857.txt https://www.rfc-editor.org/authors/rfc9857.pdf https://www.rfc-editor.org/authors/rfc9857.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9857-auth48diff.html https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by side) Diff files showing only changes made during the last editing round: https://www.rfc-editor.org/authors/rfc9857-lastdiff.html https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9857-diff.html https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9857 > On Oct 17, 2025, at 4:37 PM, Karen Moore <[email protected]> wrote: > > Hi John, > > As the responsible AD when this draft was approved, please let us know if you > approve 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://www.rfc-editor.org/authors/rfc9857-auth48diff.html>. Note that the > IDR chairs did a 2-week call for any objection to the changes, and no > objection was made. > > Best regards, > > Karen Moore > RFC Production Center > > > —Files— > (please refresh) > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9857.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9857.txt > https://www.rfc-editor.org/authors/rfc9857.pdf > https://www.rfc-editor.org/authors/rfc9857.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by side) > > Diff files showing only changes made during the last editing round: > https://www.rfc-editor.org/authors/rfc9857-lastdiff.html > https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9857-diff.html > https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9857 > > >> Begin forwarded message: >> >> From: Karen Moore <[email protected]> >> Subject: [AD] Re: AUTH48: RFC-to-be 9857 >> <draft-ietf-idr-bgp-ls-sr-policy-17> for your review >> Date: October 10, 2025 at 2:07:48 PM PDT >> To: Susan Hares <[email protected]>, John Scudder <[email protected]>, Hannes >> Gredler <[email protected]>, "Dongjie (Jimmy)" <[email protected]>, Ketan >> Talaulikar <[email protected]>, Stefano Previdi <[email protected]>, >> Jeff Tantsura <[email protected]> >> Cc: Editor RFC <[email protected]>, "[email protected]" >> <[email protected]>, idr-chairs <[email protected]>, Shawn Zandi via >> auth48archive <[email protected]> >> >> 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://www.rfc-editor.org/authors/rfc9857-auth48diff.html>. >> >> Best regards, >> >> Karen Moore >> RFC Production Center >> >> >> —Files (please refresh)— >> >> Updated XML file: >> https://www.rfc-editor.org/authors/rfc9857.xml >> >> Updated output files: >> https://www.rfc-editor.org/authors/rfc9857.txt >> https://www.rfc-editor.org/authors/rfc9857.pdf >> https://www.rfc-editor.org/authors/rfc9857.html >> >> Diff files showing all changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by side) >> >> Diff files showing only changes made during the last editing round: >> https://www.rfc-editor.org/authors/rfc9857-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9857-diff.html >> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9857 >> >> >>> >>> 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://mailarchive.ietf.org/arch/msg/idr/3SxFo0UK76CFb6cPLgJMVLBPvGY/) >>> I announced the result: >>> https://mailarchive.ietf.org/arch/msg/idr/D3OmHDe8O7Whn6kaFiWC0iW1V1s/ >>> 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://www.rfc-editor.org/auth48/rfc9857). 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://www.rfc-editor.org/auth48/rfc9857>. 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://www.rfc-editor.org/authors/rfc9857-auth48diff.html>. >>>>>>>>>>> 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://www.iana.org/assignments/bgp-ls-parameters/>) >>>>>>> 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://www.rfc-editor.org/authors/rfc9857.xml >>>>>>>>>>> Updated output files: >>>>>>> https://www.rfc-editor.org/authors/rfc9857.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9857.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9857.html >>>>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by >>>>>>> side) >>>>>>>>>>> Diff files showing only changes made during the last editing round: >>>>>>> https://www.rfc-editor.org/authors/rfc9857-lastdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html >>>>>>>>>>> Diff files showing all changes: >>>>>>> https://www.rfc-editor.org/authors/rfc9857-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) >>>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>> https://www.rfc-editor.org/auth48/rfc9857 >>>>>>>>>>> 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://www.rfc-editor.org/auth48/rfc9857 prior to >>>>>>>>>>>>>>> moving forward with publicaiton. >>>>>>>>>>>>>>> —Files (please refresh)— >>>>>>>>>>>>>>> Updated XML file: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.xml >>>>>>>>>>>>>>> Updated output files: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.html >>>>>>>>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side >>>>>>>>> by side) >>>>>>>>>>>>>>> Diff files showing only changes made during the last editing >>>>>>>>>>>>>>> round: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-lastdiff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html >>>>>>>>>>>>>>> Diff files showing all changes: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) >>>>>>>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9857 >>>>>>>>>>>>>>> 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://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 >>>>>>>>>> and Table 6 is what is listed in >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - 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://www.rfc-editor.org/authors/rfc9831.html#section-3.1 >>>>>>>>>>>>>>>>> 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://www.rfc-editor.org/rfc/rfc9256.html#table-2 and so, we >>>>>>>>>>>>>>> should try to make things consistent with that. The same is >>>>>>>>>>>>>>> there in https://www.rfc-editor.org/rfc/rfc9830#section-2.4.4.2 >>>>>>>>>>>>>>> and https://www.rfc-editor.org/rfc/rfc9831#section-2 - >>>>>>>>>>>>>>> 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://www.rfc-editor.org/authors/rfc9857.xml >>>>>>>>>>>>>>> Updated output files: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.html >>>>>>>>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side >>>>>>>>> by side) >>>>>>>>>>>>>>> Diff files showing all changes: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) >>>>>>>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9857 >>>>>>>>>>>>>>> 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://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 >>>>>>>>>> and Table 6 is what is listed in >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - 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://www.rfc-editor.org/authors/rfc9831.html#section-3.1 >>>>>>>>>>>>>>>>> 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://www.iana.org/assignments/bgp-ls-parameters/ >>>>>>>>>> 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://www.iana.org/assignments/bgp-ls-parameters/ >>>>>>>>>> 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://www.iana.org/assignments/bgp-ls-parameters/ >>>>>>>>>> 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://www.iana.org/assignments/bgp-ls-parameters/ >>>>>>>>>> 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://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>>>>>> 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://www.rfc-editor.org/faq/). >>>>>>>>>>>>>>>>> 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://trustee.ietf.org/license-info). >>>>>>>>>>>>>>>>> * 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://authors.ietf.org/rfcxml-vocabulary>. >>>>>>>>>>>>>>>>> * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>>>>>>>>>>>> * The archive itself: >>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>>>>>>>>>>>> * 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://www.rfc-editor.org/authors/rfc9857.xml >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9857.txt >>>>>>>>>>>>>>>>> Diff file of the text: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by >>>>>>>>>> side) >>>>>>>>>>>>>>>>> Diff of the XML: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9857-xmldiff1.html >>>>>>>>>>>>>>>>>>>>>>>> Tracking progress >>>>>>>>>> ----------------- >>>>>>>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9857 >>>>>>>>>>>>>>>>> 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 www.rtbrick.com >>>>>>>>>>>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
