Hi Tony, Loa, and other authors,
Thank you for responding to our questions. We have updated the document
accordingly (see files listed below) and have a few followup questions/comments.
1) Apologies for not being clear in our question about the abbreviation and
expansion in the document title. We’d like to clarify.
In the title of RFC 9613, both the expansion ("MPLS Network Actions”) and
abbreviation (“MNAs”) are plural. In the title of this document, the expansion
was plural ("MPLS Network Actions”), but the abbreviation was singular (“MNA”).
The expansion and abbreviation should match (i.e., both singular or both
plural).
It seems that the current is acceptable, but if any further updates are needed,
please let us know.
Both singular (current):
MPLS Network Action (MNA) Framework
Both plural:
MPLS Network Actions (MNAs) Framework
or
Framework for MPLS Network Actions (MNAs)
2)
>> c) The second definition below mentions "MNA label", but the first does
>> not. Also, one definition uses "special label", and the other uses
>> "special-purpose label". Are any updates needed?
>>
>> Original:
>> * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
>> contains a special label that indicates the start of the NAS.
>> ...
>> * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
>> contains a special purpose label, called the MNA label, which is
>> used to indicate the start of a network action sub-stack.
>>
>> Perhaps:
>> Network Action Sub-Stack Indicator (NASI): The special-purpose label
>> contained
>> in the first LSE in the NAS. The NSI, also called the MNA label,
>> indicates
>> the start of the NAS.
>> ...
>> * Network Action Sub-Stack Indicator (NASI): The special-purpose label
>> contained
>> in the first LSE in the NAS. The NSI, also called the MNA label,
>> indicates
>> the start of the NAS.
Tony:
> Perhaps:
> * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS.
> The NSI contains a special label that indicates the start of the NAS.
> * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS.
> The NSI contains a special purpose label, called the MNA label, which is
> used to indicate the start of a network action sub-stack.
Loa:
>
>
> I prefer the orignal but s/a special label/a special purpose label/
How about the following?
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS, which
contains a special-purpose label that indicates the start of the NAS.
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS, which
contains a special-purpose label, called the MNA label, that is
used to indicate the start of a network action sub-stack.
3) Regarding the following question, we have updated per Tony’s suggestion, but
we will wait for Stewart and/or Matthew to review per Loa’s comment below.
>> 14) <!-- [rfced] We are having trouble understanding the text starting with
>> "to
>> determine...". Please clarify.
>>
>> Original:
>> However, the BIER approach meets
>> the design goal of [RFC8296] to determine that the payload is IPv4,
>> IPv6 or with the header of a pseudowire packet with a control word,
>> rather than being a payload belonging to a BIER or some other type of
>> packet.
>> -->
Tony:
> How about:
> However, the BIER approach meets
> the design goal of [RFC8296] to determine that the payload is IPv4,
> IPv6, or the header of a pseudowire packet with a control word,
> rather than being a payload belonging to a BIER or some other type of
> packet.
Loa:
> I think this is a mine field, I hope Stewart or Matthew can help us.
4)
>> a) If no objections, we will update instances of "sub-stack" (with hyphen) to
>> "substack" (no hyphen).
>>
>>
>> b) Please review use of "special label". Should instances of
>> "special label" be updated to "special-purpose label"?
>> -->
Tony:
> Both are fine.
Loa:
> I actually prefer sub-stack, it is easier to find when reading-
We have retained the hyphen in “sub-stack”. However, note that the Chicago
Manual of Style recommends not using a hyphen with prefixes except in a few
cases (e.g., to separate two i’s as in “anti-intellectual”).
— FILES (please refresh) —
Updated XML file:
https://www.rfc-editor.org/authors/rfc9789.xml
Updated output files:
https://www.rfc-editor.org/authors/rfc9789.txt
https://www.rfc-editor.org/authors/rfc9789.pdf
https://www.rfc-editor.org/authors/rfc9789.html
Diff file showing all changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9789-auth48diff.html
https://www.rfc-editor.org/authors/rfc9789-auth48rfcdiff.html (side by side)
Diff files showing all changes:
https://www.rfc-editor.org/authors/rfc9789-diff.html
https://www.rfc-editor.org/authors/rfc9789-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9789-alt-diff.html (diff showing
changes where text is moved or deleted)
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9789
Thank you,
RFC Editor/rv
> On May 15, 2025, at 1:51 AM, Matthew Bocci (Nokia)
> <matthew.bocci=40nokia....@dmarc.ietf.org> wrote:
>
> I think the current version “MPLS Network Action (MNA) Framework” is fine.
> Although it is different in structure from RFC9613, the meaning of MNA (i.e.
> does MNA mean MPLS Network Action or MPLS Network Actions) is consistent
> between the two documents (I hope 😊).
> Cheers
> Matthew
> From: Loa Andersson <l...@pi.nu>
> Date: Thursday, 15 May 2025 at 06:45
> To: Tony Li <tony...@tony.li>, RFC Errata System <rfc-edi...@rfc-editor.org>
> Cc: Stewart Bryant <s...@stewartbryant.com>, Matthew Bocci (Nokia)
> <matthew.bo...@nokia.com>, mpls-...@ietf.org <mpls-...@ietf.org>, mpls-chairs
> <mpls-cha...@ietf.org>, ts...@cisco.com <ts...@cisco.com>, James Guichard
> <james.n.guich...@futurewei.com>,
> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>
> Subject: Re: AUTH48: RFC-to-be 9789 <draft-ietf-mpls-mna-fwk-15> for your
> review
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
> Hi,
>
> I had also started tyo to through the questions, but will add to Tony's
> mail since it is more complete then mine.
>
> Den 15/05/2025 kl. 05:56, skrev Tony Li:
> > Hi,
> >
> >> While reviewing this document during AUTH48, please resolve (as necessary)
> >> the following questions, which are also in the XML file.
> >>
> >>
> >> 1) <!-- [rfced] Per use in RFCs 9613, we updated the expansion for MNA
> >> from "MPLS
> >> Network Actions" (plural "Actions") to "MPLS Network Action" (singular
> >> "Action"). Note that we also made this change in the abstract and
> >> introduction. However, if you prefer to use the plural, perhaps we can
> >> update as
> >> follows.
> >>
> >> Original (document title):
> >> MPLS Network Actions (MNA) Framework
> >>
> >> Current:
> >> MPLS Network Action (MNA) Framework
> >>
> >> Perhaps:
> >> Framework for MPLS Network Actions (MNAs)
> >> -->
> >
> >
> > The ‘Current’ version is fine.
>
> I don't understand this, RFC 9613 has the plural:
>
> RFC 9613
> Requirements for Solutions that Support MPLS Network Actions (MNAs)
>
> I still think that the Original is best:
>
> MPLS Network Actions (MNA) Framework
>
> Caveat, this is English grammar and I normally defer to the RFC Editor
> and my co-authors, but I don't understand why we'd do the two RFC
> differently. That said I also think that the plural s in the RFC 9613
> abbreviation could be dropped, but not important enough for me to create
> an errata. The only thing that could happen with the plurarl s there is
> that if someone searches the documents for MNAs, it will not find MNA.
>
>
> >
> >
> >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> >> the title) for use on https://www.rfc-editor.org/search. -->
> >
> >
> > Some suggestions: “network function virtualization”, “service chaining”.
> >
> > The general problem here is that MNA is an extension mechanism that could
> > be made to do just about anything. “Kitchen sink” doesn’t seem like it’s
> > constructive, but it would be accurate. :-)
> >
>
> Agree with Tony.
>
> >
> >> 3) <!-- [rfced] Will readers understand which items are part of the series
> >> here?
> >> Does one of the following accurately convey the intended meaning?
> >>
> >> Original:
> >> These might include
> >> load-balancing a packet given its entropy, whether or not to perform
> >> fast-reroute on a failure, and whether or not a packet has metadata
> >> relevant to the forwarding actions along the path.
> >>
> >> Perhaps (entropy, whether or not..., whether or not...):
> >> These might include
> >> load-balancing a packet given its entropy, whether or not
> >> fast-reroute is performed on a failure, and whether or not a packet has
> >> metadata
> >> relevant to the forwarding actions along the path.
> >>
> >> Or (load-balancing, indicating, indicating):
> >> These might include
> >> load-balancing a packet given its entropy, indicating whether or not to
> >> perform
> >> Fast Reroute on a failure, and indicating whether or not a packet has
> >> metadata
> >> relevant to the forwarding actions along the path.
> >> -->
> >
> >
> > Either alternative seems fine.
>
> Yes, agree. But have a (very slight) preference for the second alternative.
> >
> >
> >> 4) <!-- [rfced] We have a few questions about the similar text below from
> >> Sections 1.2 and 2.
> >>
> >> a) Please confirm that NSI is the correct acronym for "Network Action
> >> Sub-Stack Indicator". Should it be "NASI" rather than "NSI" to correspond
> >> with
> >> "Network Action Indicator (NAI)" and "Network Action Sub-Stack (NAS)"?
> >
> >
> > NSI is correct, but we’re not married to it. If there is a good reason to
> > change, we can.
>
> Yes, we did not like NASI.
>
> >
> >
> >> b) Is the NSI the special-purpose label? If so, may we update the
> >> definition
> >> below as follows?
> >
> >
> > The NSI is the entire LSE, which includes the SPL.
>
> Ack.
>
> >
> >
> >> c) The second definition below mentions "MNA label", but the first does
> >> not. Also, one definition uses "special label", and the other uses
> >> "special-purpose label". Are any updates needed?
> >>
> >> Original:
> >> * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
> >> contains a special label that indicates the start of the NAS.
> >> ...
> >> * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
> >> contains a special purpose label, called the MNA label, which is
> >> used to indicate the start of a network action sub-stack.
> >>
> >> Perhaps:
> >> Network Action Sub-Stack Indicator (NASI): The special-purpose label
> >> contained
> >> in the first LSE in the NAS. The NSI, also called the MNA label,
> >> indicates
> >> the start of the NAS.
> >> ...
> >> * Network Action Sub-Stack Indicator (NASI): The special-purpose label
> >> contained
> >> in the first LSE in the NAS. The NSI, also called the MNA label,
> >> indicates
> >> the start of the NAS.
>
> I prefer the orignal but s/a special label/a special purpose label/
>
> >> -->
> >
> >
> > Perhaps:
> > * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS.
> > The NSI contains a special label that indicates the start of the NAS.
> > * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS.
> > The NSI contains a special purpose label, called the MNA label, which
> > is
> > used to indicate the start of a network action sub-stack.
> >
> >
> >> 5) <!-- [rfced] We see that "sub-stacks" (plural) is used early in the
> >> sentence
> >> and "sub-stack" (singular) is used later. Is the current correct, or
> >> should both instances be either plural or singular?
> >>
> >> Original:
> >> A solution must specify where in the label stack the network
> >> actions sub-stacks occur, if and how frequently they should be
> >> replicated within the label stack, and how the network action sub-
> >> stack and post-stack data are encoded.
> >> -->
> >
> >
> > Multiple sub-stacks are permissible and expected, so plural throughout
> > would make more sense.
>
> I'm not sure about this, there are places when we talk abour "a
> sub-stack" and "the sb-stack", I think this should stay singular.
>
> >
> >
> >> 6) <!-- [rfced] This sentence includes two instances of "post-stack data".
> >> Please
> >> confirm that this is correct.
> >>
> >> Original:
> >> As an example, post-stack data might appear as a label stack followed
> >> by post-stack data, followed by the payload:
> >>
> >> Perhaps:
> >> As an example, post-stack data might appear in a label stack, followed
> >> by the payload:
> >> -->
> >
> >
> > The original is correct.
> >
> > If it helps clarify things, we might also say:
> >
> > As an example, a packet containing post-stack data might contain a label
> > stack followed by post-stack data, followed by the payload:
>
> Agree with Tony.
>
> >
> >
> >> 7) <!-- [rfced] Would updating "not more than one" to simply "one" or "a
> >> single"
> >> improve readability of this sentence?
> >>
> >> Original:
> >> This document assumes that the MPLS WG will select not more than one
> >> solution for the encoding of ISD and not more than one solution for
> >> the encoding of PSD.
> >>
> >> Perhaps:
> >> This document assumes that the MPLS WG will select a single
> >> solution for the encoding of ISD and a single solution for
> >> the encoding of PSD.
> >> -->
> >
> >
> > That would be ok. There was considerable confusion that we might select
> > more than one and a distinct possibility of selecting zero, but that has
> > passed.
>
> Agree with Tony the the "Perhaps" is clearer.
>
> >
> >
> >> 8) <!-- [rfced] FYI - We updated the parenthetical as shown below.
> >>
> >> Original:
> >> A node SHOULD use signaling
> >> (e.g., [RFC9088], [RFC9089]) to determine this.
> >>
> >> Updated:
> >> A node SHOULD use signaling
> >> (e.g., the signaling described in [RFC9088] and [RFC9089]) to determine
> >> this.
> >> -->
> >
> >
> > That’s not an improvement, IMHO, but acceptable.
>
> I think the "Updated" is beter.
> >
> >
> >> 9) <!-- [rfced] Should the text introducing the list indicate if the value
> >> is
> >> "from one of the following" or "each of the following"? Or will readers
> >> understand?
> >>
> >> Original:
> >> An MNA node MUST use the RLD determined by selecting the first
> >> advertised non-zero value from:
> >>
> >> * The RLD advertised for the link.
> >>
> >> * The RLD advertised for the node.
> >>
> >> * The non-zero ERLD for the node.
> >>
> >> Perhaps:
> >> An MNA node MUST use the RLD determined by selecting the first
> >> advertised non-zero value from one of the following:
> >>
> >> * The RLD advertised for the link
> >>
> >> * The RLD advertised for the node
> >>
> >> * The non-zero ERLD for the node
> >>
> >> Or:
> >> An MNA node MUST use the RLD determined by selecting the first
> >> advertised non-zero value from each of the following:
> >>
> >> * The RLD advertised for the link
> >>
> >> * The RLD advertised for the node
> >>
> >> * The non-zero ERLD for the node
> >> -->
> >
> >
> > I think the original is clear, but if you dislike that, another version
> > might be:
> >
> > An MNA node MUST use the RLD determined by selecting the first
> > advertised non-zero value from the following:
>
> I would go with Tony's suggestion.
> >
> >
> >
> >> 10) <!-- [rfced] Each definition below includes a number of bits except for
> >> TTL. Should the TTL definition also include a number of bits?
> >>
> >> Original:
> >> Label: Label value, 20 bits
> >> TC: Traffic Class, 3 bits
> >> S: Bottom of Stack, 1 bit
> >> TTL: Time To Live
> >>
> >> Perhaps:
> >> Label: Label value, 20 bits
> >> TC: Traffic Class, 3 bits
> >> S: Bottom of Stack, 1 bit
> >> TTL: Time To Live, 8 bits
> >> -->
> >
> >
> > That’s fine.
>
> Agree.
>
> >
> >
> >> 11) <!-- [rfced] Figure 4 does not have a title; all the other figures do.
> >> What
> >> title should we add for Figure 4? Also, would it be helpful to revise the
> >> title of Figure 3 to be more descriptive?
> >>
> >> Current:
> >> Figure 3: A Label Stack Entry
> >> Figure 4
> >>
> >> Perhaps:
> >> Figure 3: A Label Stack Entry with TC and TTL Retained
> >> Figure 4: A Label Stack Entry with TC and TTL Repurposed
> >> -->
> >
> >
> > That’s fine.
>
> Agree.
>
> >
> >
> >> 12) <!-- [rfced] Should "NAI" here be plural (i.e., "NAIs")?
> >>
> >> Original:
> >> A solution may carry some NAI and AD as PSD.
> >>
> >> Perhaps (change to "NAIs"):
> >> A solution may carry some NAIs and AD as PSD.
> >>
> >> Or (remove "some"):
> >> A solution may carry NAI and AD as PSD.
> >> -->
> >
> >
> > Either is fine.
>
> Prefer removing "some".
> >
> >
> >> 13) <!-- [rfced] "ECMP'ed" has not been used in published RFCs. Will
> >> readers
> >> understand what this means? Perhaps rephrasing would be helpful.
> >>
> >> Original:
> >> For example, an
> >> Ethernet Pseudowire without a control word might have "4" or "6" in
> >> the first nibble and thus will be ECMP'ed.
> >> -->
> >
> >
> > ECMP is on our well-known acronym’s list. If you object to the informality,
> > I would suggest:
> >
> > For example, an
> > Ethernet Pseudowire without a control word might have "4" or "6" in
> > the first nibble and thus will be subject to ECMP forwarding.
> >
>
> hmmm, would prefer Tony's suggestion.
>
> >
> >> 14) <!-- [rfced] We are having trouble understanding the text starting
> >> with "to
> >> determine...". Please clarify.
> >>
> >> Original:
> >> However, the BIER approach meets
> >> the design goal of [RFC8296] to determine that the payload is IPv4,
> >> IPv6 or with the header of a pseudowire packet with a control word,
> >> rather than being a payload belonging to a BIER or some other type of
> >> packet.
> >> -->
> >
> > How about:
> >
> > However, the BIER approach meets
> > the design goal of [RFC8296] to determine that the payload is IPv4,
> > IPv6, or the header of a pseudowire packet with a control word,
> > rather than being a payload belonging to a BIER or some other type of
> > packet.
> >
>
> I think this is a mine field, I hope Stewart or Matthew can help us.
> >
> >> 15) <!-- [rfced] How may we update this sentence for clarity?
> >>
> >> Original:
> >> Network actions should be defined in a document that must contain:
> >>
> >> Perhaps:
> >> The definition of a network action in a document must contain the
> >> following:
> >>
> >> Or:
> >> Network actions should be defined in a document using the format below:
> >> -->
> >
> >
> > Your first alternative would work.
>
> Agree, but I would rather say
>
> A document defining a network action must contain the following:
>
> >
> >
> >> 16) <!-- [rfced] The "Scope", "State", and "Required/Optional" items below
> >> include
> >> complete sentences starting with "The document should..."; the other
> >> items in the list do not. How may we update these three items to create
> >> parallel structure in this list?
> >>
> >> Original:
> >> * Name: The name of the network action.
> >>
> >> * Network Action Indicator: The bit position or opcode that
> >> indicates that the network action is active.
> >>
> >> * Scope: The document should specify which nodes should perform the
> >> network action as described in Section 2.1.
> >>
> >> * State: The document should specify if the network action can
> >> modify state in the network, and if so, the state that may be
> >> modified and its side effects.
> >>
> >> * Required/Optional: The document should specify whether a node is
> >> required to perform the network action.
> >>
> >> * In-Stack Data: The number of LSEs of in-stack data, if any, and
> >> its encoding. If this is of a variable length, then the solution
> >> must specify how an implementation can determine this length
> >> without implementing the network action.
> >>
> >> * Post-Stack Data: The encoding of post-stack data, if any. If this
> >> is of a variable length, then the solution must specify how an
> >> implementation can determine this length without implementing the
> >> network action.
> >>
> >> Perhaps:
> >> Name: The name of the network action.
> >>
> >> Network Action Indicator: The bit position or opcode that indicates
> >> that the network action is active.
> >>
> >> Scope: Description of which nodes should perform the
> >> network action as described in Section 2.1.
> >>
> >> State: Indication of whether the network action can modify
> >> state in the network and, if so, the state that may be modified
> >> and its side effects.
> >>
> >> Required/Optional: Indication of whether a node is
> >> required to perform the network action.
> >>
> >> In-Stack Data: The number of LSEs of in-stack data, if any, and its
> >> encoding. If this is of a variable length, then the solution must
> >> specify how an implementation can determine this length without
> >> implementing the network action.
> >>
> >> Post-Stack Data: The encoding of post-stack data, if any. If this
> >> is of a variable length, then the solution must specify how an
> >> implementation can determine this length without implementing the
> >> network action.
> >> -->
> >
> >
> > Fine.
>
> Agree.
> >
> >
> >> 17) <!-- [rfced] May we update this text as follows to clarify "its" and
> >> "this"?
> >>
> >> Original:
> >> In-Stack Data: The number of LSEs of in-stack data, if any, and its
> >> encoding. If this is of a variable length, then the solution must
> >> specify how an implementation can determine this length without
> >> implementing the network action.
> >>
> >> Post-Stack Data: The encoding of post-stack data, if any. If this
> >> is of a variable length, then the solution must specify how an
> >> implementation can determine this length without implementing the
> >> network action.
> >>
> >> Perhaps:
> >> In-Stack Data: The number of LSEs of in-stack data, if any, and the
> >> encoding of the in-stack data. If the in-stack data is of a variable
> >> length, then the solution must
> >> specify how an implementation can determine the length without
> >> implementing the network action.
> >>
> >> Post-Stack Data: The encoding of post-stack data, if any. If the
> >> post-stack data
> >> is of a variable length, then the solution must specify how an
> >> implementation can determine the length without implementing the
> >> network action.
> >> -->
> >
> >
> > Sure.
>
> Agree
> >
> >
> >> 18) <!-- [rfced] Would you like the references to be alphabetized
> >> or left in their current order?
> >> -->
> >
> >
> > Your choice. If we have a global preference, I’ve never heard of it.
>
> Anything works. I have a slight preference for references to occur in
> the same order in the dcoument as in the reference list.
>
> >
> >
> >> 19) <!-- [rfced] The following reference appears to point to IEEE Std
> >> 802.1AE with
> >> a date of August 2006. However, that version has been superseded by a new
> >> version dated December 2018. See
> >> https://ieeexplore.ieee.org/document/8585421.
> >>
> >> We have updated this reference entry to current version. Please let us know
> >> if you have any objections.
> >>
> >> Original:
> >> [MACsec] IEEE Computer Society, "IEEE 802.1AE Media Access Control
> >> (MAC) Security", August 2006.
> >>
> >> Updated:
> >> [MACsec] IEEE, "IEEE Standard for Local and metropolitan area
> >> networks-Media Access Control (MAC) Security", IEEE Std
> >> 802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26
> >> December 2018,
> >> <https://ieeexplore.ieee.org/document/8585421>.
> >> -->
> >
> >
> > That’s fine, thank you.
>
> Agree
>
> >
> >
> >> 20) <!-- [rfced] Terminology
> >>
> >> a) If no objections, we will update instances of "sub-stack" (with hyphen)
> >> to
> >> "substack" (no hyphen).
> >>
> >>
> >> b) Please review use of "special label". Should instances of
> >> "special label" be updated to "special-purpose label"?
> >> -->
> >
> >
> > Both are fine.
>
> I actually prefer sub-stack, it is easier to find when reading-
>
> I should definitely be "special-purpose label".
> >
> >
> >
> >> 21) <!-- [rfced] Abbreviations
> >>
> >> a) FYI - We have added expansions for the following abbreviations per
> >> Section
> >> 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
> >> document carefully to ensure correctness.
> >>
> >> Operations, Administration, and Maintenance (OAM)
> >> IP Fast Reroute (IPFRR)
> >> Fast Reroute (FRR)
> >> Label Switching Router (LSR)
> >> Media Access Control Security (MACsec)
> >
> >
> > Ok.
> >
>
> OK fir the first three.
>
> MACsec is a reference identifier, never used as an abbreviation in the
> document. If you want to include I won't fight it, but it seems like a
> bit outside what we uses abbreviations for.
> >
> >> b) Is the abbreviation NAS read as "nass" or as "en-ay-ess"? We ask in
> >> order to
> >> choose the appropriate indefinite article for it to follow. Currently, both
> >> "an NAS" and "a NAS" are used in the document.
> >
> >
> > I don’t think we have any consistency. I personally use “nass”. I was
> > taught that you always use ‘an’ with an abbreviation, but I’ve never liked
> > that.
> >
> With my Swedish background I would do "a NAS", but as always I will
> defer to people with English as their mother-tongue.
> >
> >> c) The following abbreviations appear in the text but do not appear in
> >> Table 1.
> >> Would you like for them to be added to Table 1?
> >>
> >> LSP
> >> TC
> >> TTL
> >
> >
> > Not necessary, IMHO, but not objectionable either. We’ve been using those
> > abbreviations for 25 years...
>
> I'd say include them, as Tony said maybe not necessary, but for
> completeness.
>
> Label Switched Path LSP is not "well-known", there is more than one
> expansion of the abbreviation.
>
> Traffic Class (TC) also have several expansions, so include it.
>
> TTL is wellknown, but I'd prefer to have it in the list.
> >
> >
> >> d) Throughout the document, the expanded form of the following terms are
> >> often
> >> used although the abbreviations are introduced in Section 1. Would you
> >> like to
> >> use the abbreviations after the introduction in Section 1? Or do you
> >> prefer the
> >> current?
> >>
> >> network action sub-stack
> >> post-stack data
> >> ancillary data
> >> Entropy Label
> >> -->
> >
> >
> > Several WG members have requested that we decrease our use of acronyms.
>
> True, but maybe we shold look at this case by case, i.e. I would not
> support changing e.g. all "post-stack data" to PSD, but it might be
> motivated in some cases.
> >
> >
> >
> >> 22) <!-- [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.
> >> —>
> >>
> >
> >
> > No changes.
>
> If I try to do this I will just casue a mess :). No changes needed.
> >
> > Thanks,
> > Tony
>
> /Loa
> >
> >
>
> --
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> l...@pi.nu
> loa.pi....@gmail.com
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
