Re: Question about BCP 14 / RFC 8174

John C Klensin <john-ietf@jck.com> Tue, 26 August 2025 17:17 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 02F8359488D8; Tue, 26 Aug 2025 10:17:43 -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 M6KMoz2IBdMV; Tue, 26 Aug 2025 10:17:41 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id 903EF59488D1; Tue, 26 Aug 2025 10:17:41 -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 1uqxIg-0008T1-P1; Tue, 26 Aug 2025 13:17:38 -0400
Date: Tue, 26 Aug 2025 13:17:32 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Nico Williams <nico@cryptonector.com>
Subject: Re: Question about BCP 14 / RFC 8174
Message-ID: <0DDAFE2C21627482DA968A67@PSB>
In-Reply-To: <MN2PR17MB4031B3E3F451C7861C4B8073CD39A@MN2PR17MB4031.namprd17.prod.outlook.com>
References: <aKzK5qdwLUHSa3JL@ubby> <878qj67dcq.fsf@josefsson.org> <MN2PR17MB4031F73336C43683553B84B9CD39A@MN2PR17MB4031.namprd17.prod.outlook.com> <87y0r6i1p7.fsf@josefsson.org> <MN2PR17MB4031065DFE92FEBB87A23E15CD39A@MN2PR17MB4031.namprd17.prod.outlook.com> <aK3XMWzrnJPFrI4m@ubby> <MN2PR17MB4031B3E3F451C7861C4B8073CD39A@MN2PR17MB4031.namprd17.prod.outlook.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: R2DQV5ZCAYDJUTQDIXQF25ZAJIM6G3JA
X-Message-ID-Hash: R2DQV5ZCAYDJUTQDIXQF25ZAJIM6G3JA
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: Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org>, 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/owy8XAI1RfpLfmdI0gLY7JFe1kc>
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 Tuesday, August 26, 2025 15:51 +0000 "Salz, Rich"
<rsalz=40akamai.com@dmarc.ietf.org> wrote:

>   *
> Is there a rule somewhere that IETF documents (at least on the
> standards   *
> track) MUST reference BCP 14?
> 
> Nothing in the formal RFCs that document how the IETF works.
> There's an IESG statement:
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarif
> ying-the-use-of-bcp-14-key-words/

Let me go a half-step further.  There is nothing, either in BCP 14
nor that IESG statement, that requires the use of BCP 14 vocabulary
or definitions.  The IESG statement even says "BCP 14 is an optional
tool, and not strictly necessary." At least in principle, nothing
would prevent a document from avoiding BCP 14 terminology or a
reference to it, then using the same words (even in capital letters),
and giving entirely different definitions for them or using different
words entirely.   Especially if the same words were used, I'd predict
that such a document would have a very tough time during Last Call
and IESG review as various people asked (demanded?) that the authors
demonstrate sufficient justification for the confusion that would
likely cause, insisted that the document be super-clear about what it
was doing (not just omitting the BCP 14 reference), and demanded that
the justification meet a very high bar.  But the main reason for not
doing it is that it would be confusing and generally dumb, not that
there is any specific rule saying that BCP 14 definitions MUST (sic)
be used.

    john