Hi Greg, Thank you for your approval. It has been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9790
We will await approvals from Kireeti, Stewart, Matthew, Loa, and Jie prior to moving this document forward in the publication process. Best regards, RFC Editor/ap > On May 20, 2025, at 2:04 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Hi Alanna, > Thank you for keeping up with all the updates. I read Loa's latest update and > agree with it. Hence, I agree with all the updates applied during AUTH48. > Please let me know if you have any further questions. > > Regards, > Greg > > On Tue, May 20, 2025 at 10:40 AM Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > Hi James, Loa, and other authors, > > James - Thank you for your approval. It has been noted on the AUTH48 status > page: > https://www.rfc-editor.org/auth48/rfc9790 > > > Authors - We have updated the files per Loa’s updated text (see below). > > We will await approvals from each party listed on the AUTH48 status page > prior to moving this document forward in the publication process. > > > — FILES (please refresh) — > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9790.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9790.txt > https://www.rfc-editor.org/authors/rfc9790.pdf > https://www.rfc-editor.org/authors/rfc9790.html > > Diff file showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9790-auth48diff.html > https://www.rfc-editor.org/authors/rfc9790-auth48rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9790-lastdiff.html (htmlwdiff diff > between last version and this) > https://www.rfc-editor.org/authors/rfc9790-lastrfcdiff.html (rfcdiff between > last version and this) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9790-diff.html > https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9790-alt-diff.html (diff showing > changes where text is moved or deleted) > > Best regards, > RFC Editor/ap > > > On May 20, 2025, at 3:09 AM, James Guichard > > <james.n.guich...@futurewei.com> wrote: > > > > Approved. > > Jim > > From: Alanna Paloma <apal...@staff.rfc-editor.org> > > Date: Monday, May 19, 2025 at 4:27 PM > > To: James Guichard <james.n.guich...@futurewei.com>, Greg Mirsky > > <gregimir...@gmail.com>, Matthew Bocci (Nokia) <matthew.bo...@nokia.com> > > Cc: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>, Kireeti Kompella > > <kireeti.i...@gmail.com>, Stewart Bryant <s...@stewartbryant.com>, Jie Dong > > <jie.d...@huawei.com>, l...@pi.nu<l...@pi.nu>, RFC Editor > > <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org<mpls-...@ietf.org>, MPLS > > Working Group <mpls-cha...@ietf.org>, Adrian Farrel <adr...@olddog.co.uk>, > > auth48archive <auth48archive@rfc-editor.org> > > Subject: [AD] Re: AUTH48: RFC-to-be 9790 <draft-ietf-mpls-1stnibble-13> for > > your review > > Hi Matthew, Greg, and James (AD)*, > > > > *James - As the AD, please review and approve of the updated text and > > removal of the BCP 14 keyword “MUST”. > > > > Original: > > Post-stack Header (PSH): optional field of interest to the egress > > Label Switching Router (LSR) (and possibly to transit LSRs). > > Examples include a control word [RFC4385], [RFC8964] or an > > associated channel [RFC4385], [RFC5586], [RFC9546]. The PSH MUST > > indicate its length, so that a parser knows where the embedded > > packet starts. > > > > Current: > > Post-Stack Header (PSH): A field containing information that may be > > of interest to the egress Label Switching Router (LSR) or transit > > LSRs. Examples include a control word [RFC4385] [RFC8964] or an > > associated channel header [RFC4385] [RFC5586] [RFC9546]. A parser > > needs to be able to determine where the PSH ends in order to find > > the embedded packet. > > > > See this diff file: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-ad-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784329230%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=R%2FdCX1QwTrCEPHMcmLGzolTGixI4Kv4U96A6IWzDztc%3D&reserved=0 > > > > > > Authors - Thank you for your replies. We have updated as requested. We > > will await any further changes you may have and approvals from each author > > and *James prior to moving forward in the publication process. > > > > — FILES (please refresh) — > > > > Updated XML file: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784348825%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KRNEzPBurOpWcwBvFnb6zzBcRbDLwgxUOdIeGvtvaSo%3D&reserved=0 > > > > Updated output files: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784357951%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0bSRuIx%2BTDvKbcIetW37yBXQ2J%2FhW02SE2r09N%2Fh830%3D&reserved=0 > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784367688%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c8uspTKve1M5EWVu8nvFIFP5BPAgE5YIoofI3%2B6Geow%3D&reserved=0 > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784376582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lsWbPbBwgFGrC5iwuSla6hbRcbZqBm7xWGeXKUnaRIw%3D&reserved=0 > > > > Diff file showing all changes made during AUTH48: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784385268%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bWhX%2BpqcsUdCMTMvygDNBCofAyvdeqDWsr7mYENXYFU%3D&reserved=0 > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784393760%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SZQDJ1y6tmS8IO1y0Ve62Oqj7ofbZTrGx1ev%2BdBM%2FqU%3D&reserved=0 > > (side by side) > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-lastdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784401920%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cdbc83rx0Xsw32u42IYQStM0XwbM3yM7Psshfd4C%2BlM%3D&reserved=0 > > (htmlwdiff diff between last version and this) > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-lastrfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784410964%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5t81JSqP%2FFWISfESZJfJMBDyBE3A0mSQUnKd3wplyPQ%3D&reserved=0 > > (rfcdiff between last version and this) > > > > Diff files showing all changes: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784422051%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7cELS%2FmN0HNo8R9iRkGr4YiOW0Mx1uEtS410CAGKu0Y%3D&reserved=0 > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784435601%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bbAWXKpjPa5tounm0qdTNw7scgktIwmBb%2Blb8yDvwEk%3D&reserved=0 > > (side by side) > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-alt-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784444065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dMhRgIEsRsxMbOPh45dRF4QfYVuva0qtd%2B7oRiu6kuc%3D&reserved=0 > > (diff showing changes where text is moved or deleted) > > > > For the AUTH48 status of this document, please see: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784452536%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HwQ3C9c%2FE2LQw5UhmDImxmEEjuBPcAgTN%2FoMgGEzCr0%3D&reserved=0 > > > > Thank you, > > RFC Editor/ap > > > > > On May 19, 2025, at 9:47 AM, Greg Mirsky <gregimir...@gmail.com> wrote: > > > > > > Hi Rebecca, > > > I agree with the updates proposed by Matthew. > > > > > > Regards, > > > Greg > > > > > > On Mon, May 19, 2025 at 3:17 AM Matthew Bocci (Nokia) > > > <matthew.bo...@nokia.com> wrote: > > > Hi Rebecca > > > Thanks for the updated Auth48 text. I have a couple of comments. > > > Regards > > > Matthew > > > 1. Introduction: > > > I think PSH in the second sentence should be pluralised: > > > OLD: > > > Examples of PSH include existing artifacts such as control words > > > [RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296] and > > > the like, as well as new types of PSH being discussed by the MPLS Working > > > Group. > > > NEW: > > > Examples of PSHs include existing artifacts such as control words > > > [RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296] and > > > the like, as well as new types of PSH being discussed by the MPLS Working > > > Group. > > > 2.1 Definitions: > > > The definition of PSH is a bit unclear in terms of what it is referring > > > to for the optional field of interest, and it is also mandates that the > > > PSH must include a length when in fact most existing PSHs (such as the PW > > > CW or G-ACH) do not include such a field. I would propose rephrasing to: > > > OLD: > > > Post-Stack Header (PSH): > > > Optional field of interest to the egress Label Switching Router (LSR) > > > (and possibly to transit LSRs). Examples include a control word [RFC4385] > > > [RFC8964] or an associated channel [RFC4385] [RFC5586] [RFC9546]. The PSH > > > MUST indicate its length, so that a parser knows where the embedded > > > packet starts. > > > NEW: > > > Post-Stack Header (PSH): > > > A field containing information which may be of interest to the egress > > > Label Switching Router (LSR) or transit LSRs. Examples include a control > > > word [RFC4385] [RFC8964] or an associated channel header [RFC4385] > > > [RFC5586] [RFC9546]. A parser needs to be able to determine where the PSH > > > ends in order to find the embedded packet. > > > Best regards, > > > Matthew > > > From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> > > > Date: Thursday, 15 May 2025 at 22:01 > > > To: Greg Mirsky <gregimir...@gmail.com>, Kireeti Kompella > > > <kireeti.i...@gmail.com>, Stewart Bryant <s...@stewartbryant.com>, > > > Matthew Bocci (Nokia) <matthew.bo...@nokia.com>, Jie Dong > > > <jie.d...@huawei.com>, l...@pi.nu <l...@pi.nu> > > > Cc: RFC Editor <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org > > > <mpls-...@ietf.org>, MPLS Working Group <mpls-cha...@ietf.org>, Adrian > > > Farrel <adr...@olddog.co.uk>, James Guichard > > > <james.n.guich...@futurewei.com>, auth48archive > > > <auth48archive@rfc-editor.org> > > > Subject: Re: AUTH48: RFC-to-be 9790 <draft-ietf-mpls-1stnibble-13> for > > > your review > > > [You don't often get email from rvanrhee...@staff.rfc-editor.org. Learn > > > why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > > links or opening attachments. See the URL nok.it/ext for additional > > > information. > > > > > > > > > > > > Hi Greg and other authors, > > > > > > Greg - Thank you for addressing all of our questions! We have updated the > > > document accordingly. > > > > > > All - Please review the document carefully to ensure satisfaction as we > > > do not make changes once it has been published as an RFC. Contact us with > > > any further updates or with your approval of the document in its current > > > form. We will await approvals from each author prior to moving forward > > > in the publication process. > > > > > > — FILES (please refresh) — > > > > > > Updated XML file: > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784460878%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Err5GWxo3Ug3C%2Fk8AznnSRPY7ozPVeoFShwDnGpF%2FSI%3D&reserved=0 > > > > > > Updated output files: > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784469257%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Rw3AJgJa7d7CPZE6zB%2FPSUy7zXwfJAB3BcJzJC10cPU%3D&reserved=0 > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784477638%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6%2B9xC1P8I%2Fp5mBMfGx%2FHOiuBbEBkpoCMUReYn26%2Fv8g%3D&reserved=0 > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784485940%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lT0e7MKKZ34%2BT25WgdMUI55beG2EDwM6tREymDQakMQ%3D&reserved=0 > > > > > > Diff file showing all changes made during AUTH48: > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784494370%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ske5ZeYlxDcVQz74ylUjfLZ3LLfaZIVvqKM8YEcVTOo%3D&reserved=0 > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784502764%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=u1%2B5nvsWIiTpjgyJR22nks2VbRJhKepU12l268K5cuM%3D&reserved=0 > > > (side by side) > > > > > > Diff files showing all changes: > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784511359%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dF7%2BXci%2Fp%2BGcM102H0N%2FQZKuIumVQS%2FxVwbdz9Ps0O4%3D&reserved=0 > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784522353%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iqFnYkFdQJ6oYxIvgfJreR2yMvncjpgHAs4OauKL2JI%3D&reserved=0 > > > (side by side) > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-alt-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784531160%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Rm2l%2B3Qh2ar3ghWBreV9J3HBpl5q1ZrzVwdw6l%2BplTQ%3D&reserved=0 > > > (diff showing changes where text is moved or deleted) > > > > > > For the AUTH48 status of this document, please see: > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784539639%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4hDLoRGMovv%2FbLGWV0347BQOXz7Ka2kHL6KrbsWI8CI%3D&reserved=0 > > > > > > Thank you, > > > > > > RFC Editor/rv > > > > > > > > > > > > > On May 14, 2025, at 4:41 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > > > > > > > Dear RFC Editor, > > > > thank you for your help in improving this document. Please find my > > > > notes below tagged GIM>>. > > > > > > > > Regards, > > > > Greg > > > > > > > > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > > > > Date: Wednesday, 14 May 2025 at 05:24 > > > > To: kireeti.i...@gmail.com <kireeti.i...@gmail.com>, > > > > s...@stewartbryant.com<s...@stewartbryant.com>, Matthew Bocci (Nokia) > > > > <matthew.bo...@nokia.com>, gregimir...@gmail.com > > > > <gregimir...@gmail.com>, l...@pi.nu <l...@pi.nu>, jie.d...@huawei.com > > > > <jie.d...@huawei.com> > > > > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > > > > mpls-...@ietf.org<mpls-...@ietf.org>, mpls-cha...@ietf.org > > > > <mpls-cha...@ietf.org>, adr...@olddog.co.uk <adr...@olddog.co.uk>, > > > > james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, > > > > auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > > > > Subject: Re: AUTH48: RFC-to-be 9790 <draft-ietf-mpls-1stnibble-13> for > > > > your review > > > > > > > > CAUTION: This is an external email. Please be very careful when > > > > clicking links or opening attachments. See the URL nok.it/ext for > > > > additional information. > > > > > > > > > > > > > > > > Authors, > > > > > > > > While reviewing this document during AUTH48, please resolve (as > > > > necessary) the following questions, which are also in the XML file. > > > > > > > > 1) <!-- [rfced] Please note that the abbreviated title of the document > > > > has been > > > > updated as follows. The abbreviated title only appears in the running > > > > header in the pdf output. > > > > > > > > Original: > > > > 1st nibble > > > > > > > > Current: > > > > First Nibble Following Label Stack > > > > GIM>> Thank you; I agree. > > > > --> > > > > > > > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > > the title) for use on > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784548567%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9QxhyMT77pBRXq9T%2B9JzhQ42Qsc%2F%2BIZLG98RWH8Tf7o%3D&reserved=0. > > > > --> > > > > GIM>> Perhaps > > > > Post-stack header > > > > Load-balancing > > > > > > > > > > > > 3) <!-- [rfced] Please clarify "in the context associated". Note that > > > > there > > > > is a similar sentence in the IANA section. > > > > > > > > Original: > > > > Although some existing network > > > > devices may use such a method, it needs to be stressed that the > > > > correct interpretation of the Post-stack First Nibble (PFN) in a PSH > > > > can be made only in the context associated using the control or > > > > management plane with the Label Stack Element (LSE) or group of LSEs > > > > in the preceding label stack that characterize the type of the PSH, > > > > and that any attempt to rely on the value in any other context is > > > > unreliable. > > > > > > > > Perhaps: > > > > Although some existing network > > > > devices may use such a method, it needs to be stressed that the > > > > correct interpretation of the Post-stack First Nibble (PFN) in a PSH > > > > can be made only in the context of using the control or > > > > management plane with the Label Stack Entry (LSE) or group of LSEs > > > > in the preceding label stack that characterizes the type of the PSH. > > > > Any attempt to rely on the value in any other context is > > > > unreliable. > > > > > > > > Or (similar to sentence in IANA section): > > > > Although some existing network > > > > devices may use such a method, it needs to be stressed that the > > > > correct interpretation of the Post-stack First Nibble (PFN) in a PSH > > > > can be made only in the context of the Label Stack Entry (LSE) or > > > > group of LSEs > > > > in the preceding label stack that characterizes the type of the PSH. > > > > Any attempt to rely on the value in any other context is > > > > unreliable. > > > > GIM>> Thank you for your creative options. I will propose another > > > > re-wording using the first option with s/of using/established through/: > > > > Although some existing network > > > > devices may use such a method, it needs to be stressed that the > > > > correct interpretation of the Post-stack First Nibble (PFN) in a PSH > > > > can be made only in the context established through the control or > > > > management plane with the Label Stack Entry (LSE) or group of LSEs > > > > in the preceding label stack that characterizes the type of the PSH. > > > > Any attempt to rely on the value in any other context is > > > > unreliable. --> > > > > > > > > > > > > 4) <!-- [rfced] How may we update the text starting with "including..." > > > > to > > > > improve clarity? > > > > > > > > Original: > > > > * To stress the importance that any MPLS packet not carrying plain > > > > IPv4 or IPv6 packets contains a PSH, including any new version of > > > > IP (Section 2.4). > > > > > > > > Perhaps: > > > > * To stress that any MPLS packet not carrying plain > > > > IPv4 or IPv6 packets contains a PSH. This also applies to packets > > > > of > > > > any new version of IP (see Section 2.4). > > > > GIM>> Excellent! I agree. > > > > --> > > > > > > > > > > > > 5) <!-- [rfced] The sentences below are from the last two paragraphs of > > > > Section 1. > > > > In the first sentence, will readers understand what is meant by "the > > > > heuristic"? Would it be helpful to add more context, like that included > > > > in the second sentence? > > > > > > > > Original: > > > > Based on the analysis of load-balancing techniques in Section 2.1.1, > > > > this document, in Section 2.1.1.1, introduces a requirement that > > > > deprecates the use of the heuristic and recommends using a dedicated > > > > label value for load balancing. > > > > ... > > > > Furthermore, this document updates [RFC4928] by deprecating the > > > > heuristic method for identifying the type of packet encapsulated in > > > > MPLS. > > > > > > > > Perhaps: > > > > Section 2.1.1 of this document includes an analysis of load-balancing > > > > techniques; based on this, Section 2.1.1.1 introduces a requirement > > > > that deprecates the use of the heuristic method for identifying the > > > > type > > > > of packet encapsulated in MPLS and recommends using a > > > > dedicated label value for load balancing. > > > > ... > > > > Furthermore, this document updates [RFC4928] by deprecating this > > > > heuristic method. > > > > GIM>> I like the proposed update of the first paragraph. Since it is > > > > followed by two sentences, would "this heuristic method" reference be > > > > clear to a reader? Would keeping that part unchanged be acceptable? > > > > --> > > > > > > > > > > > > 6) <!-- [rfced] Would you like to alphabetize the list of abbreviations > > > > in Section 1.3 > > > > ("Abbreviations")? Or do you prefer the current order? > > > > > > > > Similarly, would you like to alphabetize the terms in Section 1.2 > > > > ("Definitions") or keep the current order? > > > > GIM>> Yes, alphabetize them, please. > > > > --> > > > > > > > > > > > > 7) <!-- [rfced] We updated this text as shown below. Specifically, we > > > > moved the > > > > third sentence of the first paragraph to follow the list and updated > > > > "A." > > > > to read "Example A:". Let us know any concerns. > > > > > > > > Original: > > > > Figure 1 shows an MPLS packet with Layer 2 header X and a label stack > > > > Y ending with Label-n. Then, there are three examples of an MPLS > > > > payload displayed in Figure 2. The complete MPLS packet thus would > > > > consist of [X Y A], or [X Y B], or [X Y C]. > > > > > > > > A. The first payload is a bare IP packet, i.e., no PSH. The PFN in > > > > this case overlaps with the IP version number. > > > > > > > > B. The next payload is a bare non-IP packet; again, no PSH. The PFN > > > > here is the first nibble of the payload, whatever it happens to be. > > > > > > > > C. The last example is an MPLS Payload that starts with a PSH > > > > followed by the embedded packet. Here, the embedded packet could be > > > > IP or non-IP. > > > > > > > > Updated: > > > > Figure 1 shows an MPLS packet with a Layer 2 header X and a label > > > > stack > > > > Y ending with Label-n. Figure 2 displays three examples of an > > > > MPLS payload: > > > > > > > > Example A: The first payload is a bare IP packet, i.e., no PSH. The > > > > PFN in this case overlaps with the IP version number. > > > > > > > > Example B: The next payload is a bare non-IP packet; again, no PSH. > > > > The PFN here is the first nibble of the payload, whatever it > > > > happens to be. > > > > > > > > Example C: This example is an MPLS Payload that starts with a PSH > > > > followed by the embedded packet. Here, the embedded packet could > > > > be IP or non-IP. > > > > > > > > Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or > > > > [X Y C]. > > > > GIM>> Thank you for your updates that improve readability of the > > > > document. > > > > --> > > > > > > > > > > > > 8) <!-- [rfced] For readability, may we update this list as follows? > > > > > > > > Original: > > > > There are four common ways to load balance an MPLS packet: > > > > > > > > 1. One can use the top label alone. > > > > > > > > 2. One can do better by using all of the non-SPLs (Special Purpose > > > > Labels) [RFC7274] in the stack. > > > > > > > > 3. One can do even better by "divining" the type of embedded packet, > > > > and using fields from the guessed header. The ramifications of > > > > using this load-balancing technique are discussed in detail in > > > > Section 2.1.1.1. > > > > > > > > 4. One can do best by using either an Entropy Label [RFC6790] or a > > > > Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see > > > > Section 2.1.1.1). > > > > > > > > Perhaps: > > > > There are four common ways to load balance an MPLS packet: > > > > > > > > 1. Use the top label alone. > > > > > > > > 2. Use all of the non-SPLs (Special Purpose > > > > Labels) [RFC7274] in the stack. This is better than using the > > > > top label alone. > > > > > > > > 3. Divine the type of embedded packet > > > > and use fields from the guessed header. The ramifications of > > > > using this load-balancing technique are discussed in detail in > > > > Section 2.1.1.1. This way is better than the two ways above. > > > > > > > > 4. Use either an Entropy Label [RFC6790] or a > > > > Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see > > > > Section 2.1.1.1). This is the best way. > > > > GIM>> I agree with the proposed updates with a suggestion to maintain > > > > quotation marks as "divine". > > > > --> > > > > > > > > > > > > 9) <!-- [rfced] Would including some text to introduce the numbered > > > > list in > > > > Section 2.1.1.1 be helpful? If so, please provide the text. > > > > GIM>> I think that the current text is sufficient but I am open to any > > > > text other authors propose. > > > > --> > > > > > > > > > > > > 10) <!-- [rfced] Would it be helpful to update "Support for" to "The > > > > framework > > > > for" in this sentence? > > > > > > > > Original: > > > > Support for MPLS Network Actions (MNAs) is described in > > > > [I-D.ietf-mpls-mna-fwk] and is an enhancement to the MPLS > > > > architecture. > > > > > > > > Perhaps: > > > > The framework for MPLS Network Actions (MNAs) is described in > > > > [RFC9789] and > > > > is an enhancement to the MPLS architecture. > > > > GIM>> I agree with the proposed change. > > > > --> > > > > > > > > > > > > 11) <!-- [rfced] This sentence notes that the PFN value of 0x0 has two > > > > different > > > > formats, but the IANA registry in Section 3 lists the value 0x0 three > > > > times. Please review and let us know if any updates are needed. > > > > > > > > Original: > > > > This issue is described in section 3.6.1 of [I-D.ietf-mpls-mna-fwk] > > > > and is further illustrated by the PFN value of 0x0 which has two > > > > different formats depending on whether the PSH is a pseudowire > > > > control word or a DetNet control word ... > > > > GIM>> Your observation is correct. Value 0x0 is used by three services > > > > that are listed in the IANA registry in Section 3. But two of these > > > > services use four-octet long format, while one - eight-octet long > > > > format. Thus, three entries in the registry but only two formats. > > > > --> > > > > > > > > > > > > 12) <!-- [rfced] How may we clarify "leading to [RFC4928]"? > > > > > > > > Original: > > > > It was then discovered that > > > > non-IP packets, misidentified as IP when the heuristic failed, were > > > > being badly load balanced, leading to [RFC4928]. > > > > > > > > Perhaps: > > > > It was then discovered that > > > > non-IP packets, misidentified as IP when the heuristic failed, were > > > > being badly load-balanced, leading to the scenario described in > > > > [RFC4928]. > > > > GIM>> Thank you for your creative editing! I agree with the proposed > > > > update. > > > > --> > > > > > > > > > > > > 13) <!-- [rfced] What does "it" refer to here? > > > > > > > > Original: > > > > It would assist with the progress toward a simpler, more coherent > > > > system of MPLS data encapsulation if the use a PSH for non-IP > > > > payloads encapsulated in MPLS was obsoleted. > > > > > > > > Perhaps: > > > > If the use a PSH for non-IP > > > > payloads encapsulated in MPLS were obsoleted, this would assist with > > > > the progress toward a simpler, more coherent > > > > system of MPLS data encapsulation > > > > > > > > Or: > > > > Obsoleting the use a PSH for non-IP > > > > payloads encapsulated in MPLS would assist with the progress toward > > > > a simpler, more coherent > > > > system of MPLS data encapsulation. > > > > GIM>> Thank you for proposing two excellent options.I slightly prefer > > > > the second with a minor modification (two options ;-) : > > > > s/the use a PSH/the use of a PSH/ or s/the use a PSH/using a PSH/ > > > > --> > > > > > > > > > > > > 14) <!-- [rfced] Please review "to load-balancing MPLS data flows". > > > > Should the > > > > "load balance" be used instead of the "load-balancing"? Or > > > > is the current correct? > > > > > > > > Original: > > > > However, before that > > > > can be done, it is important to collect sufficient evidence that > > > > there are no marketed or deployed implementations using the heuristic > > > > practice to load-balancing MPLS data flows. > > > > > > > > Perhaps: > > > > However, before that > > > > can be done, it is important to collect sufficient evidence that > > > > there are no marketed or deployed implementations using the heuristic > > > > practice to load balance MPLS data flows. > > > > GIM>> I think that the current form is acceptable. What do other > > > > authors think? > > > > --> > > > > > > > > > > > > 15) <!-- [rfced] We removed the expansion "Network Service Header" in > > > > Table 1 as > > > > this is expanded previously in the document. If no objections, we will > > > > ask IANA to update the "Post-Stack First Nibble" registry accordingly > > > > prior to publication. > > > > > > > > Link to registry: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fpost-stack-first-nibble&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784557318%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=icRrDJa8CveyR3N1O9%2FmpH%2BfnNqeC01L6JdgsX4LTLQ%3D&reserved=0 > > > > > > > > Original: > > > > | NSH | 0x0 | NSH (Network Service Header) > > > > | | | Base Header, payload > > > > > > > > Current: > > > > | NSH | 0x0 | NSH Base Header, paylod > > > > GIM>> I agree; your update makes the table easier to read. > > > > --> > > > > > > > > > > > > 16) <!-- [rfced] Abbreviations > > > > > > > > a) FYI - We updated the expansion for LSE as follows to align with the > > > > expansion used in RFCs-to-be 9789 and 9791. Also, "Label Stack Element" > > > > has > > > > not been used in published RFCs. > > > > > > > > Original: > > > > Label Stack Element > > > > > > > > Updated: > > > > Label Stack Entry > > > > GIM>> Great catch, thank you. I agree. > > > > > > > > > > > > b) FYI - We have added expansions for the following abbreviations > > > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > > expansion in the document carefully to ensure correctness. > > > > > > > > Deterministic Networking (DetNet) > > > > Virtual Private LAN Service (VPLS) > > > > Media Access Control (MAC) > > > > GIM>> Thank you for your thorough work with the document. I agree. > > > > --> > > > > > > > > > > > > 17) <!-- [rfced] Please review the "Inclusive Language" portion of the > > > > online > > > > Style Guide > > > > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784567675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kHkZBO5Z23qFXGoNFVM0PCrpYoZBAxYcOL3NVr2u4Kk%3D&reserved=0> > > > > and let us know if any changes are needed. Updates of this nature > > > > typically > > > > result in more precise language, which is helpful for readers. > > > > > > > > Note that our script did not flag any words in particular, but this > > > > should > > > > still be reviewed as a best practice. > > > > GIM>> Thank you for checking that. I couldn't find anything that raises > > > > a red flag. > > > > --> > > > > > > > > > > > > Thank you. > > > > > > > > RFC Editor/rv > > > > > > > > > > > > > > > > On May 13, 2025, at 9:19 PM, rfc-edi...@rfc-editor.org wrote: > > > > > > > > *****IMPORTANT***** > > > > > > > > Updated 2025/05/13 > > > > > > > > RFC Author(s): > > > > -------------- > > > > > > > > Instructions for Completing AUTH48 > > > > > > > > Your document has now entered AUTH48. Once it has been reviewed and > > > > approved by you and all coauthors, it will be published as an RFC. > > > > If an author is no longer available, there are several remedies > > > > available as listed in the FAQ > > > > (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784582453%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z3V6Gxv8FlJg5n6TOhAcQuojj%2BLa1bdD5FmhQp%2Flpqk%3D&reserved=0). > > > > > > > > You and you coauthors are responsible for engaging other parties > > > > (e.g., Contributors or Working Group) as necessary before providing > > > > your approval. > > > > > > > > Planning your review > > > > --------------------- > > > > > > > > Please review the following aspects of your document: > > > > > > > > * RFC Editor questions > > > > > > > > Please review and resolve any questions raised by the RFC Editor > > > > that have been included in the XML file as comments marked as > > > > follows: > > > > > > > > <!-- [rfced] ... --> > > > > > > > > These questions will also be sent in a subsequent email. > > > > > > > > * Changes submitted by coauthors > > > > > > > > Please ensure that you review any changes submitted by your > > > > coauthors. We assume that if you do not speak up that you > > > > agree to changes submitted by your coauthors. > > > > > > > > * Content > > > > > > > > Please review the full content of the document, as this cannot > > > > change once the RFC is published. Please pay particular attention to: > > > > - IANA considerations updates (if applicable) > > > > - contact information > > > > - references > > > > > > > > * Copyright notices and legends > > > > > > > > Please review the copyright notice and legends as defined in > > > > RFC 5378 and the Trust Legal Provisions > > > > (TLP – > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784592133%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Y472Ad2Bhx8wrxYx6iZzfrADz%2FW%2Fx9cO2Qdq1wMW1w%3D&reserved=0). > > > > > > > > * Semantic markup > > > > > > > > Please review the markup in the XML file to ensure that elements of > > > > content are correctly tagged. For example, ensure that <sourcecode> > > > > and <artwork> are set correctly. See details at > > > > > > > > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784600855%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Fz3b80kDVz5rbuFMTQ7YqzY1gV3QvmzPQxqJ1qXlTVM%3D&reserved=0>. > > > > > > > > * Formatted output > > > > > > > > Please review the PDF, HTML, and TXT files to ensure that the > > > > formatted output, as generated from the markup in the XML file, is > > > > reasonable. Please note that the TXT will have formatting > > > > limitations compared to the PDF and HTML. > > > > > > > > > > > > Submitting changes > > > > ------------------ > > > > > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > > > > the parties CCed on this message need to see your changes. The parties > > > > include: > > > > > > > > * your coauthors > > > > > > > > * rfc-edi...@rfc-editor.org (the RPC team) > > > > > > > > * other document participants, depending on the stream (e.g., > > > > IETF Stream participants are your working group chairs, the > > > > responsible ADs, and the document shepherd). > > > > > > > > * auth48archive@rfc-editor.org, which is a new archival mailing list > > > > to preserve AUTH48 conversations; it is not an active discussion > > > > list: > > > > > > > > * More info: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784609522%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lCEQJM6VQuffPLjyMwRfqL2ieiBcjd4PjOrkG8x0%2FSU%3D&reserved=0 > > > > > > > > * The archive itself: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784618889%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bhPY1mMm4ILyDLwlGsz3bAPB23WPn7Jd2gl9tSsJN1w%3D&reserved=0 > > > > > > > > * Note: If only absolutely necessary, you may temporarily opt out > > > > of the archiving of messages (e.g., to discuss a sensitive > > > > matter). > > > > If needed, please add a note at the top of the message that you > > > > have dropped the address. When the discussion is concluded, > > > > auth48archive@rfc-editor.org will be re-added to the CC list and > > > > its addition will be noted at the top of the message. > > > > > > > > You may submit your changes in one of two ways: > > > > > > > > An update to the provided XML file > > > > — OR — > > > > An explicit list of changes in this format > > > > > > > > Section # (or indicate Global) > > > > > > > > OLD: > > > > old text > > > > > > > > NEW: > > > > new text > > > > > > > > You do not need to reply with both an updated XML file and an explicit > > > > list of changes, as either form is sufficient. > > > > > > > > We will ask a stream manager to review and approve any changes that seem > > > > beyond editorial in nature, e.g., addition of new text, deletion of > > > > text, > > > > and technical changes. Information about stream managers can be found > > > > in > > > > the FAQ. Editorial changes do not require approval from a stream > > > > manager. > > > > > > > > > > > > Approving for publication > > > > -------------------------- > > > > > > > > To approve your RFC for publication, please reply to this email stating > > > > that you approve this RFC for publication. Please use ‘REPLY ALL’, > > > > as all the parties CCed on this message need to see your approval. > > > > > > > > > > > > Files > > > > ----- > > > > > > > > The files are available here: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784627460%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GB78o%2BMYQPa41Ygqh3lsmUMwhSE2OF09RJizYbSgZII%3D&reserved=0 > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784635940%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nLeG8kyLLDkoAREIvumQkHGKC3788Ls2h7oPTJy7ePc%3D&reserved=0 > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784644536%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yIvwZyTo7liFuOqCpHbs04iy5UBQD33nts3%2BQY03L7I%3D&reserved=0 > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784653060%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d3sjwEZOnCMKl8UtzjuF9XVjSP361h8n6DyxdziQv68%3D&reserved=0 > > > > > > > > Diff file of the text: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784662032%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UGuSDqXzWlHprpPJMyO8k%2BDzBFOuAFM5DeApcaCLjXI%3D&reserved=0 > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784670950%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fZ9oKk1ZD%2F4wIJ3RqPJuICTnV4eVwEuLdIrLN%2FvkAmM%3D&reserved=0 > > > > (side by side) > > > > > > > > Alt-diff of the text (allows you to more easily view changes > > > > where text has been deleted or moved): > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-alt-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784679643%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sZdEMT0EEuP1oHf1W53tjfa2gJZ2grQwaHbI3hZ%2BWTU%3D&reserved=0 > > > > > > > > Diff of the XML: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9790-xmldiff1.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784688576%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RapNLHmXg%2B5xS6NvT%2BpD5PZv1hh9oVBHffyV0atp6wk%3D&reserved=0 > > > > > > > > > > > > Tracking progress > > > > ----------------- > > > > > > > > The details of the AUTH48 status of your document are here: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9790&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C06ce9085667d46e12f1f08dd9713a199%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638832832784697857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ovD%2B4ffW3NQ%2BFO487RZUwq3iqyDufXI7Ue%2FTDrkmbJg%3D&reserved=0 > > > > > > > > Please let us know if you have any questions. > > > > > > > > Thank you for your cooperation, > > > > > > > > RFC Editor > > > > > > > > -------------------------------------- > > > > RFC9790 (draft-ietf-mpls-1stnibble-13) > > > > > > > > Title : IANA Registry and Processing Recommendations for the > > > > First Nibble Following a Label Stack > > > > Author(s) : K. Kompella, S. Bryant, M. Bocci, G. Mirsky, L. > > > > Andersson, J. Dong > > > > WG Chair(s) : Tarek Saad, Tony Li, Adrian Farrel > > > > > > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
