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