**Resending with “[AD]” in the subject line**
On Sep 16, 2025, at 11:21 AM, Karen Moore <kmo...@staff.rfc-editor.org> 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 —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 <jefftant.i...@gmail.com> wrote: >> >> Hi Karen, >> >> Approved. >> Thanks! >> >> Cheers, >> Jeff >> >>> On Sep 15, 2025, at 13:00, Karen Moore <kmo...@staff.rfc-editor.org> 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 <ketant.i...@gmail.com> 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 <kmo...@staff.rfc-editor.org> >>> 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 <ketant.i...@gmail.com> >>>> wrote: >>>> >>>> Hi Karen & Allana, >>>> >>>> Thanks for your help with this document. I realize it was challenging >>>> given the inconsistent use of terms within the document and across its >>>> related documents. Appreciate your tidying it up for publication. >>>> >>>> Please check inline below for responses. >>>> >>>> >>>> On Thu, Sep 11, 2025 at 3:39 AM <rfc-edi...@rfc-editor.org> 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, rfc-edi...@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/09/10 >>>> >>>> RFC Author(s): >>>> -------------- >>>> >>>> Instructions for Completing AUTH48 >>>> >>>> Your document has now entered AUTH48. Once it has been reviewed and >>>> approved by you and all coauthors, it will be published as an RFC. >>>> If an author is no longer available, there are several remedies >>>> available as listed in the FAQ (https://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 >>>> >>>> * rfc-edi...@rfc-editor.org (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). >>>> >>>> * auth48archive@rfc-editor.org, 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, >>>> auth48archive@rfc-editor.org 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 >>>> >>>> >>> >>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
