Authors, All of the documents in cluster 520 (https://www.rfc-editor.org/cluster_info.php?cid=C520) have now completed AUTH48.
We will begin to do our final checks and move this cluster forward in the publication process at this time. Thank you, RFC Editor/rv > On Jun 17, 2025, at 8:20 PM, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > > Hi Kiran and other authors, > > Kiran - We have marked your approval on the AUTH48 status page for this > document; see https://www.rfc-editor.org/auth48/rfc9791. > > All - We have now received all necessary approvals and consider AUTH48 > complete. Thank you for your attention and guidance during the AUTH48 process! > > We will begin to prepare this document for publication, but note that it will > be published at the same time as the other two documents in cluster 520. For > details of the status of each document in cluster 520, please see > https://www.rfc-editor.org/auth48/C520. > > Best regards, > RFC Editor/rv > > > >> On Jun 17, 2025, at 2:20 PM, Kiran Makhijani <kiran.i...@gmail.com> wrote: >> >> My sincere apologies everyone! I have not been following these emails. >> I am happy with the updates. Thank you for improving the document further >> and sorry for delaying the process (it was unintentional). >> -Kiran >> >> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> >> Date: Tuesday, June 17, 2025 at 8:11 AM >> To: Tarek Saad <tsaad....@gmail.com>, kiran.i...@gmail.com >> <kiran.i...@gmail.com>, Haoyu Song <haoyu.s...@futurewei.com>, Greg Mirsky >> <gregimir...@gmail.com> >> Cc: 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 Kiran, >> >> This is a friendly reminder that we have yet to hear back from you regarding >> this document’s readiness for publication. Please let us know if you >> approval the document in its current form or if further changes are needed. >> >> 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 9, 2025, at 11:56 AM, Rebecca VanRheenen >>> <rvanrhee...@staff.rfc-editor.org> wrote: >>> >>> Hi Tarek, >>> >>> Thank you for your reply! We have marked your approval on the AUTH48 status >>> page for this document: https://www.rfc-editor.org/auth48/rfc9791. >>> >>> Once Kiran approves, we will begin to prepare the document for publication. >>> >>> Best regards, >>> RFC Editor/rv >>> >>> >>>> On Jun 8, 2025, at 10:15 AM, Tarek Saad <tsaad....@gmail.com> wrote: >>>> >>>> Hi Rebecca, >>>> Thank you for the edits and suggestions. I have reviewed the latest update >>>> and approve of the document in its current form. >>>> Regards, >>>> Tarek >>>> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> >>>> Date: Monday, June 2, 2025 at 1:54 PM >>>> To: Tarek Saad <tsaad....@gmail.com>, kiran.i...@gmail.com >>>> <kiran.i...@gmail.com>, Haoyu Song <haoyu.s...@futurewei.com>, Greg Mirsky >>>> <gregimir...@gmail.com> >>>> Cc: 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 >>>> 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
