Royi, Just adding a note to say that our new system pulled up two entries for you with the two email addresses in the To: field. These originate from the datatracker profile: you may want to review and consolidate your datatracker person page(s).
Thank you. Megan Ferguson RFC Production Center > On May 22, 2026, at 11:12 AM, [email protected] wrote: > > 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. --> > > > 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. > > 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) > > 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. > > 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? > > 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 | > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > > > --> > > > 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. > --> > > > 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. > --> > > > 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. > > --> > > > 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. > > --> > > > 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. > --> > > > 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... > --> > > > 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? > > --> > > > 14) <!--[rfced] We had some questions related to the following text: > > Original: > Registration requests should comply with Section 10 as well as > security review. > > 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]. > --> > > > 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? > > 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. > > c) We most frequently see RFC 8126 cited informatively. Please review > and confirm that this document should remain in the Normative > References section. > > --> > > > 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. > > 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. > > 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. > --> > > > 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? > > 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 > > 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. > --> > > > 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. > --> > > > 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]
