Re: SHOULD vs MUST

Dean Willis <dean.willis@softarmor.com> Wed, 25 June 2008 18:09 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69CD28C0F1; Wed, 25 Jun 2008 11:09:35 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660F03A6AAB for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 11:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9Hb3XBbrlJn for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 11:09:34 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 40C5A3A6AB6 for <ietf@ietf.org>; Wed, 25 Jun 2008 11:09:34 -0700 (PDT)
Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m5PI9VuU027472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Jun 2008 13:09:32 -0500
Message-Id: <9186BADD-32A9-47C6-BCCC-DA7A040ED11E@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Fred Baker <fred@cisco.com>
In-Reply-To: <5F870CB0-73C5-4E5D-BFB3-A09BB98B3991@cisco.com>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: SHOULD vs MUST
Date: Wed, 25 Jun 2008 13:09:25 -0500
References: <20080525020040.4DE5A5081A@romeo.rtfm.com> <F66D7286825402429571678A16C2F5EE03ADF950@zrc2hxm1.corp.nortel.com> <20080620195947.29D0B5081A@romeo.rtfm.com> <9D9CF008-7350-4831-8F21-E08A0A7B255E@insensate.co.uk> <7706.1214216391.855029@peirce.dave.cridland.net> <g3ror8$2b9$1@ger.gmane.org> <900B2F8D-5960-4277-9DBC-E59A05F1CFBA@cisco.com> <48623304.1050008@employees.org> <2D990430F5F5D3C7984BDFDF@p3.JCK.COM> <5F870CB0-73C5-4E5D-BFB3-A09BB98B3991@cisco.com>
X-Mailer: Apple Mail (2.924)
Cc: John C Klensin <john-ietf@jck.com>, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jun 25, 2008, at 7:46 AM, Fred Baker wrote:

> I was about to write something like that to Scott; thanks for making  
> it unnecessary.
>
> My additional comment is that if there is some case I can think of  
> that leads me to say "should", there might also be another that I  
> didn't think of. Asking me to detail them all up front is IMHO  
> asking too much. On the other hand, I wouldn't be at all bothered by  
> being told that I had to justify a "must" - since in my mind it is  
> something to be used when not doing the action has a predictable  
> negative outcome, asking the author to say what that predictable  
> negative outcome would be is reasonable.
>
> My bottom line on a "should" is that if an implementer doesn't do  
> what the specification says he "should", he should have a good  
> reason and be prepared to explain it if questioned (for example by a  
> customer or during an interoperability test). "I disagreed with the  
> spec" is *not* a good reason, although it might be a good reason to  
> implement it and provide a configuration knob that turned that  
> functionality off, whatever it was.
>

I believe that in every instance that RFC 2119 language is used to  
state a requirement that there is either an implicit or explicit  
statement of consequences that are likely to occur if that requirement  
is violated. Further,  I believe that it is better to make those  
statements of consequence explicit, and that the severity of the  
consequences needs to support the severity of the requirements language.

We have a tendency to use RFC 2119 requirements language much too  
liberally. For example, it is frequently used in explication to show  
what happens, e.g. "To reach Bob, Alice MUST send him an INVITE  
request". There is of course a substantial difference between a  
description of what does happen, and a statement of requirement  
against which there are consequences if that requirement is not met. I  
believe that the clarity of our specifications and our ability to  
generate test plans against those specifications would greatly benefit  
from a concerted effort to reduce these spurious usages of RFC 2119  
requirements language.

The difference between an appropriately used  SHOULD and a MUST is one  
of severity of the consequences. MUST level requirements have the  
consequence that, if ignored, interoperability failure or other  
grievous harm is reasonably likely to occur. SHOULD level requirements  
have consequences of a different order; if the requirement is not met,  
some operational or functional benefit will not be achieved. MAY level  
requirements have consequences that are at the level of personal  
preference, esthetics, flavor, or style.

I try, but often fail, to convince authors to explicitly describe the  
consequences surrounding every RFC 2119 requirement, and to be frugal  
in the use of such requirements in their text. It is not to our  
advantage to  require a reader to be an expert in the subject to  
determine what the consequence of ignoring such a requirement may be,  
or we in effect require every reader of a specification to be an  
expert in the underlying art. Further, only clear statement of the  
consequences allow the reviewer of a draft to understand and make a  
judgement about the appropriateness of the strength with which a  
requirement is made.

While it is always true that there may exist rationale for a  
requirement that is not known to an author at the time of writing,  
failure to record any such rationale in a specifications seem to me to  
be a likely indicator that the specification has not been adequately  
thought through by the author, making it not yet ready for publication.

--
Dean
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf