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
