Hi all, We’d like to check in on this document. We know there has been discussion regarding the definitions in Section 1.2, but we are not sure if a conclusion has been reached. Apologies if we missed anything!
Thank you, RFC Editor/rv > On May 29, 2025, at 12:16 AM, Adrian Farrel <adr...@olddog.co.uk> wrote: > > Hi Loa, > > Document shepherd here. > > Please summarise the problem. In the working copy we have: > > The framework for MPLS Network Actions (MNAs) is described in > [RFC9789] and is an enhancement to the MPLS architecture. The use of > Post-Stack Data (PSD) to encode the MNA indicators and ancillary data > (described in Section 3.6 of [RFC9789]) > > The expansions of both "MNA" and "PSD" seem very clear. And both have > references to RFC 9789. > > I'd note that there is no occurrence of "PSD MNA" in the current text. > > I know that there has been a lot of discussion recently, but I do not see any > tidy conclusion of what the issue is. If you can produce that, I'm sure the > shepherd can work with chairs and AD to work out how to reach a conclusion. > > Thanks, > Adrian > > -----Original Message----- > From: Loa Andersson <l...@pi.nu> > Sent: 29 May 2025 06:06 > To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com>; Alanna Paloma > <apal...@staff.rfc-editor.org>; Greg Mirsky <gregimir...@gmail.com> > Cc: James Guichard <james.n.guich...@futurewei.com>; Kireeti Kompella > <kireeti.i...@gmail.com>; Stewart Bryant <s...@stewartbryant.com>; Jie Dong > <jie.d...@huawei.com>; Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>; > RFC Editor <rfc-edi...@rfc-editor.org>; mpls-...@ietf.org; MPLS Working Group > <mpls-cha...@ietf.org>; Adrian Farrel <adr...@olddog.co.uk>; auth48archive > <auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9790 <draft-ietf-mpls-1stnibble-13> for your > review > > Alana, RFC Editor, co-authors, > > > When I sent th approval mail below I thought that everything that needed > to be updated was captured. > > Since then we have had a discussion on the abbreviation PSD MNA, I still > believe several thing around that abbreviation is unclear and would not > want the draft to go forward before it is cleared out. > > /Loa > > > > Den 22/05/2025 kl. 17:18, skrev Loa Andersson: >> Alana, >> >> Approved. >> >> /Loa >> >> Den 22/05/2025 kl. 17:01, skrev Matthew Bocci (Nokia): >>> Hi Alanna >>> >>> Approved. >>> >>> Matthew >>> >>> *From: *Alanna Paloma <apal...@staff.rfc-editor.org> >>> *Date: *Wednesday, 21 May 2025 at 17:12 >>> *To: *Greg Mirsky <gregimir...@gmail.com> >>> *Cc: *James Guichard <james.n.guich...@futurewei.com>, Kireeti >>> Kompella <kireeti.i...@gmail.com>, Stewart Bryant >>> <s...@stewartbryant.com>, Matthew Bocci (Nokia) >>> <matthew.bo...@nokia.com>, l...@pi.nu <l...@pi.nu>, Jie Dong >>> <jie.d...@huawei.com>, Rebecca VanRheenen <rvanrhee...@staff.rfc- >>> editor.org>, RFC Editor <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org >>> <mpls-...@ietf.org>, MPLS Working Group <mpls-cha...@ietf.org>, Adrian >>> Farrel <adr...@olddog.co.uk>, auth48archive <auth48archive@rfc- >>> editor.org> >>> *Subject: *Re: AUTH48: RFC-to-be 9790 <draft-ietf-mpls-1stnibble-13> >>> 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 Greg, >>> >>> Thank you for your approval. It has been noted on the AUTH48 status page: >>> https://www.rfc-editor.org/auth48/rfc9790 <https://www.rfc-editor.org/ >>> auth48/rfc9790> >>> >>> We will await approvals from Kireeti, Stewart, Matthew, Loa, and Jie >>> prior to moving this document forward in the publication process. >>> >>> Best regards, >>> RFC Editor/ap >>> >>>> On May 20, 2025, at 2:04 PM, Greg Mirsky <gregimir...@gmail.com> wrote: >>>> >>>> Hi Alanna, >>>> Thank you for keeping up with all the updates. I read Loa's latest >>>> update and agree with it. Hence, I agree with all the updates applied >>>> during AUTH48. >>>> Please let me know if you have any further questions. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, May 20, 2025 at 10:40 AM Alanna Paloma <apal...@staff.rfc- >>>> editor.org> wrote: >>>> Hi James, Loa, and other authors, >>>> >>>> James - Thank you for your approval. It has been noted on the AUTH48 >>>> status page: >>>> https://www.rfc-editor.org/auth48/rfc9790 <https://www.rfc-editor.org/ >>> auth48/rfc9790> >>>> >>>> >>>> Authors - We have updated the files per Loa’s updated text (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. >>>> >>>> >>>> — FILES (please refresh) — >>>> >>>> Updated XML file: >>>> https://www.rfc-editor.org/authors/rfc9790.xml <https://www.rfc- >>> editor.org/authors/rfc9790.xml> >>>> >>>> Updated output files: >>>> https://www.rfc-editor.org/authors/rfc9790.txt <https://www.rfc- >>> editor.org/authors/rfc9790.txt> >>>> https://www.rfc-editor.org/authors/rfc9790.pdf <https://www.rfc- >>> editor.org/authors/rfc9790.pdf> >>>> https://www.rfc-editor.org/authors/rfc9790.html <https://www.rfc- >>> editor.org/authors/rfc9790.html> >>>> >>>> Diff file showing all changes made during AUTH48: >>>> https://www.rfc-editor.org/authors/rfc9790-auth48diff.html <https:// >>> www.rfc-editor.org/authors/rfc9790-auth48diff.html> >>>> https://www.rfc-editor.org/authors/rfc9790-auth48rfcdiff.html <https:// >>> www.rfc-editor.org/authors/rfc9790-auth48rfcdiff.html> (side by side) >>>> https://www.rfc-editor.org/authors/rfc9790-lastdiff.html <https:// >>> www.rfc-editor.org/authors/rfc9790-lastdiff.html> (htmlwdiff diff >>> between last version and this) >>>> https://www.rfc-editor.org/authors/rfc9790-lastrfcdiff.html <https:// >>> www.rfc-editor.org/authors/rfc9790-lastrfcdiff.html> (rfcdiff between >>> last version and this) >>>> >>>> Diff files showing all changes: >>>> https://www.rfc-editor.org/authors/rfc9790-diff.html <https://www.rfc- >>> editor.org/authors/rfc9790-diff.html> >>>> https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html <https:// >>> www.rfc-editor.org/authors/rfc9790-rfcdiff.html> (side by side) >>>> https://www.rfc-editor.org/authors/rfc9790-alt-diff.html <https:// >>> www.rfc-editor.org/authors/rfc9790-alt-diff.html> (diff showing >>> changes where text is moved or deleted) >>>> >>>> Best regards, >>>> RFC Editor/ap >>>> >>>>> On May 20, 2025, at 3:09 AM, James Guichard >>>> <james.n.guich...@futurewei.com> wrote: >>>>> >>>>> Approved. >>>>> Jim >>>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>>>> Date: Monday, May 19, 2025 at 4:27 PM >>>>> To: James Guichard <james.n.guich...@futurewei.com>, Greg Mirsky >>>> <gregimir...@gmail.com>, Matthew Bocci (Nokia) <matthew.bo...@nokia.com> >>>>> Cc: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>, Kireeti >>>> Kompella <kireeti.i...@gmail.com>, Stewart Bryant >>>> <s...@stewartbryant.com>, Jie Dong <jie.d...@huawei.com>, >>>> l...@pi.nu<l...@pi.nu>, RFC Editor <rfc-edi...@rfc-editor.org>, mpls- >>>> a...@ietf.org<mpls-...@ietf.org>, MPLS Working Group <mpls- >>>> cha...@ietf.org>, Adrian Farrel >>> <adr...@olddog.co.uk>, auth48archive <auth48archive@rfc-editor.org> >>>>> Subject: [AD] Re: AUTH48: RFC-to-be 9790 <draft-ietf- >>>> mpls-1stnibble-13> for your review >>>>> Hi Matthew, Greg, and James (AD)*, >>>>> >>>>> *James - As the AD, please review and approve of the updated text >>>> and removal of the BCP 14 keyword “MUST”. >>>>> >>>>> Original: >>>>> Post-stack Header (PSH): optional field of interest to the egress >>>>> Label Switching Router (LSR) (and possibly to transit LSRs). >>>>> Examples include a control word [RFC4385], [RFC8964] or an >>>>> associated channel [RFC4385], [RFC5586], [RFC9546]. The PSH MUST >>>>> indicate its length, so that a parser knows where the embedded >>>>> packet starts. >>>>> >>>>> Current: >>>>> Post-Stack Header (PSH): A field containing information that may be >>>>> of interest to the egress Label Switching Router (LSR) or >>>> transit >>>>> LSRs. Examples include a control word [RFC4385] [RFC8964] or an >>>>> associated channel header [RFC4385] [RFC5586] [RFC9546]. A >>>> parser >>>>> needs to be able to determine where the PSH ends in order to >>>> find >>>>> the embedded packet. >>>>> >>>>> See this diff file: >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-ad- >>> diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323372404%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Mn1qJ5aNIhJbyj32kakK9Vd%2FMLL8DRIaX03wI8hAII4%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-ad-diff.html> >>>>> >>>>> >>>>> Authors - Thank you for your replies. We have updated as >>>> requested. We will await any further changes you may have and >>>> approvals from each author >>>>> and *James prior to moving forward in the publication process. >>>>> >>>>> — FILES (please refresh) — >>>>> >>>>> Updated XML file: >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323393490%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RBmYo%2Ft3nBfKzWDlWsC6EDhR5SKWbphgbd4UDJLOACs%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.xml> >>>>> >>>>> Updated output files: >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323410190%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fj96DQft0eI90YG0zx8POcim0kafmeO39Py8Bsmnidk%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.txt> >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323425302%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O9zOXBJqS18BHY2gc5qVBXftXZheTQPkzwfIWfjR6OI%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.pdf> >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323439783%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EH2MUK93taunO23fWXHPWdZ2dnjdsRuisma7P6XqkZ4%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.html> >>>>> >>>>> Diff file showing all changes made during AUTH48: >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> auth48diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323454124%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m7Dhkxsd%2BiQ5jbUMM5nu3Ejtj025uxhbTBu34GAots0%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-auth48diff.html> >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> auth48rfcdiff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323468768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=u7QXcJCSQYoHIgADEyrUAQciGtpemaihm4ec3qfybFs%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-auth48rfcdiff.html> (side by >>> side) >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> lastdiff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323483292%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S%2BBLiKjKhyVzm%2BG5asy7d2Fc%2BkYP6hZLlqQlOJHDb%2Fw%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-lastdiff.html> (htmlwdiff diff >>> between last version and this) >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> lastrfcdiff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323498056%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I9kUzX5YXE%2FCsSicvxQU0VS2xenDQFbi1mOp1N9lQNw%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-lastrfcdiff.html> (rfcdiff >>> between last version and this) >>>>> >>>>> Diff files showing all changes: >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323512751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=obFCGOeTBeFZrZ%2Fp6nPEEOtk4uzo1Tjj1hYEyt9WEdE%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-diff.html> >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> rfcdiff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323527016%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YfpCj94Gj3NT6cArD6PITpapEavuqFwuJ5OwMFqOQPE%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html> (side by side) >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-alt- >>> diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323541323%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NgRtFDscbNBEYiLqDZ3%2FXJ5j7d1X6HDEs%2BHw4fYnokU%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-alt-diff.html> (diff showing >>> changes where text is moved or deleted) >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323560089%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hG%2FK2fw8yqjr01EjWx6FbVXQmbIL8aDfzj0vysq3nf0%3D&reserved=0 >>> <https://www.rfc-editor.org/auth48/rfc9790> >>>>> >>>>> Thank you, >>>>> RFC Editor/ap >>>>> >>>>>> On May 19, 2025, at 9:47 AM, Greg Mirsky <gregimir...@gmail.com> >>>> wrote: >>>>>> >>>>>> Hi Rebecca, >>>>>> I agree with the updates proposed by Matthew. >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> On Mon, May 19, 2025 at 3:17 AM Matthew Bocci (Nokia) >>>> <matthew.bo...@nokia.com> wrote: >>>>>> Hi Rebecca >>>>>> Thanks for the updated Auth48 text. I have a couple of comments. >>>>>> Regards >>>>>> Matthew >>>>>> 1. Introduction: >>>>>> I think PSH in the second sentence should be pluralised: >>>>>> OLD: >>>>>> Examples of PSH include existing artifacts such as control words >>>> [RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296] >>>> and the like, as well as new types of PSH being discussed by the MPLS >>>> Working Group. >>>>>> NEW: >>>>>> Examples of PSHs include existing artifacts such as control words >>>> [RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296] >>>> and the like, as well as new types of PSH being discussed by the MPLS >>>> Working Group. >>>>>> 2.1 Definitions: >>>>>> The definition of PSH is a bit unclear in terms of what it is >>>> referring to for the optional field of interest, and it is also >>>> mandates that the PSH must include a length when in fact most >>>> existing PSHs (such as the PW CW or G-ACH) do not include such a >>>> field. I would propose rephrasing to: >>>>>> OLD: >>>>>> Post-Stack Header (PSH): >>>>>> Optional field of interest to the egress Label Switching Router >>>> (LSR) (and possibly to transit LSRs). Examples include a control word >>>> [RFC4385] [RFC8964] or an associated channel [RFC4385] [RFC5586] >>>> [RFC9546]. The PSH MUST indicate its length, so that a parser knows >>>> where the embedded packet starts. >>>>>> NEW: >>>>>> Post-Stack Header (PSH): >>>>>> A field containing information which may be of interest to the >>>> egress Label Switching Router (LSR) or transit LSRs. Examples include >>>> a control word [RFC4385] [RFC8964] or an associated channel header >>>> [RFC4385] [RFC5586] [RFC9546]. A parser needs to be able to determine >>>> where the PSH ends in order to find the embedded packet. >>>>>> Best regards, >>>>>> Matthew >>>>>> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> >>>>>> Date: Thursday, 15 May 2025 at 22:01 >>>>>> To: Greg Mirsky <gregimir...@gmail.com>, Kireeti Kompella >>>> <kireeti.i...@gmail.com>, Stewart Bryant <s...@stewartbryant.com>, >>>> Matthew Bocci (Nokia) <matthew.bo...@nokia.com>, Jie Dong >>>> <jie.d...@huawei.com>, l...@pi.nu <l...@pi.nu> >>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org >>>> <mpls-...@ietf.org>, MPLS Working Group <mpls-cha...@ietf.org>, >>>> Adrian Farrel <adr...@olddog.co.uk>, James Guichard >>>> <james.n.guich...@futurewei.com>, auth48archive <auth48archive@rfc- >>>> editor.org> >>>>>> Subject: Re: AUTH48: RFC-to-be 9790 <draft-ietf- >>>> mpls-1stnibble-13> for your review >>>>>> [You don't often get email from rvanrhee...@staff.rfc-editor.org. >>>> Learn why this is important at https://aka.ms/ >>>> LearnAboutSenderIdentification <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 Greg and other authors, >>>>>> >>>>>> Greg - Thank you for addressing all of our questions! We have >>>> updated the document accordingly. >>>>>> >>>>>> All - Please review the document carefully to ensure satisfaction >>>> as we do not make changes once it has been published as an RFC. >>>> Contact us with any further updates or with your approval of the >>>> document in its current form. We will await approvals from each >>>> author prior to moving forward in the publication process. >>>>>> >>>>>> — FILES (please refresh) — >>>>>> >>>>>> Updated XML file: >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323580473%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yDNy3QEqoveZBJq0GSejSlP2GNq%2FQ8YFJ0II5smsvEg%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.xml> >>>>>> >>>>>> Updated output files: >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323599915%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CTRqZPNHQPlEss0V1mHyXtcGFFMeCqUOOg68zi2avW8%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.txt> >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323619271%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Woob8OVRyugHw8Zz5gnuh9mgAlFGiLqHBj%2FKwb9Rkxc%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.pdf> >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323638798%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fnT5qcPz5154N1I3Lj0NmUZCoRLBDYA1%2BwnKtasL5nM%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.html> >>>>>> >>>>>> Diff file showing all changes made during AUTH48: >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> auth48diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323657961%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P0HIxhZm5eXvcdwE7jJmKBnTy8Ol%2B2IGxAFgDeU4Zm4%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-auth48diff.html> >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> auth48rfcdiff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323672591%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rhETRCSOf8ypvKGV32KcIGz3YXbpp81CqymxAnxrR4w%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-auth48rfcdiff.html> (side by >>> side) >>>>>> >>>>>> Diff files showing all changes: >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323687123%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N5M%2B7BJ6TGX%2BvmJq2F44ZdoJqE5NL%2BNlGuyY%2BK1T1JA%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-diff.html> >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> rfcdiff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323860235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QhW0yTrpZVAwFgsTUDrF6oMRQ6aOw1uVPElortE0g9Q%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html> (side by side) >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-alt- >>> diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323877348%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2cnulI1GBGxGlS65hjriEUDaYr%2BoG5N3kpnNNQ8aEYs%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-alt-diff.html> (diff showing >>> changes where text is moved or deleted) >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323891853%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aURgAcuCaC3udJd1r2VyQZ6xps5xK9JLJpvorNdu8e0%3D&reserved=0 >>> <https://www.rfc-editor.org/auth48/rfc9790> >>>>>> >>>>>> Thank you, >>>>>> >>>>>> RFC Editor/rv >>>>>> >>>>>> >>>>>> >>>>>>> On May 14, 2025, at 4:41 PM, Greg Mirsky >>>> <gregimir...@gmail.com> wrote: >>>>>>> >>>>>>> Dear RFC Editor, >>>>>>> thank you for your help in improving this document. Please find >>>> my notes below tagged GIM>>. >>>>>>> >>>>>>> Regards, >>>>>>> Greg >>>>>>> >>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>>> Date: Wednesday, 14 May 2025 at 05:24 >>>>>>> To: kireeti.i...@gmail.com <kireeti.i...@gmail.com>, >>>> s...@stewartbryant.com<s...@stewartbryant.com>, Matthew Bocci (Nokia) >>>> <matthew.bo...@nokia.com>, gregimir...@gmail.com >>>> <gregimir...@gmail.com>, l...@pi.nu <l...@pi.nu>, jie.d...@huawei.com >>>> <jie.d...@huawei.com> >>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>>> mpls-...@ietf.org<mpls-...@ietf.org>, mpls-cha...@ietf.org <mpls- >>>> cha...@ietf.org>, adr...@olddog.co.uk <adr...@olddog.co.uk>, >>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, >>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9790 <draft-ietf- >>>> mpls-1stnibble-13> 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Authors, >>>>>>> >>>>>>> While reviewing this document during AUTH48, please resolve (as >>>> necessary) the following questions, which are also in the XML file. >>>>>>> >>>>>>> 1) <!-- [rfced] Please note that the abbreviated title of the >>>> document has been >>>>>>> updated as follows. The abbreviated title only appears in the >>>> running >>>>>>> header in the pdf output. >>>>>>> >>>>>>> Original: >>>>>>> 1st nibble >>>>>>> >>>>>>> Current: >>>>>>> First Nibble Following Label Stack >>>>>>> GIM>> Thank you; I agree. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>> appear in >>>>>>> the title) for use on https:// >>>> eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fsearch&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323906142%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gJM%2FVuM5%2F%2BeT7ejIc64liY0F0mUyZoptsIG7t%2FptpbA%3D&reserved=0 >>> <https://www.rfc-editor.org/search>. --> >>>>>>> GIM>> Perhaps >>>>>>> Post-stack header >>>>>>> Load-balancing >>>>>>> >>>>>>> >>>>>>> 3) <!-- [rfced] Please clarify "in the context associated". >>>> Note that there >>>>>>> is a similar sentence in the IANA section. >>>>>>> >>>>>>> Original: >>>>>>> Although some existing network >>>>>>> devices may use such a method, it needs to be stressed that the >>>>>>> correct interpretation of the Post-stack First Nibble (PFN) >>>> in a PSH >>>>>>> can be made only in the context associated using the control or >>>>>>> management plane with the Label Stack Element (LSE) or group >>>> of LSEs >>>>>>> in the preceding label stack that characterize the type of >>>> the PSH, >>>>>>> and that any attempt to rely on the value in any other >>>> context is >>>>>>> unreliable. >>>>>>> >>>>>>> Perhaps: >>>>>>> Although some existing network >>>>>>> devices may use such a method, it needs to be stressed that the >>>>>>> correct interpretation of the Post-stack First Nibble (PFN) >>>> in a PSH >>>>>>> can be made only in the context of using the control or >>>>>>> management plane with the Label Stack Entry (LSE) or group >>>> of LSEs >>>>>>> in the preceding label stack that characterizes the type of >>>> the PSH. >>>>>>> Any attempt to rely on the value in any other context is >>>>>>> unreliable. >>>>>>> >>>>>>> Or (similar to sentence in IANA section): >>>>>>> Although some existing network >>>>>>> devices may use such a method, it needs to be stressed that the >>>>>>> correct interpretation of the Post-stack First Nibble (PFN) >>>> in a PSH >>>>>>> can be made only in the context of the Label Stack Entry >>>> (LSE) or group of LSEs >>>>>>> in the preceding label stack that characterizes the type of >>>> the PSH. >>>>>>> Any attempt to rely on the value in any other context is >>>>>>> unreliable. >>>>>>> GIM>> Thank you for your creative options. I will propose >>>> another re-wording using the first option with s/of using/established >>>> through/: >>>>>>> Although some existing network >>>>>>> devices may use such a method, it needs to be stressed that the >>>>>>> correct interpretation of the Post-stack First Nibble (PFN) >>>> in a PSH >>>>>>> can be made only in the context established through the >>>> control or >>>>>>> management plane with the Label Stack Entry (LSE) or group >>>> of LSEs >>>>>>> in the preceding label stack that characterizes the type of >>>> the PSH. >>>>>>> Any attempt to rely on the value in any other context is >>>>>>> unreliable. --> >>>>>>> >>>>>>> >>>>>>> 4) <!-- [rfced] How may we update the text starting with >>>> "including..." to >>>>>>> improve clarity? >>>>>>> >>>>>>> Original: >>>>>>> * To stress the importance that any MPLS packet not >>>> carrying plain >>>>>>> IPv4 or IPv6 packets contains a PSH, including any new >>>> version of >>>>>>> IP (Section 2.4). >>>>>>> >>>>>>> Perhaps: >>>>>>> * To stress that any MPLS packet not carrying plain >>>>>>> IPv4 or IPv6 packets contains a PSH. This also applies to >>>> packets of >>>>>>> any new version of IP (see Section 2.4). >>>>>>> GIM>> Excellent! I agree. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 5) <!-- [rfced] The sentences below are from the last two >>>> paragraphs of Section 1. >>>>>>> In the first sentence, will readers understand what is meant by >>>> "the >>>>>>> heuristic"? Would it be helpful to add more context, like that >>>> included >>>>>>> in the second sentence? >>>>>>> >>>>>>> Original: >>>>>>> Based on the analysis of load-balancing techniques in >>>> Section 2.1.1, >>>>>>> this document, in Section 2.1.1.1, introduces a requirement >>>> that >>>>>>> deprecates the use of the heuristic and recommends using a >>>> dedicated >>>>>>> label value for load balancing. >>>>>>> ... >>>>>>> Furthermore, this document updates [RFC4928] by deprecating the >>>>>>> heuristic method for identifying the type of packet >>>> encapsulated in >>>>>>> MPLS. >>>>>>> >>>>>>> Perhaps: >>>>>>> Section 2.1.1 of this document includes an analysis of load- >>>> balancing >>>>>>> techniques; based on this, Section 2.1.1.1 introduces a >>>> requirement >>>>>>> that deprecates the use of the heuristic method for >>>> identifying the type >>>>>>> of packet encapsulated in MPLS and recommends using a >>>>>>> dedicated label value for load balancing. >>>>>>> ... >>>>>>> Furthermore, this document updates [RFC4928] by deprecating >>>> this >>>>>>> heuristic method. >>>>>>> GIM>> I like the proposed update of the first paragraph. Since >>>> it is followed by two sentences, would "this heuristic method" >>>> reference be clear to a reader? Would keeping that part unchanged be >>>> acceptable? >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 6) <!-- [rfced] Would you like to alphabetize the list of >>>> abbreviations in Section 1.3 >>>>>>> ("Abbreviations")? Or do you prefer the current order? >>>>>>> >>>>>>> Similarly, would you like to alphabetize the terms in Section 1.2 >>>>>>> ("Definitions") or keep the current order? >>>>>>> GIM>> Yes, alphabetize them, please. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 7) <!-- [rfced] We updated this text as shown below. >>>> Specifically, we moved the >>>>>>> third sentence of the first paragraph to follow the list and >>>> updated "A." >>>>>>> to read "Example A:". Let us know any concerns. >>>>>>> >>>>>>> Original: >>>>>>> Figure 1 shows an MPLS packet with Layer 2 header X and a >>>> label stack >>>>>>> Y ending with Label-n. Then, there are three examples of an >>>> MPLS >>>>>>> payload displayed in Figure 2. The complete MPLS packet >>>> thus would >>>>>>> consist of [X Y A], or [X Y B], or [X Y C]. >>>>>>> >>>>>>> A. The first payload is a bare IP packet, i.e., no PSH. >>>> The PFN in >>>>>>> this case overlaps with the IP version number. >>>>>>> >>>>>>> B. The next payload is a bare non-IP packet; again, no >>>> PSH. The PFN >>>>>>> here is the first nibble of the payload, whatever it happens >>>> to be. >>>>>>> >>>>>>> C. The last example is an MPLS Payload that starts with a PSH >>>>>>> followed by the embedded packet. Here, the embedded packet >>>> could be >>>>>>> IP or non-IP. >>>>>>> >>>>>>> Updated: >>>>>>> Figure 1 shows an MPLS packet with a Layer 2 header X and a >>>> label stack >>>>>>> Y ending with Label-n. Figure 2 displays three examples of an >>>>>>> MPLS payload: >>>>>>> >>>>>>> Example A: The first payload is a bare IP packet, i.e., no >>>> PSH. The >>>>>>> PFN in this case overlaps with the IP version number. >>>>>>> >>>>>>> Example B: The next payload is a bare non-IP packet; again, >>>> no PSH. >>>>>>> The PFN here is the first nibble of the payload, whatever it >>>>>>> happens to be. >>>>>>> >>>>>>> Example C: This example is an MPLS Payload that starts with >>>> a PSH >>>>>>> followed by the embedded packet. Here, the embedded >>>> packet could >>>>>>> be IP or non-IP. >>>>>>> >>>>>>> Thus, the complete MPLS packet would consist of [X Y A], [X >>>> Y B], or >>>>>>> [X Y C]. >>>>>>> GIM>> Thank you for your updates that improve readability of >>>> the document. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 8) <!-- [rfced] For readability, may we update this list as >>>> follows? >>>>>>> >>>>>>> Original: >>>>>>> There are four common ways to load balance an MPLS packet: >>>>>>> >>>>>>> 1. One can use the top label alone. >>>>>>> >>>>>>> 2. One can do better by using all of the non-SPLs (Special >>>> Purpose >>>>>>> Labels) [RFC7274] in the stack. >>>>>>> >>>>>>> 3. One can do even better by "divining" the type of >>>> embedded packet, >>>>>>> and using fields from the guessed header. The >>>> ramifications of >>>>>>> using this load-balancing technique are discussed in >>>> detail in >>>>>>> Section 2.1.1.1. >>>>>>> >>>>>>> 4. One can do best by using either an Entropy Label >>>> [RFC6790] or a >>>>>>> Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see >>>>>>> Section 2.1.1.1). >>>>>>> >>>>>>> Perhaps: >>>>>>> There are four common ways to load balance an MPLS packet: >>>>>>> >>>>>>> 1. Use the top label alone. >>>>>>> >>>>>>> 2. Use all of the non-SPLs (Special Purpose >>>>>>> Labels) [RFC7274] in the stack. This is better than >>>> using the >>>>>>> top label alone. >>>>>>> >>>>>>> 3. Divine the type of embedded packet >>>>>>> and use fields from the guessed header. The >>>> ramifications of >>>>>>> using this load-balancing technique are discussed in >>>> detail in >>>>>>> Section 2.1.1.1. This way is better than the two ways >>>> above. >>>>>>> >>>>>>> 4. Use either an Entropy Label [RFC6790] or a >>>>>>> Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see >>>>>>> Section 2.1.1.1). This is the best way. >>>>>>> GIM>> I agree with the proposed updates with a suggestion to >>>> maintain quotation marks as "divine". >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 9) <!-- [rfced] Would including some text to introduce the >>>> numbered list in >>>>>>> Section 2.1.1.1 be helpful? If so, please provide the text. >>>>>>> GIM>> I think that the current text is sufficient but I am open >>>> to any text other authors propose. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 10) <!-- [rfced] Would it be helpful to update "Support for" to >>>> "The framework >>>>>>> for" in this sentence? >>>>>>> >>>>>>> Original: >>>>>>> Support for MPLS Network Actions (MNAs) is described in >>>>>>> [I-D.ietf-mpls-mna-fwk] and is an enhancement to the MPLS >>>>>>> architecture. >>>>>>> >>>>>>> Perhaps: >>>>>>> The framework for MPLS Network Actions (MNAs) is described >>>> in [RFC9789] and >>>>>>> is an enhancement to the MPLS architecture. >>>>>>> GIM>> I agree with the proposed change. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 11) <!-- [rfced] This sentence notes that the PFN value of 0x0 >>>> has two different >>>>>>> formats, but the IANA registry in Section 3 lists the value 0x0 >>>> three >>>>>>> times. Please review and let us know if any updates are needed. >>>>>>> >>>>>>> Original: >>>>>>> This issue is described in section 3.6.1 of [I-D.ietf-mpls- >>>> mna-fwk] >>>>>>> and is further illustrated by the PFN value of 0x0 which has >>>> two >>>>>>> different formats depending on whether the PSH is a pseudowire >>>>>>> control word or a DetNet control word ... >>>>>>> GIM>> Your observation is correct. Value 0x0 is used by three >>>> services that are listed in the IANA registry in Section 3. But two >>>> of these services use four-octet long format, while one - eight-octet >>>> long format. Thus, three entries in the registry but only two formats. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 12) <!-- [rfced] How may we clarify "leading to [RFC4928]"? >>>>>>> >>>>>>> Original: >>>>>>> It was then discovered that >>>>>>> non-IP packets, misidentified as IP when the heuristic >>>> failed, were >>>>>>> being badly load balanced, leading to [RFC4928]. >>>>>>> >>>>>>> Perhaps: >>>>>>> It was then discovered that >>>>>>> non-IP packets, misidentified as IP when the heuristic >>>> failed, were >>>>>>> being badly load-balanced, leading to the scenario described >>>> in [RFC4928]. >>>>>>> GIM>> Thank you for your creative editing! I agree with the >>>> proposed update. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 13) <!-- [rfced] What does "it" refer to here? >>>>>>> >>>>>>> Original: >>>>>>> It would assist with the progress toward a simpler, more >>>> coherent >>>>>>> system of MPLS data encapsulation if the use a PSH for non-IP >>>>>>> payloads encapsulated in MPLS was obsoleted. >>>>>>> >>>>>>> Perhaps: >>>>>>> If the use a PSH for non-IP >>>>>>> payloads encapsulated in MPLS were obsoleted, this would >>>> assist with >>>>>>> the progress toward a simpler, more coherent >>>>>>> system of MPLS data encapsulation >>>>>>> >>>>>>> Or: >>>>>>> Obsoleting the use a PSH for non-IP >>>>>>> payloads encapsulated in MPLS would assist with the progress >>>> toward a simpler, more coherent >>>>>>> system of MPLS data encapsulation. >>>>>>> GIM>> Thank you for proposing two excellent options.I slightly >>>> prefer the second with a minor modification (two options ;-) : >>>>>>> s/the use a PSH/the use of a PSH/ or s/the use a PSH/using a PSH/ >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 14) <!-- [rfced] Please review "to load-balancing MPLS data >>>> flows". Should the >>>>>>> "load balance" be used instead of the "load-balancing"? Or >>>>>>> is the current correct? >>>>>>> >>>>>>> Original: >>>>>>> However, before that >>>>>>> can be done, it is important to collect sufficient evidence >>>> that >>>>>>> there are no marketed or deployed implementations using the >>>> heuristic >>>>>>> practice to load-balancing MPLS data flows. >>>>>>> >>>>>>> Perhaps: >>>>>>> However, before that >>>>>>> can be done, it is important to collect sufficient evidence >>>> that >>>>>>> there are no marketed or deployed implementations using the >>>> heuristic >>>>>>> practice to load balance MPLS data flows. >>>>>>> GIM>> I think that the current form is acceptable. What do >>>> other authors think? >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 15) <!-- [rfced] We removed the expansion "Network Service >>>> Header" in Table 1 as >>>>>>> this is expanded previously in the document. If no objections, >>>> we will >>>>>>> ask IANA to update the "Post-Stack First Nibble" registry >>>> accordingly >>>>>>> prior to publication. >>>>>>> >>>>>>> Link to registry: https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fpost-stack-first- >>> nibble&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323920690%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NE59kFQyMShjMkOEIgC1BVvn0%2BX%2FGHALYGJHSSLgxYk%3D&reserved=0 >>> <https://www.iana.org/assignments/post-stack-first-nibble> >>>>>>> >>>>>>> Original: >>>>>>> | NSH | 0x0 | NSH (Network Service Header) >>>>>>> | | | Base Header, payload >>>>>>> >>>>>>> Current: >>>>>>> | NSH | 0x0 | NSH Base Header, paylod >>>>>>> GIM>> I agree; your update makes the table easier to read. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 16) <!-- [rfced] Abbreviations >>>>>>> >>>>>>> a) FYI - We updated the expansion for LSE as follows to align >>>> with the >>>>>>> expansion used in RFCs-to-be 9789 and 9791. Also, "Label Stack >>>> Element" has >>>>>>> not been used in published RFCs. >>>>>>> >>>>>>> Original: >>>>>>> Label Stack Element >>>>>>> >>>>>>> Updated: >>>>>>> Label Stack Entry >>>>>>> GIM>> Great catch, thank you. I agree. >>>>>>> >>>>>>> >>>>>>> b) 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. >>>>>>> >>>>>>> Deterministic Networking (DetNet) >>>>>>> Virtual Private LAN Service (VPLS) >>>>>>> Media Access Control (MAC) >>>>>>> GIM>> Thank you for your thorough work with the document. I agree. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 17) <!-- [rfced] Please review the "Inclusive Language" portion >>>> of the online >>>>>>> Style Guide <https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323935176%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sWmXtEqoJOnM0ja8DqcHx40ca1bDNKf8BONOCNFjUmY%3D&reserved=0 >>> <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. >>>>>>> GIM>> Thank you for checking that. I couldn't find anything >>>> that raises a red flag. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> RFC Editor/rv >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 13, 2025, at 9:19 PM, rfc-edi...@rfc-editor.org wrote: >>>>>>> >>>>>>> *****IMPORTANT***** >>>>>>> >>>>>>> Updated 2025/05/13 >>>>>>> >>>>>>> RFC Author(s): >>>>>>> -------------- >>>>>>> >>>>>>> Instructions for Completing AUTH48 >>>>>>> >>>>>>> Your document has now entered AUTH48. Once it has been >>>> reviewed and >>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>> If an author is no longer available, there are several remedies >>>>>>> available as listed in the FAQ (https:// >>>> eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Ffaq%2F&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323949688%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RLBjJTE4I4AJ%2FqBg11yB6gwO6rskbrgvz%2Fomjq0TCV8%3D&reserved=0 >>> <https://www.rfc-editor.org/faq/>). >>>>>>> >>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>> (e.g., Contributors or Working Group) as necessary before >>>> providing >>>>>>> your approval. >>>>>>> >>>>>>> Planning your review >>>>>>> --------------------- >>>>>>> >>>>>>> Please review the following aspects of your document: >>>>>>> >>>>>>> * RFC Editor questions >>>>>>> >>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>> that have been included in the XML file as comments marked as >>>>>>> follows: >>>>>>> >>>>>>> <!-- [rfced] ... --> >>>>>>> >>>>>>> These questions will also be sent in a subsequent email. >>>>>>> >>>>>>> * Changes submitted by coauthors >>>>>>> >>>>>>> Please ensure that you review any changes submitted by your >>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>> agree to changes submitted by your coauthors. >>>>>>> >>>>>>> * Content >>>>>>> >>>>>>> Please review the full content of the document, as this cannot >>>>>>> change once the RFC is published. Please pay particular >>>> attention to: >>>>>>> - IANA considerations updates (if applicable) >>>>>>> - contact information >>>>>>> - references >>>>>>> >>>>>>> * Copyright notices and legends >>>>>>> >>>>>>> Please review the copyright notice and legends as defined in >>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>> (TLP – https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Ftrustee.ietf.org%2Flicense- >>> info&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323963961%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BeuH8JhFr%2FtfsIY4PJ9EGoAonZcJ6L0JCJuFwqjmdp0%3D&reserved=0) >>> <https://trustee.ietf.org/license-info>. >>>>>>> >>>>>>> * Semantic markup >>>>>>> >>>>>>> Please review the markup in the XML file to ensure that >>>> elements of >>>>>>> content are correctly tagged. For example, ensure that >>>> <sourcecode> >>>>>>> and <artwork> are set correctly. See details at >>>>>>> <https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml- >>> vocabulary&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323978301%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y%2BWD2YSgCb8fodIV86eWe9pNxPNkL2Qg%2B%2FoMHtXTWsM%3D&reserved=0 >>> <https://authors.ietf.org/rfcxml-vocabulary>>. >>>>>>> >>>>>>> * Formatted output >>>>>>> >>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>> formatted output, as generated from the markup in the XML >>>> file, is >>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>> limitations compared to the PDF and HTML. >>>>>>> >>>>>>> >>>>>>> Submitting changes >>>>>>> ------------------ >>>>>>> >>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ >>>> as all >>>>>>> the parties CCed on this message need to see your changes. The >>>> parties >>>>>>> include: >>>>>>> >>>>>>> * your coauthors >>>>>>> >>>>>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>>>>> >>>>>>> * other document participants, depending on the stream (e.g., >>>>>>> IETF Stream participants are your working group chairs, the >>>>>>> responsible ADs, and the document shepherd). >>>>>>> >>>>>>> * auth48archive@rfc-editor.org, which is a new archival >>>> mailing list >>>>>>> to preserve AUTH48 conversations; it is not an active >>>> discussion >>>>>>> list: >>>>>>> >>>>>>> * More info: >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf- >>> announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407323992672%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sXOq7N0XjYNi933UhG6EaZs21xr08mx00hf70P7vadM%3D&reserved=0 >>> >>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> >>>>>>> >>>>>>> * The archive itself: >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324007231%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nWCeHJyAb323JepZtsTCb8ZTavnGzTk6JTC%2BBox9zhs%3D&reserved=0 >>> <https://mailarchive.ietf.org/arch/browse/auth48archive/> >>>>>>> >>>>>>> * Note: If only absolutely necessary, you may temporarily >>>> opt out >>>>>>> of the archiving of messages (e.g., to discuss a >>>> sensitive matter). >>>>>>> If needed, please add a note at the top of the message >>>> that you >>>>>>> have dropped the address. When the discussion is concluded, >>>>>>> auth48archive@rfc-editor.org will be re-added to the CC >>>> list and >>>>>>> its addition will be noted at the top of the message. >>>>>>> >>>>>>> You may submit your changes in one of two ways: >>>>>>> >>>>>>> An update to the provided XML file >>>>>>> — OR — >>>>>>> An explicit list of changes in this format >>>>>>> >>>>>>> Section # (or indicate Global) >>>>>>> >>>>>>> OLD: >>>>>>> old text >>>>>>> >>>>>>> NEW: >>>>>>> new text >>>>>>> >>>>>>> You do not need to reply with both an updated XML file and an >>>> explicit >>>>>>> list of changes, as either form is sufficient. >>>>>>> >>>>>>> We will ask a stream manager to review and approve any changes >>>> that seem >>>>>>> beyond editorial in nature, e.g., addition of new text, >>>> deletion of text, >>>>>>> and technical changes. Information about stream managers can >>>> be found in >>>>>>> the FAQ. Editorial changes do not require approval from a >>>> stream manager. >>>>>>> >>>>>>> >>>>>>> Approving for publication >>>>>>> -------------------------- >>>>>>> >>>>>>> To approve your RFC for publication, please reply to this email >>>> stating >>>>>>> that you approve this RFC for publication. Please use ‘REPLY >>>> ALL’, >>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>> >>>>>>> >>>>>>> Files >>>>>>> ----- >>>>>>> >>>>>>> The files are available here: >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324024387%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=W2%2FmMJndix8teBEpynxM8PY9lkIe3JEnySi5YBgAZbc%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.xml> >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324044443%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=t7PBUv3rMmcgLDcmSDORDh2Py%2B%2BPZzvj28TrmeFMB%2Fg%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.html> >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324059716%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f0bBTHfTJ3a%2FffwvlOgcKbS5l5frUj7JXfYGHpZ%2B0BI%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.pdf> >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324074544%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vqfCHxYCx4M7Q4nur5dSKP60V2WuEAyoV3MAVX%2F%2BCJw%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790.txt> >>>>>>> >>>>>>> Diff file of the text: >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324089010%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=L6qIiHtm40PaY1Jiv9wjFU6MzVPZyJ2S4bJqm5dI2H0%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-diff.html> >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> rfcdiff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324103521%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nt8ZRBnnvmdIJzPJ6eDPLZefJ7c9QyI8uQ0cgd3mkkY%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html> (side by side) >>>>>>> >>>>>>> Alt-diff of the text (allows you to more easily view changes >>>>>>> where text has been deleted or moved): >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-alt- >>> diff.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324118010%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4PwuinPoYSZy%2FbW3v1%2BSSEk2sVhCZm1GPtOHqly9Guk%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-alt-diff.html> >>>>>>> >>>>>>> Diff of the XML: >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790- >>> xmldiff1.html&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324132815%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FaGqOTzbkhRrBDgwFLw0frbS19m5j7a7qK0k0R%2BRBBk%3D&reserved=0 >>> <https://www.rfc-editor.org/authors/rfc9790-xmldiff1.html> >>>>>>> >>>>>>> >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> https://eur03.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fwww.rfc- >>> editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cmatthew.bocci%40nokia.com%7C4d4c9e69f91348af67e708dd988229d8%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638834407324147131%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LsyyQHXwo9BiHMje%2Ftw33jP16Yn9cv2P2%2Bk4ewEX11A%3D&reserved=0 >>> <https://www.rfc-editor.org/auth48/rfc9790> >>>>>>> >>>>>>> Please let us know if you have any questions. >>>>>>> >>>>>>> Thank you for your cooperation, >>>>>>> >>>>>>> RFC Editor >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC9790 (draft-ietf-mpls-1stnibble-13) >>>>>>> >>>>>>> Title : IANA Registry and Processing Recommendations >>>> for the First Nibble Following a Label Stack >>>>>>> Author(s) : K. Kompella, S. Bryant, M. Bocci, G. Mirsky, >>>> L. Andersson, J. Dong >>>>>>> WG Chair(s) : Tarek Saad, Tony Li, Adrian Farrel >>>>>>> >>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van >>>> de Velde >>>> >>>> >>> >> > > -- > 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
