Last Call Review of draft-ietf-mpls-mna-fwk-12
review-ietf-mpls-mna-fwk-12-secdir-lc-meadows-2024-11-07-00
Request | Review of | draft-ietf-mpls-mna-fwk |
---|---|---|
Requested revision | No specific revision (document currently at 14) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-11-11 | |
Requested | 2024-10-21 | |
Authors | Loa Andersson , Stewart Bryant , Matthew Bocci , Tony Li | |
I-D last updated | 2024-11-07 | |
Completed reviews |
Rtgdir Early review of -06
by Toerless Eckert
(diff)
Rtgdir Last Call review of -11 by Donald E. Eastlake 3rd (diff) Secdir Last Call review of -11 by Catherine Meadows (diff) Genart Last Call review of -12 by Jouni Korhonen (diff) Secdir Last Call review of -12 by Catherine Meadows (diff) Tsvart Last Call review of -12 by Joerg Ott (diff) |
|
Assignment | Reviewer | Catherine Meadows |
State | Completed | |
Request | Last Call review on draft-ietf-mpls-mna-fwk by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/TM7Gg9ktkYic8KreHTPZT0nkVzM | |
Reviewed revision | 12 (document currently at 14) | |
Result | Has nits | |
Completed | 2024-11-07 |
review-ietf-mpls-mna-fwk-12-secdir-lc-meadows-2024-11-07-00
My apologies! I confused version 11 with version 12, and my review of version 11 was actually a review of version 12. So I will just enter it again: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready With Nits. This draft concerns MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions that impact forwarding or other processing of the packet along the Label Switched Path (LSP)and to transfer any additional information needed for such processing. They are generally carried in sub-stacks within the MPLS label stack. This document describes requirements on solutions, and an architecture is proposed that is intended to capture best practices. If a practice has issues but also has benefits, the issues are pointed out, but the practice is not discouraged; instead mitigations are suggested. I think this is a good approach to the topic, and the draft gives helpful advice that deserves to be captured in an Informational RFC. The following paragraph has a nit: The same is true for a BIER payload as for any use of the first nibble: it is not possible to conclude that the payload is BIER even if the first nibble is set to 5 because an Ethernet pseudowire without a control word might begin with a 5. However, the BIER approach meets the design goal of [RFC8296] to determine that the payload is IPv4, IPv6 or a pseudowire using a control word. I think that that last should “a pseudowire not using a control word”