[auth48] Re: AUTH48: RFC-to-be 9960 <draft-ietf-pim-sr-p2mp-policy-22> for your review

["Dan Voyer (davoyer)" <[e-mail]>]

Hi,
Let me approve again, in case my previous email didn’t reach you.
Approved !

Thanks
Dan
________________________________
From: Alanna Paloma <[e-mail]>
Sent: Monday, April 27, 2026 7:43:42 PM
To: Hooman Bidgoli (Nokia) <[e-mail]>; Dan Voyer (davoyer) <[e-mail]>
Cc: Gunter van de Velde (Nokia) <[e-mail]>; Rishabh Parekh <rishabh=[e-mail]>; Clarence Filsfils (cfilsfil) <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9960 <draft-ietf-pim-sr-p2mp-policy-22> for your review

Hi Dan and Hooman,

Thank you for your approvals. They have been noted here:
https://www.rfc-editor.org/auth48/rfc9960

We will await approvals from Rishabh, Clarence, and Zhaohui prior to moving this document forward in the publication process.

Best regards,
Alanna Paloma
RFC Production Center

> On Apr 27, 2026, at 1:46 PM, Hooman Bidgoli (Nokia) <[e-mail]> wrote:
>
> Approved
>  From: Dan Voyer (davoyer) <[e-mail]>
> Sent: Monday, April 27, 2026 2:19 PM
> To: Alanna Paloma <[e-mail]>; Gunter van de Velde (Nokia) <[e-mail]>; Rishabh Parekh <rishabh=[e-mail]>; Clarence Filsfils (cfilsfil) <[e-mail]>; Hooman Bidgoli (Nokia) <[e-mail]>;[e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [AD] AUTH48: RFC-to-be 9960 <draft-ietf-pim-sr-p2mp-policy-22> for your review
>   CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>  yes, approved !
>  Dan
>  From: Alanna Paloma <[e-mail]>
> Date: Friday, April 24, 2026 at 1:49 PM
> To: [e-mail]<[e-mail]>; Rishabh Parekh <rishabh=[e-mail]>; Dan Voyer (davoyer) <[e-mail]>; Clarence Filsfils (cfilsfil) <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail]<[e-mail]>; [e-mail] <[e-mail]>;[e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: [AD] AUTH48: RFC-to-be 9960 <draft-ietf-pim-sr-p2mp-policy-22> for your review
> Hi Authors and Gunter (AD)*,
>
> *Gunter - As the AD, please review and approve of the updated and added text in Section 4.2 in the diff file below:
>
> https://www.rfc-editor.org/authors/rfc9960-auth48diff.html
>
>
> Authors - Thank you for your reply.  We have updated as requested.
>
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9960.txt
> https://www.rfc-editor.org/authors/rfc9960.pdf
> https://www.rfc-editor.org/authors/rfc9960.html
> https://www.rfc-editor.org/authors/rfc9960.xml
>
> The relevant diff files are posted here:
> https://www.rfc-editor.org/authors/rfc9960-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9960-auth48diff.html (all AUTH48 changes)
> https://www.rfc-editor.org/authors/rfc9960-auth48rfcdiff.html (AUTH48 changes side by side)
>
> Please review the document carefully as documents do not change once published as RFCs.
>
> We will await any further changes you may have and approvals from each author and *Gunter prior to moving forward in the publication process.
>
> Please see the AUTH48 status page for this document here:
> https://www.rfc-editor.org/auth48/rfc9960
>
> Thank you,
> Alanna Paloma
> RFC Production Center
>
> > On Apr 20, 2026, at 7:57 PM, Rishabh Parekh <rishabh=[e-mail]> wrote:
> >
> > Please fine the response inline @ [RP].
> >
> > Thanks,
> > Rishabh
> >
> > From: [e-mail] <[e-mail]>
> > Date: Friday, April 17, 2026 at 3:15 PM
> > To: Rishabh Parekh <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>,[e-mail] <[e-mail]>, [e-mail]<[e-mail]>
> > Cc: [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>,[e-mail] <[e-mail]>,[e-mail] <[e-mail]>,[e-mail] <[e-mail]>
> > Subject: Re: AUTH48: RFC-to-be 9960 <draft-ietf-pim-sr-p2mp-policy-22> for your review
> >
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
> >
> > 1) <!--[rfced] Should "(SR)" and "(P2MP)" be added to this document's
> > title for consistency with the title in RFC-to-be 9961, or do you
> > prefer the current form?
> >
> > Original:
> >    Segment Routing Point-to-Multipoint Policy
> >
> > Perhaps:
> >    Segment Routing (SR) Point-to-Multipoint (P2MP) Policy
> > —>
> >
> > [RP] I prefer the current form because abbreviations in the title seem odd to me and both the abbreviations are introduced in the first sentence of the Abstract of the document. Maybe the same can be suggested to authors of RFC-to-be-9961.
> >
> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> > the title) for use on https://www.rfc-editor.org/search.
> > —>
> >
> > [RP] SR Multicast, SRv6 Multicast
> >
> >
> > 3) <!--[rfced] Please let us know how we may clarify this sentence. Does
> > "stitched to one or more Replication segments..." refer to the
> > "Root node" (option A) or to the "Replication segment" (option B)?
> > Does "at" the Leaf nodes and intermediate Replication nodes mean
> > "between"?
> >
> > Original:
> >    It consists of a Replication segment at the Root node, stitched to one
> >    or more Replication segments at Leaf nodes and intermediate
> >    Replication nodes.
> >
> > Perhaps A:
> >    It consists of a Replication segment at the Root node, which is stitched
> >    to one or more Replication segments between the Leaf nodes and intermediate
> >    Replication nodes.
> >
> > Perhaps B:
> >    It consists of a Replication segment at the Root node, and that
> >    Replication segment is stitched to one or more Replication segments
> >    between the Leaf nodes and intermediate Replication nodes.
> > —>
> >
> > [RP] Option B is more clear.
> >
> > The sentence in the document is trying to describe the following in a concise manner:
> >
> > Replication segment at the Root node is stitched to one or more replication segments at intermediate Replication nodes, and these intermediate Replication segments are stitched to either the Replication segments of subsequent intermediate Replication nodes or the Replication segments at the Leaf nodes. Note that there can be arbitrary number of intermediate Replication nodes (and associated Replication segments) in the path from the Root node to a specific Leaf node. In the simplest case, the Replication segment at the Root node is stitched  to the Replication segments at the Leaf nodes i.e. there are  no intermediate Replication nodes.
> >
> >
> > 4) <!--[rfced] We are having difficulty parsing the listed items in this
> > sentence. To clarify, may we update as follows?
> >
> > Original:
> >    For this use case, the Root MUST be zero (0.0.0.0 for IPv4 and ::
> >    for IPv6) and the Instance-ID MUST be zero and the 32-bit Tree-ID
> >    effectively make the Replication segment identifier <[0.0.0.0 or
> >    ::], Tree-ID, 0, Node-ID>.
> >
> > Perhaps:
> >    For this use case, the Root MUST be zero (0.0.0.0 for IPv4 and ::
> >    for IPv6), the Instance-ID MUST be zero, and the 32-bit Tree-ID
> >    effectively makes the Replication segment identifier <[0.0.0.0 or
> >    ::], Tree-ID, 0, Node-ID>.
> > —>
> >
> > [RP] I think the suggested change is clear, but I have another suggestion since “For this use case, …” is referring to the previous sentence and maybe these two sentences can be combined to further clarify the text.
> >
> > Section 2.3
> >
> > OLD:
> > In the simplest case, the Replication-ID of a Replication segment is a 32-bit number as per Section 2 of [RFC9524].  For this use case, the Root MUST be zero (0.0.0.0 for IPv4 and :: for IPv6) and the Instance-ID MUST be zero and the 32-bit Tree-ID effectively make the Replication segment identifier <[0.0.0.0 or ::], Tree-ID, 0, Node-ID>.
> >
> > NEW:
> > In the simplest case, the Replication-ID of a Replication segment is a 32-bit number as per Section 2 of [RFC9524] for which the Root MUST be zero (0.0.0.0 for IPv4 and :: for IPv6), the Instance-ID MUST be zero, and the 32-bit Tree-ID to effectively make the Replication segment identifier <[0.0.0.0 or ::], Tree-ID, 0, Node-ID>.
> >
> >
> > 5) <!--[rfced] FYI - To improve readability and avoid awkward hyphenation
> > of the expansion "PHP" when followed by "like", we updated
> > this text as shown below.
> >
> > Original:
> >    In SRv6 deployments, Replication segments of a PTI MUST be
> >    instantiated on Leaf nodes of the tree since PHP like behavior is not
> >    feasible because the Tree-SID is carried in IPv6 Destination Address
> >    field of outer IPv6 header.
> >
> > Current:
> >    In SRv6 deployments, Replication segments of a PTI MUST be
> >    instantiated on Leaf nodes of the tree since behavior like Penultimate
> >    Hop Popping (PHP) is not feasible because the Tree-SID is carried in IPv6
> >    Destination Address field of outer IPv6 header.
> > —>
> >
> > [RP] This change is fine.
> >
> >
> > 6) <!--[rfced] We are having difficulty understanding how "to the common
> > downstream node of these Replication segments" fits into this sentence.
> > Please review and let us know what updates may be made for clarity.
> >
> > Original:
> >    A shared Replication segment can protect
> >    Replication segments of different PTIs against an adjacency or path
> >    failure to the common downstream node of these Replication segments.
> > —>
> >
> > [RP] I think changing “.. the common downstream node ..” to “.. a common downstream node ..” should make this clear, but I have a more verbose suggestion below for clarity, but this does change the text.
> >
> > Section 4.2
> >
> > OLD:
> >    A shared Replication segment can protect
> >    Replication segments of different PTIs against an adjacency or path
> >    failure to the common downstream node of these Replication segments.
> >
> > NEW:
> > Assume a Replication node, say node X, with multiple PTIs. Assume the Replications segments of these PTIs replicate to a downstream node, say node Y, amongst other downstream nodes. This node Y is a common downstream node of these Replication segments at node X.  A Replication segment is established to protect the adjacency or path between node X and node Y; this Replication segment can be shared across all the Replication segments of the PTIs replicating from node X to node Y.
> >
> >
> >
> > 7) <!--[rfced] Is SRv6 replication intended for one downstream node or
> > multiple downstream nodes?
> >
> > Original:
> >    For details of SRv6 replication to non-adjacent downstream node and IPv6
> >    Hop Limit considerations, refer to Section 2.2 of [RFC9524].
> >
> > Perhaps A (singular):
> >    For details of SRv6 replication to a non-adjacent downstream node and IPv6
> >    Hop Limit considerations, refer to Section 2.2 of [RFC9524].
> >
> > Perhaps B (plural):
> >    For details of SRv6 replication to non-adjacent downstream nodes and IPv6
> >    Hop Limit considerations, refer to Section 2.2 of [RFC9524].
> > —>
> >
> > [RP] Option A (singular) is appropriate here since the whole paragraph is about a single replication between a pair of nodes.
> >
> >
> > 8) <!--[rfced] We note 80 instances of "SR P2MP Policy" but only two
> > instances of "SR P2MP". Are the two instances of "SR P2MP" okay as
> > is, or is an update needed for consistency?
> >
> > Current:
> >    *  Capability Exchange: A controller discovers a node's capability to
> >       participate in SR P2MP as well as advertise its capability to
> >       support SR P2MP.
> >
> > Perhaps:
> >    *  Capability Exchange: A controller discovers a node's capability to
> >       participate in an SR P2MP Policy as well as advertise its capability
> >       to support the SR P2MP Policy.
> > —>
> >
> > [RP] The suggested change is fine.
> >
> >
> > 9) <!--[rfced] We are having difficulty parsing "globally significant the
> > SR domain any it may get depleted if significant number of PTIs" in the
> > sentence below. Please review and let us know how this text may be updated
> > for clarity.
> >
> > Original:
> >    It is NOT RECOMMENDED to allocate a Replication-SID from the SRBG
> >    since this block is globally significant the SR domain any it may
> >    get depleted if significant number of PTIs are instantiated in the
> >    SR domain.
> >
> > Perhaps:
> >    It is NOT RECOMMENDED to allocate a Replication-SID from the SRGB
> >    since this block is globally significant to the SR domain and it
> >    may get depleted if a significant number of PTIs are instantiated
> >    in the SR domain.
> > —>
> >
> > [RP] I think “in” is better than “to” above, so the updated text should be:
> >
> > NEW:
> >    It is NOT RECOMMENDED to allocate a Replication-SID from the SRGB
> >    since this block is globally significant in the SR domain and it
> >    may get depleted if a significant number of PTIs are instantiated
> >    in the SR domain.
> >
> > BTW, the “Original” text snippet above has “SRBG” which is NOT in the original text. I hope this is a type since the original text has SRGB (which is the correct abbreviation).
> >
> >
> >
> > 10) <!--[rfced] To improve readability, may we update the second sentence as follows?
> >
> > Original:
> >    Some security
> >    considerations for Replication segments outlined in [RFC9524] are
> >    also applicable to this document.  Following is a brief reminder of
> >    the same.
> >
> > Perhaps:
> >    Some security
> >    considerations for Replication segments outlined in [RFC9524] are
> >    also applicable to this document.  Following is a brief reminder of
> >    those security considerations.
> > —>
> >
> > [RP] Yes, this is fine. 
> >
> >
> > 11) <!--[rfced] FYI - We have updated "to implement BCP 38 [RFC2827]" as
> > shown below for clarity. Please review and let us know of any
> > objections.
> >
> > Original:
> >    Failure to protect the SRv6 domain with inbound Infrastructure Access
> >    Control Lists (IACLs) on external interfaces, combined with failure
> >    to implement BCP 38 [RFC2827] or apply IACLs on nodes provisioning
> >    SIDs, permits attackers from outside the SR domain to send packets to
> >    the receivers of Multi-point services that use the SR P2MP Policies
> >    provisioned within the domain.
> >
> > Current:
> >    Failure to protect the SRv6 domain with inbound Infrastructure Access
> >    Control Lists (IACLs) on external interfaces, combined with failure
> >    to implement the method described in RFC2827 [BCP38] or apply IACLs on
> >    nodes provisioning SIDs, permits attackers from outside the SR domain to
> >    send packets to the receivers of multipoint services that use the SR P2MP
> >    Policies provisioned within the domain.
> > —>
> >
> > [RP] Yes, this change is fine.
> >
> >
> > 12) <!--[rfced] To reflect the text in RFC 9524, may we update this sentence
> > as follows?
> >
> > Original:
> >    For SRv6, [RFC9524] describes an exception for Parameter Problem
> >    Message, code 2 ICMPv6 Error messages.
> >
> > Perhaps:
> >    For SRv6, [RFC9524] describes an exception for the ICMPv6 Parameter Problem
> >    message with Code 2.
> > —>
> >
> > [RP] This change is fine.
> >
> >
> > 13) <!--[rfced] We are having difficulty understanding "one of IGP ECMP
> > nexthops towards R7". How should this text be clarified?
> >
> > Original:
> >    For replication to R7, R2 performs a PUSH operation of N-SID7, to
> >    send <N-SID7,T-SID1> label stack to R4, one of IGP ECMP nexthops
> >    towards R7.
> >
> > Perhaps:
> >    For replication to R7, R2 performs a PUSH operation of N-SID7 to
> >    send the <N-SID7,T-SID1> label stack to R4, which is an IGP ECMP
> >    next hop towards R7.
> > —>
> >
> > [RP] I have a slightly different suggestion
> >
> > NEW:
> >    For replication to R7, R2 performs a PUSH operation of N-SID7 to
> >    send the <N-SID7,T-SID1> label stack to R4, which is one of the IGP ECMP
> >    next hops (R5 is other) towards R7.
> >
> >
> >
> > 14) <!-- [rfced] Throughout the text, the following terminology appears to
> > be used inconsistently. Please review these occurrences and let
> > us know if/how they may be made consistent.
> >
> > a) SR domain (26) vs. SR MPLS domain (1)
> >
> > Note: is "SR MPLS domain" different than "SR domain"?
> > If not, should "MPLS" be removed for consistency?
> >
> > Current:
> >    Failure to protect the SR MPLS domain by correctly provisioning MPLS
> >    support per interface permits attackers from outside the domain to
> >    send packets to receivers of the multipoint services that use the SR
> >    P2MP Policies provisioned within the domain.
> >
> > b) SR P2MP Policy (72) vs. SR Policy (4)
> > —>
> >
> > [RP]
> >
> >     • SR-MPLS is specialized deployment of SR with MPLS data plane. SR domain is a more general (covering both SR-MPLS and SRv6). To fix this, please change the singular occurrence of “SR MPLS domain” to “SR-MPLS domain"
> >
> >       NEW:
> >    Failure to protect the SR-MPLS domain by correctly provisioning MPLS
> >    support per interface permits attackers from outside the domain to
> >    send packets to receivers of the multipoint services that use the SR
> >    P2MP Policies provisioned within the domain.
> >
> >     b) SR Policy [RFC 9256] is distinct from SR P2MP Policy described in this document. I have reviewed occurrences of “SR Policy” (exact case) and all are correct and must be retained EXCEPT one occurrence below.
> >
> >       Section 3
> >
> >       OLD:
> >       The BSID is used to steer traffic into an SR Policy, as described below, when the Root
> >                node is not the ingress node of the SR domain where the traffic arrives.
> >
> >       NEW:
> >       The BSID is used to steer traffic into an SR P2MP Policy, as described below, when the Root
> >                node is not the ingress node of the SR domain where the traffic arrives.
> >     
> >
> > 15) <!-- [rfced] Abbreviations
> > a) FYI - We have added expansions for the following abbreviations
> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> > expansion in the document carefully to ensure correctness.
> >  locator (LOC)
> >  Path Computation Element Communication Protocol (PCEP)
> >  Penultimate Hop Popping (PHP)
> >  Regional Internet Registry (RIR)
> >  Replication segment identifier (Replication-SID)
> >  Topology Independent Loop-Free Alternate (TI-LFA)
> > b) As recommended in the Web Portion of the Style Guide
> > <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an
> > abbreviation is introduced, the abbreviated form should be used
> > thereafter. Please consider if you would like to apply this style for
> > the following terms:
> >  Binding SID (BSID)
> >  candidate path (CP)
> >  P2MP tree instance (PTI)
> >  Penultimate Hop Popping (PHP)
> >  Replication segment identifier (Replication-SID)
> >  Segment Routing (SR)
> > —>
> >
> > [RP]
> >     • The expansion of the abbreviations are correct. However, when reviewing expansion of PCEP in below text, I see the reference abbreviation [SR-P2MP-PING] in text below:
> >
> >       Section 5.5
> >
> >       NEW:
> >       After computing P2MP trees, the controller instantiates the
> >           Replication segments that compose the PTIs in the SR domain using
> >               signaling protocols such as the Path Computation Element
> >               Communication Protocol (PCEP) [SR-P2MP-PING], BGP [P2MP-BGP], or
> >               other mechanisms such as NETCONF/YANG [SR-P2MP-YANG], etc.
> >
> >              The abbreviation should be [SR-P2MP-PCEP].
> >
> >      I think this is most likely due to below comment in the modified XML source of this document.
> >
> >        <!-- [I-D.ietf-pce-sr-p2mp-policy]
> > draft-ietf-pce-sr-p2mp-policy-14
> > IESG State: I-D Exists as of 04/16/26
> > * Note this draft is also part of C556 *
> > —>
> >
> >             The above comment is incorrect since draft-ietf-pce-sr-p2mp-policy is a PCE WG document which has NOT been reviewed by IESG yet and it NOT part of cluster C556. draft-ietf-pim-p2mp-policy-ping is the IESG reviewed document (I guess soon to be RFC 9661) in cluster C556, but this document does NOT have a reference to it. Please fix this.
> >
> >       b) The abbreviations in the list can be used in the documented as per the style guide.
> >
> > 16) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > and let us know if any changes are needed.  Updates of this nature typically
> > result in more precise language, which is helpful for readers.
> > Note that our script did not flag any words in particular, but this should
> > still be reviewed as a best practice.
> > —>
> >
> > [RP] I reviewed the inclusive language style guidelines and I don't see any changes required.
> >
> > Thank you.
> > Alanna Paloma and Karen Moore
> > RFC Production Center
> >
> >
> > On Apr 17, 2026, at 3:12 PM, [e-mail] wrote:
> > *****IMPORTANT*****
> > Updated 2026/04/17
> > 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/rfc9960.xml
> >   https://www.rfc-editor.org/authors/rfc9960.html
> >   https://www.rfc-editor.org/authors/rfc9960.pdf
> >   https://www.rfc-editor.org/authors/rfc9960.txt
> > Diff file of the text:
> >   https://www.rfc-editor.org/authors/rfc9960-diff.html
> >   https://www.rfc-editor.org/authors/rfc9960-rfcdiff.html (side by side)
> > Diff of the XML:
> >   https://www.rfc-editor.org/authors/rfc9960-xmldiff1.html
> > Tracking progress
> > -----------------
> > The details of the AUTH48 status of your document are here:
> >   https://www.rfc-editor.org/auth48/rfc9960
> > Please let us know if you have any questions.
> > Thank you for your cooperation,
> > RFC Editor
> > --------------------------------------
> > RFC9960 (draft-ietf-pim-sr-p2mp-policy-22)
> > Title            : Segment Routing Point-to-Multipoint Policy
> > Author(s)        : R. Parekh, Ed., D. Voyer, Ed., C. Filsfils, H. Bidgoli, Z. Zhang
> > WG Chair(s)      : Stig Venaas, Mike McBride
> > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
> > [EXTERNAL]