On Wed, Jan 15, 2025 at 6:31 PM Watson Ladd <watsonbl...@gmail.com> wrote:
> > > On Wed, Jan 15, 2025, 3:15 PM Quynh Dang <quyn...@gmail.com> wrote: > >> >> >> On Wed, Jan 15, 2025 at 1:27 PM Tim Hollebeek <tim.holleb...@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 <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> 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> 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 >> >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
