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

"Dan Harkins" <> Thu, 08 October 2015 07:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 67E141B323B; Thu, 8 Oct 2015 00:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tsweum35Vj8d; Thu, 8 Oct 2015 00:08:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D53CC1ACDE5; Thu, 8 Oct 2015 00:08:43 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 719B010224008; Thu, 8 Oct 2015 00:08:43 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Thu, 8 Oct 2015 00:08:43 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <> <>
Date: Thu, 8 Oct 2015 00:08:43 -0700 (PDT)
From: "Dan Harkins" <>
To: "Barry Leiba" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <>
Cc:, IESG <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-bess-spbm-evpn-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Oct 2015 07:08:45 -0000

  Hi Barry,

On Wed, October 7, 2015 1:02 pm, Barry Leiba wrote:
> 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.

  The problem is the passive voice does not instruct implementations

> 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.

  The _overview_ (which is arguably informative) has more normative
statements than the body of the draft that is supposed to instruct
implementations in how to behave! And the body of the draft says that
implementations MUST do a collection of passive-voiced and conditional

> 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?

  It alerts an implementer to something he or she needs to pay
attention to because it has interoperability implications.

  If nothing in subsections 4.1 to 4.8 need normative text then get
rid of the RFC 2119 word in section 4 that compels an implementation
to behavior that is passive-voiced and conditional.

  Overuse of RFC 2119 key words may be attracting your attention
but the issue here is not an overuse but a dearth of them. On the
other hand, if you're so concerned about overuse of RFC 2119 words
then maybe you should make a comment on this draft that putting
such normative statements in something like an informative overview
is not appropriate. If RFC 2119 words are not necessary when describing
the protocol behavior then they are certainly not necessary in an
informative overview. And therefore there is no reason to reference
RFC 2119 in this Standards Track RFC.


> Barry