Consensus has nothing to do with number of votes. We don’t vote, and we shouldn’t. We also shouldn’t disadvantage those who can’t attend sessions live for whatever reason. The existing rules cover this pretty well, imo.
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 <quyn...@gmail.com> Sent: Wednesday, January 15, 2025 1:04 PM To: Ted Lemon <mel...@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 <mel...@fugue.com <mailto:mel...@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 <quyn...@gmail.com <mailto:quyn...@gmail.com> > wrote: On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein <d...@cr.yp.to <mailto:d...@cr.yp.to> > wrote: Quynh Dang writes: > D. J. Bernstein <d...@cr.yp.to <mailto:d...@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 <mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org <mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org <mailto:tls-le...@ietf.org>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
