Hi Matthew, Loa, Jie, and James (AD)*,
*James - As the AD, please review and approve of the definitions updated by Jie.
Original:
Label Stack: For an MPLS packet, all labels (four-octet fields)
after the Layer 2 header, up to and including the label with the
Bottom of Stack bit set [RFC3032].
MPLS Payload: All data after the label stack, including the PFN, an
optional post-stack header, and the embedded packet.
Current:
Label Stack: A label stack is represented as a consecutive sequence
of "label stack entries (four-octet fields)" after the Layer 2
header but before any network layer header. The last label stack
entry of a label stack has its Bottom of Stack bit set.
MPLS Payload: All data after the label stack and the optional Post-
Stack header.
See this diff:
https://www.rfc-editor.org/authors/rfc9790-ad-diff.html
Authors - We have noted Matthew’s and Loa’s approvals on the AUTH48 status
page. Additionally, we have updated the files with the new definitions
suggested by Jie.
— FILES (please refresh) —
Updated XML file:
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.pdf
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-auth48rfcdiff.html (side by side)
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 (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-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9790-alt-diff.html (diff showing changes
where text is moved or deleted)
Please review the files and let us know if you have any further updates. Once
we receive approvals from *James, Kireeti, Stewart, and Jie, we will move this
document forward in the publication process.
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9790
Thank you,
RFC Editor/ap
> On May 22, 2025, at 5:50 AM, Dongjie (Jimmy) <jie.d...@huawei.com> wrote:
>
> Hi Alanna,
>
> Thanks for your effort on the text update . I have some remaining comments:
>
> 1.2 Definitions
>
> a. The definition of Label Stack is a bit unclear. The length of MPLS label
> is 20 bits, while the text says "all labels (four-octet fields)", it should
> actually refer to the label stack entries in RFC 3032. And the bottom of
> stack bit is in the label stack entry, not in the label. It is suggested to
> update the definition as below:
>
> OLD:
> Label Stack:
> For an MPLS packet, all labels (four-octet fields) after the Layer 2 header,
> up to and including the label with the Bottom of Stack bit set [RFC3032].
>
> NEW:
> Label Stack:
> A label stack is represented as a consecutive sequence of "label stack
> entries (four-octet fields)" after the Layer 2 header but before any network
> layer header. The last label stack entry of a label stack has its Bottom of
> Stack bit set.
>
>
> b. The definition of MPLS Payload is not quite clear, especially with the
> introduction of post-stack data in draft-ietf-mpls-mna-fwk. It is considered
> that post-stack data is part of the MPLS layer, rather than MPLS payload. It
> is suggested to update the definition as below:
>
> OLD:
> MPLS Payload: All data after the label stack, including the PFN, an optional
> post-stack header, and the embedded packet.
>
> NEW:
> MPLS Payload: All data after the label stack and the optional Post-Stack
> header.
>
> Best regards,
> Jie
>
>> -----Original Message-----
>> From: Alanna Paloma <apal...@staff.rfc-editor.org>
>> Sent: Thursday, May 22, 2025 12:11 AM
>> 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; Dongjie (Jimmy)
>> <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
>>
>> Hi Greg,
>>
>> Thank you for your approval. It has been noted on the AUTH48 status page:
>> 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
>>>
>>>
>>> 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
>>>
>>> Updated output files:
>>> https://www.rfc-editor.org/authors/rfc9790.txt
>>> https://www.rfc-editor.org/authors/rfc9790.pdf
>>> 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-auth48rfcdiff.html (side by
>> side)
>>> 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 (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-rfcdiff.html (side by side)
>>> 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-...@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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-ad-diff.html&data=05%7C02%7Cjames.n.g
>> uichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784329230%7CU
>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=R%2FdCX1QwTrCEPHMcmLGzolTGixI4Kv4U96A6IWzDztc%3D&reserve
>> d=0
>>>>
>>>>
>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784348825%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K
>> RNEzPBurOpWcwBvFnb6zzBcRbDLwgxUOdIeGvtvaSo%3D&reserved=0
>>>>
>>>> Updated output files:
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784357951%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0
>> bSRuIx%2BTDvKbcIetW37yBXQ2J%2FhW02SE2r09N%2Fh830%3D&reserved=0
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784367688%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c
>> 8uspTKve1M5EWVu8nvFIFP5BPAgE5YIoofI3%2B6Geow%3D&reserved=0
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cjames.n.guichar
>> d%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a
>> 3b240189c753a1d5591fedc%7C1%7C1%7C638832832784376582%7CUnkno
>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata
>> =lsWbPbBwgFGrC5iwuSla6hbRcbZqBm7xWGeXKUnaRIw%3D&reserved=0
>>>>
>>>> Diff file showing all changes made during AUTH48:
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-auth48diff.html&data=05%7C02%7Cjame
>> s.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7
>> C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784385268
>> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
>> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
>> %7C&sdata=bWhX%2BpqcsUdCMTMvygDNBCofAyvdeqDWsr7mYENXYFU%3D
>> &reserved=0
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-auth48rfcdiff.html&data=05%7C02%7Cja
>> mes.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199
>> %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C6388328327843937
>> 60%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA
>> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
>> 7C%7C&sdata=SZQDJ1y6tmS8IO1y0Ve62Oqj7ofbZTrGx1ev%2BdBM%2FqU%3
>> D&reserved=0 (side by side)
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-lastdiff.html&data=05%7C02%7Cjames.n.
>> guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fe
>> e8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784401920%7C
>> Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=cdbc83rx0Xsw32u42IYQStM0XwbM3yM7Psshfd4C%2BlM%3D&reserv
>> ed=0 (htmlwdiff diff between last version and this)
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-lastrfcdiff.html&data=05%7C02%7Cjames.
>> n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C
>> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784410964%
>> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
>> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
>> 7C&sdata=5t81JSqP%2FFWISfESZJfJMBDyBE3A0mSQUnKd3wplyPQ%3D&rese
>> rved=0 (rfcdiff between last version and this)
>>>>
>>>> Diff files showing all changes:
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-diff.html&data=05%7C02%7Cjames.n.guic
>> hard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff
>> 2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784422051%7CUnk
>> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI
>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda
>> ta=7cELS%2FmN0HNo8R9iRkGr4YiOW0Mx1uEtS410CAGKu0Y%3D&reserved=
>> 0
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-rfcdiff.html&data=05%7C02%7Cjames.n.g
>> uichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784435601%7CU
>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=bbAWXKpjPa5tounm0qdTNw7scgktIwmBb%2Blb8yDvwEk%3D&reserv
>> ed=0 (side by side)
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-alt-diff.html&data=05%7C02%7Cjames.n.g
>> uichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784444065%7CU
>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=dMhRgIEsRsxMbOPh45dRF4QfYVuva0qtd%2B7oRiu6kuc%3D&reserve
>> d=0 (diff showing changes where text is moved or deleted)
>>>>
>>>> For the AUTH48 status of this document, please see:
>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cjames.n.guichard%40f
>> uturewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240
>> 189c753a1d5591fedc%7C1%7C1%7C638832832784452536%7CUnknown%7
>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
>> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HwQ
>> 3C9c%2FE2LQw5UhmDImxmEEjuBPcAgTN%2FoMgGEzCr0%3D&reserved=0
>>>>
>>>> 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 ]
>>>>>
>>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784460878%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=E
>> rr5GWxo3Ug3C%2Fk8AznnSRPY7ozPVeoFShwDnGpF%2FSI%3D&reserved=0
>>>>>
>>>>> Updated output files:
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784469257%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=R
>> w3AJgJa7d7CPZE6zB%2FPSUy7zXwfJAB3BcJzJC10cPU%3D&reserved=0
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784477638%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6
>> %2B9xC1P8I%2Fp5mBMfGx%2FHOiuBbEBkpoCMUReYn26%2Fv8g%3D&reserv
>> ed=0
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cjames.n.guichar
>> d%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a
>> 3b240189c753a1d5591fedc%7C1%7C1%7C638832832784485940%7CUnkno
>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata
>> =lT0e7MKKZ34%2BT25WgdMUI55beG2EDwM6tREymDQakMQ%3D&reserved
>> =0
>>>>>
>>>>> Diff file showing all changes made during AUTH48:
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-auth48diff.html&data=05%7C02%7Cjame
>> s.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7
>> C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784494370
>> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
>> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
>> %7C&sdata=ske5ZeYlxDcVQz74ylUjfLZ3LLfaZIVvqKM8YEcVTOo%3D&reserved=
>> 0
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-auth48rfcdiff.html&data=05%7C02%7Cja
>> mes.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199
>> %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C6388328327845027
>> 64%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA
>> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
>> 7C%7C&sdata=u1%2B5nvsWIiTpjgyJR22nks2VbRJhKepU12l268K5cuM%3D&re
>> served=0 (side by side)
>>>>>
>>>>> Diff files showing all changes:
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-diff.html&data=05%7C02%7Cjames.n.guic
>> hard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff
>> 2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784511359%7CUnk
>> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI
>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda
>> ta=dF7%2BXci%2Fp%2BGcM102H0N%2FQZKuIumVQS%2FxVwbdz9Ps0O4%3D
>> &reserved=0
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-rfcdiff.html&data=05%7C02%7Cjames.n.g
>> uichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784522353%7CU
>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=iqFnYkFdQJ6oYxIvgfJreR2yMvncjpgHAs4OauKL2JI%3D&reserved=0
>> (side by side)
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-alt-diff.html&data=05%7C02%7Cjames.n.g
>> uichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784531160%7CU
>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=Rm2l%2B3Qh2ar3ghWBreV9J3HBpl5q1ZrzVwdw6l%2BplTQ%3D&rese
>> rved=0 (diff showing changes where text is moved or deleted)
>>>>>
>>>>> For the AUTH48 status of this document, please see:
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cjames.n.guichard%40f
>> uturewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240
>> 189c753a1d5591fedc%7C1%7C1%7C638832832784539639%7CUnknown%7
>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
>> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4hDL
>> oRGMovv%2FbLGWV0347BQOXz7Ka2kHL6KrbsWI8CI%3D&reserved=0
>>>>>
>>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fsearch&data=05%7C02%7Cjames.n.guichard%40futurewei.co
>> m%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d
>> 5591fedc%7C1%7C1%7C638832832784548567%7CUnknown%7CTWFpbGZsb
>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF
>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9QxhyMT77pBRX
>> q9T%2B9JzhQ42Qsc%2F%2BIZLG98RWH8Tf7o%3D&reserved=0. -->
>>>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>> ana.org%2Fassignments%2Fpost-stack-first-nibble&data=05%7C02%7Cjames.n
>> .guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0f
>> ee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784557318%7
>> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
>> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7
>> C&sdata=icRrDJa8CveyR3N1O9%2FmpH%2BfnNqeC01L6JdgsX4LTLQ%3D&rese
>> rved=0
>>>>>>
>>>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C
>> 02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9
>> 713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832
>> 784567675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
>> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
>> C0%7C%7C%7C&sdata=kHkZBO5Z23qFXGoNFVM0PCrpYoZBAxYcOL3NVr2u4Kk
>> %3D&reserved=0>
>>>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.c
>> om%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1
>> d5591fedc%7C1%7C1%7C638832832784582453%7CUnknown%7CTWFpbGZs
>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
>> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z3V6Gxv8FlJg5n
>> 6TOhAcQuojj%2BLa1bdD5FmhQp%2Flpqk%3D&reserved=0).
>>>>>>
>>>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftruste
>> e.ietf.org%2Flicense-info&data=05%7C02%7Cjames.n.guichard%40futurewei.c
>> om%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1
>> d5591fedc%7C1%7C1%7C638832832784592133%7CUnknown%7CTWFpbGZs
>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
>> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Y472Ad2Bhx8w
>> rxYx6iZzfrADz%2FW%2Fx9cO2Qdq1wMW1w%3D&reserved=0).
>>>>>>
>>>>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
>> ors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cjames.n.guichard%40fut
>> urewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b24018
>> 9c753a1d5591fedc%7C1%7C1%7C638832832784600855%7CUnknown%7CT
>> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa
>> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Fz3b8
>> 0kDVz5rbuFMTQ7YqzY1gV3QvmzPQxqJ1qXlTVM%3D&reserved=0>.
>>>>>>
>>>>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailar
>> chive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8
>> O4Zc&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce90856
>> 67d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
>> 7C1%7C638832832784609522%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
>> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lCEQJM6VQuffPLjyMwRfqL2ieiBcjd
>> 4PjOrkG8x0%2FSU%3D&reserved=0
>>>>>>
>>>>>> * The archive itself:
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailar
>> chive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cja
>> mes.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199
>> %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C6388328327846188
>> 89%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA
>> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
>> 7C%7C&sdata=bhPY1mMm4ILyDLwlGsz3bAPB23WPn7Jd2gl9tSsJN1w%3D&re
>> served=0
>>>>>>
>>>>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784627460%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
>> GB78o%2BMYQPa41Ygqh3lsmUMwhSE2OF09RJizYbSgZII%3D&reserved=0
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cjames.n.guichar
>> d%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a
>> 3b240189c753a1d5591fedc%7C1%7C1%7C638832832784635940%7CUnkno
>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata
>> =nLeG8kyLLDkoAREIvumQkHGKC3788Ls2h7oPTJy7ePc%3D&reserved=0
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784644536%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y
>> IvwZyTo7liFuOqCpHbs04iy5UBQD33nts3%2BQY03L7I%3D&reserved=0
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cjames.n.guichard
>> %40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3
>> b240189c753a1d5591fedc%7C1%7C1%7C638832832784653060%7CUnknow
>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d
>> 3sjwEZOnCMKl8UtzjuF9XVjSP361h8n6DyxdziQv68%3D&reserved=0
>>>>>>
>>>>>> Diff file of the text:
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-diff.html&data=05%7C02%7Cjames.n.guic
>> hard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff
>> 2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784662032%7CUnk
>> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI
>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda
>> ta=UGuSDqXzWlHprpPJMyO8k%2BDzBFOuAFM5DeApcaCLjXI%3D&reserved=0
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-rfcdiff.html&data=05%7C02%7Cjames.n.g
>> uichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784670950%7CU
>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=fZ9oKk1ZD%2F4wIJ3RqPJuICTnV4eVwEuLdIrLN%2FvkAmM%3D&reser
>> ved=0 (side by side)
>>>>>>
>>>>>> Alt-diff of the text (allows you to more easily view changes
>>>>>> where text has been deleted or moved):
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-alt-diff.html&data=05%7C02%7Cjames.n.g
>> uichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784679643%7CU
>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
>> &sdata=sZdEMT0EEuP1oHf1W53tjfa2gJZ2grQwaHbI3hZ%2BWTU%3D&reserve
>> d=0
>>>>>>
>>>>>> Diff of the XML:
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauthors%2Frfc9790-xmldiff1.html&data=05%7C02%7Cjames.n
>> .guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0f
>> ee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784688576%7
>> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
>> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7
>> C&sdata=RapNLHmXg%2B5xS6NvT%2BpD5PZv1hh9oVBHffyV0atp6wk%3D&re
>> served=0
>>>>>>
>>>>>>
>>>>>> Tracking progress
>>>>>> -----------------
>>>>>>
>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
>> fc-editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cjames.n.guichard%40f
>> uturewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240
>> 189c753a1d5591fedc%7C1%7C1%7C638832832784697857%7CUnknown%7
>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
>> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ovD%
>> 2B4ffW3NQ%2BFO487RZUwq3iqyDufXI7Ue%2FTDrkmbJg%3D&reserved=0
>>>>>>
>>>>>> 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
>>>
>>>
>>
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
