[Last-Call] Re: [bess] Secdir last call review of draft-ietf-bess-evpn-irb-extended-mobility-18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Robert,

Thanks for the review and comments. Have uploaded rev19 to address comments received from you and other reviewers. 

Please see inline for details.

On Mon, Nov 18, 2024 at 8:12 AM Robert Sparks via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Robert Sparks
Review result: Has Nits

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.

[NM]: ack. Modified section 6 title in rev19 to "Methods for Sequence Number Assignment". Section 5 does talk about three main parts to the solution that we are calling "Solution Components". This includes section 5.3 which was perhaps not clearly titled - I have modified the title in rev19 to "Sequence Number Synchronization"
 

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.

[NM]: I did discuss with other authors and concluded that since node and host names in the diagrams are extensively used in the text to describe the scenarios, we will retain the diagrams.

Thanks,
Neeraj

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux