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

John C Klensin <klensin@jck.com> Sat, 13 August 2016 01:57 UTC

Return-Path: <klensin@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 74DF712D0EB for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 18:57:42 -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 cs9dmUsVMlZi for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 18:57:41 -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 166BF12D675 for <ietf@ietf.org>; Fri, 12 Aug 2016 18:57:41 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1bYOCd-0006YO-58; Fri, 12 Aug 2016 21:57:35 -0400
Date: Fri, 12 Aug 2016 21:57:30 -0400
From: John C Klensin <klensin@jck.com>
To: Pete Resnick <presnick@qti.qualcomm.com>, Stewart Bryant <stewart.bryant@gmail.com>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
Message-ID: <CEDD538D1242500E6610ACBD@JcK-HP8200>
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: klensin@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/PWQwVMEBq8Nv7pEGhk0aBMZhgdU>
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: Sat, 13 Aug 2016 01:57:42 -0000


--On Friday, August 12, 2016 18:13 -0500 Pete Resnick
<presnick@qti.qualcomm.com> wrote:

>...
> One last (and perhaps fruitless) attempt to keep this section
> and deprecate the adjectives:
> 
> Using REQUIRED and OPTIONAL results in exactly the problem of
> using passive voice anywhere: REQUIRED by whom? OPTIONAL for
> whom? If you say, "A MUST do X and B MAY do Y", it is
> perfectly clear which actor is responsible (and in network
> protocols there are inevitably at least 2). If you say "X is
> REQUIRED and Y is OPTIONAL", you'll end up needing more text
> to explain the actors and their roles.
> 
> Using REQUIRED and OPTIONAL is lazy. It makes specs less
> clear. They ought to be dropped.

Pete,

Just for the record, I agree that REQUIRED and OPTIONAL cause
more problems than they are worth and should be dropped.  But
doing so is (obviously) controversial.  It may be entangled with
a few other things, like the T/S <-> A/S distinction and the
terminology we should be using for them (and Experimental, BCP,
and procedural BCP, documents).   So, as a mostly-rhetorical
question, do you think that, if we were going to open one of the
many issues in 2119 that might reasonably be addressed but that
would be controversial, do you think those two words top the
list?  As another one, if the IESG simply told the RFC Editor to
make sure that, if REQUIRED or OPTIONAL appeared in a spec, the
relevant section needed to be completely clear, would that be a
road to solving the problem that would not require a change to
2119?  

Note that 2119 doesn't say those terms are allowed, only what
they mean if they are allowed and used. A decision that they are
allowed iff the authors can convince the RFC Editor that the
relevant specs are clear and that the usage is not lazy would be
completely consistent with that.

  best,
    john