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

Pete Resnick <> Sat, 13 August 2016 00:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 041A712D88E for <>; Fri, 12 Aug 2016 17:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.267
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BcKO29uIZSyz for <>; Fri, 12 Aug 2016 17:20:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 702DA12D7EF for <>; Fri, 12 Aug 2016 17:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; 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 ([]) by 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 ([]) by with ESMTP/TLS/RC4-SHA; 12 Aug 2016 17:20:07 -0700
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 12 Aug 2016 17:20:06 -0700
From: Pete Resnick <>
To: Joe Touch <>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
Date: Fri, 12 Aug 2016 19:20:04 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_ED1B225C-C5B2-4505-B3CC-3B8FBAA628C8_="
X-Mailer: MailMate (1.9.4r5239)
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Archived-At: <>
Cc: Barry Leiba <>, IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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


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