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]
