Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24

Richard Barnes <rlb@ipv.sx> Wed, 30 October 2013 14:47 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFE711E8180 for <secdir@ietfa.amsl.com>; Wed, 30 Oct 2013 07:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.892
X-Spam-Level:
X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA92aqSyTBcT for <secdir@ietfa.amsl.com>; Wed, 30 Oct 2013 07:47:12 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB68011E8221 for <secdir@ietf.org>; Wed, 30 Oct 2013 07:47:11 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id l20so1547279oag.3 for <secdir@ietf.org>; Wed, 30 Oct 2013 07:47:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iXRPR1n8zTI9DKYJTcLV5r4MjjAUaP46keIs99tZGMs=; b=Agf1pl/pzP4lpPSkWb+qdGqdhGK0fzGShZo3oCu4MktBIicNG1FxOr3GFPI1J65qC5 97m6OeUIrGDQyIoxWF/i4QUnyBOpS8FU1boiy2VDJ3AAEer5rHKSSpvNDR3iXTp85kXU 48wzIxWdcqj1bYCq0lIRH+YWlMGh1LXnRNAXAUdVvaVMbrrY0ryAVlqR9tG7Tqo2VFb9 outDNM2wEq+af1ej5y/+iZpiaWwtU6jbJH5S3nV9JkcPfYE73B6YB6Wf2Bhg5jF3yy0y EwGYPifJz5c/zmkGW44ZcId0RvBNkPTGA507yb9iPkZFy3YQRgrNv9grljaWlbr69esR Tx2Q==
X-Gm-Message-State: ALoCoQlE/eICM7P7AfOYLeJyZ9YQoYuR25xYgEUkCEPj153Bkz5Q4BHJOs5gFLwnDPkp8rnfax85
MIME-Version: 1.0
X-Received: by 10.182.229.163 with SMTP id sr3mr556097obc.79.1383144431290; Wed, 30 Oct 2013 07:47:11 -0700 (PDT)
Received: by 10.76.101.10 with HTTP; Wed, 30 Oct 2013 07:47:11 -0700 (PDT)
In-Reply-To: <5271105A.10105@gmx.de>
References: <52700DE4.8020208@bbn.com> <5271051E.4040908@gmx.de> <CAL02cgRdWK77ZCu32KA2p3_5+CrmC9v=fyUMBJXgQrT1qSUz4g@mail.gmail.com> <5271105A.10105@gmx.de>
Date: Wed, 30 Oct 2013 10:47:11 -0400
Message-ID: <CAL02cgT+UZ18Lvm68rbKBzTHsfeO9Bf=us0W3a8dsMdc2boA6g@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=001a1136221e8021cd04e9f668a2
Cc: secdir <secdir@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, "fielding@gbiv.com" <fielding@gbiv.com>, "Mankin, Allison" <amankin@verisign.com>, HTTP Working Group <ietf-http-wg@w3.org>, Barry Leiba <barryleiba@computer.org>, "mnot@pobox.com" <mnot@pobox.com>
Subject: Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 14:47:18 -0000

On Wed, Oct 30, 2013 at 9:57 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2013-10-30 14:42, Richard Barnes wrote:
>
>> ...
>>
>> Do you mean that your intent was ought==should and might==may?
>>
>> Why do you feel the need to avoid SHOULD and MAY here?  They don't place
>> any more burden on implementors than "ought" and "might".
>> --Richard
>> ...
>>
>
> I believe in following the guidance in RFC 2119:
>
>  6. Guidance in the use of these Imperatives
>>
>>    Imperatives of the type defined in this memo must be used with care
>>    and sparingly.  In particular, they MUST only be used where it is
>>    actually required for interoperation or to limit behavior which has
>>    potential for causing harm (e.g., limiting retransmisssions)  For
>>    example, they must not be used to try to impose a particular method
>>    on implementors where the method is not required for
>>    interoperability.
>>
>
> I also note that there clearly is no community consensus about what the
> right degree of 2119 usage is. Until there is such thing, I recommend that
> we focus on 2119 keywords being used when they are needed, and not
> bike-shed over the other instances as long as the specification is
> consistent with respect to this.
>

The key word there, though, is "imperatives".  Nothing we're talking about
here is an imperative, just a recommendation (or RECOMMENDATION).  Skimming
through the instances of "ought to" in the document, it seems like they all
meet the definition of "SHOULD" in 2119, i.e., things that implementations
should only diverge from if they have a good reason.  (In fact, there are
some that seem like they should be "MUST", but that's a different topic.)

--Richard



> Best regards, Julian
>
>
>