Re: Question about BCP 14 / RFC 8174

John C Klensin <john-ietf@jck.com> Fri, 29 August 2025 02:47 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 16FD25A660B3 for <ietf@mail2.ietf.org>; Thu, 28 Aug 2025 19:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbdlY_M9X18W for <ietf@mail2.ietf.org>; Thu, 28 Aug 2025 19:47:32 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id C8C905A660AE for <ietf@ietf.org>; Thu, 28 Aug 2025 19:47:32 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1urp9D-000ODl-Is; Thu, 28 Aug 2025 22:47:27 -0400
Date: Thu, 28 Aug 2025 22:47:20 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Toerless Eckert <tte@cs.fau.de>
Subject: Re: Question about BCP 14 / RFC 8174
Message-ID: <D739413C0AE13FFFFCB670A2@PSB>
In-Reply-To: <51f521aa-0b66-4f35-a9b1-815cb92a169e@gmail.com>
References: <aKzK5qdwLUHSa3JL@ubby> <CAC4RtVASn123qUSuFZg50wL4Nrjebz=QMf5AU=jeZLgQd5fsDg@mail.gmail.com> <9953f535-672f-49de-8b8f-9e1a471d97b8@gmail.com> <aLDiRY6Tw7PTKQoy@faui48e.informatik.uni-erlangen.de> <51f521aa-0b66-4f35-a9b1-815cb92a169e@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Message-ID-Hash: DKRQAAXTQES6YRLBNKTTOCGZ7DOAKZ4P
X-Message-ID-Hash: DKRQAAXTQES6YRLBNKTTOCGZ7DOAKZ4P
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ietf@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XMYjNnbH5bAVTAmDOuI2vL3JBzo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>


--On Friday, August 29, 2025 11:45 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> Toerless, I agree with you but again, my concern is not really
> about MUST/MANDATORY or MAY/OPTIONAL. It's about
> SHOULD/RECOMMENDED, where it might often be better to write MUST...
> UNLESS without BCP 14 really being needed.
> 
> As in "You SHOULD look both ways before crossing the road" vs "You
> MUST look both ways before crossing the road UNLESS you are being
> chased by a grizzly bear." That's the BCP 14 interpretation of
> SHOULD, but we have often seen evidence of developers interpreting
> it as "You don't really have to look both ways before crossing the
> road."

And, although this has been said many times before, if we more often
insisted on "SHOULD ... unless" discussions where they are possible
-- e.g., "You SHOULD look both ways before crossing the road unless
you are being chased by a dangerous animal" -- we'd probably have
fewer misunderstandings of what SHOULD implies, in particular the
misunderstanding about it having a definition closer to "we'd prefer
that you do it that way, but it is really up to you".

And I agree with Toerless, and apparently you, about the BCP 14
language.  I'd go a tad further and suggest it is better adapted to
Technical Specifications than to Applicability Statements, better for
Applicability Statements than to BCPs, and better for BCPs than
Experimental or Informational documents.  Maybe eventually a question
for offspring-of-PROCON.

> I think operators are much less likely to make that mistake,
> whether the RFC cites BCP 14 or not.

Probably.

best,
  john