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]
