Hi Loa and Matthew, You approvals have been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9789
Once we receive Stewart’s approval, we will move this document forward in the publication process. Thank you, RFC Editor/ap > On May 22, 2025, at 3:08 AM, Matthew Bocci (Nokia) <matthew.bo...@nokia.com> > wrote: > > Alanna > Thanks for the updates. > I approve. > Best regards > Matthew > From: Alanna Paloma <apal...@staff.rfc-editor.org> > Date: Tuesday, 20 May 2025 at 18:09 > To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com> > Cc: Loa Andersson <l...@pi.nu>, Stewart Bryant <s...@stewartbryant.com>, Tony > Li <tony...@tony.li>, 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 athttps://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 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 athttps://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
