RE: New Version Notification for draft-leiba-rfc2119-update-00.txt

John C Klensin <john-ietf@jck.com> Thu, 11 August 2016 14:56 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6B12D76B for <ietf@ietfa.amsl.com>; Thu, 11 Aug 2016 07:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 geQbmUOsPOom for <ietf@ietfa.amsl.com>; Thu, 11 Aug 2016 07:56:17 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EB512D59E for <ietf@ietf.org>; Thu, 11 Aug 2016 07:55:48 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bXrOX-0002pR-M3; Thu, 11 Aug 2016 10:55:42 -0400
Date: Thu, 11 Aug 2016 10:55:36 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>, Ted Lemon <mellon@fugue.com>, Stewart Bryant <stewart.bryant@gmail.com>
Subject: RE: New Version Notification for draft-leiba-rfc2119-update-00.txt
Message-ID: <745064B40DD3E2F1DEFCAA70@JcK-HP8200>
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30D9240CEB5@GLKXM0002V.GREENLNK.net>
References: <147077254472.30640.13738163813175851232.idtracker@ietfa.amsl.com> <CALaySJLHx7ytgZqZ9zQXA3vVSU-pNggQQs+QiDnzQ4tBEH5VAQ@mail.gmail.c om> <B31EEDDDB8ED7E4A93FDF12A4EECD30D9240CC47@GLKXM0002V.GREENLNK.net> <f30c2fb9-2f84-4ff1-8bd2-f70fe4201838@gmail.com> <CAPt1N1=1C0fprYQiN0httHHXiZPJCfO=epvKVL37Kx4QTGx+mw@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D9240CEB5@GLKXM0002V.GREENLNK.net >
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZWtPyBqsx_TV3vv9vUpc0a1xg3Q>
Cc: Barry Leiba <barryleiba@computer.org>, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2016 14:56:19 -0000

--On Thursday, August 11, 2016 13:38 +0000 "Dearlove,
Christopher (UK)" <chris.dearlove@baesystems.com> wrote:

> Plenty of standards use shall, but never must, as their
> imperative word. For example (the first standard I had to
> hand) ISO 27001 has many occurrences of shall (not
> capitalised, that seems to be an IETF special) and none of
> must.
>...

Hi.

This may be OBE given Barry's recent note about dropping the
text deprecating the synonyms but let me try to explain one
other issue just in the hope of increasing understanding as we
go forward.  Several people have commented that (most or all)
other standards bodies tend to use "SHALL" rather than "MUST",
etc.  At least some of the reason is that they, historically,
have thought about standards-writing in terms of conformance.
One "shall" do something if one is to conform and, because there
is almost never a notion of partially conforming, terms
equivalent to the way we use "SHOULD" have no role.

Traditionally, the IETF and its predecessors have been more
interested in interoperability than in conformance.   In an
interoperability context, statements like "you MUST do things
this way if implementations are to interoperate" and "you SHOULD
do things this way because it will increase the likelihood of
interoperation and operational success" make perfect sense.  

If the wording sounds a little awkward relative to the way other
SDOs write about conformance, that may actually be an advantage
for alerting people to the difference.

There is an additional complication: we make a formal
distinction between Technical Specifications (which should
always be about whet is needed for interoperability) and
Applicability Statements (which may reasonably contain
conformance clauses as well as making recommendations (note that
word) about the use of particular features.  Perhaps, in
retrospect, we should have separated non-technical (e.g., IETF
procedural) BCPs from ones about technical practices and TS
documents from AS ones and then specified different terminology
or definitions for each.  We didn't, and that has led to other
types of (IMO, time-wasting) arguments about whether the use of
2119 terms in BCPs, especially IETF process BCPs, is legitimate.
Similarly, if the focus is really as narrowly on
interoperability as 2119 seems to imply, a "MUST" in an
Experimental specification to express "this may be an
experiment, but we already know that, if you fail to do
so-and-so, things won't interoperate" makes perfectly good
sense, but we've had seemingly-endless arguments about that too.

Scott may remember how much those distinctions and
considerations figured into 2119 and how much, or if, they were
discussed at the time.  I don't remember.  But it seems to me
that those distinctions suggest that, unless there is consensus
that 2119 is broken enough for us to open up all of these issues
and completely revise how we do things, we should confine
ourselves to find-tuning (Section 2 of
draft-leiba-rfc2119-update, plus or minus further tuning seems
consistent with that) and editorial advice --to authors and to
the RFC Editor about what we consider a likely source of
problems that should be given attention-- and avoid trying to
mess with principles piecemeal.

best,
    john