Adrian, thank you for your exceptional Shepherding. I agree with all the updates, including the ones noted in Adrian's email. Please let me know if there are any outstanding questions.
Regards, Greg On Wed, Jun 18, 2025 at 10:20 AM Adrian Farrel <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
