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

Pete Resnick <presnick@qti.qualcomm.com> Sat, 13 August 2016 00:20 UTC

Return-Path: <presnick@qti.qualcomm.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 041A712D88E for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 17:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.267
X-Spam-Level:
X-Spam-Status: No, score=-8.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 BcKO29uIZSyz for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 17:20:08 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702DA12D7EF for <ietf@ietf.org>; Fri, 12 Aug 2016 17:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1471047608; x=1502583608; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=nmBv0y22eqjaCFlc60hWz9S6UHOwRJqcHX+jriAKzHA=; b=DB8SqBlX9wUv3UrndfguhLSzvlVUh9UIMh1zWDJBtJsw783qJRkIB+xH u69SceFVxLyMeTm48CawRroyKqXtJbSQVywXoKfpREv9rO2U13Mi/hFe2 VX1JWfHqKEGIwHYP9z5AzMkzvJU2XAPV98ls2mOZ5zwwMifBxCxR68kZV s=;
X-IronPort-AV: E=Sophos;i="5.28,513,1464678000"; d="scan'208,217";a="216290912"
Received: from unknown (HELO Ironmsg04-L.qualcomm.com) ([10.53.140.111]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Aug 2016 17:20:07 -0700
X-IronPort-AV: E=McAfee;i="5700,7163,8255"; a="1180775705"
X-Amp-Result: CLEAN
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Aug 2016 17:20:07 -0700
Received: from [10.64.229.149] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 12 Aug 2016 17:20:06 -0700
From: Pete Resnick <presnick@qti.qualcomm.com>
To: Joe Touch <touch@isi.edu>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
Date: Fri, 12 Aug 2016 19:20:04 -0500
Message-ID: <5A419C3F-E7C7-47E8-B1D6-ED5F09AFED89@qti.qualcomm.com>
In-Reply-To: <6433bb28-3e68-a18b-6bec-6017701baa03@isi.edu>
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> <6433bb28-3e68-a18b-6bec-6017701baa03@isi.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_ED1B225C-C5B2-4505-B3CC-3B8FBAA628C8_="
X-Mailer: MailMate (1.9.4r5239)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/194dd9eHPFixDfbJkpFPB3RhWSQ>
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:20:10 -0000

On 12 Aug 2016, at 19:04, Joe Touch wrote:

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

Perfect example. That passive construction is just as bad as "X is 
REQUIRED". That's a compliance statement, not an interoperability 
statement as required by 2119. When "X" is a feature (not a protocol 
operation) what does "X MUST be supported" even mean? Why MUST it be 
supported? What interoperability problem does it cause if I choose to do 
otherwise? 99 times out of 100, when I've see "X is REQUIRED" or "X MUST 
be supported", it's a completely bogus use.

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

And I would say don't use any of them. ("X is a MUST" is an 
abomination.)

> 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.

Rewriting things to use an adverb is good because it requires you to 
have a verb. If the verbs are "support" or "comply", it's a pretty good 
sign that you're making the spec less clear.

> 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.

Violent agreement on that one.

pr

> 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/>
Qualcomm Technologies, Inc. - +1 (858)651-4478