Hi David, The change looks great.
Thank you! RFC Editor/rv > On Jul 1, 2025, at 7:22 PM, David Dong via RT <iana-mat...@iana.org> wrote: > > Hi Rebecca, > > This has been completed: > > NSH 0x0 NSH Base Header, payload [RFC8300] > > Registry: > https://www.iana.org/assignments/post-stack-first-nibble/ > > Thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Tue Jul 01 17:36:31 2025, rvanrhee...@staff.rfc-editor.org wrote: >> Hello IANA, >> >> Please update the Description column for NSH in the "Post-Stack First >> Nibble" registry (https://www.iana.org/assignments/post-stack-first- >> nibble) as follows: >> >> OLD: >> NSH (Network Service Header) Base Header, payload >> >> NEW: >> NSH Base Header, payload >> >> >> If needed, here are the output files and the diff file: >> >> https://www.rfc-editor.org/authors/rfc9790.txt >> https://www.rfc-editor.org/authors/rfc9790.pdf >> https://www.rfc-editor.org/authors/rfc9790.html >> https://www.rfc-editor.org/authors/rfc9790-alt-diff.html >> >> Thank you! >> RFC Editor/rv >> >> >> >>> On Jul 1, 2025, at 10:33 AM, Rebecca VanRheenen >>> <rvanrhee...@staff.rfc-editor.org> wrote: >>> >>> 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
