[secdir] Secdir last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

Melinda Shore via Datatracker <noreply@ietf.org> Tue, 16 February 2021 05:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65C13A0DAC; Mon, 15 Feb 2021 21:19:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Melinda Shore via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: bess@ietf.org, draft-ietf-bess-evpn-oam-req-frmwk.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161345277284.30643.18088597111622319295@ietfa.amsl.com>
Reply-To: Melinda Shore <melinda.shore@nomountain.net>
Date: Mon, 15 Feb 2021 21:19:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4VMIavdPpc9NbHzWOOw04RM6l8I>
Subject: [secdir] Secdir last call review of draft-ietf-bess-evpn-oam-req-frmwk-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2021 05:19:33 -0000

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.

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'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").  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.