Thanks Megan for the great work. Please record my approval.
P.S. You may change United States to United States of America for Kireeti as well to match the other changes. Thanks, Rakesh On Fri, May 22, 2026 at 10:38 PM Megan Ferguson < [email protected]> wrote: > Rakesh, > > Thank you for catching that! > > I’ve updated as requested and reposted. > > Please review carefully as we do not make changes once the document is > published as an RFC: > > The files are available here (please refresh): > https://www.rfc-editor.org/authors/rfc9994.xml > https://www.rfc-editor.org/authors/rfc9994.html > https://www.rfc-editor.org/authors/rfc9994.pdf > https://www.rfc-editor.org/authors/rfc9994.txt > > Diff files are available here (please refresh): > https://www.rfc-editor.org/authors/rfc9994-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9994-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9994-auth48diff.html (Final > Review changes only) > https://www.rfc-editor.org/authors/rfc9994-auth48rfcdiff.html (side by > side) > > The details of the Final Review status of your document are here: > https://www.rfc-editor.org/auth48/rfc9994 > > Thank you. > > Megan Ferguson > RFC Production Center > > > On May 22, 2026, at 5:33 PM, Rakesh Gandhi <[email protected]> > wrote: > > > > Hi Megan, > > > > Many thanks for the prompt updates. > > > > All updates look good to me, but I have one comment below: > > > > Regarding > > #9: *AD - This change is to BPC 14 keywords and thus will require AD > approval > > > > >> 9) <!--[rfced] Please review this quick change between BCP 14 > markings in > > >> back-to-back related sentences and let us know if any updates are > > >> necessary. > > > > OLD: > > * System designers must be aware that information included in AD may > > be transmitted "in the clear". Network actions that require the > > exchange of sensitive data must be defined in such a way that the > > data is encrypted in transit. Otherwise, sensitive data MUST NOT > > be transmitted using these mechanisms. > > > > > > NEW: > > * System designers must be aware that information included in AD may > > be transmitted "in the clear". Network actions that require the > > exchange of sensitive data MUST be defined in such a way that the > > data is encrypted in transit. Otherwise, sensitive data MUST NOT > > be transmitted using these mechanisms. > > > > <RG> Note that the first must after "System designers" may not change, > it is after the "sensitive data" that we may change to MUST. > > <RG> You may need to revert the first change of must. > > > > Thanks, > > Rakesh (for authors) > > > > > > > > On Fri, May 22, 2026 at 6:59 PM Megan Ferguson < > [email protected]> wrote: > > Hi Rakesh (and *AD), > > > > Thank you for the prompt reply! > > > > We have used your guidance to update the files. We had a few follow-up > questions: > > > > #6: Please review our further rephrasing and confirm that this would > work for you. > > > > #7: Please disregard: I think this was just a misreading on my part. > > > > #9: *AD - This change is to BPC 14 keywords and thus will require AD > approval > > > > >> 9) <!--[rfced] Please review this quick change between BCP 14 > markings in > > >> back-to-back related sentences and let us know if any updates are > > >> necessary. > > >> > > >> Original: > > >> Network actions that require the exchange of sensitive data, must be > > >> defined in such a way that the data is encrypted in transit. > > >> Otherwise, sensitive data MUST NOT be transmitted using these > > >> mechanisms. > > >> > > >> —> > > >> > > >> <RG> So maybe the first should be BCP 14. > > >> Network actions that require the exchange of sensitive data, MUST be > > >> defined in such a way that the data is encrypted in transit. > > >> Otherwise, sensitive data MUST NOT be transmitted using these > > >> mechanisms. > > > > #10: We have further updated the rephrasing, please review and confirm > we’ve captured your intent. > > > > #11: We have cut this text as this use seems unusual (generally, the > registry group itself seems to be the top layer mentioned. > > > > All other updates can be reviewed in the files linked below. > > > > Please review carefully as we do not make changes once the document is > published as an RFC: > > > > The files are available here (please refresh): > > https://www.rfc-editor.org/authors/rfc9994.xml > > https://www.rfc-editor.org/authors/rfc9994.html > > https://www.rfc-editor.org/authors/rfc9994.pdf > > https://www.rfc-editor.org/authors/rfc9994.txt > > > > Diff files are available here (please refresh): > > https://www.rfc-editor.org/authors/rfc9994-diff.html (comprehensive) > > https://www.rfc-editor.org/authors/rfc9994-rfcdiff.html (side by side) > > > > https://www.rfc-editor.org/authors/rfc9994-auth48diff.html (Final > Review changes only) > > https://www.rfc-editor.org/authors/rfc9994-auth48rfcdiff.html (side > by side) > > > > The details of the Final Review status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9994 > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > > > > > > On May 22, 2026, at 2:31 PM, Rakesh Gandhi <[email protected]> > wrote: > > > > > > Hello RFC Editor, > > > > > > Many thanks for the great editorial changes. > > > > > > Please see replies inline with <RG>... > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > From: <[email protected]> > > > Date: Fri, May 22, 2026 at 1:12 PM > > > Subject: Re: RFC-to-be 9994 draft-ietf-mpls-mna-hdr for your review > > > To: <[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]> > > > > > > > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the source file. > > > > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. —> > > > > > > <RG> Perhaps: > > > > > > MNA Header > > > > > > MNA Encoding > > > > > > 2) <!--[rfced] We had the following questions/comments regarding the > > > abbreviations table: > > > > > > a) We note that RFC 9789 uses "NSI" for "Network Action Sub-Stack > > > Indicator", while this document uses "NASI" for the same expansion. > > > Please let us know if any updates for uniformity are desired. > > > > > > <RG> We can use NSI as defined in RFC 9789. > > > > > > b) We have updated the following to match their use in the relevant > > > normative reference (with regard to capitalization, hyphenation, > > > pluralization, etc.). Please let us know any objections: > > > > > > Current: > > > Bottom of Stack (BoS) > > > Hop-by-Hop (HbH) > > > Ingress to Egress (I2E) > > > In-Stack Data (ISD) > > > base Special-Purpose Label (bSPL) > > > MPLS Network Action (MNA) > > > Time to Live (TTL) > > > > > > <RG> Ok. > > > > > > c) We see NAS expanded as "Network Action Sub-Stack" in this document > > > and RFC 9789. However, we see past uses in RFCs as "Network Action > > > Substack" (Substack is a closed compound). Please review and let us > > > know if any updates are necessary. > > > > > > <RG> We can use the same as RFC 9789. > > > > > > d) The text above the table says: > > > > > > Original: > > > The abbreviations defined in [RFC9789] and [RFC9613] are used in this > > > document. > > > > > > As the table that follows then lists abbreviations from those > > > documents and many others, should this sentence be cut? Or is the > > > meaning that some abbreviations in those documents that do not appear > > > in the table are also used? > > > > > > <RG> We could remove the sentence as all abbreviations would have been > listed here with their references. > > > > > > Please review. > > > > > > e) We note that RFC 9789 does not use the abbreviation "IHS". How may > > > we update for accuracy? > > > > > > Original: > > > | IHS | I2E, HbH, or Select | [RFC9789], | > > > | | | This document | > > > > > > > > > <RG> In that case, we can remove RFC9789 from this row. > > > > > > > > > 3) <!--[rfced] Please consider if an update like the following makes > sense: > > > > > > Original: > > > This LSE can carry up to 13 bits of ancillary data. > > > > > > Perhaps: > > > The Data field of this LSE can carry up to 13 bits of ancillary data. > > > —> > > > > > > > > > <RG> Ok. > > > > > > > > > 4) <!--[rfced] Should Section 9.4 "Egress Node Responsibilities" be > > > referenced here instead of Section 9? > > > > > > Original: > > > The egress node may receive a NAS at the top of the label stack as > > > discussed in Section 9. > > > > > > Perhaps: > > > The egress node may receive a NAS at the top of the label stack as > > > discussed in Section 9.4. > > > —> > > > > > > <RG Ok. > > > > > > 5) <!--[rfced] Please clarify the antecedent of "it" in the following > > > sentence: > > > > > > Original: > > > For a NAS with Select scope, it is processed by the node that brings > > > it to the top of stack (for example, in the case of using MPLS label > > > pop operation in Segment Routing) and then the NAS is removed from the > > > stack. > > > —> > > > > > > <RG> Perhaps: > > > A NAS with Select scope is processed by the node that brings > > > the NAS to the top of stack (for example, in the case of using MPLS > label > > > pop operation in Segment Routing) and then the NAS is removed from the > > > stack. > > > > > > > > > 6) <!--[rfced] This sentence is complex and difficult to follow on a > > > quick read. Please consider rephrasing: > > > > > > Original: > > > * The mechanisms by which the capabilities of the nodes are known > by > > > the node responsible for selecting a path through the MPLS > network > > > are out of scope for this document. > > > > > > > > > —> > > > > > > <RG> Perhaps: > > > The mechanisms by which the node responsible for selecting a path > through the > > > MPLS network learns about the capabilities of the nodes are out of > scope for this document. > > > > > > > > > 7) <!--[rfced] Please let rephrase "that can be ready by the > > > MNA-processing nodes in the path". Should this be "that can be > > > made ready"? > > > > > > Original: > > > This ensures that the label stack depth of a computed path does not > > > exceed the maximum number of labels (i.e., MSD) the node is capable of > > > imposing and the maximum number of labels that can be read by the > > > MNA-processing nodes in the path. > > > —> > > > > > > <RG> There is no “ready” in the sentence. We could add a comma before > “and the maximum number"? > > > > > > This ensures that the label stack depth of a computed path does not > > > exceed the maximum number of labels (i.e., MSD) the node is capable of > > > imposing, and the maximum number of labels that can be read by the > > > MNA-processing nodes in the path. > > > > > > > > > 8) <!--[rfced] May we update this text as follows? > > > > > > Original: > > > The following information MUST be defined for a new Network Action > > > Indicator opcode request in the document that specifies the Network > > > Action. > > > > > > Perhaps: > > > The following information MUST be defined in documentation for any new > > > NAI opcode request. > > > —> > > > > > > <RG> Ok. > > > > > > > > > 9) <!--[rfced] Please review this quick change between BCP 14 markings > in > > > back-to-back related sentences and let us know if any updates are > > > necessary. > > > > > > Original: > > > Network actions that require the exchange of sensitive data, must be > > > defined in such a way that the data is encrypted in transit. > > > Otherwise, sensitive data MUST NOT be transmitted using these > > > mechanisms. > > > > > > —> > > > > > > <RG> So maybe the first should be BCP 14. > > > Network actions that require the exchange of sensitive data, MUST be > > > defined in such a way that the data is encrypted in transit. > > > Otherwise, sensitive data MUST NOT be transmitted using these > > > mechanisms. > > > > > > > > > 10) <!--[rfced] Will the reader know what the "MNA application > documents" > > > are? Maybe a citation would be helpful here? Additionally, "are > > > encouraged to be addressed" reads a bit strangely (who is > > > encouraged?). > > > > > > Original: > > > The considerations for performance and scale assessments are outside > > > the scope of this document but are encouraged to be addressed in the > > > MNA application documents. > > > > > > Perhaps: > > > Performance and scale assessments are outside the scope of this > > > document; the authors of the MNA application documents [citation(s)?] > > > are encouraged to address them. > > > > > > —> > > > > > > <RG> Ok, but those would be future documents and no citations are > needed. > > > > > > > > > 11) <!--[rfced] What does "within the 'Multiprotocol Label Switching > > > Architecture (MPLS)' category" mean? We generally see registry > > > names and within a certain registry group. > > > > > > Original: > > > This document requests that IANA create a new registry group called > > > "MPLS Network Actions Parameters" within the "Multiprotocol Label > > > Switching Architecture (MPLS)" category. > > > > > > —> > > > > > > <RG> Perhaps, replace category with registry. > > > <RG> FYI: It is listed here. > > > https://www.iana.org/protocols > > > > > > > > > 12) <!--[rfced] Please clarify this text. If our suggested text does > not > > > capture the intended meaning, please rephrase. > > > > > > Original: > > > ...(due to NASL limit of 15 and Format D requires Format C LSE)... > > > > > > Perhaps: > > > ...(due to the NASL limit of 15 and the constraint of Format D > > > requiring a Format C LSE... > > > —> > > > > > > <RG> Ok. > > > > > > 13) <!--[rfced] We had the following questions/comments related to > Table 4: > > > > > > a) Table 4 contains only the Registration Procedures for the "Network > > > Action Flags Without Ancillary Data" registry. We have updated the > > > column headings and removed the reference column to match what we see > > > at > > > > https://www.iana.org/assignments/mpls-network-actions/mpls-network-actions.xhtml#network-action-flags-without-ancillary-data > . > > > > > > b) It appears that there are currently no values registered in this > > > registry. Please confirm that this is as desired. If so, perhaps it > > > makes sense to mention in the document that the original contents of > > > the registry are empty? > > > > > > —> > > > > > > <RG> Yes. > > > > > > > > > 14) <!--[rfced] We had some questions related to the following text: > > > > > > Original: > > > Registration requests should comply with Section 10 as well as > > > security review. > > > > > > > > > <RG> Perhaps: > > > > > > OLD: > > > security review > > > NEW: > > > Security Considerations in Section 11. > > > > > > > > > a) Might it be helpful to the reader to clarify what "security review" > > > means (Security Considerations text or is this some kind of other > > > review)? > > > > > > b) We do see RFC 8126 mentioned in the Security Considerations section > > > as follows. This seems procedural for IANA. Is there some kind of > > > risk this text is supposed to address? Otherwise, perhaps remove this > > > text as this is already captured in the IANA Considerations section? > > > > > > Original: > > > * The "private Use" opcodes in "Network Action Opcodes" Section > 14.4 > > > and "Network Action Flags Without Ancillary Data" Section 14.3 > > > Registry are subject to the considerations described in > [RFC8126]. > > > —> > > > > > > <RG> Yes. > > > > > > > > > 15) <!--[rfced] We had the following questions related to references: > > > > > > a) Would you like the reference entries to be alphabetized or left in > > > their current order? > > > > > > <RG> Numerical order of the RFC number. > > > > > > b) We happened to notice the RFC 9789 references RFC 3031 normatively. > > > This document references it informatively. Please review and confirm > > > this reference appears as desired. > > > > > > <RG> Yes, we can keep it as is. > > > > > > c) We most frequently see RFC 8126 cited informatively. Please review > > > and confirm that this document should remain in the Normative > > > References section. > > > > > > —> > > > > > > <RG> There is no reason for it to be different here than the other > documents. > > > > > > > > > 16) <!--[rfced] We had the following questions/comments related to > > > abbreviations used throughout the document: > > > > > > a) Please note that we have expanded abbreviations on first use. > > > Please review for accuracy. > > > > > > <RG> Ok. > > > > > > b) We have updated to use abbreviations only after their first > > > expanded introduction in accordance with > > > https://www.rfc-editor.org/styleguide/part2/#exp_abbrev. Please let > > > us know any objections. > > > > > > <RG> Ok. > > > > > > c) We have updated to use "a NAS" instead of "an NAS" as we believe > > > this is an acronym (i.e., read as a word instead of an initialism). > > > This tracks with past use in RFCs. Please let us know any objections. > > > —> > > > > > > <RG> Ok. > > > > > > 17) <!--[rfced] We had the following questions related to terminology > used > > > throughout the document: > > > > > > a) We see both Format-B and Format B (and A, C, D, etc.). How may we > > > make these consistent? > > > > > > <RG> Format B. > > > > > > > > > b) We see multiple forms of the following. Please let us know if/how > > > to make them consistent throughout the document: > > > > > > Last LSE vs. last LSE > > > MNA Sub-Stack vs. MNA sub-stack > > > In-Stack vs. in-stack > > > Network Action vs. network action > > > Network Action Flag vs. network action flag > > > Label Stack vs. label stack > > > Select scope vs. select-scoped > > > > > > <RG> Perhaps: > > > last LSE > > > Sub-Stack as used in RFC 9789. > > > in-stack as used in RFC 9789. > > > network action as used in RFC 9789 > > > network action flag > > > label stack as used in RFC 9789 > > > Select scope as used in RFC 9789 > > > > > > > > > > > > > > > c) We see some possible inconsistencies with the following: > > > > > > I2E scope NAS > > > NAS with I2E scope > > > HbH NAS > > > HbH scope NAS > > > NAS with HbH scope > > > > > > Please let us know if/how to make these uniform. > > > —> > > > > > > <RG> Perhaps: > > > NAS with I2E scope > > > NAS with HbH scope > > > > > > > > > 18) <!-- [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. > > > —> > > > > > > <RG> Ack. > > > > > > Many thanks Megan, > > > > > > Rakesh (for authors) > > > > > > > > > > > > > > > Thank you. > > > > > > Megan Ferguson > > > RFC Production Center > > > > > > *****IMPORTANT***** > > > > > > 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/rfc9994.xml > > > https://www.rfc-editor.org/authors/rfc9994.html > > > https://www.rfc-editor.org/authors/rfc9994.pdf > > > https://www.rfc-editor.org/authors/rfc9994.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9994-diff.html > > > https://www.rfc-editor.org/authors/rfc9994-rfcdiff.html (side by > side) > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9994-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9994 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC 9994 (draft-ietf-mpls-mna-hdr) > > > > > > Title : MPLS Network Action (MNA) Sub-Stack Specification > including In-Stack Network Actions and Data > > > Author(s) : J. Rajamanickam, Ed., > > > R. Gandhi, Ed., > > > R. Zigler, > > > H. Song, > > > K. Kompella > > > 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]
