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

Joe Touch <touch@isi.edu> Sat, 13 August 2016 00:05 UTC

Return-Path: <touch@isi.edu>
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 2F25212D8B1 for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 17:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.146
X-Spam-Level:
X-Spam-Status: No, score=-3.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3ov2TZgFIT3M for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 17:05:14 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5BE12D89C for <ietf@ietf.org>; Fri, 12 Aug 2016 17:05:14 -0700 (PDT)
Received: from [128.9.184.139] ([128.9.184.139]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u7D04l4q011952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 12 Aug 2016 17:04:48 -0700 (PDT)
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
To: Pete Resnick <presnick@qti.qualcomm.com>, Stewart Bryant <stewart.bryant@gmail.com>
References: <147077254472.30640.13738163813175851232.idtracker@ietfa.amsl.com> <CALaySJLHx7ytgZqZ9zQXA3vVSU-pNggQQs+QiDnzQ4tBEH5VAQ@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D9240CC47@GLKXM0002V.GREENLNK.net> <f30c2fb9-2f84-4ff1-8bd2-f70fe4201838@gmail.com> <379B29D6-2C56-4EB1-BA50-4740A605C9D0@qti.qualcomm.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <6433bb28-3e68-a18b-6bec-6017701baa03@isi.edu>
Date: Fri, 12 Aug 2016 17:04:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <379B29D6-2C56-4EB1-BA50-4740A605C9D0@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary="------------D9D9B60F2D180672F3CE90E5"
X-MailScanner-ID: u7D04l4q011952
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cD3QpdHX3yED8BFD1erquTnjdPY>
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 00:05:15 -0000

It's inefficient to repeat the phrase "X MUST be supported by any
implementation that complies with this specification".

The phrase "X is REQUIRED", RECOMMENDED, or OPTIONAL corresponds to the
incorrect English of "X is a MUST".

I.e., these are reasonable adjective forms of the adverbs
MUST/MAY/SHOULD. Omitting these adjectives then requires authors to
select their own adjective forms or to have to rewrite everything as an
adverb.

IMO, if you want to drop anything, drop the MUST/MAY/SHOULD - directives
of protocol specs should describe the spec, not the actions of the
implementer.

Joe


On 8/12/2016 4:13 PM, Pete Resnick wrote:
>
> On 11 Aug 2016, at 6:44, Stewart Bryant wrote:
>
>     Optional is useful in a requirements RFC.
>
>     Feature x is REQUIRED
>
>     Feature y is OPTIONAL
>
> 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.
>
> pr
> -- 
> Pete Resnick http://www.qualcomm.com/~presnick/
> <http://www.qualcomm.com/%7Epresnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>