[TLS] Re: Changing WG Mail List Reputation

Watson Ladd <watsonbladd@gmail.com> Wed, 15 January 2025 17:52 UTC

Return-Path: <watsonbladd@gmail.com>
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 78D71C1840E6 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 09:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sgOp0xeZZmpu for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 09:52:02 -0800 (PST)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF81DC169402 for <tls@ietf.org>; Wed, 15 Jan 2025 09:52:02 -0800 (PST)
Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-38632b8ae71so74399f8f.0 for <tls@ietf.org>; Wed, 15 Jan 2025 09:52:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736963520; x=1737568320; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bL9GOFnjcRpbupD9m30LfKGGi0NCEuDt8SngJmJNmSM=; b=RQWhZNc5kHhbzXCDnT0kFFn0Tblil0RLP+nUAy1ddiVjk78gZWZWCywZ4gSOqdYugi +tjHfSlHJHGg0uNihrtZVyFb9s3FrDDEyW+Yja8PBfscP6r8MJNehW+vBPh3MxBD1sBn BgLr7PmStJXDz+zLNOOMeVs/PweH4zfgiMhk5AOvGaIB0wbkThdTL2YOgLWTbYYLVEW7 9j1NWxmq+zwbaSHPzWTAQPhc+DtjHtLyCl8ncB7ljSZxE2EY0HRb64HLCVDPGuwip2/P ysLAOFzByyNIvTv7MYtDjScXVfmF7SlceS4CEf/s3kxACPOz2QILUdkt0MrAexj1awGd PLYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736963520; x=1737568320; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bL9GOFnjcRpbupD9m30LfKGGi0NCEuDt8SngJmJNmSM=; b=wB8QqNR02ccP5OqyBNytP7jIa/SthS0Az+f4Uigpr66W/P/VviTcXnSwmLnsm3wiaz HcCR8awYwbeiVfnuMXlOj2FvG++YD7Em7c4HDDX0bZj7ym5v85e4IfyKgUywm5w/qSnK IApgYMBMV0IeyYnIqW5FrSr106xkhKOgC/+/0DyWllYPY5gW81QQMLqJ7xfRqLZ5NcbV CXJ2Z6IBQsNUTIYjvF9+89CYPEfUIQICPqH/uVkzFpAGiE0NVhZY9dNHR6zAvSH5xyGw Ygw8mjuRLODBAh/2xL+5MMpeTzbjytI5XafupN7kWttUW/+UOeaw4FgnlC5nm1ats0pS 5zzA==
X-Gm-Message-State: AOJu0YwlYdDlXhIzBDjG4txslKzRg8lOONuBIp/zD8rdFqR+wP/H9YeJ KCgf3rpTIhxapPFn3Lm8fwoPnSrDTCMfoZDdFtA+wxdWhZs1lXlaKkYGZf1XtWoo+G4w/LgGbX6 ojiUqh7xJx22J0kjRsoQaBuVfY5A=
X-Gm-Gg: ASbGnctl+w57LO4xyc8d82fQ6G69TRs/77PosMoVqwxZmjgkp/T9ERy9AUQ6YLOEnKl 0LWJR0LQh8GsAuLXOvqkvTQRs+MhFSKT3W+uQUGofzeqrxwpge7XkZkEKpUKOcRrYOIXbCQ==
X-Google-Smtp-Source: AGHT+IG/yeGdk8vdJ+Wf2/qywSfsKG8VwbSgIwzu+ul54w14WFnEVJGeDoP7xJhZ2JG6QI5N90T+xdlMJoPogGA/TZ0=
X-Received: by 2002:a05:6000:2a3:b0:386:32ca:aa12 with SMTP id ffacd0b85a97d-38a8733b9dbmr25890111f8f.49.1736963519529; Wed, 15 Jan 2025 09:51:59 -0800 (PST)
MIME-Version: 1.0
References: <CAE3-qLSe_KU2HkGu-LBGpmF=in4ZHKzotXRQMrO_AfYFv8pNrA@mail.gmail.com> <20250115163905.447729.qmail@cr.yp.to> <CAE3-qLS2462ThM5UVTJ_NukYEXAjR4teBhdNityj+acmqzueXg@mail.gmail.com>
In-Reply-To: <CAE3-qLS2462ThM5UVTJ_NukYEXAjR4teBhdNityj+acmqzueXg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 15 Jan 2025 09:51:51 -0800
X-Gm-Features: AbW1kvZmKPcjA_clKrkWNxZWhsJ-tokACqEXPDNs7srJMXlL_DflxvrIR6YFK4s
Message-ID: <CACsn0cn=QhPS8FAd=WgNTJwdnydFnQPHpDWJkH+14k47YtULmQ@mail.gmail.com>
To: Quynh Dang <quynh97@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000091cc1a062bc25546"
Message-ID-Hash: B54R4T73YZDTIQ7VQC33P3AT3VWBF5FU
X-Message-ID-Hash: B54R4T73YZDTIQ7VQC33P3AT3VWBF5FU
X-MailFrom: watsonbladd@gmail.com
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
CC: TLS List <tls@ietf.org>
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/VWzl7Y22_qm1btzKGh93O5ydz_k>
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>

On Wed, Jan 15, 2025, 9:39 AM Quynh Dang <quynh97@gmail.com> wrote:

>
>
> On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein <djb@cr.yp.to> wrote:
>
>> 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.
>>
>
> As discussed previously, "what's best from an engineering perspective", is
> there the decision maker such as a judge to say A is the right one, not B
> or give a verdict such as this patent covers this, but not that ?  That is
> why the IETF requires "rough" consensus.
>
>
>> 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."
>
>
> I have not advocated against "rough consensus".
>
> The problem is that "rough consensus" is so broadly or vaguely defined.
> So consensus calls can be made based on inconsistent "policies" or "unknown
> rules/policies" and many people might feel that they are treated unfairly
> in many consensus calls and they could have a question in their head: why
> did the chairs do that to me ?  So the problem makes the job of the chairs
> so hard and stressful.
>
> Defining a minimum percentage of votes to have  the consensus would take
> care of the problem and the chairs at the IETF would love that.
>

That's not something the *TLS* working group can do. I'm also not sure it's
the contributor to the issues with the tone on the mailing list that would
justify this massive deviation from the historical process.


> Regards,
> Quynh.
>
>
>>
>> ---D. J. Bernstein
>>
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-leave@ietf.org
>>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>