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://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://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)
For the AUTH48 status of this document, please see:
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 ]
>
> 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://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)
>
> 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 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://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%7C8f9821d8e9c94a4affb208dd93f38fd0%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638829396764446385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=gz3KCSRJkFUXqjZhW6jTKBtAxqfOPeeoJY0WaeOwpIk%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://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://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://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://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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >
> > * The archive itself:
> > 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://www.rfc-editor.org/authors/rfc9790.xml
> > https://www.rfc-editor.org/authors/rfc9790.html
> > https://www.rfc-editor.org/authors/rfc9790.pdf
> > https://www.rfc-editor.org/authors/rfc9790.txt
> >
> > Diff file of the text:
> > https://www.rfc-editor.org/authors/rfc9790-diff.html
> > 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://www.rfc-editor.org/authors/rfc9790-alt-diff.html
> >
> > Diff of the XML:
> > https://www.rfc-editor.org/authors/rfc9790-xmldiff1.html
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> > 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
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
