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

["Hooman Bidgoli (Nokia)" <[e-mail]>]

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

Thanks
Hooman

-----Original Message-----
From: Voyer, Daniel <[e-mail]> 
Sent: Tuesday, February 13, 2024 1:22 PM
To: Rishabh Parekh (riparekh) <[e-mail]>; Megan Ferguson <[e-mail]>
Cc: [e-mail]; Clarence Filsfils (cfilsfil) <[e-mail]>; Hooman Bidgoli (Nokia) <[e-mail]>; [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

Hi, I have reviewed the document and I approve its publication.

Thanks
Dan

On 2024-02-13, 1:18 PM, "Rishabh Parekh (riparekh)" <[e-mail] <mailto:[e-mail]>> wrote:


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


Thanks,
-Rishabh


> -----Original Message-----
> From: Megan Ferguson <[e-mail] <mailto:[e-mail]>>
> Sent: Monday, February 12, 2024 11:28 AM
> To: Rishabh Parekh (riparekh) <[e-mail] 
> <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; Clarence Filsfils 
> (cfilsfil) <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; spring- [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Mankamana Mishra (mankamis) 
> <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>;
> [e-mail] <mailto:[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.txt>
> https://www.rfc-editor.org/authors/rfc9524.pdf 
> <https://www.rfc-editor.org/authors/rfc9524.pdf>
> https://www.rfc-editor.org/authors/rfc9524.html 
> <https://www.rfc-editor.org/authors/rfc9524.html>
> https://www.rfc-editor.org/authors/rfc9524.xml 
> <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 
> <https://www.rfc-editor.org/authors/rfc9524-diff.html> (comprehensive 
> diff) https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html 
> <https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html> 
> (comprehensive side-
> by-side)
> https://www.rfc-editor.org/authors/rfc9524-auth48diff.html 
> <https://www.rfc-editor.org/authors/rfc9524-auth48diff.html> (all 
> AUTH48
> changes)
> https://www.rfc-editor.org/authors/rfc9524-lastdiff.html 
> <https://www.rfc-editor.org/authors/rfc9524-lastdiff.html> (last 
> version to this) 
> https://www.rfc-editor.org/authors/rfc9524-lastrfcdiff.html 
> <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 
> <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] <mailto:[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] 
> >> <mailto:[e-mail]>>
> >> Sent: Monday, February 5, 2024 5:05 PM
> >> To: Rishabh Parekh (riparekh) <[e-mail] 
> >> <mailto:[e-mail]>>
> >> Cc: [e-mail] <mailto:[e-mail]>; 
> >> [e-mail] <mailto:[e-mail]>; Clarence 
> >> Filsfils (cfilsfil) <[e-mail] 
> >> <mailto:[e-mail]>>; [e-mail] 
> >> <mailto:[e-mail]>;
> >> [e-mail] <mailto:[e-mail]>; spring- 
> >> [e-mail] <mailto:[e-mail]>; [e-mail] 
> >> <mailto:[e-mail]>; Mankamana Mishra (mankamis) 
> >> <[e-mail] <mailto:[e-mail]>>; 
> >> [e-mail] 
> >> <mailto:[e-mail]>; 
> >> [e-mail] <mailto:[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.txt>
> >> https://www.rfc-editor.org/authors/rfc9524.pdf 
> >> <https://www.rfc-editor.org/authors/rfc9524.pdf>
> >> https://www.rfc-editor.org/authors/rfc9524.html 
> >> <https://www.rfc-editor.org/authors/rfc9524.html>
> >> https://www.rfc-editor.org/authors/rfc9524.xml 
> >> <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 
> >> <https://www.rfc-editor.org/authors/rfc9524-diff.html> 
> >> (comprehensive) 
> >> https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html 
> >> <https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html>
> >> (comprehensive side-
> >> by-side)
> >> https://www.rfc-editor.org/authors/rfc9524-auth48diff.html 
> >> <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 
> >> <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] <mailto:[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] 
> >>>> <mailto:[e-mail]> <[e-mail] 
> >>>> <mailto:[e-mail]>>
> >>>> Sent: Friday, January 19, 2024 11:15 AM
> >>>> To: [e-mail] <mailto:[e-mail]>; Clarence 
> >>>> Filsfils (cfilsfil) <[e-mail] 
> >>>> <mailto:[e-mail]>>; Rishabh Parekh (riparekh) 
> >>>> <[e-mail] <mailto:[e-mail]>>; 
> >>>> [e-mail] <mailto:[e-mail]>; 
> >>>> [e-mail] <mailto:[e-mail]>
> >>>> Cc: [e-mail] <mailto:[e-mail]>; 
> >>>> [e-mail] <mailto:[e-mail]>; 
> >>>> [e-mail] <mailto:[e-mail]>; Mankamana 
> >>>> Mishra (mankamis) <[e-mail] 
> >>>> <mailto:[e-mail]>>; [e-mail] 
> >>>> <mailto:[e-mail]>;
> >>>> [e-mail] 
> >>>> <mailto:[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 <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 
> >>>> <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> 
> >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&
> >>>> gt;> 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/ <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/ <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> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.
> >>>>
> >>>> * 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] <mailto:[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] 
> >>>> <mailto:[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- 
> >>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh->
> >>>> 4Q9l2USxIAe6P8O4Zc
> >>>>
> >>>> * The archive itself:
> >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ 
> >>>> <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] 
> >>>> <mailto:[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.xml>
> >>>> https://www.rfc-editor.org/authors/rfc9524.html 
> >>>> <https://www.rfc-editor.org/authors/rfc9524.html>
> >>>> https://www.rfc-editor.org/authors/rfc9524.pdf 
> >>>> <https://www.rfc-editor.org/authors/rfc9524.pdf>
> >>>> https://www.rfc-editor.org/authors/rfc9524.txt 
> >>>> <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-diff.html>
> >>>> https://www.rfc-editor.org/authors/rfc9524-rfcdiff.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 
> >>>> <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 
> >>>> <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 
> >>>> <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 
> >>>> <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>


------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints