[TLS] Re: Changing WG Mail List Reputation

Quynh Dang <quynh97@gmail.com> Wed, 15 January 2025 23:13 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 49F88C1E8950 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 15:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 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, 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 EU1az51Yv0KD for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 15:13:05 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 440C5C1E8927 for <tls@ietf.org>; Wed, 15 Jan 2025 15:13:05 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-53e3778bffdso418478e87.0 for <tls@ietf.org>; Wed, 15 Jan 2025 15:13:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736982783; x=1737587583; 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=J9Zh5DPet4GGnxtQfyKIo8h0U645TcrpsnOUf4KtSZc=; b=WjrQe4DBBrx+bmKcEQSo/JoD8bqX9y8MdlNWaA/V9cFXGIHat4WdhVuxqZsIHGM/pL v9ZuUezLuNhMf6dLEnjLZO5QUSpRrfYPp4Tb5+JLyFeVJb6+4ShjTEj12tdcOV4WoH2a pAi/GOVeD1hEveiEsRsgV/2XxYSrfKqlV4MkxSIg2vldSu3ckW9iZkDLw3cd750vsYTG FZ2yYpSVZ6ffasooeW7A2ebJ+9ROVNotqHU1C0ZRqgG5SOlbeuyMH6p5NIXSIAvffWaJ hHdTim6OPNvg3Q4j+ywTs+XdbjZ4nfh/rXbU+y5NXyZg0K4fOXjTpGjX0b+MxRM9QDZl /nHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736982783; x=1737587583; 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=J9Zh5DPet4GGnxtQfyKIo8h0U645TcrpsnOUf4KtSZc=; b=sXbKINQRgaYPGbKitNap3Lxznd/5YIzR3a1Df18eXxpUWHvjINm1dTgL87ur+V9LfB NnSf5bB1vxLNWZysjPOsn+kvcG6wXeVZ2EJxNy3aKniIl/8l6HhZW8xVLFiTcdDzp9Z7 0shVMyWPGcSBuJY+slM8mAa6cIXJPsCEclNZu/brBb4ZTV89UJT3x6SJzFlRwsJHBd/u UOBT3X4YMx+8SIrjfMsegSw9+V8oj7Sd4CpR7i1Ftg6RoTTuRWE504p4GzZ7fqpUGo+x xxNVxE9soZhqdyRaNjA8faAZQYWX+cfvncRG3qg9ELTNV6PcMHt60iqVasOoiBous6Qv L2Ig==
X-Forwarded-Encrypted: i=1; AJvYcCXHLOVZ6lX0qaXMY+wCY449qBtCtmr/gCVwz3r0ZOlEziBZCtBMW1aUKXYH45fuLR/v7gA=@ietf.org
X-Gm-Message-State: AOJu0YwARey28KkKpPjuiv5uSdjHWS3aUai0jZQt1Skfai74eOTRvFSh +pWWsyIqkZTKOj+UiRYNp2fY2Q5NZUBIpIwqIUfjXe23MYzSMVF05Q6oHU7NFmGxtA//PKP1N0c RVge5H2jyGHhhVbRB8vop8DVABQQ=
X-Gm-Gg: ASbGncuwGIrSXdr7AjfCrlEIMKTFLDKMxXGiPDjXmfuoFc678LKijH5P6azsi6WlJQ4 cih+aoDNmsy7AmlxmmrPtICoH6RIPh2NpjVYoHkU=
X-Google-Smtp-Source: AGHT+IG9s3tBDSbJbOSD/zjZBPlRNmkRvqplsfKB4d9p8+TrOeDtKj4JOo4nMev6h9Zcf/bxyUxb7Z1dyhuf1yoRy4w=
X-Received: by 2002:a05:6512:318c:b0:542:213f:7901 with SMTP id 2adb3069b0e04-542845b0effmr8763811e87.44.1736982782711; Wed, 15 Jan 2025 15:13:02 -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> <CAPt1N1mTWgSR-EymNW2cv-xbYAJr_Lk3nHypQDb6_hC-D47CEw@mail.gmail.com> <CAE3-qLT9--E5RZGexPW9e63P6kOmzgyVEbtU1o8gGyqXU5wqpw@mail.gmail.com> <SN7PR14MB649213AB97E4BCB4888F531683192@SN7PR14MB6492.namprd14.prod.outlook.com>
In-Reply-To: <SN7PR14MB649213AB97E4BCB4888F531683192@SN7PR14MB6492.namprd14.prod.outlook.com>
From: Quynh Dang <quynh97@gmail.com>
Date: Wed, 15 Jan 2025 18:12:45 -0500
X-Gm-Features: AbW1kvZj0HBobKnTnXf1BDXXJjMLw3bA-f9gxnaj9v9U62Fz_x32Hj5uTBSkH6k
Message-ID: <CAE3-qLTVFtvQg+2w_Zk38Mxb2E9ureEK1jzFgZORXcFWgWKd2w@mail.gmail.com>
To: Tim Hollebeek <tim.hollebeek@digicert.com>
Content-Type: multipart/alternative; boundary="000000000000bea911062bc6d186"
Message-ID-Hash: 44SWUB733KSJAKDFSZCPRBEJR7QDCZXJ
X-Message-ID-Hash: 44SWUB733KSJAKDFSZCPRBEJR7QDCZXJ
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
CC: "tls@ietf.org" <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/Ez_-mFDTPBwrgDymf2H0xZ_1UYQ>
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 1:27 PM Tim Hollebeek <tim.hollebeek@digicert.com>
wrote:

> Consensus has nothing to do with number of votes.
>

I have not discussed how the current consensus calls work. Filippo Valsorda
sent an email which basically said "the current practice of consensus calls
are so hard and painful sometimes" yesterday.  So, I discussed some ideas
(change suggestions) to improve the situation.



> We don’t vote, and we shouldn’t. We also shouldn’t disadvantage those who
> can’t attend sessions live for whatever reason.
>

I recommend you re(read) my second email on this thread.  If the consensus
calls are based on votes (my suggestion) and they are done over emails,
then how to prevent one person using many emails to vote? That was where
the suggestion of requiring the consensus calls to be done at the live
meetings and only the participants online or in person can vote.  The ones
who participate in another IETF meeting at the same time ( a meeting
conflict) can cast their votes later.



> The existing rules cover this pretty well, imo.
>

Good for you!

Regards,
Quynh.


>
>
> The reason we appoint technically competent chairs and directors, and
> those chairs and directors spend quite a bit of time on this stuff, is
> because it can’t be handled by arbitrary rules or just counting. And we
> have appeals procedures, too. If you ever have any questions about a
> particular consensus call or believe consensus is being declared when it
> hasn’t been achieved, please feel free to publicly or privately reach out
> to a chair or area director.
>

>
> -Tim
>
>
>
> *From:* Quynh Dang <quynh97@gmail.com>
> *Sent:* Wednesday, January 15, 2025 1:04 PM
> *To:* Ted Lemon <mellon@fugue.com>
> *Cc:* tls@ietf.org
> *Subject:* [TLS] Re: Changing WG Mail List Reputation
>
>
>
>
>
>
>
> On Wed, Jan 15, 2025 at 12:47 PM Ted Lemon <mellon@fugue.com> wrote:
>
> Although it is, as ekr has pointed out, not normative, nevertheless RFC
> 7282 provides a solid process for coming to rough consensus. This method
> does not involve voting, and I think operates in the way that DJB proposes.
> I certainly would not consider vote counting to be a valid way to determine
> consensus, because it doesn't inform the working group in any way—it's
> really just a count of how many bodies a particular proponent was able to
> throw at the problem.
>
>
>
> As for what the minimum number of people involved should be, that's also
> really hard to state objectively because some working groups get vastly
> more participation than others: what works for one will not work for
> another.
>
>
>
> I'm not suggesting that we make RFC 7282 normative; what I am suggesting
> is that it's a good basis for reasoning about this problem, and we do
> really already know how to solve this problem. Unfortunately it does
> require that WG leadership and IETF leadership actually put the effort in
> to accurately judge the consensus.
>
>
>
> How the chair "accurately judge the consensus." and to avoid the problem I
> mentioned in the previous email : "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 ?" ?
>
>
>
> If we don't think the problem above is a problem, then we don't have to
> change anything.  But if we think that problem is a problem, then I don't
> see any better way to take care of it other than defining a minimum
> percentage of votes to have the consensus.
>
>
>
> Regards,
>
> Quynh.
>
>
>
>
>
>
>
> If there really is no better reason to choose solution A as opposed to
> solution B as the number of votes, then the decision is effectively
> arbitrary anyway, and a coin flip would also work (and this has been done
> in the past in such situations).
>
>
>
>
>
> On Wed, Jan 15, 2025 at 6:39 PM 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.
>
>
>
> 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
>
>