Approved. T
> On May 20, 2025, at 10:06 AM, Alanna Paloma - apaloma at staff.rfc-editor.org > <mailforwa...@cloudmails.net> wrote: > > Hi Matthew, > > Thank you for your input. We have updated the files accordingly (see below). > > We will await approvals from each party listed on the AUTH48 status page > prior to moving this document forward in the publication process: > https://www.rfc-editor.org/auth48/rfc9789 > > > — 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) > > Best regards, > RFC Editor/ap > >> On May 20, 2025, at 2:08 AM, Matthew Bocci (Nokia) <matthew.bo...@nokia.com> >> wrote: >> >> Hi All >> I think it is trying to say that the payload is a packet with a header that >> includes a PW control word. If I read the suggested text below, it could be >> interpreted as saying the payload is *only* a header. >> Maybe?: >> “However, the BIER approach meets the design goal of [RFC8296] to determine >> that the payload is IPv4, IPv6, or a packet with a header that includes a >> pseudowire control word.” >> >> Regards >> Matthew >> From: Alanna Paloma <apal...@staff.rfc-editor.org> >> Date: Monday, 19 May 2025 at 21:26 >> To: Loa Andersson <l...@pi.nu>, Stewart Bryant <s...@stewartbryant.com>, >> Matthew Bocci (Nokia) <matthew.bo...@nokia.com>, Tony Li <tony...@tony.li> >> Cc: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>, RFC Editor >> <rfc-edi...@rfc-editor.org>, 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 >> [You don't often get email from apal...@staff.rfc-editor.org. Learn why this >> is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> 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 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
