Hi Ketan, Checking in to see how the reivew of this document is going with the WG.
Best regards, Karen Moore RFC Production Center > On Sep 23, 2025, at 10:36 PM, Ketan Talaulikar <[email protected]> wrote: > > Hi Karen, > > John (as the responsible AD when this draft was approved by the previous > IESG) has already approved the rest of the AUTH48 and asked that this one > point be taken to the WG to check their views. This is what is going to > happen soon. > > Of course, no concerns from my side if Jim (or Gunter) needs to step in. > > Thanks, > Ketan > > > On Tue, Sep 23, 2025 at 11:39 PM Karen Moore <[email protected]> > wrote: > Hi Ketan, > > Thanks for letting us know the status. If there are changes as a result of > your consultation, please let us know if we should perhaps ask another AD to > approve the updates (perhaps Jim Guichard as he is listed as a Routing AD). > > Best regards, > > Karen Moore > RFC Production Center > > > On Sep 22, 2025, at 11:02 PM, Ketan Talaulikar <[email protected]> > > wrote: > > > > Hi Karen, > > > > With my current role as the responsible AD for IDR WG, I find myself a bit > > conflicted to take this to the WG myself and would prefer if one of the IDR > > chairs does this. > > > > However, the shepherding co-chair Sue may be away on personal exigencies > > and Jeff is also on PTO. So, I will take it to the WG with my "editor of > > this document" hat, in case the IDR chairs are unable to get to this in the > > next couple of days. > > > > Thanks, > > Ketan > > > > > > On Tue, Sep 23, 2025 at 12:06 AM Karen Moore <[email protected]> > > wrote: > > Hello Stefano and Jie, > > > > We have noted your approval of the document on the AUTH48 status page > > (https://www.rfc-editor.org/auth48/rfc9857). We will assume your assent to > > any further changes proposed by your coauthor(s) unless we hear otherwise > > at that time. > > > > We now await potential updates to the document per the recent discussion on > > this thread prior to moving forward with publication. > > > > Best regards, > > > > Karen Moore > > RFC Production Center > > > > > > > On Sep 22, 2025, at 2:22 AM, Dongjie (Jimmy) via auth48archive > > > <[email protected]> wrote: > > > > > > Hi Karen, > > > > > > I approve the publication of this document once the discussion about the > > > segment types description is resolved. > > > > > > Best regards, > > > Jie > > > > > On Sep 19, 2025, at 4:21 AM, Stefano Previdi <[email protected]> wrote: > > > > > > Hi, > > > > > > I approve. > > > > > > Thanks. > > > s. > > > > > > On Thu, Sep 18, 2025, 20:18 Karen Moore <[email protected]> > > > wrote: > > > Hi Hannes, Jeff, Ketan, and John, > > > > > > Thank you for your replies. We have noted approval of the document for > > > Hannes and Jeff on the AUTH48 status page. Hannes and Jeff, we will > > > assume your assent to any further changes proposed by your coauthors > > > unless we hear otherwise. > > > > > > We will stand by as Ketan consults with the WG per the discussion with > > > John. > > > > > > Best regards, > > > > > > Karen Moore > > > RPC Production Center > > > > > > > > > > On Sep 16, 2025, at 12:07 PM, Hannes Gredler <[email protected]> wrote: > > > > > > > > Hi Karen, > > > > > > > > approved. > > > > > > > > thanks. > > > > > > > > /hannes > > > > > > > > On Tue, Sep 16, 2025 at 8:21 PM Karen Moore > > > > <[email protected]> wrote: > > > > Hi Jeff and *John (AD), > > > > > > > > Thank you for providing your approval of the document; we have noted it > > > > here <https://www.rfc-editor.org/auth48/rfc9857>. We now await > > > > approvals from Hannes, Jie, and Stefano. > > > > > > > > *John, please review the following updates and let us know if you > > > > approve. The changes can be reviewed here: > > > > <https://www.rfc-editor.org/authors/rfc9857-auth48diff.html>. > > > > > > > > 1) Update to the description of “V-Flag” in Section 5.3 (added “MUST”) > > > > 2) Updates to Table 1 in Section 5.7.1.1 to match the descriptions in > > > > RFCs 9256, 9830, and 9831 > > > > 3) Updates to Table 6 in Section 8.5 (FYI: updates will be needed to > > > > the "BGP-LS SR > > > > Segment Descriptor Types” IANA registry at > > > > <https://www.iana.org/assignments/bgp-ls-parameters/>) > > > > 4) Updates to the titles of Sections 5.7.1.1.1 - 5.7.1.1.11 to more > > > > closely match Table 6 > > > > > > > > > > > > > > > On Sep 16, 2025, at 7:56 AM, Jeff Tantsura <[email protected]> > > > > wrote: > > > > > > > > Hi Karen, > > > > > > > > Approved. > > > > Thanks! > > > > > > > > Cheers, > > > > Jeff > > > > > > > > > > > > > > —Files (please refresh)— > > > > > > > > Updated XML file: > > > > https://www.rfc-editor.org/authors/rfc9857.xml > > > > > > > > Updated output files: > > > > https://www.rfc-editor.org/authors/rfc9857.txt > > > > https://www.rfc-editor.org/authors/rfc9857.pdf > > > > https://www.rfc-editor.org/authors/rfc9857.html > > > > > > > > Diff files showing all changes made during AUTH48: > > > > https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > > > > https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by > > > > side) > > > > > > > > Diff files showing only changes made during the last editing round: > > > > https://www.rfc-editor.org/authors/rfc9857-lastdiff.html > > > > https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html > > > > > > > > Diff files showing all changes: > > > > https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) > > > > > > > > For the AUTH48 status of this document, please see: > > > > https://www.rfc-editor.org/auth48/rfc9857 > > > > > > > > Best regards, > > > > > > > > Karen Moore > > > > RFC Production Center > > > > > > > > > > > > > On Sep 16, 2025, at 7:56 AM, Jeff Tantsura <[email protected]> > > > > > wrote: > > > > > > > > > > Hi Karen, > > > > > > > > > > Approved. > > > > > Thanks! > > > > > > > > > > Cheers, > > > > > Jeff > > > > > > > > > >> On Sep 15, 2025, at 13:00, Karen Moore <[email protected]> > > > > >> wrote: > > > > >> > > > > >> Hi Ketan, > > > > >> > > > > >> Thank you for the clarifications. We have updated 2 instances of > > > > >> “RESERVED” as advised in Section 5.7 and have updated Table 1 to > > > > >> match the descriptions in RFCs 9256, 9830, and 9831. Please review. > > > > >> We have also noted your approval of the document. > > > > >> > > > > >> If any further updates are needed in Sections 5.7.1.1.1 - 5.7.1.1.11 > > > > >> to more closely match the wording/changes in Table 1, please let us > > > > >> know. > > > > >> > > > > >> Note that we await approvals of the document from all coauthors > > > > >> listed at https://www.rfc-editor.org/auth48/rfc9857 prior to moving > > > > >> forward with publicaiton. > > > > >> > > > > >> —Files (please refresh)— > > > > >> > > > > >> Updated XML file: > > > > >> https://www.rfc-editor.org/authors/rfc9857.xml > > > > >> > > > > >> Updated output files: > > > > >> https://www.rfc-editor.org/authors/rfc9857.txt > > > > >> https://www.rfc-editor.org/authors/rfc9857.pdf > > > > >> https://www.rfc-editor.org/authors/rfc9857.html > > > > >> > > > > >> Diff files showing all changes made during AUTH48: > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side > > > > >> by side) > > > > >> > > > > >> Diff files showing only changes made during the last editing round: > > > > >> https://www.rfc-editor.org/authors/rfc9857-lastdiff.html > > > > >> https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html > > > > >> > > > > >> Diff files showing all changes: > > > > >> https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > >> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by > > > > >> side) > > > > >> > > > > >> For the AUTH48 status of this document, please see: > > > > >> https://www.rfc-editor.org/auth48/rfc9857 > > > > >> > > > > >> Best regards, > > > > >> > > > > >> Karen Moore > > > > >> RFC Production Center > > > > >> > > > > >> > > > > >> > > > > >> On Sep 14, 2025, at 8:18 PM, Ketan Talaulikar > > > > >> <[email protected]> wrote: > > > > >> > > > > >> Hi Karen, > > > > >> > > > > >> Please check inline below for responses. > > > > >> > > > > >> Besides the comment below about Table 1, there is only one minor > > > > >> update needed: For the fields that were marked as RESERVED1 and 2 in > > > > >> the figures, please make the same change in the individual field > > > > >> descriptions below those figures as well. > > > > >> > > > > >> Once these are taken care of, please consider this email as my > > > > >> approval for publication. > > > > >> > > > > >> > > > > >> On Sat, Sep 13, 2025 at 5:35 AM Karen Moore > > > > >> <[email protected]> wrote: > > > > >> Hi Ketan, > > > > >> > > > > >> Thank you for your comment and close review of the > > > > >> questions/document. We have updated our files per your suggestions. > > > > >> Please note that we have a few additional questions. > > > > >> > > > > >> 1) Regarding the comments below, we updated the titles of Sections > > > > >> 5.7.1.1.1 - 5.7.1.1.11 accordingly. We also updated the descriptions > > > > >> in Table 6, which we agree will align better with RFCs-to-be 9830 > > > > >> and 9831. Please review to ensure the changes are correct. > > > > >> > > > > >> KT> Ack > > > > >> > > > > >>> Comparing this to RFC9830/1, the Table 1 is what is listed > > > > >>> in https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 > > > > >>> and Table 6 is what is listed in > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - more > > > > >>> specifically, I would prefer > > > > >>> that we have alignment for the Table 1 column Segment Description > > > > >>> with the other two RFCs > > > > >>> with one change that we want to keep the (Type X) as a prefix in > > > > >>> this document. > > > > >>> > > > > >>> KT> There is no change required for Table 1, however, we can and > > > > >>> perhaps should > > > > >> > > > > >>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect > > > > >>> RFC9830 sections > > > > >>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. > > > > >>> > > > > >>> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment > > > > >>> Type A > > > > >>> > > > > >>> This will make the section headings short and align with the other > > > > >>> two RFCs that specify > > > > >>> the southbound BGP signaling while this document specifies its > > > > >>> northbound reporting. > > > > >>> > > > > >>> The titles for figures are ok. > > > > >>> > > > > >>> The descriptions can then be changed along the lines of > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 > > > > >>> > > > > >>> As an example: (Type A) SR-MPLS Label -> Type A Segment > > > > >>> > > > > >>> Please let me know your views from the perspective of readability > > > > >>> and alignment across RFC9256 and > > > > >>> the 3 BGP RFCs under RFC Editor currently including this document. > > > > >> > > > > >> 2) It was mentioned that no changes were required for Table 1 - want > > > > >> to clarify if that is still the case or if any further updates are > > > > >> needed for consistency with the wording/style in Table 2 of RFC 9256. > > > > >> > > > > >> KT> The descriptions originate from > > > > >> https://www.rfc-editor.org/rfc/rfc9256.html#table-2 and so, we > > > > >> should try to make things consistent with that. The same is there in > > > > >> https://www.rfc-editor.org/rfc/rfc9830#section-2.4.4.2 and > > > > >> https://www.rfc-editor.org/rfc/rfc9831#section-2 - therefore, the > > > > >> Table 1 descriptions should be the same. The only exception is that > > > > >> the alphabetical Type is indicated in brackets to provide the > > > > >> necessary correlation between the two separate code point spaces. I > > > > >> hope this also covers the queries below. > > > > >> > > > > >> Thanks, > > > > >> Ketan > > > > >> > > > > >> > > > > >> > > > > >> Please also consider the following. > > > > >> > > > > >> a) Section 5.7.1.1.6 describes the IPv4 Local & Remote Interface > > > > >> Addresses as a “pair”; is “pair" correct to add to the description > > > > >> of Type F in Table 1? > > > > >> > > > > >> Current: > > > > >> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface > > > > >> Addresses > > > > >> > > > > >> Perhaps A: > > > > >> (Type F) SR-MPLS Adjacency SID as pair of IPv4 Local & Remote > > > > >> Interface Addresses > > > > >> > > > > >> Perhaps B (in attempt to follow the style of RFC 9256): > > > > >> (Type F) IPv4 Interface Addresses for SR-MPLS Adjacency SID as > > > > >> Local, Remote pair > > > > >> > > > > >> b) Does the pair consist of one IPv6 global address and one > > > > >> interface ID? Please let us know if any clarifcation is needed. This > > > > >> applies to Types G (Section 5.7.1.1.7) and J (Section 5.7.1.1.10). > > > > >> > > > > >> Table 1: > > > > >> Current: > > > > >> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & > > > > >> Interface ID for > > > > >> Local & Remote nodes > > > > >> > > > > >> Perhaps A: > > > > >> (Type G) SR-MPLS Adjacency SID as pair of an IPv6 Global Address & > > > > >> Interface ID for Local & Remote Nodes > > > > >> > > > > >> Perhaps B (in attempt to follow the style of RFC 9256): > > > > >> (Type G) IPv6 Global Address & Interface ID for SR-MPLS Adjacency > > > > >> SID as > > > > >> Local, Remote Node pair > > > > >> > > > > >> Section 5.7.1.1.7 > > > > >> Current: > > > > >> The Segment is an SR-MPLS Adjacency SID type and is specified as a > > > > >> pair of IPv6 global address and interface ID for local and remote > > > > >> nodes. > > > > >> > > > > >> Perhaps: > > > > >> The Segment is an SR-MPLS Adjacency SID type and is specified as a > > > > >> pair of one IPv6 global address and one interface ID for local and > > > > >> remote > > > > >> nodes. > > > > >> > > > > >> --Files-- > > > > >> Note that it may be necessary for you to refresh your browser to > > > > >> view the most recent version. Please review the document carefully > > > > >> to ensure satisfaction as we do not make changes once it has been > > > > >> published as an RFC. > > > > >> > > > > >> We will await approvals from each author prior to moving forward in > > > > >> the publication process. > > > > >> > > > > >> Updated XML file: > > > > >> https://www.rfc-editor.org/authors/rfc9857.xml > > > > >> > > > > >> Updated output files: > > > > >> https://www.rfc-editor.org/authors/rfc9857.txt > > > > >> https://www.rfc-editor.org/authors/rfc9857.pdf > > > > >> https://www.rfc-editor.org/authors/rfc9857.html > > > > >> > > > > >> Diff files showing all changes made during AUTH48: > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side > > > > >> by side) > > > > >> > > > > >> Diff files showing all changes: > > > > >> https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > >> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by > > > > >> side) > > > > >> > > > > >> For the AUTH48 status of this document, please see: > > > > >> https://www.rfc-editor.org/auth48/rfc9857 > > > > >> > > > > >> Best regards, > > > > >> > > > > >> Karen Moore > > > > >> RFC Production Center > > > > >> > > > > >> > > > > >>> On Sep 11, 2025, at 5:14 AM, Ketan Talaulikar > > > > >>> <[email protected]> wrote: > > > > >>> > > > > >>> Hi Karen & Allana, > > > > >>> > > > > >>> Thanks for your help with this document. I realize it was > > > > >>> challenging given the inconsistent use of terms within the document > > > > >>> and across its related documents. Appreciate your tidying it up for > > > > >>> publication. > > > > >>> > > > > >>> Please check inline below for responses. > > > > >>> > > > > >>> > > > > >>> On Thu, Sep 11, 2025 at 3:39 AM <[email protected]> wrote: > > > > >>> Authors, > > > > >>> > > > > >>> While reviewing this document during AUTH48, please resolve (as > > > > >>> necessary) the following questions, which are also in the source > > > > >>> file. > > > > >>> > > > > >>> 1) <!--[rfced] May we update "PCEP protocol" to simply read "PCEP" > > > > >>> to > > > > >>> avoid redundancy? If expanded, "PCEP protocol" would read as "Path > > > > >>> Computation Element Communication Protocol protocol". > > > > >>> > > > > >>> Original: > > > > >>> As illustrated in the figure below, the > > > > >>> PCC is not an LSR in the routing domain, thus the head-end nodes of > > > > >>> the SR Policies may not implement the PCEP protocol. > > > > >>> > > > > >>> Perhaps: > > > > >>> As illustrated in the figure below, the > > > > >>> PCC is not an LSR in the routing domain, thus the head-end nodes of > > > > >>> the SR Policies may not implement the PCEP. > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 2) <!--[rfced] In Section 3, should the list be formatted as a > > > > >>> definition > > > > >>> list for ease of reading and consistency with other sections? > > > > >>> > > > > >>> Original: > > > > >>> Where: > > > > >>> > > > > >>> * Protocol-ID field specifies the component that owns the SR > > > > >>> Policy > > > > >>> state in the advertising node. An additional Protocol-ID > > > > >>> "Segment > > > > >>> Routing" (value 9) is introduced by this document that MUST be > > > > >>> used for advertisement of SR Policies. > > > > >>> > > > > >>> * "Identifier" is an 8 octet value as defined in section 5.2 of > > > > >>> [RFC9552]. > > > > >>> > > > > >>> * "Local Node Descriptor" (TLV 256) [RFC9552] is used as specified > > > > >>> further in this section. > > > > >>> > > > > >>> * The SR Policy Candidate Path Descriptor TLV is specified in > > > > >>> Section 4. > > > > >>> > > > > >>> Perhaps: > > > > >>> Where: > > > > >>> > > > > >>> * Protocol-ID field: Specifies the component that owns the SR > > > > >>> Policy > > > > >>> state in the advertising node. An additional Protocol-ID > > > > >>> "Segment > > > > >>> Routing" (value 9) is introduced by this document that MUST be > > > > >>> used for the advertisement of SR Policies. > > > > >>> > > > > >>> * Identifier: 8-octet value as defined in Section 5.2 of > > > > >>> [RFC9552]. > > > > >>> > > > > >>> * Local Node Descriptors (TLV 256): Defined in [RFC9552] and used > > > > >>> as > > > > >>> specified further in this section. > > > > >>> > > > > >>> * SR Policy Candidate Path Descriptor TLV: Specified in Section 4. > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 3) <!--[rfced] As shown below, we removed "Number" from "Autonomous > > > > >>> System Number (TLV 512)" per RFC 9552, and we removed "ASN" > > > > >>> following "AS Confederation Identifier" as it is not present in > > > > >>> RFC 5065. Note that this change was also applied to similar text > > > > >>> in Section 3.2. Please let us know of any objections. > > > > >>> > > > > >>> Note that "ASN" was expanded only on the first mention. > > > > >>> > > > > >>> Original: > > > > >>> * Autonomous System Number (TLV 512) [RFC9552], which contains the > > > > >>> ASN (or AS Confederation Identifier (ASN) [RFC5065], if > > > > >>> confederations are used) of the headend node of the SR Policy. > > > > >>> > > > > >>> Current: > > > > >>> * Autonomous System (TLV 512) [RFC9552], which contains the > > > > >>> Autonomous System Number (ASN) (or AS Confederation Identifier > > > > >>> [RFC5065], if confederations are used) of the headend node of > > > > >>> the SR Policy. > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 4) <!--[rfced] In RFC 9552, we note that "IGP Router-ID" is listed > > > > >>> as > > > > >>> both a sub-TLV and a TLV code point. As "sub-TLV" and "TLV" are > > > > >>> not included in the description, how may we update "IGP Router-ID > > > > >>> sub-TLV (TLV 515)" for conciseness? Would "IGP Router-ID > > > > >>> (sub-TLV/TLV 515)" be correct? Note that there are two instances > > > > >>> in the document. > > > > >>> > > > > >>> Original: > > > > >>> The determination of whether the > > > > >>> IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID > > > > >>> or a 6-octet ISO System-ID is to be done based on the length of > > > > >>> that sub-TLV since the Protocol-ID in the NLRI is always going to > > > > >>> be "Segment Routing". > > > > >>> > > > > >>> Perhaps: > > > > >>> The determination of whether the > > > > >>> IGP Router-ID (sub-TLV/TLV 515) contains a 4-octet OSPF Router-ID > > > > >>> or a 6-octet ISO System-ID is to be done based on the length of > > > > >>> that sub-TLV because the Protocol-ID in the NLRI is always going > > > > >>> to be "Segment Routing". > > > > >>> --> > > > > >>> > > > > >>> KT> The reference here is to the TLV and the IANA registry is for > > > > >>> TLV codepoints but they can also be used as sub-TLVs. So, I agree > > > > >>> that your suggestion is better, but how about "IGP Router-ID (TLV > > > > >>> 515)" ? > > > > >>> > > > > >>> > > > > >>> > > > > >>> 5) <!-- [rfced] We note that Section 6.2.3 of RFC 9256 uses > > > > >>> "Specified-BSID-only". Given this, should "Specified BSID" be > > > > >>> updated for consistency? > > > > >>> > > > > >>> Original: > > > > >>> The TLV MAY also optionally contain the Specified BSID value for > > > > >>> reporting as described in section 6.2.3 of [RFC9256]. > > > > >>> > > > > >>> Perhaps: > > > > >>> The TLV MAY also optionally contain the Specified-BSID-only value > > > > >>> for reporting as described in Section 6.2.3 of [RFC9256]. > > > > >>> --> > > > > >>> > > > > >>> KT> This change is not appropriate. Here, the idea is to signal the > > > > >>> Specified-BSID value. Whether or not the Specified-BSID-only is to > > > > >>> be used is indicated by a different flag. > > > > >>> > > > > >>> > > > > >>> > > > > >>> 6) <!--[rfced] Please clarify if "BSID" should be singular (option > > > > >>> A) or > > > > >>> plural (option B) in the following: > > > > >>> > > > > >>> Original: > > > > >>> D-Flag: Indicates the dataplane for the BSIDs and if they are > > > > >>> 16 octet SRv6 SID (when set) or are 4 octet SR/MPLS > > > > >>> label value (when clear). > > > > >>> > > > > >>> Perhaps A: > > > > >>> D-Flag: Indicates the data plane for the BSIDs and if a BSID is > > > > >>> a 16-octet SRv6 SID (when set) or a 4-octet SR/MPLS > > > > >>> label value (when clear). > > > > >>> > > > > >>> Perhaps B: > > > > >>> D-Flag: Indicates the data plane for the BSIDs and if the BSIDs > > > > >>> are 16-octet SRv6 SIDs (when set) or 4-octet SR/MPLS > > > > >>> label values (when clear). > > > > >>> --> > > > > >>> > > > > >>> KT> A is better. > > > > >>> > > > > >>> > > > > >>> > > > > >>> 7) <!--[rfced] We note that Figures 7 and 19 use "Sub-TLVs" > > > > >>> (capitalized), > > > > >>> while Figures 11 and 18 use "sub-TLVs" (lowercased). Should these be > > > > >>> consistent? If yes, which form is preferred? > > > > >>> --> > > > > >>> > > > > >>> KT> Here "sub-TLVs" is appropriate as it is not referring to a > > > > >>> specific sub-TLV name. > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> 8) <!--[rfced] We note multiple instances of "MUST be set to 0 by > > > > >>> the > > > > >>> originator and MUST be ignored by a receiver". Should the one > > > > >>> instance below that contains only one "MUST" be updated > > > > >>> accordingly (see Section 5.3)? > > > > >>> > > > > >>> Original: > > > > >>> V-Flag: Indicates the candidate path has at least one valid > > > > >>> SID-List > > > > >>> when set and indicates no valid SID-List is available or evaluated > > > > >>> when clear. When the E-Flag is clear (i.e. the candidate path has > > > > >>> not > > > > >>> been evaluated), then this flag MUST be set to 0 by the originator > > > > >>> and > > > > >>> ignored by the receiver. > > > > >>> > > > > >>> Perhaps: > > > > >>> V-Flag: Indicates that the candidate path has at least one valid > > > > >>> SID-List > > > > >>> when set and that no valid SID-List is available or evaluated when > > > > >>> clear. > > > > >>> When the E-Flag is clear (i.e., the candidate path has not been > > > > >>> evaluated), > > > > >>> then this flag MUST be set to 0 by the originator and MUST be > > > > >>> ignored by a > > > > >>> receiver. > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 9) <!--[rfced] Please review 2 instances of the term "NULL" in this > > > > >>> document. Should "NULL terminator" be "NUL terminator" or "null > > > > >>> terminator" for correctness? We ask per guidance received from a > > > > >>> Gen Art reviewer. Note that RFC 9256 uses "null endpoint", > > > > >>> "Explicit Null Label Policy", and "IPv6 Explicit NULL Label". > > > > >>> > > > > >>> Current: > > > > >>> SR Policy Name: Symbolic name for the SR Policy without a NULL > > > > >>> terminator as specified in Section 2.1 of [RFC9256]. > > > > >>> > > > > >>> Candidate Path Name: Symbolic name for the SR Policy candidate path > > > > >>> without a NULL terminator as specified in Section 2.6 of > > > > >>> [RFC9256]. > > > > >>> --> > > > > >>> > > > > >>> KT> It should be the NUL - which is what I believe it is called in > > > > >>> ASCII. > > > > >>> > > > > >>> > > > > >>> > > > > >>> 10) <!--[rfced] How may we clarify this "either" sentence. Is the > > > > >>> intended > > > > >>> meaning that the dynamic path is computed by the headend or > > > > >>> delegated to a controller (option A)? Or that the dynamic path is > > > > >>> computed by the headend or by delegation to a controller (option B)? > > > > >>> > > > > >>> Original: > > > > >>> The constraints are generally applied to a dynamic candidate path > > > > >>> which is > > > > >>> computed either by the headend or may be delegated to a controller. > > > > >>> > > > > >>> Perhaps A: > > > > >>> The constraints are generally applied to a dynamic candidate path > > > > >>> that is > > > > >>> either computed by the headend or delegated to a controller. > > > > >>> > > > > >>> Perhaps B: > > > > >>> The constraints are generally applied to a dynamic candidate path > > > > >>> that is > > > > >>> computed by either the headend or delegation to a controller. > > > > >>> --> > > > > >>> > > > > >>> KT> A is correct. > > > > >>> > > > > >>> > > > > >>> > > > > >>> 11) <!--[rfced] We note that Figure 15 uses "Request-Flags" and > > > > >>> "Status-Flags" > > > > >>> (hyphenated), while the definitions of these fields use "Request > > > > >>> Flags" > > > > >>> and "Status Flags" (unhyphenated). To make these consistent, which > > > > >>> form is > > > > >>> preferred? > > > > >>> --> > > > > >>> > > > > >>> KT> the unhyphenated please > > > > >>> > > > > >>> > > > > >>> > > > > >>> 12) <!-- [rfced] For consistency, should "Association Object" be > > > > >>> updated > > > > >>> to "ASSOCIATION object" per use in Section 6.1 of [RFC8697]? Note > > > > >>> that there are four instances. > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 13) <!--[rfced] How may we rephrase the text in Section 5.6.6 for > > > > >>> clarity? > > > > >>> > > > > >>> KT> I think a copy/paste error from my side in section 5.6.6 with > > > > >>> referencine Table 1 has caused a confusion between metric types and > > > > >>> segment types. > > > > >>> > > > > >>> In the first sentence, we note that Table 1 (Section 5.7.1.1) > > > > >>> does not list references for the types. Should the term > > > > >>> "reference" be replaced with "Segment Descriptor" or other for > > > > >>> conciseness? And may we rephrase the second sentence as shown > > > > >>> below for clarity and to make it parallel? > > > > >>> > > > > >>> We also note that Tables 1 and 6 contain the same information. > > > > >>> Should > > > > >>> Table 1 be removed and references to Table 1 (in Sections 5.6.6 and > > > > >>> 5.7.1.1) be updated to point to Table 6? > > > > >>> > > > > >>> KT> The two tables have different purposes. The Table 1 provides > > > > >>> the mapping between the > > > > >>> segment types (A to K) defined in RFC 9256 with the code points of > > > > >>> the types defined in > > > > >>> this document. While table 6 represents the initial allocations for > > > > >>> the codepoints > > > > >>> for the segment types for IANA. Comparing this to RFC9830/1, the > > > > >>> Table 1 is what is listed > > > > >>> in https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 > > > > >>> and Table 6 is what is listed in > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - more > > > > >>> specifically, I would prefer > > > > >>> that we have alignment for the Table 1 column Segment Description > > > > >>> with the other two RFCs > > > > >>> with one change that we want to keep the (Type X) as a prefix in > > > > >>> this document. > > > > >>> > > > > >>> KT> There is no change required for Table 1, however, we can and > > > > >>> perhaps should > > > > >>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect > > > > >>> RFC9830 sections > > > > >>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. > > > > >>> > > > > >>> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment > > > > >>> Type A > > > > >>> > > > > >>> This will make the section headings short and align with the other > > > > >>> two RFCs that specify > > > > >>> the southbound BGP signaling while this document specifies its > > > > >>> northbound reporting. > > > > >>> > > > > >>> The titles for figures are ok. > > > > >>> > > > > >>> The descriptions can then be changed along the lines of > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 > > > > >>> > > > > >>> As an example: (Type A) SR-MPLS Label -> Type A Segment > > > > >>> > > > > >>> Please let me know your views from the perspective of readability > > > > >>> and alignment across RFC9256 and > > > > >>> the 3 BGP RFCs under RFC Editor currently including this document. > > > > >>> > > > > >>> > > > > >>> Original (Section 5.6.6): > > > > >>> The Table 1 below lists the metric types introduced by this > > > > >>> document > > > > >>> along with reference for each. Where the references are for IS-IS > > > > >>> and OSPF specifications, those metric types are defined for a link > > > > >>> while in the SR Policy context those relate to the candidate path > > > > >>> or the segment list. > > > > >>> > > > > >>> Perhaps: > > > > >>> Table 6 lists the metric types introduced by this document along > > > > >>> with a Segment Descriptor for each. Where the Segment Descriptors > > > > >>> relate to IS-IS and OSPF specifications, the metric types are > > > > >>> defined > > > > >>> for a link. Where the Segment Descriptors relate to the SR Policy, > > > > >>> the metric types are defined for a candidate path or a segment > > > > >>> list. > > > > >>> > > > > >>> > > > > >>> KT> Can you please fix/update this blob as below? > > > > >>> > > > > >>> Below is a list of metric types introduced by this document > > > > >>> along with references for each. Where the references are for > > > > >>> IS-IS > > > > >>> and OSPF specifications, those metric types are defined for a > > > > >>> link > > > > >>> while in the SR Policy context those relate to the candidate > > > > >>> path > > > > >>> or the segment list. > > > > >>> > > > > >>> The "list" is actually right after the paragraph with this text and > > > > >>> the reference to Table 1 > > > > >>> was an error. I hope this clarifies. > > > > >>> > > > > >>> ... > > > > >>> Original (Section 5.7.1.1) > > > > >>> The following types are currently defined and their mapping to the > > > > >>> respective segment types defined in [RFC9256]: > > > > >>> > > > > >>> Perhaps: > > > > >>> See Table 6 for the type definitions and their mappings to the > > > > >>> respective segment types defined in [RFC9256]. > > > > >>> --> > > > > >>> > > > > >>> KT> The above change is now not necessary. > > > > >>> > > > > >>> > > > > >>> > > > > >>> 14) <!--[rfced] For clarity, should the registry that the metric > > > > >>> types are > > > > >>> taken from be listed here instead of only the registry that they are > > > > >>> not listed in? > > > > >>> > > > > >>> Original: > > > > >>> Note that the metric type in this field is not taken from the "IGP > > > > >>> Metric Type" registry from IANA "IGP Parameters" and is a separate > > > > >>> registry that includes IGP Metric Types as well as metric types > > > > >>> specific to SR Policy path computation. > > > > >>> > > > > >>> Perhaps: > > > > >>> Note that the metric types in this field are taken from the > > > > >>> "BGP-LS SR Policy Metric Types" IANA registry, which includes > > > > >>> IGP Metric Types as well as metric types specific to SR Policy > > > > >>> path computation (i.e., the metric types are not from the > > > > >>> "IGP Metric-Type" registry). > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 15) <!--[rfced] In Section 5.6.6, we updated "Average" to "Avg" to > > > > >>> match use in Table 7 and the "BGP-LS SR Policy Metric Types" > > > > >>> registry. If you prefer to update the registry to reflect > > > > >>> "Average" instead of "Avg", please let us know. > > > > >>> > > > > >>> Link to registry: > > > > >>> https://www.iana.org/assignments/bgp-ls-parameters/ > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>. > > > > >>> > > > > >>> Original: > > > > >>> Type 6: Average Unidirectional Delay: > > > > >>> > > > > >>> Current: > > > > >>> Type 6: Avg Unidirectional Delay: > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 16) <!--[rfced] We note that Figure 18 contains two "RESERVED" > > > > >>> fields. > > > > >>> As these are two distinctly different fields, should they be updated > > > > >>> as "RESERVED1" and "RESERVED2", which would reflect Figure 11? > > > > >>> --> > > > > >>> > > > > >>> KT> Yes, please do the same for Figure 11 > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> 17) <!--[rfced] Table 6 (Section 8.5) specifies the SRv6 SID as an > > > > >>> "IPv6 > > > > >>> address", but Section 5.7.1.1.2 specifies it as an "SRv6 SID > > > > >>> address". > > > > >>> Is an update needed in Section 5.7.1.1.2 for consistency with Table > > > > >>> 6? > > > > >>> > > > > >>> Original: > > > > >>> The Segment is SRv6 type and is specified simply as the SRv6 SID > > > > >>> address. > > > > >>> > > > > >>> Perhaps: > > > > >>> The Segment is an SRv6 type and is specified simply as the IPv6 > > > > >>> address. > > > > >>> --> > > > > >>> > > > > >>> KT> It should just say "SRv6 SID" in 7.7.1.1.2 and in Table 6. But > > > > >>> please refer to the previous suggestion on Table 6. > > > > >>> > > > > >>> > > > > >>> > > > > >>> 18) <!--[rfced] In Section 5.7.1.1.6, should "interface" be added > > > > >>> to more > > > > >>> closely match Table 6 (the "BGP-LS SR Segment Descriptor Types" > > > > >>> registry)? > > > > >>> > > > > >>> Link to registry: > > > > >>> https://www.iana.org/assignments/bgp-ls-parameters/ > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types > > > > >>> > > > > >>> Original: > > > > >>> IPv4 Local Address: > > > > >>> IPv4 Remote Address: > > > > >>> > > > > >>> Perhaps: > > > > >>> IPv4 Local Interface Address: > > > > >>> IPv4 Remote Interface Address: > > > > >>> > > > > >>> ... > > > > >>> Original (Figure 25): > > > > >>> IPv4 Local Address (4 octets) > > > > >>> IPv4 Remote Address (4 octets) > > > > >>> > > > > >>> Perhaps: > > > > >>> IPv4 Local Interface Address (4 octets) > > > > >>> IPv4 Remote Interface Address (4 octets) > > > > >>> --> > > > > >>> > > > > >>> KT> Ack for both > > > > >>> > > > > >>> > > > > >>> > > > > >>> 19) <!--[rfced] In Sections 5.7.1.1.8 and 5.7.1.1.11, should the > > > > >>> following > > > > >>> be updated for consistency with the descriptions in Table 6 (the > > > > >>> "BGP-LS SR Segment Descriptor Types" registry)? > > > > >>> > > > > >>> Link to registry: > > > > >>> https://www.iana.org/assignments/bgp-ls-parameters/ > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types? > > > > >>> > > > > >>> Original: > > > > >>> IPv6 Local Address: > > > > >>> IPv6 Remote Address: > > > > >>> > > > > >>> Perhaps: > > > > >>> IPv6 Local Global Address: > > > > >>> IPv6 Remote Global Address: > > > > >>> > > > > >>> ... > > > > >>> Original (Figures 27 and 30): > > > > >>> Global IPv6 Local Interface Address (16 octets) > > > > >>> Global IPv6 Remote Interface Address (16 octets) > > > > >>> > > > > >>> Perhaps: > > > > >>> IPv6 Local Interface Global Address (16 octets) > > > > >>> IPv6 Remote Interface Global Address (16 octets) > > > > >>> --> > > > > >>> > > > > >>> KT> Ack for both. > > > > >>> > > > > >>> > > > > >>> > > > > >>> 20) <!-- [rfced] Section 4 of this document as well as RFC 9256 uses > > > > >>> "Protocol-Origin" rather than "Protocol Origin". Are any updates > > > > >>> needed to the "SR Policy Protocol Origin" registry name, two > > > > >>> instances of "SR Protocol Origin", or "Protocol Origin field"? > > > > >>> > > > > >>> Original: > > > > >>> Per this document, IANA has created and maintains a new registry > > > > >>> called "SR Policy Protocol Origin" under the "Segment Routing" > > > > >>> registry group with the allocation policy of Expert Review > > > > >>> [RFC8126] > > > > >>> using the guidelines for designated experts as specified in > > > > >>> [RFC9256]. This registry contains the code points allocated to the > > > > >>> "Protocol Origin" field defined in Section 4. > > > > >>> --> > > > > >>> > > > > >>> KT> Lets use "Protocol-Origin" to be consistent with RFC9256 > > > > >>> > > > > >>> > > > > >>> > > > > >>> 21) <!--[rfced] Under the "Segment Descriptor" column in the > > > > >>> "BGP-LS SR > > > > >>> Segment Descriptor Types" registry, should the following changes > > > > >>> be made to the code point descriptions? That is, add articles, > > > > >>> make names following "pair" plural, and capitalize instances of > > > > >>> "address" and "node", accordingly. > > > > >>> > > > > >>> The form to the right of the arrow is suggested. If changes are > > > > >>> made, > > > > >>> we will update the running text accordingly (namely the subsections > > > > >>> under Section 5.7.1.1) as well as the IANA registry. > > > > >>> > > > > >>> Link to registry: > > > > >>> <https://www.iana.org/assignments/bgp-ls-parameters/ > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types> > > > > >>> > > > > >>> (Type B) SRv6 SID as IPv6 address -> (Type B) SRv6 SID as an IPv6 > > > > >>> Address > > > > >>> > > > > >>> > > > > >>> (Type C) SR-MPLS Prefix SID as IPv4 Node Address -> > > > > >>> (Type C) SR-MPLS Prefix SID as an IPv4 Node Address > > > > >>> > > > > >>> (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address -> > > > > >>> (Type D) SR-MPLS Prefix SID as an IPv6 Node Global Address > > > > >>> > > > > >>> (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local > > > > >>> Interface ID -> > > > > >>> (Type E) SR-MPLS Adjacency SID as an IPv4 Node Address & a Local > > > > >>> Interface ID > > > > >>> > > > > >>> (Note: Section 5.7.1.1.6 describes Type F as a "pair"; is that > > > > >>> correct to add?) > > > > >>> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface > > > > >>> Addresses -> > > > > >>> (Type F) SR-MPLS Adjacency SID as a pair of IPv4 Local & Remote > > > > >>> Interface Addresses > > > > >>> > > > > >>> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & > > > > >>> Interface ID for > > > > >>> Local & Remote nodes -> > > > > >>> (Type G) SR-MPLS Adjacency SID as a pair of IPv6 Global > > > > >>> Addresses & > > > > >>> Interface IDs for Local & Remote Nodes > > > > >>> > > > > >>> (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for > > > > >>> the > > > > >>> Local & Remote Interface -> > > > > >>> (Type H) SR-MPLS Adjacency SID as a pair of IPv6 Global > > > > >>> Addresses for > > > > >>> Local & Remote Interface Addresses > > > > >>> > > > > >>> (Type I) SRv6 END SID as IPv6 Node Global Address -> > > > > >>> (Type I) SRv6 END SID as an IPv6 Node Global Address > > > > >>> > > > > >>> (Type J) SRv6 END.X SID as pair of IPv6 Global Address & Interface > > > > >>> ID > > > > >>> for Local & Remote nodes -> > > > > >>> (Type J) SRv6 END.X SID as a pair of IPv6 Global Addresses & > > > > >>> Interface IDs > > > > >>> for Local & Remote Nodes > > > > >>> > > > > >>> (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for the > > > > >>> Local & > > > > >>> Remote Interface -> > > > > >>> (Type K) SRv6 END.X SID as a pair of IPv6 Global Addresses for > > > > >>> Local & > > > > >>> Remote Interface Addresses > > > > >>> --> > > > > >>> > > > > >>> KT> Please refer to my response to your point 13 that impacts this. > > > > >>> With that in mind, I would think > > > > >>> that these queries are no longer relevant? > > > > >>> > > > > >>> > > > > >>> > > > > >>> 22) <!--[rfced] FYI: In the Contributors section, we updated the > > > > >>> lead-in > > > > >>> text as follows to indicate that the individuals listed are > > > > >>> coauthors. > > > > >>> > > > > >>> Original: > > > > >>> The following people have substantially contributed to the editing > > > > >>> of > > > > >>> this document: > > > > >>> > > > > >>> Current: > > > > >>> The following people have contributed substantially to the > > > > >>> content of this document and should be considered coauthors: > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 23) <!-- [rfced] Terminology > > > > >>> > > > > >>> a) Throughout the text, the following terminology appears to be used > > > > >>> inconsistently. Please review these occurrences and let us know > > > > >>> if/how they > > > > >>> may be made consistent. > > > > >>> > > > > >>> -Flag vs. -flag > > > > >>> (e.g., "D-Flag" vs. "A-flag" in the running text) > > > > >>> > > > > >>> KT> -flag > > > > >>> > > > > >>> Metric Type field vs. "metric type" field > > > > >>> (Note: the companion document uses "metric type field" with no > > > > >>> quote marks) > > > > >>> > > > > >>> KT> metric type field - without the quotes > > > > >>> > > > > >>> Segment Descriptor vs. Segment descriptor > > > > >>> > > > > >>> KT> segment descriptor (except when used in titles where > > > > >>> capitalization is used) > > > > >>> > > > > >>> Segment List vs. segment list > > > > >>> > > > > >>> KT> 2nd > > > > >>> > > > > >>> SID-List vs. SID-list vs. SID-LIST vs. SID List > > > > >>> > > > > >>> KT> SID list to be consistent with a single usage in RFC9256 > > > > >>> > > > > >>> SR Policy Candidate Path NLRI Type vs. SR Policy Candidate Path > > > > >>> NLRI type > > > > >>> > > > > >>> KT> 2nd > > > > >>> > > > > >>> > > > > >>> SR Policy Candidate Path vs. SR Policy Candidate path vs. SR Policy > > > > >>> candidate path > > > > >>> > > > > >>> KT> Capitalization when used in name (1st) and otherwise (3rd) > > > > >>> > > > > >>> > > > > >>> > > > > >>> b) We updated the following terms for consistency. Please let us > > > > >>> know of any objections. > > > > >>> > > > > >>> codepoint -> code point (per IANA registries) > > > > >>> dataplane -> data plane > > > > >>> drop upon invalid -> Drop-Upon-Invalid (per RFC 9256) > > > > >>> Global address -> global address (2 instances in the running text) > > > > >>> head-end -> headend > > > > >>> nexthop -> next hop > > > > >>> traffic engineering -> Traffic Engineering (per RFC 9552 and the > > > > >>> companion document) > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> c) FYI: We made "Constraints" in the following sub-TLV names > > > > >>> singular for consistency > > > > >>> with Table 4. > > > > >>> > > > > >>> SR Affinity Constraints Sub-TLV -> SR Affinity Constraint Sub-TLV > > > > >>> (Figure 12) > > > > >>> SR Bandwidth Constraints Sub-TLV -> SR Bandwidth Constraint Sub-TLV > > > > >>> (Figure 14) > > > > >>> > > > > >>> SR Bidirectional Group Constraints Sub-TLV -> > > > > >>> SR Bidirectional Group Constraint Sub-TLV (Figure 16) > > > > >>> > > > > >>> SR Disjoint Group Constraints Sub-TLV -> SR Disjoint Group > > > > >>> Constraint Sub-TLV (Figure 15) > > > > >>> SR Metric Constraints Sub-TLV -> SR Metric Constraint Sub-TLV > > > > >>> (Figure 17 and Section 5.7.2) > > > > >>> SR SRLG Constraints Sub-TLV -> SR SRLG Constraint Sub-TLV (Figure > > > > >>> 13) > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> d) FYI: We updated 7 instances of "Descriptor" to "Descriptors" > > > > >>> for TLV 256 per RFC 9552. > > > > >>> > > > > >>> Local Node Descriptor (TLV 256) -> Local Node Descriptors (TLV 256) > > > > >>> --> > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 24) <!-- [rfced] Abbreviations > > > > >>> > > > > >>> a) FYI - We have added expansions for the following abbreviations > > > > >>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > > >>> expansion in the document carefully to ensure correctness. > > > > >>> > > > > >>> Autonomous System Number (ASN) > > > > >>> Bidirectional Forwarding Detection (BFD) > > > > >>> External BGP (EBGP) > > > > >>> Label Edge Routers (LERs) > > > > >>> Label Switched Path (LSP) > > > > >>> Label Switching Router (LSR) > > > > >>> Network Layer Reachability Information (NLRI) > > > > >>> Path Computation Element Communication Protocol (PCEP) > > > > >>> > > > > >>> KT> Ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> b) To reflect more common usage in previously published RFCs, may > > > > >>> we update > > > > >>> the expansion of "BGP-LS" from "BGP Link-State" to "BGP - Link > > > > >>> State"? If yes, > > > > >>> note that the title of this document would also be updated > > > > >>> accordingly. > > > > >>> > > > > >>> Original: > > > > >>> Advertisement of Segment Routing Policies using BGP Link-State > > > > >>> ... > > > > >>> This document describes a mechanism to collect the Segment Routing > > > > >>> Policy information that is locally available in a node and > > > > >>> advertise > > > > >>> it into BGP Link-State (BGP-LS) updates. > > > > >>> > > > > >>> Perhaps: > > > > >>> Advertisement of Segment Routing Policies using BGP - Link State > > > > >>> ... > > > > >>> This document describes a mechanism to collect the Segment Routing > > > > >>> Policy information that is locally available in a node and > > > > >>> advertise > > > > >>> it into BGP - Link State (BGP-LS) updates. > > > > >>> --> > > > > >>> > > > > >>> KT> ack > > > > >>> > > > > >>> > > > > >>> > > > > >>> 25) <!-- [rfced] Please review the "Inclusive Language" portion of > > > > >>> the online > > > > >>> Style Guide > > > > >>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > > >>> and let us know if any changes are needed. Updates of this nature > > > > >>> typically > > > > >>> result in more precise language, which is helpful for readers. > > > > >>> > > > > >>> Note that our script did not flag any words in particular, but this > > > > >>> should > > > > >>> still be reviewed as a best practice. > > > > >>> --> > > > > >>> > > > > >>> KT> Looks good to me. > > > > >>> > > > > >>> Thanks, > > > > >>> Ketan > > > > >>> > > > > >>> > > > > >>> > > > > >>> Thank you. > > > > >>> > > > > >>> Karen Moore and Alanna Paloma > > > > >>> RFC Production Center > > > > >>> > > > > >>> > > > > >>> On Sep 10, 2025, at 3:08 PM, [email protected] wrote: > > > > >>> > > > > >>> *****IMPORTANT***** > > > > >>> > > > > >>> Updated 2025/09/10 > > > > >>> > > > > >>> RFC Author(s): > > > > >>> -------------- > > > > >>> > > > > >>> Instructions for Completing AUTH48 > > > > >>> > > > > >>> Your document has now entered AUTH48. Once it has been reviewed and > > > > >>> approved by you and all coauthors, it will be published as an RFC. > > > > >>> If an author is no longer available, there are several remedies > > > > >>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > >>> > > > > >>> You and you coauthors are responsible for engaging other parties > > > > >>> (e.g., Contributors or Working Group) as necessary before providing > > > > >>> your approval. > > > > >>> > > > > >>> Planning your review > > > > >>> --------------------- > > > > >>> > > > > >>> Please review the following aspects of your document: > > > > >>> > > > > >>> * RFC Editor questions > > > > >>> > > > > >>> Please review and resolve any questions raised by the RFC Editor > > > > >>> that have been included in the XML file as comments marked as > > > > >>> follows: > > > > >>> > > > > >>> <!-- [rfced] ... --> > > > > >>> > > > > >>> These questions will also be sent in a subsequent email. > > > > >>> > > > > >>> * Changes submitted by coauthors > > > > >>> > > > > >>> Please ensure that you review any changes submitted by your > > > > >>> coauthors. We assume that if you do not speak up that you > > > > >>> agree to changes submitted by your coauthors. > > > > >>> > > > > >>> * Content > > > > >>> > > > > >>> Please review the full content of the document, as this cannot > > > > >>> change once the RFC is published. Please pay particular attention > > > > >>> to: > > > > >>> - IANA considerations updates (if applicable) > > > > >>> - contact information > > > > >>> - references > > > > >>> > > > > >>> * Copyright notices and legends > > > > >>> > > > > >>> Please review the copyright notice and legends as defined in > > > > >>> RFC 5378 and the Trust Legal Provisions > > > > >>> (TLP – https://trustee.ietf.org/license-info). > > > > >>> > > > > >>> * Semantic markup > > > > >>> > > > > >>> Please review the markup in the XML file to ensure that elements > > > > >>> of > > > > >>> content are correctly tagged. For example, ensure that > > > > >>> <sourcecode> > > > > >>> and <artwork> are set correctly. See details at > > > > >>> <https://authors.ietf.org/rfcxml-vocabulary>. > > > > >>> > > > > >>> * Formatted output > > > > >>> > > > > >>> Please review the PDF, HTML, and TXT files to ensure that the > > > > >>> formatted output, as generated from the markup in the XML file, is > > > > >>> reasonable. Please note that the TXT will have formatting > > > > >>> limitations compared to the PDF and HTML. > > > > >>> > > > > >>> > > > > >>> Submitting changes > > > > >>> ------------------ > > > > >>> > > > > >>> To submit changes, please reply to this email using ‘REPLY ALL’ as > > > > >>> all > > > > >>> the parties CCed on this message need to see your changes. The > > > > >>> parties > > > > >>> include: > > > > >>> > > > > >>> * your coauthors > > > > >>> > > > > >>> * [email protected] (the RPC team) > > > > >>> > > > > >>> * other document participants, depending on the stream (e.g., > > > > >>> IETF Stream participants are your working group chairs, the > > > > >>> responsible ADs, and the document shepherd). > > > > >>> > > > > >>> * [email protected], which is a new archival mailing > > > > >>> list > > > > >>> to preserve AUTH48 conversations; it is not an active discussion > > > > >>> list: > > > > >>> > > > > >>> * More info: > > > > >>> > > > > >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > >>> > > > > >>> * The archive itself: > > > > >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > >>> > > > > >>> * Note: If only absolutely necessary, you may temporarily opt > > > > >>> out > > > > >>> of the archiving of messages (e.g., to discuss a sensitive > > > > >>> matter). > > > > >>> If needed, please add a note at the top of the message that > > > > >>> you > > > > >>> have dropped the address. When the discussion is concluded, > > > > >>> [email protected] will be re-added to the CC list > > > > >>> and > > > > >>> its addition will be noted at the top of the message. > > > > >>> > > > > >>> You may submit your changes in one of two ways: > > > > >>> > > > > >>> An update to the provided XML file > > > > >>> — OR — > > > > >>> An explicit list of changes in this format > > > > >>> > > > > >>> Section # (or indicate Global) > > > > >>> > > > > >>> OLD: > > > > >>> old text > > > > >>> > > > > >>> NEW: > > > > >>> new text > > > > >>> > > > > >>> You do not need to reply with both an updated XML file and an > > > > >>> explicit > > > > >>> list of changes, as either form is sufficient. > > > > >>> > > > > >>> We will ask a stream manager to review and approve any changes that > > > > >>> seem > > > > >>> beyond editorial in nature, e.g., addition of new text, deletion of > > > > >>> text, > > > > >>> and technical changes. Information about stream managers can be > > > > >>> found in > > > > >>> the FAQ. Editorial changes do not require approval from a stream > > > > >>> manager. > > > > >>> > > > > >>> > > > > >>> Approving for publication > > > > >>> -------------------------- > > > > >>> > > > > >>> To approve your RFC for publication, please reply to this email > > > > >>> stating > > > > >>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > > > > >>> as all the parties CCed on this message need to see your approval. > > > > >>> > > > > >>> > > > > >>> Files > > > > >>> ----- > > > > >>> > > > > >>> The files are available here: > > > > >>> https://www.rfc-editor.org/authors/rfc9857.xml > > > > >>> https://www.rfc-editor.org/authors/rfc9857.html > > > > >>> https://www.rfc-editor.org/authors/rfc9857.pdf > > > > >>> https://www.rfc-editor.org/authors/rfc9857.txt > > > > >>> > > > > >>> Diff file of the text: > > > > >>> https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > >>> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by > > > > >>> side) > > > > >>> > > > > >>> Diff of the XML: > > > > >>> https://www.rfc-editor.org/authors/rfc9857-xmldiff1.html > > > > >>> > > > > >>> > > > > >>> Tracking progress > > > > >>> ----------------- > > > > >>> > > > > >>> The details of the AUTH48 status of your document are here: > > > > >>> https://www.rfc-editor.org/auth48/rfc9857 > > > > >>> > > > > >>> Please let us know if you have any questions. > > > > >>> > > > > >>> Thank you for your cooperation, > > > > >>> > > > > >>> RFC Editor > > > > >>> > > > > >>> -------------------------------------- > > > > >>> RFC9857 (draft-ietf-idr-bgp-ls-sr-policy-17) > > > > >>> > > > > >>> Title : Advertisement of Segment Routing Policies using > > > > >>> BGP Link-State > > > > >>> Author(s) : S. Previdi, K. Talaulikar, Ed., J. Dong, H. > > > > >>> Gredler, J. Tantsura > > > > >>> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas > > > > >>> > > > > >>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > > > > >>> Velde > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > NOTICE TO RECIPIENT This e-mail message and any attachments are > > > > confidential and may be privileged. If you received this e-mail in > > > > error, any review, use, dissemination, distribution, or copying of this > > > > e-mail is strictly prohibited. Please notify us immediately of the > > > > error by return e-mail and please delete this message from your system. > > > > For more information about Rtbrick, please visit us at www.rtbrick.com > > > > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
