Skip to main content

Last Call Review of draft-ietf-bess-evpn-irb-extended-mobility-18
review-ietf-bess-evpn-irb-extended-mobility-18-secdir-lc-sparks-2024-11-18-00

Request Review of draft-ietf-bess-evpn-irb-extended-mobility
Requested revision No specific revision (document currently at 21)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-11-19
Requested 2024-10-29
Authors Neeraj Malhotra , Ali Sajassi , Aparna Pattekar , Jorge Rabadan , Avinash Reddy Lingala , John Drake
I-D last updated 2025-04-30 (Latest revision 2024-12-04)
Completed reviews Rtgdir Early review of -10 by Donald E. Eastlake 3rd (diff)
Genart IETF Last Call review of -18 by Stewart Bryant (diff)
Secdir IETF Last Call review of -18 by Robert Sparks (diff)
Tsvart IETF Last Call review of -18 by Dr. Joseph D. Touch (diff)
Opsdir IETF Last Call review of -18 by Susan Hares (diff)
Intdir Telechat review of -18 by Brian Haberman (diff)
Assignment Reviewer Robert Sparks
State Completed
Request IETF Last Call review on draft-ietf-bess-evpn-irb-extended-mobility by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/w8t0DnPoVZqY0L7kXI-fdDKdI9Y
Reviewed revision 18 (document currently at 21)
Result Has nits
Completed 2024-11-18
review-ietf-bess-evpn-irb-extended-mobility-18-secdir-lc-sparks-2024-11-18-00
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 review
comments.

This document is difficult to read. There are structural issues, and maybe some
unnecessary content. I'm marking this "Has Nits" rather than "Has issues" since
as far as I can tell, the addition to protocol it describes have no new
security issues other than what is noted in the security considerations
section. Please consider whether there are other operational considerations
that might help avoid over-consumption of sequence numbers.

Nits:

Please look at the outline as reflected in the Table of Contents. In section 6,
there are things listed as "Requirements" that aren't requirements. Consider
separating discussion of the things like race conditions that lead to
requirements from the requirements and state the requirements succinctly.
Similarly section 5 claims to be about "components" but talks about things
(particularly in 5.3) that are not components themselves.

Consider removing most of the diagrams. They aren't leveraged well in the
discussion, and I don't think they advance understanding the problem or the
proposed protocol beyond the prose.

Please consider asking for early input from the RFC Editor.