Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 05 November 2015 22:46 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DF1B3CDC for <bfcpbis@ietfa.amsl.com>; Thu, 5 Nov 2015 14:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 2dhvT-INDclS for <bfcpbis@ietfa.amsl.com>; Thu, 5 Nov 2015 14:46:27 -0800 (PST)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6731B3CDB for <bfcpbis@ietf.org>; Thu, 5 Nov 2015 14:46:27 -0800 (PST)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-12v.sys.comcast.net with comcast id dymJ1r00329Cfhx01ymSvh; Thu, 05 Nov 2015 22:46:26 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id dymS1r00A3KdFy101ymS1A; Thu, 05 Nov 2015 22:46:26 +0000
To: bfcpbis@ietf.org
References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <CAKKJt-ci2kndZsxmkUKchWCcEPApvoFT9QMsw6MeC7hfKso3tQ@mail.gmail.com> <D261445D.5E397%eckelcu@cisco.com> <CAKKJt-euqJ6skSf_0ivT04Yi5NpGPBSeWTOOiJRqq5QOrS61xA@mail.gmail.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <563BDC41.3030006@alum.mit.edu>
Date: Thu, 05 Nov 2015 17:46:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446763586; bh=rFMY//rOjNiEDvvRo2YIF1lZ76nHj4hlzJakb8CxYf4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uDCvvjjcU/Q2p6UPQuufQ92Mc7v+1sVI4U8tcD2iHDY6sG7UewJC4nTLQntvKxzox XdfsaeIFwpmJtrqV1/SjUSY+JIfuorDiUw2xt1TZncisJPs5VrCTP87fD5DNGvBuMv pAw0a3VAuspy6UXK+SylK8Jh4TTNhzOuU0HN/EjRwY3EfxMyf3ijNuAkCh5ZAq7z37 OTxHAzuxAmQ9xrtjtDXJB2kLfYtGrUKffqRA4vS0peeSh6c1iiuWLP3xuOrbGXncND 46f6+lUza2gRZ+3lD/NISOZbOPTjJLpTOd9oTwfCDpy/FtVgU43C1TrxHv/v6aoKEx 3ce2WrIhccqmA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/Eed5xCRReKjBKJsHK_CMtSaLx94>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 22:46:28 -0000

On 11/5/15 5:06 PM, Alissa Cooper wrote:

> "REQUIRED unless" strikes me as a faulty construction. That case is what
> RECOMMENDED is for, when there is a known exception to the requirement.

I don't think I agree.

I think "REQUIRED unless" is quite precise. Using "RECOMMENDED unless" 
says to me that in cases where the the "unless" doesn't apply then 
RECOMMENDED applies and hence can still be violated for cause.

Historically, SHOULD/RECOMMENDED has been used in a rather casual way, 
in the spirit of "we trust you to be responsible about this". And it 
hasn't worked out well. So now we at least *say* that you ought not use 
SHOULD/RECOMMENDED without being explicit about the conditions when it 
is acceptable to violate it. At that point, the distinction between MUST 
and SHOULD goes away.

I think the following constructions are most clear:

- You MUST do foobar except when blah blah blah.
- You are REQUIRED to do foobar except when blah blah blah.
- You SHOULD do foobar. The only acceptable situation to not do foobar
   is blah blah blah.
- It is RECOMMENDED that you do foobar. The only acceptable situation
   to not do foobar is blah blah blah.

I have had implementers tell me that when they get an assignment to 
implement a spec, their management tells them to only do the MUSTs, 
because that is all that is required to satisfy the checkoff!

	Thanks,
	Paul