Hi Loa and other authors, Thank you for your reply. We have updated the files accordingly.
Please note that we are awaiting word from Stewart and/or Matthew regarding the question below. > 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. > — 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) https://www.rfc-editor.org/authors/rfc9789-lastdiff.html (htmlwdiff diff between last version and this) https://www.rfc-editor.org/authors/rfc9789-lastrfcdiff.html (rfcdiff between last version and this) 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/ap > On May 17, 2025, at 4:27 AM, Loa Andersson <l...@pi.nu> wrote: > > Rebecca, > > Let me forst say, that whenever wqe are discussing something that is > primarily "English grammar" just tell me so and I will most of the time I > will defer. My knowledge of English grammar is not good enough to stand up in > that type of discussion. > > More inline. > > Den 17/05/2025 kl. 11:27, skrev Rebecca VanRheenen: >> 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) > > With the explanation above and understanding that there are more than one > MNA, I would prefer "both plural" and ending with Framework, i.e. "MPLS > Network Actions (MNAs) Framework". > >> 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. > This works for me. >> 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. > > OK. > >> >>>> 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”). > > While I cna understand where Chicago Manual of Style are coming from, at > least in our context "sub-stack" is a new word that we created, it stands > out better with the hyphen, unless my co-authors have a different opinion I'd > be happy to stay with the hyphen. > > /Loa >> — 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 > > -- > 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
