[auth48] Re: [AD] Re: AUTH48: RFC-to-be 9790

Fri, 20 Jun 2025 09:17:06 -0700

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)
Stewart Bryant <s...@stewartbryant.com>; Dongjie (Jimmy)
MPLS Working Group <mpls-cha...@ietf.org>; auth48archive
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:
 
— FILES (please refresh) —
 
Updated XML file:
 
Updated output files:
 
Diff file showing changes made during AUTH48:
between last version and this)
last version and this)
 
Diff files showing all changes:
changes where text is moved or deleted)
 
For the AUTH48 status of this document, please see:
 
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
>
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

Reply via email to