Megan, Thank you so much for this!
I reviewed the changes, and approve publication. Thanks, Carlos Pignataro (He/Him) Founder and Principal Blue Fern Consulting<https://bluefern.consulting/> Email: [email protected]<mailto:[email protected]> Mobile: +1 919 345 3028<tel:+19193453028> From: Megan Ferguson <[email protected]> Date: Friday, October 24, 2025 at 5:10 PM To: [email protected] <[email protected]> Cc: RFC Editor <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Carlos Pignataro <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, James Guichard <[email protected]>, [email protected] <[email protected]> Subject: Re: [AD] AUTH48: RFC-to-be 9884 <draft-ietf-mpls-spring-lsp-ping-path-sid-13> for your review Thanks, Xiao Min! We have folded in these changes as requested. As a few updates requested in AUTH48 have now affected the following terms, we would like to request a re-review to ensure/confirm they appear as desired throughout (e.g., perhaps they should be lowercase everywhere except in the sub-TLV or TLV names?). > a) We see mixed use of the following forms. Please let us know if/how these > should be made consistent. > > SR path vs. SR Path > segment-list vs. Segment List vs. segment list > candidate path vs. Candidate Path vs. Candidate path Please review the files carefully as we do not make changes after publication. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9884.txt https://www.rfc-editor.org/authors/rfc9884.pdf https://www.rfc-editor.org/authors/rfc9884.html https://www.rfc-editor.org/authors/rfc9884.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9884-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9884-rfcdiff.html (comprehensive side by side) https://www.rfc-editor.org/authors/rfc9884-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9884-auth48rfcdiff.html (AUTH48 side by side) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9884 Thank you. Megan Ferguson RFC Production Center > On Oct 23, 2025, at 8:23 PM, [email protected] wrote: > > Hi Megan, > > Thank you for the update. Your new text looks good to me. > Following the text change, I propose two more editorial changes as below. > OLD: > When a PSID is used to identify a Segment List, the Target FEC > > NEW: > When a PSID is used to identify a single segment list, the Target FEC > > OLD: > When a PSID is used to identify some segment lists in a Candidate path or an > SR policy, the Target FEC > > NEW: > When a PSID is used to identify some segment lists in a candidate path or an > SR policy, the Target FEC > > Cheers, > Xiao Min > Original > From: MeganFerguson <[email protected]> > To: 肖敏10093570; > Cc: RFC Editor > <[email protected]>;彭少富10053815;[email protected] > <[email protected]>;[email protected] > <[email protected]>;[email protected] > <[email protected]>;[email protected] > <[email protected]>;[email protected] > <[email protected]>;[email protected] <[email protected]>;James Guichard > <[email protected]>;[email protected] > <[email protected]>; > Date: 2025年10月24日 00:59 > Subject: Re: [AD] AUTH48: RFC-to-be 9884 > <draft-ietf-mpls-spring-lsp-ping-path-sid-13> for your review > Hi Xiao Min, > > Your list was really helpful in explaining your intent — thank you! Perhaps > using something similar in the text would be most clear to readers? What do > you think about using the following? > > Original: > As specified in Section 2 of [RFC9545], a PSID is used to identify a > segment list, some or all segment lists in a Candidate path or an SR > policy, so six different Target FEC Stack sub-TLVs need to be defined > for PSID. > > Current: > > As specified in Section 2 of [RFC9545], a PSID is used to identify > the following: > > * a single segment list, some segment lists, or all segment lists in > a candidate path of an SR policy, > > * some segment lists across multiple candidate paths of an SR > policy, or > > * all segment lists in all candidate paths of an SR policy. > > Therefore, six different Target FEC Stack sub-TLVs need to be defined > for PSID. > > If you’d prefer something else, please let us know. We’ve included the above > in the files posted. Please review the files carefully as we do not make > changes after publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9884.txt > https://www.rfc-editor.org/authors/rfc9884.pdf > https://www.rfc-editor.org/authors/rfc9884.html > https://www.rfc-editor.org/authors/rfc9884.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9884-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9884-rfcdiff.html (comprehensive side > by side) > https://www.rfc-editor.org/authors/rfc9884-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9884-auth48rfcdiff.html (AUTH48 side > by side) > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9884 > > Thank you. > > Megan Ferguson > RFC Production Center > > > On Oct 22, 2025, at 8:01 PM, [email protected] wrote: > > > > Hi Megan, > > > > Thank you for the prompt response. > > Please see inline. > > Original > > From: MeganFerguson <[email protected]> > > To: 肖敏10093570; > > Cc: RFC Editor > > <[email protected]>;彭少富10053815;[email protected] > > <[email protected]>;[email protected] > > <[email protected]>;[email protected] > > <[email protected]>;[email protected] > > <[email protected]>;[email protected] > > <[email protected]>;[email protected] > > <[email protected]>;[email protected] > > <[email protected]>;[email protected] > > <[email protected]>; > > Date: 2025年10月23日 09:24 > > Subject: Re: [AD] AUTH48: RFC-to-be 9884 > > <draft-ietf-mpls-spring-lsp-ping-path-sid-13> for your review > > Xiao Min, > > > > Thanks for pointing this out. > > > > We have incorporated this change into the existing files. Please note that > > we added a further comma to the original to make a list of three (i.e., a > > PSID identifies 1) a segment list, 2) some or all segment lists in a > > Candidate path, or 3) an SR policy). Please confirm that this is your > > intended meaning. Please also confirm that Candidate path (and not > > Candidate Path) is correct here. > > [XM]>>> If the original text is deemed not clear enough, then I propose to > > change the text as below. > > OLD: > > a PSID is used to identify a segment list, some or all segment lists in a > > Candidate path or an SR policy, > > NEW: > > a PSID is used to identify a segment list, some segment lists, or all > > segment lists, in a candidate path or an SR policy, > > The intended meaning is to cover a list of five as follows: > > * a segment list in a candidate path of an SR policy > > * some segment lists in a candidate path of an SR policy > > * all segment lists in a candidate path of an SR policy > > * some segment lists across multiple candidate paths of an SR policy > > * all segment lists in all candidate paths of an SR policy > > Also note that in the NEW text "candidate path" is used to substitute > > "Candidate path". > > > > Cheers, > > Xiao Min > > > > Please review the files carefully as we do not make changes after > > publication. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9884.txt > > https://www.rfc-editor.org/authors/rfc9884.pdf > > https://www.rfc-editor.org/authors/rfc9884.html > > https://www.rfc-editor.org/authors/rfc9884.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9884-diff.html (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9884-rfcdiff.html (comprehensive > > side by side) > > https://www.rfc-editor.org/authors/rfc9884-auth48diff.html (AUTH48 > > changes only) > > https://www.rfc-editor.org/authors/rfc9884-auth48rfcdiff.html (AUTH48 > > side by side) > > > > The AUTH48 status page for this document is available here: > > > > https://www.rfc-editor.org/auth48/rfc9884 > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > > On Oct 21, 2025, at 9:43 PM, [email protected] wrote: > > > > > > Hi Megan, > > > > > > Thank you for the update. > > > Just one point I might be not clear enough in my response. Copy it here. > > > > 5) <!--[rfced] Please review our following update and let us know any > > > > objections. > > > > > > > > Original: > > > > As specified in Section 2 of [RFC9545], a PSID is used to identify a > > > > segment list, some or all segment lists in a Candidate path or an SR > > > > policy, so six different Target FEC Stack sub-TLVs need to be defined > > > > for PSID. > > > > > > > > Current: > > > > As specified in Section 2 of [RFC9545], a PSID is used to identify a > > > > segment list and/or some or all segment lists in a Candidate path or an > > > > SR > > > > policy, so six different Target FEC Stack sub-TLVs need to be defined > > > > for PSID. > > > > --> > > > > [XM]>>> Here "a segment list" is also in a Candidate path or an SR > > > > policy, so "and/or" seems inappropriate. > > > My thought was that I prefer to remain the original text as is. > > > > > > Cheers, > > > Xiao Min > > > Original > > > From: MeganFerguson <[email protected]> > > > To: 肖敏10093570; > > > Cc: RFC Editor > > > <[email protected]>;彭少富10053815;[email protected] > > > <[email protected]>;[email protected] > > > <[email protected]>;[email protected] > > > <[email protected]>;[email protected] > > > <[email protected]>;[email protected] > > > <[email protected]>;[email protected] > > > <[email protected]>;[email protected] > > > <[email protected]>;[email protected] > > > <[email protected]>; > > > Date: 2025年10月22日 09:44 > > > Subject: Re: [AD] AUTH48: RFC-to-be 9884 > > > <draft-ietf-mpls-spring-lsp-ping-path-sid-13> for your review > > > Hi Xiao Min, > > > > > > Thank you for your guidance and careful review. (Thanks to James, > > > Adrian, and Carlos for your replies as well!) > > > > > > We have updated accordingly. > > > > > > Please review the files carefully as we do not make changes after > > > publication. > > > > > > The files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9884.txt > > > https://www.rfc-editor.org/authors/rfc9884.pdf > > > https://www.rfc-editor.org/authors/rfc9884.html > > > https://www.rfc-editor.org/authors/rfc9884.xml > > > > > > The relevant diff files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9884-diff.html (comprehensive > > > diff) > > > https://www.rfc-editor.org/authors/rfc9884-rfcdiff.html (comprehensive > > > side by side) > > > https://www.rfc-editor.org/authors/rfc9884-auth48diff.html (AUTH48 > > > changes only) > > > https://www.rfc-editor.org/authors/rfc9884-auth48rfcdiff.html (AUTH48 > > > side by side) > > > > > > Please contact us with any further updates/questions/comments you may > > > have. > > > > > > 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/rfc9884 > > > > > > Thank you. > > > > > > RFC Editor/mf > > > > > > > On Oct 21, 2025, at 5:35 AM, [email protected] wrote: > > > > > > > > Hi Megan, > > > > > > > > Many thanks for your efforts. > > > > Please see inline. > > > > Original > > > > From: [email protected] <[email protected]> > > > > To: 肖敏10093570;彭少富10053815;[email protected] > > > > <[email protected]>;[email protected] > > > > <[email protected]>;[email protected] > > > > <[email protected]>; > > > > Cc: [email protected] > > > > <[email protected]>;[email protected] > > > > <[email protected]>;[email protected] > > > > <[email protected]>;[email protected] > > > > <[email protected]>;[email protected] > > > > <[email protected]>;[email protected] > > > > <[email protected]>; > > > > Date: 2025年10月21日 11:20 > > > > Subject: Re: [AD] AUTH48: RFC-to-be 9884 > > > > <draft-ietf-mpls-spring-lsp-ping-path-sid-13> for your review > > > > Authors and *AD, > > > > > > > > While reviewing this document during AUTH48, please resolve (as > > > > necessary) the following questions, which are also in the source file. > > > > > > > > 1) <!--[rfced] Please note that we have updated the title as follows (to > > > > include articles). > > > > > > > > Original Document Title: > > > > Label Switched Path Ping for Segment Routing Path Segment Identifier > > > > with MPLS Data Plane > > > > > > > > Current: > > > > A Label Switched Path Ping for the Segment Routing Path Segment > > > > Identifier > > > > with an MPLS Data Plane > > > > --> > > > > [XM]>>> I prefer to remain the original document title as is, because > > > > we already have RFCs as below. > > > > RFC 8287: Label Switched Path (LSP) Ping/Traceroute for Segment Routing > > > > (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS > > > > Data Planes > > > > RFC 9703: Label Switched Path (LSP) Ping/Traceroute for Segment Routing > > > > (SR) Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS > > > > Data Plane > > > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > > the title) for use on https://www.rfc-editor.org/search. --> > > > > [XM]>>> Target FEC Stack, PSID. > > > > > > > > 3) <!--[rfced] Please review the use of the two citations in the > > > > sentence > > > > below. RFC 8029 is "Detecting Multiprotocol Label Switched > > > > (MPLS) Data-Plane Failures" while RFC 8287 is "Label Switched > > > > Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix > > > > and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data > > > > Planes". > > > > > > > > Original: > > > > Procedure for LSP Ping [RFC8029] as defined in Section 7.4 of > > > > [RFC8287] is also applicable to PSID, and this document appends > > > > existing step 4a with a new step 4b specific to PSID. > > > > --> > > > > [XM]>>> That's fine. RFC 8029 is the base spec for LSP Ping, which is > > > > extended by both RFC 8287 and this document for SR scenarios. > > > > > > > > 4) <!--[rfced] *ADs - Please confirm that no "Updates" relationship to > > > > RFC 8287 should be indicated in the header/Abstract/metadata of the > > > > document with the following text (and all of Section 4.1) in > > > > mind: > > > > > > > > Original: > > > > Procedure for LSP Ping [RFC8029] as defined in Section 7.4 of > > > > [RFC8287] is also applicable to PSID, and this document appends > > > > existing step 4a with a new step 4b specific to PSID. > > > > --> > > > > > > > > > > > > 5) <!--[rfced] Please review our following update and let us know any > > > > objections. > > > > > > > > Original: > > > > As specified in Section 2 of [RFC9545], a PSID is used to identify a > > > > segment list, some or all segment lists in a Candidate path or an SR > > > > policy, so six different Target FEC Stack sub-TLVs need to be defined > > > > for PSID. > > > > > > > > Current: > > > > As specified in Section 2 of [RFC9545], a PSID is used to identify a > > > > segment list and/or some or all segment lists in a Candidate path or an > > > > SR > > > > policy, so six different Target FEC Stack sub-TLVs need to be defined > > > > for PSID. > > > > --> > > > > [XM]>>> Here "a segment list" is also in a Candidate path or an SR > > > > policy, so "and/or" seems inappropriate. > > > > > > > > 6) <!--[rfced] Please review the following uses of "PSID FEC Stack > > > > sub-TLV" and "malformed FEC Stack sub-TLV". Other uses of "FEC > > > > Stack sub-TLV" begin with "Target". > > > > > > > > Original: > > > > ....validity checks on the content of the PSID FEC Stack sub-TLV. > > > > > > > > and > > > > > > > > If a malformed FEC Stack sub-TLV is received... > > > > > > > > Perhaps: > > > > ....validity checks on the content of the PSID Target FEC Stack sub-TLV. > > > > > > > > and > > > > > > > > If a malformed Target FEC Stack sub-TLV is received... > > > > [XM]>>> OK. > > > > --> > > > > > > > > > > > > 7) <!--[rfced] Please confirm that the following are the general > > > > concepts > > > > and not field names (note that these are examples, more instances > > > > occur): > > > > > > > > Original: > > > > * Validate that the signaled or provisioned headend, color, > > > > and endpoint, for the PSID, matches with the corresponding > > > > fields in the received SR Policy Associated PSID - IPv4 sub- > > > > TLV. > > > > > > > > Perhaps: > > > > * Validate that the signaled or provisioned Headend, Color, > > > > and Endpoint fields for the PSID match with the > > > > corresponding > > > > fields in the received SR Policy Associated PSID - IPv4 > > > > sub-TLV. > > > > > > > > > > > > Original: > > > > * Validate that the signaled or provisioned headend, color, > > > > endpoint, originator, and discriminator, for the PSID, > > > > matches with the corresponding fields in the received SR > > > > Candidate Path Associated PSID - IPv4 sub-TLV. > > > > > > > > Perhaps: > > > > * Validate that the signaled or provisioned Headend, Color, > > > > Endpoint, Originator, and Discriminator fields for the PSID > > > > match with the corresponding fields in the received SR > > > > Candidate Path Associated PSID - IPv4 sub-TLV. > > > > [XM]>>> They are the general concepts and not field names, so no > > > > changes needed. > > > > --> > > > > > > > > > > > > 8) <!--[rfced] Please note that we have updated the reference to > > > > draft-ietf-idr-bgp-ls-sr-policy-17 to point to the RFC-to-be: as > > > > this I-D is currently in AUTH48 (with nearly all approvals > > > > complete), we assume it will move to publication prior to the > > > > publication of this document. > > > > > > > > Please let us know how you would like to proceed if RFC-to-be 9857 is > > > > not published before this document (i.e., return to the I-D form of > > > > the reference or wait for the publication of 9857). --> > > > > [XM]>>> Return to the I-D form of the reference. > > > > > > > > 9) <!--[rfced] We had the following questions/comments related to > > > > abbreviation use throughout the document: > > > > > > > > a) Please note that abbreviations have been expanded upon first use. > > > > Please review and confirm all expansions inserted appear as desired. > > > > [XM]>>> OK. > > > > b) Please note that we will update to use the following abbreviations, > > > > instead of their expanded forms, after the first use in accordance with > > > > https://www.rfc-editor.org/styleguide/part2/#exp_abbrev: > > > > SR > > > > PSID > > > > [XM]>>> OK. > > > > --> > > > > > > > > > > > > 10) <!--[rfced] We had the following questions related to terminology > > > > used throughout the document: > > > > > > > > a) We see mixed use of the following forms. Please let us know if/how > > > > these should be made consistent. > > > > > > > > SR path vs. SR Path > > > > segment-list vs. Segment List vs. segment list > > > > candidate path vs. Candidate Path vs. Candidate path > > > > [XM]>>> In my opinion it's not necessary to make them consistent, > > > > because the contexts are different. > > > > > > > > b) Is Return Subcode <RSC> the same as "return code"? Please review > > > > and advise if these should be made uniform. > > > > [XM]>>> No, they're different. Both of them are defined in RFC 8029. > > > > --> > > > > > > > > > > > > 11) <!-- [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. > > > > --> > > > > [XM]>>> No issues found. > > > > > > > > [XM]>>> I propose five editorial changes as below. > > > > > > > > Section #2.2 > > > > > > > > OLD: > > > > (Section 5.2 of [PCE-MULTIPATH]) > > > > > > > > NEW: > > > > (Section 4.2 of [PCE-MULTIPATH]) > > > > > > > > Section #3.4 > > > > > > > > OLD: > > > > as an SR Policy Associated PSID - IPv6 Sub-TLV > > > > > > > > NEW: > > > > as an SR Policy Associated PSID - IPv6 sub-TLV > > > > > > > > Section #4 > > > > > > > > OLD: > > > > receive an echo request and sends an echo reply > > > > > > > > NEW: > > > > receive an echo request and send an echo reply > > > > > > > > Section #4.1 > > > > > > > > OLD: > > > > (the notation <RSC> refers to the Return Subcode) > > > > > > > > COMMENT: > > > > the same text appears twice, please delete the second one > > > > > > > > Section #4.1 > > > > > > > > OLD: > > > > and segment-list-id, for the PSID > > > > > > > > NEW: > > > > and segment-list-id for the PSID > > > > > > > > Cheers, > > > > Xiao Min > > > > > > > > > > > > Thank you. > > > > > > > > Megan Ferguson > > > > RFC Production Center > > > > > > > > *****IMPORTANT***** > > > > > > > > Updated 2025/10/20 > > > > > > > > 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 > > > > > > > > * [email protected] (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). > > > > > > > > * [email protected], 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, > > > > [email protected] 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/rfc9884.xml > > > > https://www.rfc-editor.org/authors/rfc9884.html > > > > https://www.rfc-editor.org/authors/rfc9884.pdf > > > > https://www.rfc-editor.org/authors/rfc9884.txt > > > > > > > > Diff file of the text: > > > > https://www.rfc-editor.org/authors/rfc9884-diff.html > > > > https://www.rfc-editor.org/authors/rfc9884-rfcdiff.html (side by > > > > side) > > > > > > > > Diff of the XML: > > > > https://www.rfc-editor.org/authors/rfc9884-xmldiff1.html > > > > > > > > > > > > Tracking progress > > > > ----------------- > > > > > > > > The details of the AUTH48 status of your document are here: > > > > https://www.rfc-editor.org/auth48/rfc9884 > > > > > > > > Please let us know if you have any questions. > > > > > > > > Thank you for your cooperation, > > > > > > > > RFC Editor > > > > > > > > -------------------------------------- > > > > RFC9884 (draft-ietf-mpls-spring-lsp-ping-path-sid-13) > > > > > > > > Title : Label Switched Path Ping for Segment Routing Path > > > > Segment Identifier with MPLS Data Plane > > > > Author(s) : X. Min, S. Peng, L. Gong, R. Gandhi, C. Pignataro > > > > WG Chair(s) : Tarek Saad, Tony Li, Adrian Farrel > > > > > > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > > > > > > > > > > > > > > > > > > > > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
