Hi Loa, Thank you for the update!
Best regards, RFC Editor/rv > On Jun 11, 2025, at 1:02 AM, Loa Andersson <l...@pi.nu> wrote: > > Rebecca, > > There is a discussion at least among some of the authors and the document > shepherd about what we need to say about "MLPL Payload" and the capabilities > of a post-stack parser. > > The discussion seem to have stalled, I have sent mails to remind. > > As son as we converged on this I will approve publication. > > /Loa > > Den 10/06/2025 kl. 23:16, skrev Rebecca VanRheenen: >> 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 >>> > > -- > 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