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 20)
Type 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 2024-11-18
Completed reviews Rtgdir Early review of -10 by Donald E. Eastlake 3rd (diff)
Genart Last Call review of -18 by Stewart Bryant (diff)
Secdir Last Call review of -18 by Robert Sparks (diff)
Tsvart Last Call review of -18 by Dr. Joseph D. Touch (diff)
Opsdir 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 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 20)
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.