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

[Megan Ferguson <[e-mail]>]

Rishabh,

Thank you for your reply and the updated file.  We have reposted our version to match.

  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 diff)
   https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html (comprehensive side-by-side)
   https://www.rfc-editor.org/authors/rfc9524-auth48diff.html (all AUTH48 changes)
   https://www.rfc-editor.org/authors/rfc9524-lastdiff.html (last version to this)
   https://www.rfc-editor.org/authors/rfc9524-lastrfcdiff.html (last version to this side-by-side)

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 Feb 9, 2024, at 4:23 PM, Rishabh Parekh (riparekh) <[e-mail]> wrote:
> 
> 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>
>> 
>> 
>> 
>> 
> 
> <rfc9524-Feb09.xml><rfc9524-Feb09.diff.html>