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
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… John R Levine
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… John Levine
- Re: New Version Notification for draft-leiba-rfc2… Randall Gellens (IETF)
- Re: New Version Notification for draft-leiba-rfc2… Joe Touch
- Re: New Version Notification for draft-leiba-rfc2… Gmail
- Re: New Version Notification for draft-leiba-rfc2… Brian E Carpenter
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Pete Resnick
- Re: New Version Notification for draft-leiba-rfc2… Joe Touch
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Pete Resnick
- Re: New Version Notification for draft-leiba-rfc2… Julian Reschke
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Julian Reschke
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Ben Campbell
- Re: New Version Notification for draft-leiba-rfc2… HANSEN, TONY L
- RE: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- RE: New Version Notification for draft-leiba-rfc2… Dearlove, Christopher (UK)
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- RE: New Version Notification for draft-leiba-rfc2… Dearlove, Christopher (UK)
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Doug Ewell
- Re: New Version Notification for draft-leiba-rfc2… Dave Cridland
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Time Warner Cable
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… John Leslie
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Randy Bush
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Mark Andrews
- Re: New Version Notification for draft-leiba-rfc2… John R Levine
- Re: New Version Notification for draft-leiba-rfc2… Mark Andrews
- Re: New Version Notification for draft-leiba-rfc2… John Levine
- Re: New Version Notification for draft-leiba-rfc2… Scott O. Bradner
- Re: New Version Notification for draft-leiba-rfc2… Joe Touch
- Re: New Version Notification for draft-leiba-rfc2… Sam Hartman
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Sam Hartman
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Stephan Wenger
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Ted Hardie
- Re: New Version Notification for draft-leiba-rfc2… Paul Hoffman