Re: [secdir] secdir review of draft-ietf-bess-spbm-evpn-02

Barry Leiba <barryleiba@computer.org> Wed, 07 October 2015 20:02 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4141B2A69; Wed, 7 Oct 2015 13:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgRi9u8mlG1P; Wed, 7 Oct 2015 13:02:45 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D33C1B2FC4; Wed, 7 Oct 2015 13:02:45 -0700 (PDT)
Received: by vkat63 with SMTP id t63so18899394vka.1; Wed, 07 Oct 2015 13:02:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Y6QebDfk7ZfXrE8d6cONLSUM0MVvcCoLA/ZBew99kBs=; b=zvOztmN/BhBVDCjuOPdUh581Q/fpxS2wZVWspRA0XlF7oCA5AEcaUMmGeujJG+FPLZ SMJqWBUkGSDPM1c9q7t0C7SSzrM/q4iU5QbLMBghkcKiVkp4NaiHFo+0LhrTynXnzG1E Lt6f+iDhk3PJMaLeDIgCY688wxLCI/VRYwPDdRI991VSf+MfWgWdqCy2q28bHUnSBNHQ 7z9IbbHvgcwovDscqD6W4yhvP63zHNYYBEexD7MFlMVLNuzscc7FxunPt78fZ2Uu3S60 Aca6rl4vpOya6Nv79WKs1K/wsov36fz54kQIIMwksRKSSVuj9KP7nRT5P3oiipCk7Y2f ybEg==
MIME-Version: 1.0
X-Received: by 10.31.192.9 with SMTP id q9mr2514879vkf.63.1444248164362; Wed, 07 Oct 2015 13:02:44 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.31.88.196 with HTTP; Wed, 7 Oct 2015 13:02:44 -0700 (PDT)
In-Reply-To: <28535528a17e73ee9a093c8f86a1de3b.squirrel@www.trepanning.net>
References: <28535528a17e73ee9a093c8f86a1de3b.squirrel@www.trepanning.net>
Date: Wed, 7 Oct 2015 13:02:44 -0700
X-Google-Sender-Auth: R7Xnju2koRXURyHxP8G3R3FYh7I
Message-ID: <CALaySJKNBhPaYOnV5KUvuvwod8BZcYMV5mLvfw=R0kvEuKyzDA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/xjUGnUoRYGoxw4expE31H2R4tPo>
Cc: draft-ietf-bess-spbm-evpn.all@tools.ietf.org, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-bess-spbm-evpn-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Wed, 07 Oct 2015 20:02:47 -0000

Hi, Dan, and thanks for the SecDir review.

>   After an overview the body of the draft is basically a single
> section  ("4. Elements of Procedure") that states "A PE MUST implement
> and perform the following operations" but none of the following
> subsections contain any normative text. I think some normative
> text is needed in each of the sub-sections, e.g instead of "The
> following is configured..." maybe "The following SHALL be
> configured...").

I've seen similar comments about other documents, and I find it
troubling that we often consider that the only statements that are
normative are ones that include 2119 key words.  I think that is not
at all so, and that what we say in a standards document *is* normative
unless we say otherwise.

I have not yet reviewed this document, so I might see it differently
when I do, but I've just taken a look at Section 4.1 to see Dan's
example.  I don't see why anything needs to be changed: the text, as
it is, is clear that the specified items have to be configured.  What
would adding "SHALL" or "MUST" change here?  Does the existing text
seem to give anyone any options here?  As I read the current text, if
I fail to include a route target or an SPSourceID in the
configuration, I am not complying with this specification.

Now, I generally think we overuse 2119 key words, so that's where I'm
starting from.  But honestly: how does adding 2119 key words to
Section 4.1 improve it?

Barry