Hi Karen, approved.
thanks. /hannes On Tue, Sep 16, 2025 at 8:21 PM 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 > >>> > >>> > >> > >> > > -- 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 <http://www.rtbrick.com>
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
