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. 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> wrote: > > > On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein <d...@cr.yp.to> wrote: > >> Quynh Dang writes: >> > D. J. Bernstein <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 >> To unsubscribe send an email to tls-le...@ietf.org >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
