Authors, All of the documents in cluster 520 (https://www.rfc-editor.org/cluster_info.php?cid=C520) have now completed AUTH48.
We will begin to do our final checks and move this document forward in the publication process at this time. Thank you, RFC Editor/rv > On Jun 2, 2025, at 10:28 AM, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > > Hi Stewart and other authors, > > Stewart - We marked your approval on the AUTH48 status page for this > document: https://www.rfc-editor.org/auth48/rfc9789. > > All - We have now received all necessary approvals and consider AUTH48 > complete. Thank you for your attention and guidance during the AUTH48 > process. > > We will begin to prepare this document for publication, but note that it will > be published at the same time as the other two documents in cluster 520. For > details of the status of each document in cluster 520, please see > https://www.rfc-editor.org/auth48/C520. > > Best regards, > RFC Editor/rv > > > >> On May 30, 2025, at 7:33 AM, Stewart Bryant <s...@stewartbryant.com> wrote: >> >> I am sorry for the delay. >> >> I have read the latest version of the text and I am content for it to >> proceed to publication. >> >> Stewart >> >>> On 19 May 2025, at 21:25, Alanna Paloma <apal...@staff.rfc-editor.org> >>> wrote: >>> >>> 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
