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]
