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
