[TLS] Re: Changing WG Mail List Reputation

Quynh Dang <quynh97@gmail.com> Wed, 15 January 2025 23:43 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 05619C09C236 for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 15:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level:
X-Spam-Status: No, score=-1.854 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_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 DiC2X_PRndTb for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 15:43:32 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 EE344C1F8BD5 for <tls@ietf.org>; Wed, 15 Jan 2025 15:43:31 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-540201cfedbso268426e87.3 for <tls@ietf.org>; Wed, 15 Jan 2025 15:43:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736984610; x=1737589410; 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=oqNZ5ozuxf00712+xOc8HtKEhfYqMRx//nRydNLjTH4=; b=IEEY+VKirx9A9mx9ij9kTMAFDS2eJBRc8cwmS2PfoONP9vn+lk5mAX6x8RJB/GqqA6 AwWAp1iA8pFISeKIfT0uALxu+ZDykVnofZDNAsdSUly7lrkRMKuZEJJF0h9oGsMwoYRx BsZcPixPLr7qH2Rh0Wc5zLEfclF1LUAwp9xLmXpiSvTYi1EAVkEUTaXVNG8v2YcSx19H WMrFqDW1SugifNKuQ41ekM4rJmLvps0LP3L8G7y8lSnOgUNEAD2wSDv8oHACuxa1kACn 8Oy/W2lSTBgXbkS3jSlPp+ksTplqJHin2OV4Q/y5D6OeFZubYqSVspYyEef162MiUjnm 6ffA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736984610; x=1737589410; 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=oqNZ5ozuxf00712+xOc8HtKEhfYqMRx//nRydNLjTH4=; b=hqH7aZvAtul48BjYnPqeCkIH8uJ4ZEbWdGxlBUs9qRLfaEhbhbFoTU+pC0XUfeBza7 htSaCV8pOCqyQF+GA9ND09Q45qB5mtRDFTKPDMIiPTaRx2UDDnzQdUyikEcxa9kPBYG9 2Y4roW1nWiovObg49UXapnhaYSw/Q/fHPAKtDl2ebZW74cpTeSUbUWngC6isemTL8+u/ qAXxcMgNHASGd9GS+6talYDCdATKMvzAyH9xy/VGmRTM3HywC5bju7tJdjg+NrdNttrm CJDRQEqs/56XwkwywHvOzxbM1jHypcRpyow/gKjZBbmX1h7Vr0FB4bwl79dsh1ESmbf5 mL/A==
X-Forwarded-Encrypted: i=1; AJvYcCWfGuQOSu6SSVBP7eU8nE+TshltgT9c6UEPuK+SlePzMHfVvRUSAnBH1pEGltbVVNyID9w=@ietf.org
X-Gm-Message-State: AOJu0YypsQf2bAn+HFMi5lM+3eMLlOwIszowrrnTh/BTX9NG2lXwqmqs DPMoQSJ/f639OlglVGTael8xkhtmP8zMS+4NDgkQK8aHE3MBztg0VgAgUsG54v/BMSYXgG3NmN4 BYw//iuB3425r0lvfICp/DfMi3by8rA==
X-Gm-Gg: ASbGncvWl2uQeCygawwN0gAT7+nQ3mC+/6wl6TyRbbZvfArkWXXN4mW36BLEFyX8V/o pyflzet21h9HUkZ4OG9biKsXuaL/PIBL7NyrHH2Q=
X-Google-Smtp-Source: AGHT+IHYtVml9xI89FIh3S3di9lKHvV/0bS5ClfwQhy4lYi6P8KSzpNlR2I7A3dnSnlelQ9DhCXABYuEduNlfdEH55s=
X-Received: by 2002:a05:6512:3e28:b0:53e:3aaa:5c7c with SMTP id 2adb3069b0e04-542845d1687mr10936494e87.51.1736984609632; Wed, 15 Jan 2025 15:43:29 -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> <CAE3-qLTVFtvQg+2w_Zk38Mxb2E9ureEK1jzFgZORXcFWgWKd2w@mail.gmail.com> <CACsn0cn_aKEmPLm2NoErHvB_t3JAeeNdg-Sf9NchDzbJ+rD8rw@mail.gmail.com>
In-Reply-To: <CACsn0cn_aKEmPLm2NoErHvB_t3JAeeNdg-Sf9NchDzbJ+rD8rw@mail.gmail.com>
From: Quynh Dang <quynh97@gmail.com>
Date: Wed, 15 Jan 2025 18:43:12 -0500
X-Gm-Features: AbW1kvaoZFIPTFp68Vx_BCWD6WWUqobDVRaDdTR5aU4HEPkIexPqq6kERe2FHwk
Message-ID: <CAE3-qLRrg4E7gJwaLK9V3=W_M6GJ7Xz6h+8+VAvC_y=Ekcg3KQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a33fb7062bc73e46"
Message-ID-Hash: LMNRDHAF7UGZKO7NLINO3CXDIWI7CPFK
X-Message-ID-Hash: LMNRDHAF7UGZKO7NLINO3CXDIWI7CPFK
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 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/_jQ366alzVEcf9U3nuGLqspYhso>
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 6:31 PM Watson Ladd <watsonbladd@gmail.com> wrote:

>
>
> On Wed, Jan 15, 2025, 3:15 PM Quynh Dang <quynh97@gmail.com> wrote:
>
>>
>>
>> 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.
>>
>
> I don't think that's what Fillipo said. Consensus is not the same as
> consensus calls to gauge it.
>

I never indicated they are the same. Maybe my wording was not clear. I
meant it is hard to decide whether or not there is a consensus on some
matter by a clear and consistent rule sometimes.


>
> It's also not possible for the TLS WG to change those rules but it is
> possible to address some of the issues on the list.
>
>>
>>
>>
>>> 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
>>>
>>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-leave@ietf.org
>>
>