Hi Melinda On Tue, Feb 16, 2021 at 12:19 AM Melinda Shore via Datatracker <noreply@xxxxxxxx> wrote: > Reviewer: Melinda Shore > Review result: Has Nits > > This is a very nicely-structured, efficient, well-written document - among the > most clearly-written that I've read in a few years. Thanks. > Nits: As a minor point, I am really not a fan of using RFC 2119 language for > informational documents, and in this case it's being used somewhat > inconsistently (for example, the lowercase "must" in section 4). I agree that usage should be consistent. I'll capitalize that "must". As to the general question of using RFC 2119 language in this document, I guess we will see what the IESG says. > I'm also a > bit unclear on what's intended by "must optionally authenticate" and suggest > that that should be clarified as to whether what's meant is "mandatory to > implement but optional to use," or "optional to implement" and should probably > be a "SHOULD" (or a "should"). Of the three points listed in the Security Considerations, I would agree that the first two should be SHOULD. But the third, preventing OAM packet leaking, is, I believe, correctly a MUST. "Optionally authenticate communicating endpoints" refers, in opinion, to an implementation requirement, not a use requirement. > Additionally, it may be helpful to provide an > example or two of how the EVPN OAM channel could be exploited as a DOS vector, > and to explain what problem is solved by authenticating EVPN endpoints. One example would be forged communications that overflow the capability of an OAM endpoint to maintain state. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
