[TLS] Re: Changing WG Mail List Reputation

"D. J. Bernstein" <djb@cr.yp.to> Wed, 15 January 2025 16:39 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C769C151995 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 08:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHUxbg-O33w3 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 08:39:18 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 3043BC1519B3 for <tls@ietf.org>; Wed, 15 Jan 2025 08:39:17 -0800 (PST)
Received: (qmail 26446 invoked by uid 1010); 15 Jan 2025 16:39:17 -0000
Received: from unknown (unknown) by unknown with QMTP; 15 Jan 2025 16:39:17 -0000
Received: (qmail 447731 invoked by uid 1000); 15 Jan 2025 16:39:05 -0000
Date: Wed, 15 Jan 2025 16:39:05 -0000
Message-ID: <20250115163905.447729.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <CAE3-qLSe_KU2HkGu-LBGpmF=in4ZHKzotXRQMrO_AfYFv8pNrA@mail.gmail.com>
Message-ID-Hash: TLBLRC5AYUMBVKHAJIRAJ6BLDHMQENUU
X-Message-ID-Hash: TLBLRC5AYUMBVKHAJIRAJ6BLDHMQENUU
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Changing WG Mail List Reputation
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-NPF5kKoi8wPtz9C-yNKcPIE0tQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Quynh Dang writes:
> D. J. Bernstein <djb@cr.yp.to> wrote:
> > Quynh Dang writes:
> > > Any result will hurt one group (can't be both groups have what they
> > > want).
> > BCP 54: "IETF participants use their best engineering judgment to find
> > the best solution for the whole Internet, not just the best solution for
> > any particular network, technology, vendor, or user."
> The key point in that policy is "the best solution for the whole Internet".
> So, in my example, one group thinks A is the one and the other group thinks
> B is the one.

That wouldn't be a case of some group not getting what it wants. It
would be everyone wanting what's best for the Internet, but not enough
analysis having been carried out yet to know what that is. The usual way
out of such cases is via a closer look at the engineering.

The "not just" part of the above BCP 54 quote is recognizing that
vendors have an incentive to push for what's best for those vendors.
That's a much more obvious reason for conflicts---and if one starts by
thinking of IETF as a way to manage conflicts of vendor interests then
votes might seem to be a natural way to make decisions. But the policy
is saying that IETF's goal is instead to do what's best from an
engineering perspective for the Internet as a whole.

Votes don't help the engineering process; they disrupt it. Voting is not
how IETF is supposed to work in the first place. As Dave Clark famously
said in https://www.ietf.org/proceedings/24.pdf: "We reject: kings,
presidents and voting. We believe in: rough consensus and running code."

---D. J. Bernstein