Kireeti and other authors, Kireeti - Thank you for confirming your approval! We have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9790).
All - All questions have been addressed, and we have received all author approvals. In a separate email, we will ask IANA to update the registry to match the edited document. Once that is complete, we will begin to prepare this document (and the other two documents in cluster 520) for publication. Best regards, RFC Editor/rv > On Jun 27, 2025, at 7:27 PM, Kireeti Kompella <kireeti.i...@gmail.com> wrote: > > I do indeed approve of the doc in its current form. > > Kireeti. > >> On 26 Jun 2025, at 10:09, Rebecca VanRheenen >> <rvanrhee...@staff.rfc-editor.org> wrote: >> >> Hi Kireeti, >> >> Thank you for letting us know! We will retain Post-stack First Nibble/PFN. >> All questions have now been addressed. >> >> Can you let us know if you approve the document in its current form? >> >> Thank you, >> RFC Editor/rv >> >> >> >>> On Jun 26, 2025, at 5:30 AM, Kireeti Kompella <kireeti.i...@gmail.com> >>> wrote: >>> >>> Thank you, Rebecca. >>> >>> I’m fine with continuing to use Post-stack First Nibble/PFN. >>> >>> Kireeti. >>> >>>> On 23 Jun 2025, at 14:17, Rebecca VanRheenen >>>> <rvanrhee...@staff.rfc-editor.org> wrote: >>>> >>>> Hi Kireeti and Loa, >>>> >>>> Kireeti, thank you for your review and suggestions! We have updated the >>>> document accordingly, except for the following: >>>> >>>> Current: >>>> Post-stack First Nibble (PFN) >>>> >>>> Suggested: >>>> Post-Stack First Nibble (PFN) >>>> >>>> As Loa notes, the use of lowercase aligns the expansion with the chosen >>>> abbreviation, so we suggest leaving this as is. However, if all authors >>>> all agree to capitalize “-Stack” in this expansion, we suggest also adding >>>> “S” to the abbreviation (i.e., “PSFN”). Note that this would mean 31 >>>> updates of "PFN" to “PSFN”. Please let us know your thoughts. >>>> >>>> Note that once this is addressed, we will ask Jim (as AD) to review and >>>> approve the change in paragraph 3 of Section 2.5. >>>> >>>> — 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 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) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9790 >>>> >>>> Thank you, >>>> RFC Editor/rv >>>> >>>> >>>>> On Jun 21, 2025, at 11:03 AM, Loa Andersson <l...@pi.nu> wrote: >>>>> >>>>> All, >>>>> >>>>> I'm OK with the change Section 2.5, para 3 of RFC 4385. >>>>> >>>>> I'm more uncertain about doing >>>>> >>>>> Post-Stack First Nibble (PFN) >>>>> >>>>> raather than >>>>> >>>>> Post-stack First Nibble (PFN) >>>>> >>>>> I thought capitalising in the name indicated the letters chosen for the >>>>> abbreviation. >>>>> >>>>> /Loa >>>>> >>>>> Den 21/06/2025 kl. 10:07, skrev Kireeti Kompella: >>>>>> Hi Rebecca, >>>>>> Apologies for the very late response. I seem to have lost the original >>>>>> email, but I do have this thread, so replying here. >>>>>> Thank you for the detailed review and the great work making this >>>>>> document immensely more readable! I sincerely appreciate it. >>>>>> Since several comments have been made and addressed, I looked at the >>>>>> “all changes” diffs and commented on them. Excuse the colorful cut-n- >>>>>> paste from the side-by-side diffs. >>>>>> There is one _important change_ that I suggest; this will need to be >>>>>> reviewed by the shepherd, the WG chairs and ADs. I'm putting it first. >>>>>> The rest of my comments are mostly NITs. Most things “Post-Stack” have a >>>>>> capital S, but “Post-stack First Nibble” consistently uses a lower case >>>>>> s. That bothers me, but it may be just me. >>>>>> There are a couple of indefinite articles that I think should be changed >>>>>> (one added, one deleted). Finally, an unwanted hyphen in “load >>>>>> balancing”, to be consistent. >>>>>> ——— >>>>>> Section 2.5, para 3 >>>>>> OLD >>>>>> Obsoleting the use of a PSH for non-IP payloads encapsulated in MPLS >>>>>> would assist with the progress toward a simpler, more coherent system >>>>>> of MPLS data encapsulation. However, before that can be done, it is ... >>>>>> NEW >>>>>> RFC 4385, Section 2 suggests the use of a PSH solely for the purpose >>>>>> of avoiding IP ECMP treatment of non-IP payloads encapsulated in MPLS. >>>>>> Obsoleting this use of a PSH would assist with the progress toward a >>>>>> simpler, more coherent system of MPLS data encapsulation. (Other uses >>>>>> of a PSH may still be valid.) However, before that can be done, it is >>>>>> ... >>>>>> ——— >>>>>> Section 1, para 1 >>>>>> /* NIT */ >>>>>> OLD >>>>>> correct interpretation of the : >>>>> >>>>> >>>>> in a PSH >>>>>> NEW >>>>>> correct interpretation of the Post-Stack First Nibble (PFN) in a PSH >>>>>> Section 1, para 7 >>>>>> /*NIT*/ >>>>>> OLD >>>>>> this document enable a more robust network operation. >>>>>> NEW >>>>>> this document enable more robust network operation. >>>>>> Section 1.2, para 6 >>>>>> /* NIT */ >>>>>> OLD >>>>>> Post-stack First Nibble (PFN): The most significant four bits of the >>>>>> NEW >>>>>> Post-Stack First Nibble (PFN): The most significant four bits of the >>>>>> Section 1.3 >>>>>> /* NIT */ >>>>>> OLD >>>>>> PFN: Post-stack First Nibble >>>>>> NEW >>>>>> PFN: Post-Stack First Nibble >>>>>> Section 1.4 >>>>>> OLD >>>>>> Figure 2: Examples of an MPLS Packet Payload With and Without >>>>>> Preceding Post-Stack Header >>>>>> NEW >>>>>> Figure 2: Examples of an MPLS Packet Payload With and Without >>>>>> a Preceding Post-Stack Header >>>>>> Section 2.1.1.1, para 4 >>>>>> OLD >>>>>> heuristic can work very badly for non-IP packet as shown in example B >>>>>> in Figure 2. For example, if payload B is an Ethernet frame, then >>>>>> NEW >>>>>> heuristic can work very badly for the non-IP packet as shown in example >>>>>> B in Figure 2. For example, if payload B is an Ethernet frame, then >>>>>> Section 2.2, para 5 >>>>>> /* NIT */ >>>>>> OLD >>>>>> | (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all >>>>>> NEW >>>>>> | (Post-Stack First Nibble) value that is neither 0x4 nor 0x6 in all >>>>>> Section 2.2, last para >>>>>> /*NIT*/ >>>>>> | PFN: Post-stack First Nibble >>>>>> NEW >>>>>> | PFN: Post-Stack First Nibble >>>>>> Section 2.5, para 3 >>>>>> OLD >>>>>> or deployed implementations using the heuristic practice to load- >>>>>> balancing MPLS data flows. >>>>>> NEW >>>>>> or deployed implementations using the heuristic practice to load >>>>>> balancing MPLS data flows. >>>>>> (Frankly, I would prefer “to load balance MPLS data flows” to “to load >>>>>> balancing …”.) >>>>>> Kireeti. >>>>>>> On 20 Jun 2025, at 22:18, Rebecca VanRheenen <rvanrhee...@staff.rfc- >>>>>>> editor.org> wrote: >>>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> Thank you for the replies. We added the sentence that Loa suggested to >>>>>>> the Acknowledgments section with a small edit. We also incorporated the >>>>>>> changes sent by Jie. These changes are best viewed in the alt-diff or >>>>>>> lastdiff files listed below. >>>>>>> >>>>>>> Loa and Stewart, we have marked your approvals on the AUTH48 status >>>>>>> page for this document. Jim, we have also marked your AD approval. See >>>>>>> https://www.rfc-editor.org/auth48/rfc9790. >>>>>>> >>>>>>> We are now waiting for approvals or further updates from Jie and >>>>>>> Kireeti. >>>>>>> >>>>>>> — 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 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) >>>>>>> >>>>>>> For the AUTH48 status of this document, please see: >>>>>>> https://www.rfc-editor.org/auth48/rfc9790 >>>>>>> >>>>>>> Thank you, >>>>>>> RFC Editor/rv >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 20, 2025, at 11:36 AM, Adrian Farrel <adr...@olddog.co.uk> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Yes, thanks for you diligence, Jie. Those changes are needed. >>>>>>>> Adrian >>>>>>>>> On 20/06/2025 15:27 BST Dongjie (Jimmy) <jie.d...@huawei.com> wrote: >>>>>>>>> Hi Rebecca, >>>>>>>>> Thanks for the effort on this update. >>>>>>>>> The update to the definition of "MPLS payload" and "Post-Stack Header >>>>>>>>> (PSH)" looks good. While I found that in section 1.4, there is one >>>>>>>>> usage of "MPLS payload" which needs to be updated to align with the >>>>>>>>> current definition. >>>>>>>>> OLD: >>>>>>>>> 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. >>>>>>>>> Since the current definition says the MPLS Payload is after the label >>>>>>>>> stack and optional PSHs, the text in this example also needs to be >>>>>>>>> updated. >>>>>>>>> Here is the suggested text: >>>>>>>>> NEW: >>>>>>>>> Example C: This example is an MPLS Payload that follows a PSH. Here, >>>>>>>>> the embedded packet could be IP or non-IP. >>>>>>>>> And the title of Figure 2 needs to be updated accordingly: >>>>>>>>> OLD: >>>>>>>>> Figure 2: Examples of an MPLS Packet Payload With and Without Post- >>>>>>>>> Stack Header. >>>>>>>>> New: >>>>>>>>> Figure 2: Examples of an MPLS Packet Payload With and Without >>>>>>>>> Preceding Post-Stack Header >>>>>>>>> Hope this helps. >>>>>>>>> Best regards, >>>>>>>>> Jie >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> >>>>>>>>>> Sent: Friday, June 20, 2025 4:51 AM >>>>>>>>>> To: Adrian Farrel <adr...@olddog.co.uk>; Loa Andersson <l...@pi.nu>; >>>>>>>>>> Kireeti >>>>>>>>>> Kompella <kireeti.i...@gmail.com>; Matthew Bocci (Nokia) >>>>>>>>>> <matthew.bo...@nokia.com>; Greg Mirsky <gregimir...@gmail.com>; >>>>>>>>>> Stewart Bryant <s...@stewartbryant.com>; Dongjie (Jimmy) >>>>>>>>>> <jie.d...@huawei.com>; James Guichard >>>>>>>>>> <james.n.guich...@futurewei.com> >>>>>>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; m...@ietf.org; mpls- >>>>>>>>>> a...@ietf.org; >>>>>>>>>> MPLS Working Group <mpls-cha...@ietf.org>; auth48archive >>>>>>>>>> <auth48archive@rfc-editor.org> >>>>>>>>>> Subject: [AD] Re: AUTH48: RFC-to-be 9790 <draft-ietf- >>>>>>>>>> mpls-1stnibble-13> >>>>>>>>>> Hi Adrian, authors, and Jim*, >>>>>>>>>> Adrian - Thank you for providing the updated text. We have updated >>>>>>>>>> the files >>>>>>>>>> accordingly (see list of files below) >>>>>>>>>> Authors - Please let us know if you approve of the document in its >>>>>>>>>> current form >>>>>>>>>> or if any further updates are needed. >>>>>>>>>> *Jim - As AD, please review the changes to the definitions for "MPLS >>>>>>>>>> Payload” >>>>>>>>>> and "Post-Stack Header (PSH)” in Section 1.2 and let us know if you >>>>>>>>>> approve. >>>>>>>>>> These changes are best viewed in this diff file: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790-lastdiff.html. >>>>>>>>>> — 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 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) >>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9790 Thank you, >>>>>>>>>> RFC Editor/rv >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jun 18, 2025, at 1:20 PM, Adrian Farrel <adr...@olddog.co.uk> >>>>>>>>>>> wrote: >>>>>>>>>>> RFC Editor (Rebecca), authors, Working Group, >>>>>>>>>>> Document Shepherd here. >>>>>>>>>>> This document seemed to stagnate over the discussion of a couple of >>>>>>>>>>> minor >>>>>>>>>> editorial points. So I have been chatting with Greg and Loa, and we >>>>>>>>>> have >>>>>>>>>> agreed some changes that seem to address the concerns. >>>>>>>>>>> >>>>>>>>>>> I have based these changes on the text at >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790.txt > >>>>>>>>>>> Section 1.2 >>>>>>>>>>> OLD >>>>>>>>>>> MPLS Payload: All data after the label stack and the optional Post- >>>>>>>>>>> Stack header. >>>>>>>>>>> NEW >>>>>>>>>>> MPLS Payload: All data after the label stack and any optional PSHs. >>>>>>>>>>> It >>>>>>>>>>> is possible that more than one type of PSH may be present in a >>>>>>>>>>> packet, and some PSH specifications might allow multiple PSHs of >>>>>>>>>>> the same type. The presence rules for multiple PSHs are a matter >>>>>>>>>>> for the documents that define those PSHs, e.g., in >>>>>>>>>>> [I-D.ietf-mpls-mna-ps-hdr]. >>>>>>>>>>> END >>>>>>>>>>> Section 1.2 >>>>>>>>>>> OLD >>>>>>>>>>> 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. >>>>>>>>>>> NEW >>>>>>>>>>> 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]. >>>>>>>>>>> END >>>>>>>>>>> >>>>>>>>>>> I hope with these two changes, all of the authors can confirm their >>>>>>>>>>> AUTH48 >>>>>>>>>> proposal. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Adrian >>>>>>> >>>>> >>>>> -- >>>>> 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
