[TLS] Re: Changing WG Mail List Reputation

Quynh Dang <quynh97@gmail.com> Wed, 15 January 2025 17:38 UTC

Return-Path: <quynh97@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 78106C1E0D63 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 09:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.853
X-Spam-Level:
X-Spam-Status: No, score=-1.853 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_ENVFROM_END_DIGIT=0.25, 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 PC07_XH9LcgH for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 09:38:19 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 933A4C1DFD3D for <tls@ietf.org>; Wed, 15 Jan 2025 09:38:19 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-54263b52b5aso46883e87.1 for <tls@ietf.org>; Wed, 15 Jan 2025 09:38:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736962696; x=1737567496; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=hhVruoU+r7frEHJAg9bKCjecO6uJPnpXrfwNBqX4ImY=; b=SD7TK/BX1UFWB0ZM2CkMjLvnhr0HZUAHGOlivD+smyaHPxxkHDp2WRDG3LiEZfxvYM ZPhiIXZD8VuDfFvsu1JF0CYm8iANDCSlEJ1mXwYPzgqC2Mo8zaeKnP6fwqf33Eqbs0LG 3QN/7zt4g5Zk6hX+/Iir4P8Dk/TIDXumh+8cMRbqp7YR9fc62VZPgUGwQct0hUzJX30Z UAJDTLy4wsXxjlPAn7mFABVCZ/9l9KzVrZ2BVi86gYLfsOxdZx+/3ME6FcWQY2o4+1Hj +w2qdwP4dF9Ynn45Tluni9nbKSYLEbM4PtV3CPuU0JEUX9/HeSLfDYv0o1FoBzzmKkNy aRfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736962696; x=1737567496; h=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=hhVruoU+r7frEHJAg9bKCjecO6uJPnpXrfwNBqX4ImY=; b=GVSGXsI+HK7XMTA7OWFGdvLJNk0qAproWC9Hrpg/lk8sJB77AHCbL+RfuuVhL44U4o wioZ1753PyhaKwl9zq9OhbAF7N+Vjt4RnPNc/6qQiDvaz3xJsv1gE5t4lVb2bVuOzTLq D/ZCNlkCEUFlqJT/AKjFFyIXiiuGd4BvTkK/ZKq663BSJCYMEKKaADr8ooL5FBtQ7fjY 7eRLwASrfYixcl5ck9JwciJz1cAoyU9erNpsj0rXZmNZnufKpfbKm9mfIVjj9XwcF9wB jY8l96P5g95jcEYzXrdo3grgf4L34tkOYLka3pgMWu7vvUs9KNn6T4yyG9DJcda2JIDe THeQ==
X-Gm-Message-State: AOJu0Yy0da0xvpuVQ5mrWYy5FVU2RnEEhXq48szJvKkHZK+n3RvqRiVl 3pqUzMlPqWZMRJTp9sjBDPiqJqGl9raT63RDaUY9sDOPt7rKRSryfe8ZJy66WHYEOYQxYRNHxEE 68dzkNCXKV5ZgcRO3Mk4Sf4sKDM7Oqw==
X-Gm-Gg: ASbGncsQtyTJXMhwjwOCPVZux/GhkpZOfYriZ98QT6mQYK4xYuyfceNeYX2L91OXviN RukQWfNQCvgDA3xqA3uKj3xeYD/surniDfDb539bEhjWdZ33AuA==
X-Google-Smtp-Source: AGHT+IG7+vSAZGFnovPOtNL0AChKhR5E7hucMB9W8WgW9e+G1gtn/5ezQHbY/6phjbnLM7LGtpyP4BXR+Fz7RyHvj78=
X-Received: by 2002:a05:6512:1382:b0:540:2201:57d2 with SMTP id 2adb3069b0e04-54284816f7emr10603782e87.49.1736962696199; Wed, 15 Jan 2025 09:38:16 -0800 (PST)
MIME-Version: 1.0
References: <CAE3-qLSe_KU2HkGu-LBGpmF=in4ZHKzotXRQMrO_AfYFv8pNrA@mail.gmail.com> <20250115163905.447729.qmail@cr.yp.to>
In-Reply-To: <20250115163905.447729.qmail@cr.yp.to>
From: Quynh Dang <quynh97@gmail.com>
Date: Wed, 15 Jan 2025 12:37:58 -0500
X-Gm-Features: AbW1kvaILGG-YjPNEaK7fC0O0jDsi1dM15gdHDCwjXkNVwJDORqxTaIEDnDV8ww
Message-ID: <CAE3-qLS2462ThM5UVTJ_NukYEXAjR4teBhdNityj+acmqzueXg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007ec94b062bc224e7"
Message-ID-Hash: 3Z7Y5JL6UDBO25UWYBNCJUUVCXSD7KVS
X-Message-ID-Hash: 3Z7Y5JL6UDBO25UWYBNCJUUVCXSD7KVS
X-MailFrom: quynh97@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
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/C08AQIkQOthkzy-wLz3PG-JIn_g>
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 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.

Regards,
Quynh.


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