Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 20 March 2014 10:59 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8B0681A06C3; Thu, 20 Mar 2014 03:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 0ppqZnebJVhT; Thu, 20 Mar 2014 03:59:07 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 992EF1A08B5; Thu, 20 Mar 2014 03:59:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6EA8EBE51; Thu, 20 Mar 2014 10:58:55 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag9Sk4quK3lc; Thu, 20 Mar 2014 10:58:54 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.46.29.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 18BA1BE4D; Thu, 20 Mar 2014 10:58:54 +0000 (GMT)
Message-ID: <532AC9ED.80108@cs.tcd.ie>
Date: Thu, 20 Mar 2014 10:58:53 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>, "Shaun Cooley (shcooley)" <shcooley@cisco.com>
References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <CAL0qLwYqNKmVH8ruEGBoh3A8h04hazda3X2q6ONuQHC4penTCQ@mail.gmail.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> <CAL0qLwYNLuUfYCmwV8dnohZEu_yX9Z883dJoMeo+HPis027gDQ@mail.gmail.com>
In-Reply-To: <CAL0qLwYNLuUfYCmwV8dnohZEu_yX9Z883dJoMeo+HPis027gDQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xUM4CyGD_1PNJDd-ts7jER29xJs
Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" <draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field
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: <http://www.ietf.org/mail-archive/web/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: Thu, 20 Mar 2014 10:59:08 -0000

On 03/20/2014 08:36 AM, Murray S. Kucherawy wrote:
> I can't recall the exact reason why it's been said that RFC2119 language
> ought not be used in Security Considerations (or similar) prose, or which
> document's development cycle brought it up, but my general recollection is
> that those words were intended to convey aspects of interoperability having
> to do with protocol elements, and not otherwise.  It would appear this
> opinion has formed since RFC3552 was published, since obviously there's a
> conflict between them.  But like I said, it does seem to vary depending on
> who and when one is asking.  Could also be the person(s) who told me this
> are actually plain wrong.
> 
> I'm happy to take direction from the sponsoring AD on this one.

I'm sure you'll get that.

FWIW, from my POV there should be no magical interactions between
RFC section headings and RFC 2119. You should do what makes sense
and is more clear for the reader. That can and often does include
using e.g. a 2119 MUST in the security considerations section.

In other words, I figure the folklore you describe above ought be
ignored and/or corrected. I do not believe that's written down
anywhere in an RFC or IESG statement, if you find it is, please let
me know and I'll try get it fixed.

S.