Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review

["Rishabh Parekh (riparekh)" <[e-mail]>]

Replies inline @ [RP]

I have made some of suggested changes in attached XML file.

-Rishabh

> -----Original Message-----
> From: Megan Ferguson <[e-mail]>
> Sent: Monday, February 5, 2024 5:05 PM
> To: Rishabh Parekh (riparekh) <[e-mail]>
> Cc: [e-mail]; [e-mail]; Clarence Filsfils (cfilsfil)
> <[e-mail]>; [e-mail]; [e-mail]; spring-
> [e-mail]; [e-mail]; Mankamana Mishra (mankamis)
> <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-
> 19> for your review
> 
> Hi Rishabh,
> 
> Thank you for sending along your edited file and responses to our queries.
> 
> We have combined the two and posted the updated files below.
> 
> We also had a few additional questions:
> 
> 1.) It looks like we missed sending the following question:
> 
> <!--[rfced] We had a few questions regarding the following text:
> 
> Original:
> Given the definition of the Replication segment in this document, an attacker
> subverting ingress filter above cannot take advantage of a stack of replication
> segments to perform amplification attacks nor link exhaustion attacks.
> 
> a) Would it be helpful to the reader to point them to the section in which they
> can find the definition of “Replication segment” (i.e., Section 1.1, Section 2)?

[RP] I don't think it is necessary to refer to the definition. We can assume the reader has read the preceding sections before the Security section.

> 
> b) It might help the reader to clarify what/where “above” is referring to.
> We see this as the only instance of “ingress filters” in the document.
> 

[RP] I don't think it is necessary, but if the RFC editors think it will help to clarify "above", please do so.

> c) (Maybe depending on the response to b above) Should “subverting ingress
> filter”
> be made either “subverting ingress filters” (plural) or “subverting an ingress
> filter”?
> 

[RP] I see that latest XML has changed this to plural "ingress filters" which is fine.

> —>
> 
> 2.) And we would like you to further review the use of “Replication state” vs.
> “Replication segment state”.
> 

[RP] I have changed text for "Replication segment state" in the attached XML file.

> 3) In the pseudocode, may we put parentheses around the following?
> 
> Original:
>    S01.   Lookup FUNCT portion of S to get Replication state RS
> 
> Perhaps:
>    S01.   Lookup FUNCT portion of S to get Replication state (RS)

[RP] I have made the change in attached XML file.

> 
>   The files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9524.txt
>    https://www.rfc-editor.org/authors/rfc9524.pdf
>    https://www.rfc-editor.org/authors/rfc9524.html
>    https://www.rfc-editor.org/authors/rfc9524.xml
> 
>   The relevant diff files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9524-diff.html (comprehensive)
>    https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html (comprehensive side-
> by-side)
>    https://www.rfc-editor.org/authors/rfc9524-auth48diff.html (AUTH48 changes
> only)
> 
> Upon review, please let us know if any further updates are necessary.
> Please review the files carefully as we do not make changes after publication.
> 
> We will await approvals from each of the parties listed on the AUTH48 status
> page prior to moving forward to publication.
> 
> The AUTH48 status page for this document is available here:
> 
> https://www.rfc-editor.org/auth48/rfc9524
> 
> Thank you.
> 
> RFC Editor/mf
> 
> > On Jan 26, 2024, at 6:40 PM, Rishabh Parekh (riparekh)
> <riparekh=[e-mail]> wrote:
> >
> > I have made some of the suggested modifications in the attached XML
> > file. For other questions and concerns, please look for my inline
> > replies @ [RP]
> >
> > Thanks,
> > -Rishabh
> >
> >> -----Original Message-----
> >> From: [e-mail] <[e-mail]>
> >> Sent: Friday, January 19, 2024 11:15 AM
> >> To: [e-mail]; Clarence Filsfils (cfilsfil)
> >> <[e-mail]>; Rishabh Parekh (riparekh) <[e-mail]>;
> >> [e-mail]; [e-mail]
> >> Cc: [e-mail]; [e-mail];
> >> [e-mail]; Mankamana Mishra (mankamis)
> >> <[e-mail]>; [e-mail];
> >> [e-mail]
> >> Subject: Re: AUTH48: RFC-to-be 9524
> >> <draft-ietf-spring-sr-replication-segment-
> >> 19> for your review
> >>
> >> Authors,
> >>
> >> While reviewing this document during AUTH48, please resolve (as
> >> necessary) the following questions, which are also in the XML file.
> >>
> >> 1) <!-- [rfced] Please note that the title of the document has been
> >>     updated as follows:
> >>
> >> a. Abbreviations have been expanded per Section 3.6 of RFC 7322 (“RFC
> >> Style Guide”).  Additionally, please let us know any suggestions for
> >> reducing the redundancy of "Segment" (see our suggestion below).
> >>
> >> b. We have also removed the hyphen from "Multi-point" for consistency
> >> with previous RFCs (in the title and throughout).  Please review and
> >> let us know any objections.
> >>
> >> Original:
> >>
> >> SR Replication segment for Multi-point Service Delivery
> >>
> >> Current:
> >>
> >> Segment Routing Replication Segment for Multipoint Service Delivery
> >>
> >> Perhaps:
> >> Segment Routing Replication for Multipoint Service Delivery
> >> -->
> >>
> >
> > [RP] I have changed the tile in the edited XML file.
> >
> >>
> >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> >>     the title) for use on https://www.rfc-editor.org/search.
> >> -->
> >>
> >>
> >> 3) <!--[rfced] We see the following three similar sentences in close
> >>     proximity:
> >>
> >> Original:
> >> This Replication segment can be either provisioned locally on ingress
> >> and egress nodes, or using dynamic auto-discovery procedures for MVPN
> and EVPN.
> >>
> >> and
> >>
> >> Original:
> >> A Replication segment is a local segment instantiated at a
> >> Replication node.  It can be either provisioned locally on a node or
> programmed by a control plane.
> >>
> >
> > [RP] In this sentence the control plane refers to something like a PCE rather
> than MVPN or EVPN (as used for ingress replication).
> >
> >> and
> >>
> >> Original:
> >> Replication segments can be stitched together to form a tree by
> >> either local provisioning on nodes or using a control plane.
> >
> > [RP] Again, the control plane refers to PCE in this context as explained later in
> the paragraph.
> >
> >>
> >> a) Please confirm our update to the first sentence (see below)
> >> correctly captures your intent.  Our goal is to make the two phrases joined by
> "either"
> >> symmetrical.
> >>
> >> Perhaps:
> >> This Replication segment can be either provisioned locally on ingress
> >> and egress nodes or using dynamic autodiscovery procedures for MVPN and
> EVPN.
> >
> > [RP] I have rearranged the first sentence to make both options (local and
> dynamic) symmetrical.
> >
> >>
> >> b) Please review the three similar sentences listed above and ensure
> >> that they do not need to be made more uniform and/or review if
> >> redundancy should be reduced.
> >>
> >> -->
> >>
> >>
> >> 4) <!--[rfced] In the following, does "Anycast set" mean "a set of
> >>     Anycast SIDs"?  Note: this text occurs two times in the text.
> >>
> >> Original:
> >>   *  A Replication node MAY use an Anycast SID or a Border Gateway
> >>      Protocol (BGP) PeerSet SID in segment list to send a
> >>      replicated packet to one downstream Replication node in an Anycast set...
> >>
> >>
> >> -->
> >
> > [RP] Anycast-SID is one SID that is shared by multiple nodes in an Anycast set.
> I have re-worded the sentence to make this clear.
> >
> >>
> >>
> >> 5) <!-- [rfced] We had the following questions regarding the pseudocode in
> >>     Section 2.2.1.
> >>
> >> a) The following line exceeds the 72-character limit. Please let us
> >> know how this line can be modified.
> >>
> >> Original:
> >>
> >> S03.     Discard the packet
> >> S04.     # ICMPv6 Time Exceeded is not permitted (ICMPv6 section below)
> >> S05.   }
> >>
> >> Perhaps:
> >>
> >> S03.     Discard the packet
> >> S04.     # ICMPv6 Time Exceeded is not permitted
> >>           (ICMPv6 section below)
> >> S05.   }
> >>
> >
> > [RP] Fixed
> >
> >> b) Will it be clear what "ICMPv6 section below" in the parenthetical
> >> in point a) above refers to?  Should this be replaced by a specific
> >> section number.  Note this occurs more than once.
> >>
> >
> > [RP] Although it should be clear that this refers to Section 2.2.3, changing this
> to an explicit reference is fine.
> >
> >> c) We note that there is no space between PPC and its expansion.  May
> >> we make the following updates?
> >>
> >> Original:
> >> S20.       Derive packet processing context(PPC) from Segment List
> >>
> >> Perhaps:
> >> S20.       Derive packet processing context (PPC) from Segment List
> >>
> >> Original:
> >> S28.       Derive packet processing context(PPC)
> >>
> >> Perhaps:
> >> S28.       Derive packet processing context (PPC)
> >
> > [RP] Fixed.
> >
> >>
> >> d) In the pseudocode, we see Upper-layer Header.  In other parts of
> >> the document, we mostly see Upper-Layer header (but upper layer
> >> headers also appears).  Please let us know if/how these terms may be
> >> made consistent in both the pseudocode and the body of the document.
> >>
> >> Original:
> >> S12.     # (SR Upper-layer Header Error)
> >>
> >> Perhaps:
> >> S12.     # (SR Upper-Layer header Error)
> >>
> >
> > [RP] RFC 8986 uses "Upper-Layer Header" with capital H in title of Section
> 4.1.1 and "Upper-Layer header" in rest of the text. I think we can use the same
> approach.
> >
> >> e)  Please review our update to the reference to RFC 8986 in the
> >> pseudocode and let us know any concerns.
> >>
> >> Original:
> >>   S09.         Execute H.Encaps or H.Encaps.Red with RS.Segment-List
> >>                on packet copy #RFC 8986 Section 5.1, 5.2
> >>
> >> Current:
> >>   S09.         Execute H.Encaps or H.Encaps.Red with RS.Segment-List
> >>                on packet copy #RFC 8986, Sections 5.1 and 5.2
> >>
> >>
> >
> > [RP] This is fine.
> >
> >> 	  -->
> >>
> >>
> >> 6) <!--[rfced] In the first sentence, "transit node" is singular.  In the
> >>     second, it's plural (i.e., "The transit nodes...").  Please
> >>     review and let us know if/how updates should be made for clarity.
> >>
> >> Original:
> >> The source can then send the Echo Request packet to a transit node's
> >> Replication SID.  The transit nodes replicate the packet by replacing
> >> the IPv6 destination address till the packet reaches the Leaf/Bud
> >> node which responds with an ICMPv6 Echo Reply.
> >>
> >> Perhaps:
> >> The source can then send the Echo Request packet to a transit node's
> >> Replication SID.  The transit node replicates the packet by replacing
> >> the IPv6 destination address until the packet reaches the Leaf/Bud
> >> node, which responds with an ICMPv6 Echo Reply.
> >
> > [RP] I have made the suggested change in edited XML file.
> >
> >>
> >> -->
> >>
> >>
> >> 7) <!--[rfced] In the following text:
> >>
> >> Original:
> >> Traceroute to a Leaf/Bud node Replication SID is not possible due to
> >> restriction prohibiting origination of ICMPv6 Time Exceeded error
> >> message for a Replication SID as described in the section below.
> >>
> >> Current:
> >> Traceroute to a Leaf/Bud node Replication SID is not possible due to
> >> restrictions prohibiting the origination of the ICMPv6 Time Exceeded
> >> error message for a Replication SID as described in Section 2.2.3.
> >>
> >> a) Please review our update to make "restrictions" plural.
> >>
> >> b) Please also confirm the update to point to Section 2.2.3.
> >>
> >
> > [RP] The changes are fine.
> >
> >> -->
> >>
> >>
> >> 8) <!--[rfced] In the following, the close proximity of two occurrences
> >>     of "from" makes this sentence possibly difficult to parse on a
> >>     single read-through.  Might the following suggested text be
> >>     acceptable?
> >>
> >> Original:
> >> This is to prevent a storm of ICMPv6 error messages resulting from
> >> replicated
> >> IPv6 packets from overwhelming a source node.
> >>
> >> Perhaps:
> >> This is to prevent a source node from being overwhelmed by a storm of
> >> ICMPv6 error messages resulting from replicated IPv6 packets.
> >> -->
> >>
> >
> > [RP] I have made the suggested change in edited XML file.
> >
> >>
> >> 9) <!--[rfced] Please review the list in the Security Considerations
> >>     section.  While most points begin with a verb phrase, a few
> >>     points do not.  Please let us know if/how we may make this list
> >>     parallel in structure.
> >>
> >> Original:
> >>
> >>   *  For SR-MPLS deployments:
> >>
> >>      -  By disabling MPLS on external interfaces of each edge node or
> >>         any other technique to filter labeled traffic ingress on these
> >>         interfaces.
> >>
> >>   *  For SRv6 deployments:
> >>
> >>      -  Allocate all the SIDs from an IPv6 prefix block S/s and
> >>         configure each external interface of each edge node of the
> >>         domain with an inbound infrastructure access list (IACL) that
> >>         drops any incoming packet with a destination address in S/s.
> >>
> >>      -  Additionally, an iACL may be applied to all nodes (k)
> >>         provisioning SIDs as defined in this specification:
> >>
> >>         o  Assign all interface addresses from within IPv6 prefix A/a.
> >>            At node k, all SIDs local to k are assigned from prefix Sk/
> >>            sk.  Configure each internal interface of each SR node k in
> >>            the SR domain with an inbound IACL that drops any incoming
> >>            packet with a destination address in Sk/sk if the source
> >>            address is not in A/a.
> >>
> >>      -  Denying traffic with spoofed source addresses by implementing
> >>         recommendations in BCP 84 [RFC3704].
> >>
> >>      -  Additionally the block S/s from which SIDs are allocated may be
> >>         a non-globally-routable address such as ULA or the prefix
> >>         defined in [I-D.ietf-6man-sids].
> >> -->
> >
> > [RP] The updated text is fine.
> >
> >>
> >>
> >> 10) <!--[rfced] This sentence may be easier to get through on a single
> >>     read if broken into a list as follows.  Please let us know if
> >>     this is agreeable.
> >>
> >> Original:
> >> If an attacker can forge an IPv6 packet with source address of a
> >> node, Replication SID as destination address and an IPv6 Hop Limit
> >> such that nodes which forward replicated packets on IPv6 locator
> >> unicast prefix, decrement the Hop Limit to zero, then these nodes can
> >> cause a storm of
> >> ICMPv6 Error packets to overwhelm the source node under attack.
> >>
> >> Perhaps:
> >>
> >> If an attacker can forge an IPv6 packet with:
> >>
> >> * the source address of a node,
> >> * a Replication SID as the destination address, and
> >> * an IPv6 Hop Limit such that nodes that forward replicated packets
> >> on an IPv6 locator unicast prefix decrement the Hop Limit to zero,
> >>
> >> then these nodes can cause a storm of ICMPv6 error packets to
> >> overwhelm the source node under attack.
> >>
> >
> > [RP] I have split up the sentence as suggested in edited XML file.
> >
> >> -->
> >>
> >>
> >> 11) <!-- [rfced] Please review the "type" attribute of each sourcecode
> >>     element in the XML file to ensure correctness. If the current
> >>     list of preferred values for "type"
> >>     (https://www.rfc-editor.org/materials/sourcecode-types.txt) does
> >>     not contain an applicable type, then feel free to let us
> >>     know. Also, it is acceptable to leave the "type" attribute not
> >>     set.
> >
> > [RP] "pseudocode" type is appropriate.
> >
> >> -->
> >>
> >>
> >> 12) <!-- [rfced] We have a few questions regarding the terms used in this
> >>     document.
> >>
> >> a. End.Replicate is treated differently in the two instances below.
> >> Please review and let us know if/how these should be made uniform.
> >> Perhaps this term should be added to the Terminology section in lieu of the
> two descriptions?
> >>
> >> Original:
> >> “Endpoint with replication” behavior (End.Replicate for short)
> >>
> >> and
> >>
> >> Original:
> >> The "Endpoint with replication and/or decapsulate behavior
> >> (End.Replicate for
> >> short) is variant of End behavior.
> >>
> >
> > [RP] I have made changes to make both of this consistent (by using " Endpoint
> with replication and/or decapsulate") in the edited XML file.
> >
> >>
> >> b. Regarding hyphenation and capitalization of the following terms:
> >>
> >> i. Anycast SID: This term appears without a hyphen throughout the
> >> document, but in cited RFCs, it appears as Anycast-SID. May we update
> >> to the hyphenated form for consistency with these previous RFCs?
> >>
> > [RP] Yes, please update.
> >
> >> ii. Adjacency SID: This term seems to be "Adj-SID" in RFC 8402.
> >> Please review this usage and let us know if we can adjust to use "Adj-SID"
> >> for consistency with this cited RFC.
> >>
> > [RP] Yes, please use "Adj-SID"
> >
> >> iii. Replication SID: This term appears both hyphenated and without a
> >> hyphen (and in lowercase at times) throughout the document. May we
> >> update all instances to "Replication-SID", for consistency with the
> >> previous related terms and cited RFCs?
> >>
> > [RP] Yes, please update to "Replication-SID"
> >
> >> iv. FYI - Related to the above, we see the following terms in the
> >> document:
> >>
> >> Node-SID
> >> PeerSet SID
> >> context SID
> >>
> >
> > [RP] RFC 8402 uses "Node-SID" and "PeerSet SID" (without hyphenation) and
> we have adopted it from there, but it is fine to use "PeerSet-SID". "context SID"
> is introduced in this document and can therefore be changed to "context-SID".
> >
> >> In addition to:
> >> R-SID
> >> A-SID
> >> N-SID
> >>
> >> Please consider these when making decisions related to i-iii above.
> >>
> >> c. Several terms in this document appear separated with a slash (/),
> >> but it is unclear whether the slash stands for "and", "or", or
> >> "and/or". Please review uses of the slash throughout this document
> >> and let us know how to adjust for clarity.
> >>
> > [RP] I have replaced all occurrences of  slash (/) in "Leaf/Bud" and
> "MVPN/EVPN" with "and" or "or" as appropriate. Please let me know if there
> are any other ambiguous usage of the slash.
> >
> >>
> >> d. Should the following capitalized terms (seemingly node names) be
> >> changed to lowercase throughout for consistency with previous RFCs?
> >>
> >> Downstream
> >> Root
> >> Leaf
> >> Bud
> >>
> >> Related: We see both Replication node and Non-replication node.
> >> Please consider if all node name should be lowercase in light of the above.
> >>
> > [RP] Yes, these can be changed to lowercase.
> >
> >> e. We have updated the following terms to use the form on the right.
> >> Please review and let us know any objections:
> >>
> >> Active Segment / active segment (to match RFC 8402) replication
> >> branch / Replication branch
> >>
> > [RP] Change to "active segment" is fine, but I don't think "Replication branch"
> change is appropriate because lowercase "replication" is used to signify the act
> of replication instead of needing a proper noun with uppercase "Replication".
> >
> >>
> >> f. We see the following terms used inconsistently throughout the document.
> >> Please review and let us know if/how these may be made uniform.
> >>
> >> Replication segment vs. Replication Segment vs. replication segment
> >
> > [RP] I think using "Replication segment" will be consistent.
> >
> >>
> >> f. Please review the following questions about the message names below:
> >>
> >> i. Should "message" be lowercased or capitalized?
> >>
> >> Packet Too Big message vs. Parameter Problem Message
> >>
> >> ii. We see Parameter Problem both with and without ICMPv6.  Please
> >> review and let us know if/how these uses should be made uniform.
> >>
> >> iii. May we make the error codes uniform with regard to capping and
> ordering?
> >>
> >>
> >> Originals:
> >> ICMPv6 Parameter Problem with Code 0
> >> ICMPv6 Parameter Problem with Code 4
> >> an ICMPv6 error message (parameter problem, code 0) Parameter Problem
> >> Message, Code 2 Parameter Problem Message, code 2 ICMPv6 Error
> messages.
> >>
> >> Perhaps (making assumptions about i, ii, and iii above):
> >> ICMPv6 Parameter Problem message with Code 0
> >> ICMPv6 Parameter Problem message with Code 4
> >> ICMPv6 Parameter Problem message with Code 0
> >> ICMPv6 Parameter Problem message with Code 2
> >> ICMPv6 Parameter Problem message with Code 2
> >>
> > [RP] Above suggestion is fine.
> >
> >> -->
> >>
> >>
> >> 13) <!--[rfced] We had the following questions/comments related to
> >>     abbreviations used throughout the document:
> >>
> >> a. FYI - We have expanded the following abbreviations upon first use
> >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> >> expansion in the document carefully to ensure correctness:
> >>
> >> Destination Address (DA)
> >> Unique Local Address (ULA)
> >> Operations, Administration, and Maintenance (OAM)
> >>
> > [RP] This is fine.
> >
> >> b. FYI - We will update to use the abbreviated form of the following
> >> terms after the abbreviation is expanded on first use.  Please let us know any
> objections.
> >>
> >> Destination Address will become DA
> >> Replication state will become RS
> >> Segment Routing will become SR
> >>
> > [RP] This Is fine.
> >
> >>
> >> c) Please review this use of POP:
> >>
> >> Original:
> >> ...is a Replication SID, the processing results in a POP [RFC8402]...
> >>
> >> We do not see POP being expanded as an abbreviation in RFC 8402 or
> >> any of the normative references.  Please let us know if/how we may expand
> it.
> >>
> > [RP] POP is not used an acronym here. It signifies a "pop" operation on the
> top label of the label stack.
> >
> >> d) Please review the expansion and use of IACL/iACL.
> >>
> >> While we see the same expansion as used in this document in RFC 8754
> >> (see below), we are curious about the 1:1 relationship between the
> >> initialism and the expansion.
> >>
> >> We also note a single use of "iACL" in this document (see below).
> >>
> >> Original:
> >> -  Allocate all the SIDs from an IPv6 prefix block S/s and
> >>   configure each external interface of each edge node of the
> >>   domain with an inbound infrastructure access list (IACL) that
> >>   drops any incoming packet with a destination address in S/s.
> >>
> >> then later:
> >>
> >> Original:
> >> -  Additionally, an iACL may be applied to all nodes (k)
> >>   provisioning SIDs as defined in this specification:
> >>
> >> i) Should these uses be made "infrastructure Access Control List
> >> (iACL)" on expansion and then "iACL" thereafter?  Note that we see
> >> "Infrastructure Access Control List (iACL)" used in RFCs 7404 and 9098.
> >>
> >> ii) Or perhaps "infrastructure Access Control List (ACL)" on
> >> expansion as used in RFCs 6752 and 9252 (and "infrastructure ACL
> thereafter")?
> >>
> >> iii) Or maybe we should switch to using "Infrastructure Access
> >> Control List (IACL)" with a 1:1 between the expansion and the
> >> initialism and corresponding capitalization?  This form has not
> >> appeared in any published RFCs to date, but if this is how people know it,
> then perhaps this is the way to go in the future?
> >>
> >> We appreciate any guidance you may have.
> >>
> >
> > [RP] I don't think there is an established terminology for ACL and lowercase
> "i" or uppercase "I" do not make a difference. It should be fine to use using
> "Infrastructure Access Control List (IACL)".
> >> -->
> >>
> >>
> >> 14) <!-- [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.
> >>
> >> Note that our script did not flag any words in particular, but this
> >> should still be reviewed as a best practice.-->
> >>
> >>
> >> Thank you.
> >>
> >> RFC Editor/kf/mf
> >>
> >> *****IMPORTANT*****
> >>
> >> Updated 2024/01/19
> >>
> >> 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
> >>
> >>   *  [e-mail] (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).
> >>
> >>   *  [e-mail], 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,
> >>        [e-mail] 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/rfc9524.xml
> >>   https://www.rfc-editor.org/authors/rfc9524.html
> >>   https://www.rfc-editor.org/authors/rfc9524.pdf
> >>   https://www.rfc-editor.org/authors/rfc9524.txt
> >>
> >> Diff file of the text:
> >>   https://www.rfc-editor.org/authors/rfc9524-diff.html
> >>   https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html (side by
> >> side)
> >>
> >> Diff of the XML:
> >>   https://www.rfc-editor.org/authors/rfc9524-xmldiff1.html
> >>
> >> The following files are provided to facilitate creation of your own
> >> diff files of the XML.
> >>
> >> Initial XMLv3 created using XMLv2 as input:
> >>   https://www.rfc-editor.org/authors/rfc9524.original.v2v3.xml
> >>
> >> XMLv3 file that is a best effort to capture v3-related format updates
> >> only:
> >>   https://www.rfc-editor.org/authors/rfc9524.form.xml
> >>
> >>
> >> Tracking progress
> >> -----------------
> >>
> >> The details of the AUTH48 status of your document are here:
> >>   https://www.rfc-editor.org/auth48/rfc9524
> >>
> >> Please let us know if you have any questions.
> >>
> >> Thank you for your cooperation,
> >>
> >> RFC Editor
> >>
> >> --------------------------------------
> >> RFC9524 (draft-ietf-spring-sr-replication-segment-19)
> >>
> >> Title            : SR Replication segment for Multi-point Service Delivery
> >> Author(s)        : D. Voyer, Ed., C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang
> >> WG Chair(s)      : Bruno Decraene, Alvaro Retana, Joel M. Halpern
> >>
> >> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> >>
> >
> > <rfc9524-Jan26.xml><rfc9524-Jan26.diff.html>
> 
> 
> 
>