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

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

I have reviewed the document and I approve the publication of this document.

Thanks,
-Rishabh

> -----Original Message-----
> From: Megan Ferguson <[e-mail]>
> Sent: Monday, February 12, 2024 11:28 AM
> 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
> 
> 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>