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

Reply via email to