Hi Greg, We have marked your approval on the AUTH48 status page for this document: https://www.rfc-editor.org/auth48/rfc9791.
Thank you! RFC Editor/rv > On Jun 2, 2025, at 3:23 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Hi Rebecca, > thank you for your help in improving this document. I have reviewed all the > updates and approve the document in its current form. > > Regards, > Greg > > On Tue, Jun 3, 2025 at 2:54 AM Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > Hello authors, > > Thank you for the input on the question about the document title. We have > updated the title accordingly. All questions have now been addressed. > > Please contact us with any further updates or with your approval of the > document in its current form. We will await approvals from each author prior > to moving forward in the publication process. > > > — FILES (please refresh) — > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9791.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9791.txt > https://www.rfc-editor.org/authors/rfc9791.pdf > https://www.rfc-editor.org/authors/rfc9791.html > > Diff file showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9791-auth48diff.html > https://www.rfc-editor.org/authors/rfc9791-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9791-diff.html > https://www.rfc-editor.org/authors/rfc9791-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9791-alt-diff.html (diff showing > changes where text is moved or deleted) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9791 > > Thank you, > RFC Editor/rv > > > > > On Jun 2, 2025, at 7:15 AM, Tarek Saad <tsaad....@gmail.com> wrote: > > > > Hi Alanna, > > Thanks, and sorry for the delay. > > >> Perhaps: > > >> Use Cases for MPLS Network Action Indicators and Ancillary Data > > I have no objections to changing the title as suggested. > > Regards, > > Tarek > > From: Alanna Paloma <apal...@staff.rfc-editor.org> > > Date: Tuesday, May 27, 2025 at 5:36 PM > > To: tsaad....@gmail.com <tsaad....@gmail.com>, > > kiran.i...@gmail.com<kiran.i...@gmail.com> > > Cc: Haoyu Song <haoyu.s...@futurewei.com>, Greg Mirsky > > <gregimir...@gmail.com>, Rebecca VanRheenen > > <rvanrhee...@staff.rfc-editor.org>, James Guichard > > <james.n.guich...@futurewei.com>, RFC Editor <rfc-edi...@rfc-editor.org>, > > mpls-...@ietf.org <mpls-...@ietf.org>, > > mpls-cha...@ietf.org<mpls-cha...@ietf.org>, tony...@tony.li > > <tony...@tony.li>, auth48archive@rfc-editor.org > > <auth48archive@rfc-editor.org> > > Subject: Re: [AD] AUTH48: RFC-to-be 9791 <draft-ietf-mpls-mna-usecases-15> > > for your review > > Hi Tarek and Kiran, > > > > As Greg and Haoyu have indicated that they both have no preference, please > > let us know if/how the title of this document should be updated. > > > > > 2) <!-- [rfced] The document title includes two instances of "MPLS". Are > > > both needed? > > > > > > Original: > > > Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data > > > > > > Perhaps: > > > Use Cases for MPLS Network Action Indicators and Ancillary Data > > > --> > > > > Thank you, > > RFC Editor/ap > > > > > > > On May 19, 2025, at 2:27 PM, Haoyu Song <haoyu.s...@futurewei.com> wrote: > > > > > > Hi Alanna, > > > > > > For the remaining question, I'm okay with either way. Thanks! > > > > > > Best regards, > > > Haoyu > > > > > > -----Original Message----- > > > From: Alanna Paloma <apal...@staff.rfc-editor.org> > > > Sent: Monday, May 19, 2025 1:30 PM > > > To: Greg Mirsky <gregimir...@gmail.com>; tsaad....@gmail.com; > > > kiran.i...@gmail.com; Haoyu Song <haoyu.s...@futurewei.com> > > > Cc: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>; James Guichard > > > <james.n.guich...@futurewei.com>; RFC Editor <rfc-edi...@rfc-editor.org>; > > > mpls-...@ietf.org; mpls-cha...@ietf.org; tony...@tony.li; > > > auth48archive@rfc-editor.org > > > Subject: Re: [AD] AUTH48: RFC-to-be 9791 > > > <draft-ietf-mpls-mna-usecases-15> for your review > > > > > > Hi Greg and other authors, > > > > > > Thank you for responding to our questions. We have updated the document > > > accordingly (see files listed below). > > > > > > Regarding the question below, we have not updated the title and will > > > await input from Tarek, Kiran, and/or Haoyu. > > > > > >> 2) <!-- [rfced] The document title includes two instances of "MPLS". Are > > >> both needed? > > >> > > >> Original: > > >> Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data > > >> > > >> Perhaps: > > >> Use Cases for MPLS Network Action Indicators and Ancillary Data > > >> GIM>> I don't strongly prefer either version, and I can live with any > > >> decision other authors will support. > > >> --> > > > > > > > > > > > > — FILES (please refresh) — > > > > > > Updated XML file: > > > https://www.rfc-editor.org/authors/rfc9791.xml > > > > > > Updated output files: > > > https://www.rfc-editor.org/authors/rfc9791.txt > > > https://www.rfc-editor.org/authors/rfc9791.pdf > > > https://www.rfc-editor.org/authors/rfc9791.html > > > > > > Diff file showing all changes made during AUTH48: > > > https://www.rfc-editor.org/authors/rfc9791-auth48diff.html > > > https://www.rfc-editor.org/authors/rfc9791-auth48rfcdiff.html (side by > > > side) > > > > > > Diff files showing all changes: > > > https://www.rfc-editor.org/authors/rfc9791-diff.html > > > https://www.rfc-editor.org/authors/rfc9791-rfcdiff.html (side by side) > > > https://www.rfc-editor.org/authors/rfc9791-alt-diff.html (diff showing > > > changes where text is moved or deleted) > > > > > > For the AUTH48 status of this document, please see: > > > https://www.rfc-editor.org/auth48/rfc9791 > > > > > > Thank you, > > > RFC Editor/ap > > > > > >> On May 17, 2025, at 2:32 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > >> > > >> Hi Rebecca, > > >> thank you for your help in improving this document. Please find my notes > > >> below tagged GIM>>. > > >> > > >> Regards, > > >> Greg > > >> > > >> On Wed, May 14, 2025 at 10:09 AM Rebecca VanRheenen > > >> <rvanrhee...@staff.rfc-editor.org> wrote: > > >> Hi Greg, > > >> > > >> The AUTH48 announcement and questions were sent yesterday. I’ve pasted > > >> the questions below. > > >> > > >> You can also see the messages in the AUTH48 mail archive: > > >> https://mailarchive.ietf.org/arch/browse/auth48archive/?q=9791. > > >> > > >> Thank you for checking in! > > >> > > >> Best regards, > > >> RFC Editor/rv > > >> > > >> > > >> 1) <!-- [rfced] *AD: We see that consensus is set to "Unknown" > > >> for this document in the datatracker. See > > >> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>. > > >> > > >> This document was sent to Last Call, so we have used the consensus > > >> Status of This Memo. Please confirm that this is correct. > > >> --> > > >> > > >> > > >> 2) <!-- [rfced] The document title includes two instances of "MPLS". Are > > >> both needed? > > >> > > >> Original: > > >> Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data > > >> > > >> Perhaps: > > >> Use Cases for MPLS Network Action Indicators and Ancillary Data > > >> GIM>> I don't strongly prefer either version, and I can live with any > > >> decision other authors will support. > > >> --> > > >> > > >> > > >> 3) <!-- [rfced] Please insert any keywords (beyond those that appear > > >> in the title) for use on > > >> https://www/. > > >> rfc-editor.org%2Fsearch&data=05%7C02%7Chaoyu.song%40futurewei.com%7Cb9 > > >> 7a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1% > > >> 7C1%7C638832834079747630%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > > >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > > >> D%7C60000%7C%7C%7C&sdata=XlyTbo3qeWgsn23qnAzeDhEnhflkwUZ2qoRJEiTe2TE%3 > > >> D&reserved=0. --> > > >> GIM>> Perhaps > > >> Special Purpose Label > > >> MPLS data plane > > >> > > >> > > >> 4) <!-- [rfced] We see that "MPLS Ancillary Data" appears in Section > > >> 1.1 ("Terminology"). We see instances of "ancillary data" (no "MPLS") > > >> in the document, but we only see "MPLS Ancillary Data" used in the > > >> document title. Are any updates needed? > > >> GIM>> Perhaps we can note the equivalence between "MPLS Ancillary Data" > > >> and "ancillary data" as is done for terms related to a network slice. > > >> Might the following update be acceptable (using the proposed text below): > > >> OLD TEXT: > > >> MPLS Ancillary Data: > > >> NEW TEXT: > > >> MPLS Ancillary Data (also referred to in this document as "ancillary > > >> data"): > > >> > > >> Also, note that we slightly updated the definition list as follows. > > >> > > >> Original: > > >> RFC 9543 Network Slice > > >> is interpreted as defined in [RFC9543]. Furthermore, this > > >> document uses "network slice" interchangeably as a shorter version > > >> of the RFC 9543 Network Slice term. > > >> > > >> The MPLS Ancillary Data is classified as: > > >> * residing within the MPLS label stack and referred to as In- > > >> Stack Data, and > > >> > > >> * residing after the Bottom of Stack (BoS) and referred to as > > >> Post-Stack Data. > > >> > > >> Updated: > > >> RFC 9543 Network Slice: > > >> Interpreted as defined in [RFC9543]. This document > > >> uses "network slice" interchangeably as a shorter version of the > > >> term "RFC 9543 Network Slice". > > >> > > >> MPLS Ancillary Data: > > >> Data that can be classified as: > > >> > > >> * residing within the MPLS label stack (referred to as "in-stack > > >> data"), and > > >> > > >> * residing after the Bottom of Stack (BoS) (referred to as "post- > > >> stack data"). > > >> GIM>> I agree with the proposed update. > > >> --> > > >> > > >> > > >> 5) <!-- [rfced] Would you like for the abbreviations listed in Section > > >> 1.2 > > >> ("Abbreviations") to be alphabetized? Or do you prefer the current order? > > >> GIM>> Yes, please alphabetize it; thank you. > > >> --> > > >> > > >> > > >> 6) <!-- [rfced] Please review "Policy as a policy construct". May we > > >> update as follows (i.e., remove "policy")? > > >> > > >> Original: > > >> Section 5 of > > >> [I-D.ietf-teas-ns-ip-mpls] defines a Network Resource Partition (NRP) > > >> Policy as a policy construct that enables the instantiation of > > >> mechanisms to support one or more network slice services. > > >> > > >> Perhaps: > > >> Section 5 of [NS-IP-MPLS] > > >> defines a Network Resource Partition (NRP) Policy as a > > >> construct that enables the instantiation of mechanisms to support one > > >> or more network slice services. > > >> GIM>> I prefer the current form because "NRP Policy" is a term, and > > >> "policy construct" emphasizes that it is a rule that governs the > > >> instantiation of a network slice. > > >> > > >> --> > > >> > > >> > > >> 7) <!-- [rfced] We believe that "label stack elements" here should be > > >> updated to "label stack entries", which is used earlier in this document > > >> and in RFC 8595. > > >> Please confirm. Also note that "label stack element" has not been used > > >> in the RFC Series. > > >> > > >> Original: > > >> [RFC8595] describes how Service Function Chaining can be realized in > > >> an MPLS network by emulating the Network Service Header (NSH) > > >> [RFC8300] using only MPLS label stack elements. > > >> GIM>> You are correct. Please update as s/elements/entries/ > > >> --> > > >> > > >> > > >> 8) <!-- [rfced] Please confirm that "FUNC::ARG" is correct here. We > > >> ask because we see "LOC:FUNCT:ARG" in RFC 8986. > > >> > > >> Original: > > >> MNA can be used to encode > > >> the FUNC::ARGs to support the functional equivalent of FUNC::ARG in > > >> SRv6 as described in [RFC8986]. > > >> GIM>> I believe that FUNC::ARG is correct for SR-MPLS, as it does not > > >> require the locator part of SRv6. > > >> --> > > >> > > >> > > >> 9) <!-- [rfced] Would you like to update "bottom of the label stack" > > >> here to "BoS" or leave as is? > > >> > > >> Original: > > >> In this case, BIER has defined 0b0101 as the > > >> value for the first nibble in the data that immediately appears after > > >> the bottom of the label stack for any BIER-encapsulated packet over > > >> MPLS. > > >> > > >> Perhaps: > > >> In this case, BIER has defined 0b0101 as the > > >> value for the first nibble in the data that immediately appears after > > >> the BoS for any BIER-encapsulated packet over > > >> MPLS. > > >> GIM>> I agree to the proposed update, thank you. > > >> --> > > >> > > >> > > >> 10) <!-- [rfced] Please confirm that the citation is correct here. We > > >> ask because we do not see the specific wording "non-protocol > > >> specifying document" in RFC-to-be 9789 (ietf-mpls-mna-fwk). > > >> > > >> Also, to improve readability, we upddated "non-protocol specifying > > >> documents" > > >> as follows. Let us know any concerns. > > >> > > >> Original: > > >> Section 7 of "MPLS Network Action (MNA) Framework", > > >> [I-D.ietf-mpls-mna-fwk] outlines security considerations for non- > > >> protocol specifying documents. > > >> > > >> Updated: > > >> Section 7 of the MNA framework [RFC9789] outlines security > > >> considerations for documents that do not specify protocols. > > >> GIM>> AFAICS, the full title of RFC 9789-to-be is MPLS Network Action > > >> (MNA) Framework. Perhaps we can omit the full title altogether, making > > >> this sentence as follows: > > >> NEW TEXT: > > >> Section 7 of [RFC9789] outlines security > > >> considerations for documents that do not specify protocols. > > >> --> > > >> > > >> > > >> 11) <!-- [rfced] FYI - We lowercased "post-stack data" and "in-stack > > >> data" per usage in RFC-to-be 9789 (ietf-mpls-mna-fwk). > > >> GIM>> Thank you for your thorough review of both drafts, ensuring > > >> consistency of terminology. > > >> --> > > >> > > >> > > >> 12) <!-- [rfced] Abbreviations > > >> > > >> a) This document uses "Ingress to Edge" as the expansion for I2E, but > > >> RFC-to-be 9789 (ietf-mpls-mna-fwk) and other documents in the RFC > > >> Series use "Ingress to Egress". If no objections, we will update this > > >> document accordingly. > > >> > > >> Current: > > >> Ingress to Edge > > >> > > >> Perhaps: > > >> Ingress to Egress > > >> GIM>> Thank you for catching this. Agreed > > >> > > >> > > >> b) 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. > > >> > > >> Deterministic Networking (DetNet) > > >> Segment Routing over IPv6 (SRv6) > > >> Segment Routing over MPLS (SR-MPLS) > > >> Service Level Objectives (SLOs) > > >> GIM>> All are correct; thank you > > >> --> > > >> > > >> > > >> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the > > >> online Style Guide > > >> <https://www/ > > >> .rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 > > >> C02%7Chaoyu.song%40futurewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C > > >> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832834079759907%7CUnknow > > >> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW > > >> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Rt8uf0hG > > >> lAhNTThSJ8vgcBtkqFzwEFp9DeFRYA4pYX4%3D&reserved=0> > > >> 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. > > >> GIM>> I don't find any red flags. > > >> --> > > >> > > >> > > >> Thank you. > > >> > > >> RFC Editor/rv > > >> > > >> > > >> On May 13, 2025, at 9:31 PM, rfc-edi...@rfc-editor.org wrote: > > >> > > >> *****IMPORTANT***** > > >> > > >> Updated 2025/05/13 > > >> > > >> 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 > > >> > > >> * rfc-edi...@rfc-editor.org (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). > > >> > > >> * auth48archive@rfc-editor.org, which is a new archival mailing list > > >> to preserve AUTH48 conversations; it is not an active discussion > > >> list: > > >> > > >> * More info: > > >> > > >> https://mail/ > > >> archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P > > >> 8O4Zc&data=05%7C02%7Chaoyu.song%40futurewei.com%7Cb97a07e4fd744af430aa > > >> 08dd9713edc5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832834079 > > >> 813636%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > > >> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C > > >> &sdata=%2FU2oVZ8DXINZn48aCaOtIwmQGLqE%2FRwLiwgVSXpHHPM%3D&reserved=0 > > >> > > >> * The archive itself: > > >> > > >> https://mail/ > > >> archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Chao > > >> yu.song%40futurewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a > > >> 3b240189c753a1d5591fedc%7C1%7C1%7C638832834079826643%7CUnknown%7CTWFpb > > >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > > >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=NWirAB2Tu36isDUIr > > >> Lj%2F24evXT5AzX5SzE9vDgvHxk4%3D&reserved=0 > > >> > > >> * 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, > > >> auth48archive@rfc-editor.org 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%2Fauthors%2Frfc9791.xml&data=05%7C02%7Chaoyu.song%40fut > > >> urewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b240189c753a > > >> 1d5591fedc%7C1%7C1%7C638832834079839598%7CUnknown%7CTWFpbGZsb3d8eyJFbX > > >> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > > >> IldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=XlZ1afJEZGoa%2BoaLiDLikYIPvMb3 > > >> RWcO4uWy72mQT%2Bc%3D&reserved=0 > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauthors%2Frfc9791.html&data=05%7C02%7Chaoyu.song%40fu > > >> turewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b240189c753 > > >> a1d5591fedc%7C1%7C1%7C638832834079852478%7CUnknown%7CTWFpbGZsb3d8eyJFb > > >> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > > >> sIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=8fUjg7Z8P131Vfszdsu9ob%2FNVX% > > >> 2FbI4hF8ydjrEc01tg%3D&reserved=0 > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauthors%2Frfc9791.pdf&data=05%7C02%7Chaoyu.song%40fut > > >> urewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b240189c753a > > >> 1d5591fedc%7C1%7C1%7C638832834079864970%7CUnknown%7CTWFpbGZsb3d8eyJFbX > > >> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > > >> IldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Bc%2BxGnxzVpBpu9cm1lopHj%2FLr9 > > >> jcx%2BAl2AVor8ksteI%3D&reserved=0 > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauthors%2Frfc9791.txt&data=05%7C02%7Chaoyu.song%40fut > > >> urewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b240189c753a > > >> 1d5591fedc%7C1%7C1%7C638832834079878177%7CUnknown%7CTWFpbGZsb3d8eyJFbX > > >> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > > >> IldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=0UPImoQ5lBgvM0gb0AtKnz8XB9aD8Z > > >> i65Oe%2BweUYIGY%3D&reserved=0 > > >> > > >> Diff file of the text: > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauthors%2Frfc9791-diff.html&data=05%7C02%7Chaoyu.song > > >> %40futurewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b24018 > > >> 9c753a1d5591fedc%7C1%7C1%7C638832834079890449%7CUnknown%7CTWFpbGZsb3d8 > > >> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > > >> FpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=AWlbHBpgM1v2kD8%2Bn1pUai > > >> wyoyILiVJ5JOKh1pyJA%2F0%3D&reserved=0 > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauthors%2Frfc9791-rfcdiff.html&data=05%7C02%7Chaoyu.s > > >> ong%40futurewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b24 > > >> 0189c753a1d5591fedc%7C1%7C1%7C638832834079903337%7CUnknown%7CTWFpbGZsb > > >> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > > >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=EWvG19GaM62A%2FRdFUJJ > > >> Rt0yxe43Jlq21Rn3X03x%2Bk2M%3D&reserved=0 (side by side) > > >> > > >> Alt-diff of the text (allows you to more easily view changes where > > >> text has been deleted or moved): > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauthors%2Frfc9791-alt-diff.html&data=05%7C02%7Chaoyu. > > >> song%40futurewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b2 > > >> 40189c753a1d5591fedc%7C1%7C1%7C638832834079916101%7CUnknown%7CTWFpbGZs > > >> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > > >> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=PamCqv0wTgAyI1h3y0nM > > >> jRwoGgHdnReSseqogz%2Bn73k%3D&reserved=0 > > >> > > >> Diff of the XML: > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauthors%2Frfc9791-xmldiff1.html&data=05%7C02%7Chaoyu. > > >> song%40futurewei.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b2 > > >> 40189c753a1d5591fedc%7C1%7C1%7C638832834079928961%7CUnknown%7CTWFpbGZs > > >> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > > >> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=vRwecOGfEQnNNjnMX%2B > > >> 0m%2BQqLfQ5AP7jsqKqDAn40c3g%3D&reserved=0 > > >> > > >> > > >> Tracking progress > > >> ----------------- > > >> > > >> The details of the AUTH48 status of your document are here: > > >> > > >> https://www/. > > >> rfc-editor.org%2Fauth48%2Frfc9791&data=05%7C02%7Chaoyu.song%40futurewe > > >> i.com%7Cb97a07e4fd744af430aa08dd9713edc5%7C0fee8ff2a3b240189c753a1d559 > > >> 1fedc%7C1%7C1%7C638832834079943577%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 > > >> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > > >> joyfQ%3D%3D%7C60000%7C%7C%7C&sdata=KtVO4AnUYWqo4l7TPAGxnIq3BarzLnneZv3 > > >> ze2VKFu4%3D&reserved=0 > > >> > > >> Please let us know if you have any questions. > > >> > > >> Thank you for your cooperation, > > >> > > >> RFC Editor > > >> > > >> -------------------------------------- > > >> RFC9791 (draft-ietf-mpls-mna-usecases-15) > > >> > > >> Title : Use Cases for MPLS Network Action Indicators and MPLS > > >> Ancillary Data > > >> Author(s) : T. Saad, K. Makhijani, H. Song, G. Mirsky > > >> WG Chair(s) : Tarek Saad, Tony Li, Adrian Farrel > > >> > > >> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > >> > > >>> On May 14, 2025, at 9:25 AM, Greg Mirsky <gregimir...@gmail.com> wrote: > > >>> > > >>> Dear RFC Editor, > > >>> for some reason I didn't receive the note from the RFC Editor. If there > > >>> are any questions to the authors, please let me know and I will work on > > >>> addressing them. > > >>> > > >>> Regards, > > >>> Greg > > >>> > > >>> On Wed, May 14, 2025 at 4:03 AM James Guichard > > >>> <james.n.guich...@futurewei.com> wrote: > > >>> > > >>> > > >>> 1) <!-- [rfced] *AD: We see that consensus is set to "Unknown" > > >>> for this document in the datatracker. See > > >>> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>. > > >>> > > >>> This document was sent to Last Call, so we have used the consensus > > >>> Status of This Memo. Please confirm that this is correct. > > >>> --> > > >>> > > >>> Jim> Confirmed. > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
