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-...@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
> >
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
