[TLS] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Tue, Jan 14, 2025 at 2:57 PM Bob Beck  wrote:

>
>
> > On Jan 14, 2025, at 12:20 PM, Dang, Quynh H. (Fed)  40nist@dmarc.ietf.org> wrote:
> >
> >  Maybe consensus calls can only be made and completed at the in-person
> meetings ?
>
> The problem with in-person (or even virtual at the in-person meetings) is
> it then becomes even more of a pay-to-play proposition to participate.
>
> Not all valuable participants have an organization funding their
> participation at IETF. I believe we still want to encourage such
> participation, not discourage it.
>

I believe your point has been accepted as a very good point over the
years.  Yes, we need to find ways and to create more opportunities for more
people to contribute to the IETF's works, especially the students and early
career engineers/scientists.

I can't think of any method that works well for all.

The individuals who don't join in the IETF meetings (virtually or in
person) can share their knowledge and thoughts over emails.

I believe it is true that there are people who want to, but the financial
cost  prohibits them from joining in an IETF meeting either virtually or in
person.

For the people not attending the meeting due to other reasons (not
financial one)  and some of possible reasons are they don't want to pay the
fee or don't want to travel etc., they can't vote and I expect most of them
(if not all) would feel that is not fair to them and I agree with them on
this.  Let's say there are 2 options: A and B and this group supports A.

The other group who are willing to pay thousands and time to travel long
distances ( and to get tortured by the jetlag) join in the meeting to
support B (either this group pays for themselves or their employers pay for
them).  So, it seems there is some evidence to support the thought that the
choice is more important to the group supporting B than to the other group
supporting A.

Any result will hurt one group (can't be both groups have what they want).

How about the situation when people have meeting conflicts ? Their record
of attending the IETF could allow them to vote later, say within a week or
two after the IETF ends.

I started the question about "how to avoid the potential problem of one
person using multiple emails to vote if the consensus calls are done over
emails".  And, that was my thought, I did not know any better ways. My hope
was that other people will come up with better ideas which would make the
email only group (the group supporting A above) feel fair.

Regards,
Quynh.









>
> ___
> 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] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 2:45 PM Andrei Popov 
wrote:

>
>- I started with some change suggestions for you to consider
>
> Understood; the suggestion that consensus should be determined at the
> meetings has been opposed by others,
>

I have seen 2 or 3 as being "others" in your message.


> I don’t need to repeat the arguments.
>
> Even as an employee of a large business, I cannot rely solely on the
> (increasingly more expensive) meeting attendance to participate in the IETF
> consensus process.
>
>
>
> Also, the general idea of voting to pick the best course of action for
> complicated technical matters seems questionable.
>

I recommend you to re(read) my first email.  The chairs start a discussion
of a technical matter, later at a meeting, if the chairs think that the
matter has been well discussed and understood enough, the chairs start for
a consensus call (votes). It is basically the same with what is going on
right now.


> There is no minimum technical qualification requirement or process for the
> IETF attendees.
>

Do you want to test someone's qualifications before they are allowed to
vote or their voice can have any value ?  The chairs can ask the
participants to provide the reason(s) for their vote.

Regards,
Quynh.


>
> I agree that as things stand, there is some level of WG chair discretion
> in determining consensus; I believe the chairs are doing a good job of
> this, in general.
>
> And I say this even though I’ve been in the rough quite a few times😊
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 11:16 AM
> *To:* Andrei Popov 
> *Cc:* Tim Bray ; tls@ietf.org
> *Subject:* Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
>
>
>
>
> On Wed, Jan 15, 2025 at 2:08 PM Andrei Popov 
> wrote:
>
>
>- Did you mean the number of people attending a particular meeting ?
>
> My understanding is that consensus is not determined by meeting
> participants; it’s always determined on the mailing list. Are you
> suggesting that a certain minimum percentage of mailing list subscribers
> have to be in favor?
>
>
>
> I have not been talking about how the current consensus process works. I
> started with some change suggestions for you to consider.  Please read my
> first email(s) first.
>
>
>
> Regards,
>
> Quynh.
>
>
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 11:01 AM
> *To:* Andrei Popov 
> *Cc:* Tim Bray ; tls@ietf.org
> *Subject:* Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
> You don't often get email from quyn...@gmail.com. Learn why this is
> important 
>
>
>
>
>
> On Wed, Jan 15, 2025 at 1:50 PM Andrei Popov 
> wrote:
>
> In the absence of a roster of participants, how can a percentage of votes
> be determined?
>
> We don’t have WG membership registrations, AFAIK.
>
>
>
> Did you mean the number of people attending a particular meeting ?
> Requiring them to sign in using the online tools. For the people who
> don't sign and they attend another meeting, they can send their IETF
> registration for that day or for the whole week to the chairs and their
> votes can be cast within a week or so after the IETF ends.
>
>
>
> That would be an easy task I think and I don't think we should talk about
> it now.
>
>
>
> Regards,
>
> Quynh.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 10:44 AM
> *To:* Tim Bray 
> *Cc:* tls@ietf.org
> *Subject:* [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
> You don't often get email from quyn...@gmail.com. Learn why this is
> important 
>
>
>
>
>
> On Wed, Jan 15, 2025 at 1:26 PM Tim Bray  wrote:
>
> On Jan 15, 2025 at 11:37:58 AM, Quynh Dang  wrote:
>
>
>
> 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.
>
>
>
> No it wouldn’t
>
>
>
> Why do you think it wouldn't take care of the problem I described?
>
>
>
> Regards,
>
> Quynh.
>
>
>
> and no we (speaking as former co-chair of two WGs) wouldn’t.
>
>
>
> I’m not sure why we’re relitigating the works-pretty-OK process of
> consensus calls from the chair and potential appeals.
>
>
>
>  -T
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Changing WG Mail List Reputation

[Watson Ladd]

On Wed, Jan 15, 2025, 3:15 PM Quynh Dang  wrote:

>
>
> On Wed, Jan 15, 2025 at 1:27 PM Tim Hollebeek 
> 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.

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 
>> *Sent:* Wednesday, January 15, 2025 1:04 PM
>> *To:* Ted Lemon 
>> *Cc:* tls@ietf.org
>> *Subject:* [TLS] Re: Changing WG Mail List Reputation
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jan 15, 2025 at 12:47 PM Ted Lemon  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  wrote:
>>
>>
>>
>>
>>
>> On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:
>>
>> Quynh Dang writes:
>> > D. J. Bernstein  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 get

[TLS] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 1:27 PM Tim Hollebeek 
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 
> *Sent:* Wednesday, January 15, 2025 1:04 PM
> *To:* Ted Lemon 
> *Cc:* tls@ietf.org
> *Subject:* [TLS] Re: Changing WG Mail List Reputation
>
>
>
>
>
>
>
> On Wed, Jan 15, 2025 at 12:47 PM Ted Lemon  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  wrote:
>
>
>
>
>
> On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:
>
> Quynh Dang writes:
> > D. J. Bernstein  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 b

[TLS] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 6:31 PM Watson Ladd  wrote:

>
>
> On Wed, Jan 15, 2025, 3:15 PM Quynh Dang  wrote:
>
>>
>>
>> On Wed, Jan 15, 2025 at 1:27 PM Tim Hollebeek 
>> 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 
>>> *Sent:* Wednesday, January 15, 2025 1:04 PM
>>> *To:* Ted Lemon 
>>> *Cc:* tls@ietf.org
>>> *Subject:* [TLS] Re: Changing WG Mail List Reputation
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jan 15, 2025 at 12:47 PM Ted Lemon  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  wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:
>>>
>>> Quynh Dang writes:
>>> > D. J. Bernstein  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 en

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Andrei Popov]

  *   Did you mean the number of people attending a particular meeting ?
My understanding is that consensus is not determined by meeting participants; 
it’s always determined on the mailing list. Are you suggesting that a certain 
minimum percentage of mailing list subscribers have to be in favor?

Cheers,

Andrei

From: Quynh Dang 
Sent: Wednesday, January 15, 2025 11:01 AM
To: Andrei Popov 
Cc: Tim Bray ; tls@ietf.org
Subject: Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation

You don't often get email from quyn...@gmail.com. 
Learn why this is important


On Wed, Jan 15, 2025 at 1:50 PM Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:
In the absence of a roster of participants, how can a percentage of votes be 
determined?
We don’t have WG membership registrations, AFAIK.

Did you mean the number of people attending a particular meeting ? Requiring 
them to sign in using the online tools. For the people who don't sign and they 
attend another meeting, they can send their IETF registration for that day or 
for the whole week to the chairs and their votes can be cast within a week or 
so after the IETF ends.

That would be an easy task I think and I don't think we should talk about it 
now.

Regards,
Quynh.

Cheers,

Andrei

From: Quynh Dang mailto:quyn...@gmail.com>>
Sent: Wednesday, January 15, 2025 10:44 AM
To: Tim Bray mailto:tb...@textuality.com>>
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation

You don't often get email from quyn...@gmail.com. 
Learn why this is important


On Wed, Jan 15, 2025 at 1:26 PM Tim Bray 
mailto:tb...@textuality.com>> wrote:
On Jan 15, 2025 at 11:37:58 AM, Quynh Dang 
mailto:quyn...@gmail.com>> wrote:

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.

No it wouldn’t

Why do you think it wouldn't take care of the problem I described?

Regards,
Quynh.

and no we (speaking as former co-chair of two WGs) wouldn’t.

I’m not sure why we’re relitigating the works-pretty-OK process of consensus 
calls from the chair and potential appeals.

 -T
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Andrei Popov]

  *   I started with some change suggestions for you to consider
Understood; the suggestion that consensus should be determined at the meetings 
has been opposed by others, I don’t need to repeat the arguments.
Even as an employee of a large business, I cannot rely solely on the 
(increasingly more expensive) meeting attendance to participate in the IETF 
consensus process.

Also, the general idea of voting to pick the best course of action for 
complicated technical matters seems questionable. There is no minimum technical 
qualification requirement or process for the IETF attendees.

I agree that as things stand, there is some level of WG chair discretion in 
determining consensus; I believe the chairs are doing a good job of this, in 
general.
And I say this even though I’ve been in the rough quite a few times😊

Cheers,

Andrei

From: Quynh Dang 
Sent: Wednesday, January 15, 2025 11:16 AM
To: Andrei Popov 
Cc: Tim Bray ; tls@ietf.org
Subject: Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation



On Wed, Jan 15, 2025 at 2:08 PM Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:

  *   Did you mean the number of people attending a particular meeting ?
My understanding is that consensus is not determined by meeting participants; 
it’s always determined on the mailing list. Are you suggesting that a certain 
minimum percentage of mailing list subscribers have to be in favor?

I have not been talking about how the current consensus process works. I 
started with some change suggestions for you to consider.  Please read my first 
email(s) first.

Regards,
Quynh.


Cheers,

Andrei

From: Quynh Dang mailto:quyn...@gmail.com>>
Sent: Wednesday, January 15, 2025 11:01 AM
To: Andrei Popov mailto:andrei.po...@microsoft.com>>
Cc: Tim Bray mailto:tb...@textuality.com>>; 
tls@ietf.org
Subject: Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation

You don't often get email from quyn...@gmail.com. 
Learn why this is important


On Wed, Jan 15, 2025 at 1:50 PM Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:
In the absence of a roster of participants, how can a percentage of votes be 
determined?
We don’t have WG membership registrations, AFAIK.

Did you mean the number of people attending a particular meeting ? Requiring 
them to sign in using the online tools. For the people who don't sign and they 
attend another meeting, they can send their IETF registration for that day or 
for the whole week to the chairs and their votes can be cast within a week or 
so after the IETF ends.

That would be an easy task I think and I don't think we should talk about it 
now.

Regards,
Quynh.

Cheers,

Andrei

From: Quynh Dang mailto:quyn...@gmail.com>>
Sent: Wednesday, January 15, 2025 10:44 AM
To: Tim Bray mailto:tb...@textuality.com>>
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation

You don't often get email from quyn...@gmail.com. 
Learn why this is important


On Wed, Jan 15, 2025 at 1:26 PM Tim Bray 
mailto:tb...@textuality.com>> wrote:
On Jan 15, 2025 at 11:37:58 AM, Quynh Dang 
mailto:quyn...@gmail.com>> wrote:

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.

No it wouldn’t

Why do you think it wouldn't take care of the problem I described?

Regards,
Quynh.

and no we (speaking as former co-chair of two WGs) wouldn’t.

I’m not sure why we’re relitigating the works-pretty-OK process of consensus 
calls from the chair and potential appeals.

 -T
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025, 2:45 PM Andrei Popov 
wrote:

>
>- I started with some change suggestions for you to consider
>
> Understood; the suggestion that consensus should be determined at the
> meetings has been opposed by others, I don’t need to repeat the arguments.
>
> Even as an employee of a large business, I cannot rely solely on the
> (increasingly more expensive) meeting attendance to participate in the IETF
> consensus process.
>
One can pay for 1 day participation to join in a meeting, see my second
email on this thread.

Regards,
Quynh.

>
>
> Also, the general idea of voting to pick the best course of action for
> complicated technical matters seems questionable. There is no minimum
> technical qualification requirement or process for the IETF attendees.
>
>
>
> I agree that as things stand, there is some level of WG chair discretion
> in determining consensus; I believe the chairs are doing a good job of
> this, in general.
>
And I say this even though I’ve been in the rough quite a few times😊
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 11:16 AM
> *To:* Andrei Popov 
> *Cc:* Tim Bray ; tls@ietf.org
> *Subject:* Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
>
>
>
>
> On Wed, Jan 15, 2025 at 2:08 PM Andrei Popov 
> wrote:
>
>
>- Did you mean the number of people attending a particular meeting ?
>
> My understanding is that consensus is not determined by meeting
> participants; it’s always determined on the mailing list. Are you
> suggesting that a certain minimum percentage of mailing list subscribers
> have to be in favor?
>
>
>
> I have not been talking about how the current consensus process works. I
> started with some change suggestions for you to consider.  Please read my
> first email(s) first.
>
>
>
> Regards,
>
> Quynh.
>
>
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 11:01 AM
> *To:* Andrei Popov 
> *Cc:* Tim Bray ; tls@ietf.org
> *Subject:* Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
> You don't often get email from quyn...@gmail.com. Learn why this is
> important 
>
>
>
>
>
> On Wed, Jan 15, 2025 at 1:50 PM Andrei Popov 
> wrote:
>
> In the absence of a roster of participants, how can a percentage of votes
> be determined?
>
> We don’t have WG membership registrations, AFAIK.
>
>
>
> Did you mean the number of people attending a particular meeting ?
> Requiring them to sign in using the online tools. For the people who
> don't sign and they attend another meeting, they can send their IETF
> registration for that day or for the whole week to the chairs and their
> votes can be cast within a week or so after the IETF ends.
>
>
>
> That would be an easy task I think and I don't think we should talk about
> it now.
>
>
>
> Regards,
>
> Quynh.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 10:44 AM
> *To:* Tim Bray 
> *Cc:* tls@ietf.org
> *Subject:* [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
> You don't often get email from quyn...@gmail.com. Learn why this is
> important 
>
>
>
>
>
> On Wed, Jan 15, 2025 at 1:26 PM Tim Bray  wrote:
>
> On Jan 15, 2025 at 11:37:58 AM, Quynh Dang  wrote:
>
>
>
> 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.
>
>
>
> No it wouldn’t
>
>
>
> Why do you think it wouldn't take care of the problem I described?
>
>
>
> Regards,
>
> Quynh.
>
>
>
> and no we (speaking as former co-chair of two WGs) wouldn’t.
>
>
>
> I’m not sure why we’re relitigating the works-pretty-OK process of
> consensus calls from the chair and potential appeals.
>
>
>
>  -T
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Changing WG Mail List Reputation

[D. J. Bernstein]

Quynh Dang writes:
> D. J. Bernstein  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.

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."

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption Call for Trust Anchor IDs

[Bob Beck]

Rather obviously, I support adoption. 

I believe TAI is a good starting point for a practical solution for the problem 
we agreed was a useful thing to solve at the interim. 


> On Jan 15, 2025, at 8:59 AM, Joseph Salowey  wrote:
> 
> At the trust tussle Interim in October we had consensus that the working 
> group was interested in working on the following problem:
> 
> “Avoid client trust conflicts by enabling servers to reliably and efficiently 
> support clients with diverse trust anchor lists, particularly in larger PKIs 
> where the existing certificate_authorities extension is not viable”
> 
> After IETF 121, we asked for submissions for possible working group adoption 
> as a starting point for this work. We received two submissions:
> 
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> 
> [1] defines a new protocol mechanism, while [2] provides an explanation of 
> why the mechanism in [1] may not be needed and may be problematic. Since the 
> second draft does not define a protocol mechanism we are not considering it 
> for adoption, but we request that working group members review both documents 
> and use [2] as input into determining whether we should adopt [1] as a 
> working group item.  Adoption as a working group item means the working group 
> has change control over and can modify it as necessary; an adopted document 
> is only a starting point.  Please respond to this thread if you think the 
> document should be adopted as a working group item. If you think the document 
> is not appropriate for adoption please indicate why.  This adoption call will 
> close on February 7, 2025.  Also please remember to maintain professional 
> behavior and keep the discussion focused on technical issues. 
> 
> Thanks,
> 
> Sean, Deirdre and Joe
> ___
> 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] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 9:42 AM D. J. Bernstein  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."
>
> ---D. J. Bernstein
>

Hi Dan,

Long time no see. Hope you are doing well.

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.

Regards,
Quynh.


>
> ___
> 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] Re: Adoption Call for Trust Anchor IDs

[David Benjamin]

Unsurprisingly, I support adoption.

To recap from the interim where we took on this problem, server operators
need to be compatible with all their supported clients, while clients need
to curate accepted certificates to maintain user security.

This client function is security-critical: accepting a wrong name/key
binding enables that key to intercept TLS. Clients cannot just check a
name/key binding from first principles, so they delegate to PKIs: elaborate
systems of trusted keys, trusted operators, expiration, revocation,
delegation, etc. These systems are inherently dynamic. To trust a CA is to
predict its future behavior, which is inherently subjective. Sometimes
those CAs are found untrustworthy, and clients must act to preserve user
security. Beyond that, as the working group often discusses, different
clients have different needs. Not everything looks like a browser. Those
different needs influence how the client interacts with a PKI.

This naturally leads to diversity, across different clients and different
versions of the same client. From the interim, supporting this, with
today's PKIs and today's tools (including cross-signs), is not easy for
server operators. The result is a conflict between security-critical PKI
maintenance, and keeping a service available to users. Both goals then
suffer, thus the motivation to solve this problem.

Trust Anchor IDs applies TLS's standard, well-understood approach to these
problems: parameter negotiation. It is a retool of certificate_authorities,
a similar, longstanding mechanism dating back to SSL 3.0. It is widely
deployed in client certificates PKIs, but is not ideal for existing, larger
PKIs. Trust Anchor IDs tries to meet those existing PKIs where they
are, and TLS's usual style of solution. At the same time, it is not
specific to one PKI. Not everything is a browser.

I think this is a good starting point for the working group. My coauthors
and I are eager to start working on it with you all. As with other drafts,
we very much expect that this too will change after adoption, perhaps
significantly. (E.g. discussion over how to approach tradeoffs between DNS
vs. unhinted ClientHellos.) This is a large solution space, and navigating
it in a working group document lets us do so reflecting the group's
consensus.

As for the draft arguing not to solve this, gosh, coming up on ten years of
contributing to this community, I don't think I've ever been quoted so
much! Unfortunately, it largely misrepresents both what's in our draft and
the motivations discussed at the interim. I'd rather not follow this
pattern of quoting and trying to dispute each sentence at length. Speaking
for myself, I am exhausted by the tenor of discussion that produces, and am
eager to move on to a more productive stage of this process. I think more
effective would be that we discuss any specific topics on the list that
folks may be interested in.

Thanks all!

David

On Wed, Jan 15, 2025 at 11:00 AM Joseph Salowey  wrote:

> At the trust tussle Interim in October we had consensus that the working
> group was interested in working on the following problem:
>
> “Avoid client trust conflicts by enabling servers to reliably and
> efficiently support clients with diverse trust anchor lists, particularly
> in larger PKIs where the existing certificate_authorities extension is not
> viable”
>
> After IETF 121, we asked for submissions for possible working group
> adoption as a starting point for this work. We received two submissions:
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> 
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> 
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of
> why the mechanism in [1] may not be needed and may be problematic. Since
> the second draft does not define a protocol mechanism we are not
> considering it for adoption, but we request that working group members
> review both documents and use [2] as input into determining whether we
> should adopt [1] as a working group item.  Adoption as a working group item
> means the working group has change control over and can modify it as
> necessary; an adopted document is only a starting point.  Please respond to
> this thread if you think the document should be adopted as a working group
> item. If you think the document is not appropriate for adoption please
> indicate why.  This adoption call will close on February 7, 2025.  Also
> please remember to maintain professional behavior and keep the discussion
> focused on technical issues.
>
>
> Thanks,
>
>
> Sean, Deirdre and Joe
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To

[TLS] Re: Changing WG Mail List Reputation

[Ted Lemon]

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  wrote:

>
>
> On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:
>
>> Quynh Dang writes:
>> > D. J. Bernstein  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] Re: Changing WG Mail List Reputation

[Watson Ladd]

On Wed, Jan 15, 2025, 9:39 AM Quynh Dang  wrote:

>
>
> On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:
>
>> Quynh Dang writes:
>> > D. J. Bernstein  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.
>

That's not something the *TLS* working group can do. I'm also not sure it's
the contributor to the issues with the tone on the mailing list that would
justify this massive deviation from the historical process.


> 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] Re: Changing WG Mail List Reputation

[Tim Bray]

On Jan 15, 2025 at 11:37:58 AM, Quynh Dang  wrote:

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.
>

No it wouldn’t and no we (speaking as former co-chair of two WGs) wouldn’t.

I’m not sure why we’re relitigating the works-pretty-OK process of
consensus calls from the chair and potential appeals.

 -T
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 12:47 PM Ted Lemon  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  wrote:
>
>>
>>
>> On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:
>>
>>> Quynh Dang writes:
>>> > D. J. Bernstein  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 

[TLS] Re: Changing WG Mail List Reputation

[D. J. Bernstein]

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."

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Adoption Call for Trust Anchor IDs

[Joseph Salowey]

At the trust tussle Interim in October we had consensus that the working
group was interested in working on the following problem:

“Avoid client trust conflicts by enabling servers to reliably and
efficiently support clients with diverse trust anchor lists, particularly
in larger PKIs where the existing certificate_authorities extension is not
viable”

After IETF 121, we asked for submissions for possible working group
adoption as a starting point for this work. We received two submissions:

[1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03


[2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00


[1] defines a new protocol mechanism, while [2] provides an explanation of
why the mechanism in [1] may not be needed and may be problematic. Since
the second draft does not define a protocol mechanism we are not
considering it for adoption, but we request that working group members
review both documents and use [2] as input into determining whether we
should adopt [1] as a working group item.  Adoption as a working group item
means the working group has change control over and can modify it as
necessary; an adopted document is only a starting point.  Please respond to
this thread if you think the document should be adopted as a working group
item. If you think the document is not appropriate for adoption please
indicate why.  This adoption call will close on February 7, 2025.  Also
please remember to maintain professional behavior and keep the discussion
focused on technical issues.


Thanks,


Sean, Deirdre and Joe
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 1:50 PM Andrei Popov 
wrote:

> In the absence of a roster of participants, how can a percentage of votes
> be determined?
>
> We don’t have WG membership registrations, AFAIK.
>

Did you mean the number of people attending a particular meeting ?
Requiring them to sign in using the online tools. For the people who
don't sign and they attend another meeting, they can send their IETF
registration for that day or for the whole week to the chairs and their
votes can be cast within a week or so after the IETF ends.

That would be an easy task I think and I don't think we should talk about
it now.

Regards,
Quynh.

>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 10:44 AM
> *To:* Tim Bray 
> *Cc:* tls@ietf.org
> *Subject:* [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
> You don't often get email from quyn...@gmail.com. Learn why this is
> important 
>
>
>
>
>
> On Wed, Jan 15, 2025 at 1:26 PM Tim Bray  wrote:
>
> On Jan 15, 2025 at 11:37:58 AM, Quynh Dang  wrote:
>
>
>
> 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.
>
>
>
> No it wouldn’t
>
>
>
> Why do you think it wouldn't take care of the problem I described?
>
>
>
> Regards,
>
> Quynh.
>
>
>
> and no we (speaking as former co-chair of two WGs) wouldn’t.
>
>
>
> I’m not sure why we’re relitigating the works-pretty-OK process of
> consensus calls from the chair and potential appeals.
>
>
>
>  -T
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption Call for Trust Anchor IDs

[Watson Ladd]

I'm not sure what I think about adoption, but maybe it rounds to yes.

At the interim I think I said (although I can't remember if I said or
typed it snarkily in a backchannel) that just because problems are
worth solving doesn't mean we can solve them. I'm afraid this is one
of them.

For the specific case of devices with long lifetimes and short
updates, sending the CA in the already existing channel ought to work.
The problem with trust anchors is it requires some far reaching
changes impacting all server software, TLS implementations, client
software, server operations, ACME clients, and maybe DNS as well. That
ain't happening to a first approximation.

Perversely, the implementors best suited to do this are the ones that
we need to adopt this the least.

At the same time I think that we have a very real "just works in
Chrome" problem that negotiation would enable. We've already seen CAs
pay more attention to Google and Apple than Mozilla in dealing with
incidents. Older proposals where it would have just been an anchor the
server needs to know how to deal with would have had all the fun of
User Agent capability negotiation. I'm glad to see this proposal at
least on a first glance avoids much of that.

I do think there are some changes that can fix some of the ubiquity
issues, in approximate reverse order of my confidence in them:

- Use a hash of the root certificate as an identifier. Do something
really clever/stupid depending on perspective to shrink it. This way
servers have a fighting chance of figuring out what it is without
additional configuration.
- Use DNS as an initial hint, not a mandatory field (maybe in
draft-beck, not sure)
- HRR for when client hello's don't have a right one, so servers can
fix busted DNS.
- wildcard by client, for cases where DNS doesn't have any info to
learn the server config
- Some guidance on how to cache this.

I do think I need to think more, and I'm definitely not sure we'll
eventually solve this, although I'm optimistic enough we can start
here. However, if the benefit requires near universal adoption with
some really far reaching systemic impacts, I don't think publication
would be warranted.

Sincerely,
Watson

On Wed, Jan 15, 2025 at 8:00 AM Joseph Salowey  wrote:
>
> At the trust tussle Interim in October we had consensus that the working 
> group was interested in working on the following problem:
>
>
> “Avoid client trust conflicts by enabling servers to reliably and efficiently 
> support clients with diverse trust anchor lists, particularly in larger PKIs 
> where the existing certificate_authorities extension is not viable”
>
>
> After IETF 121, we asked for submissions for possible working group adoption 
> as a starting point for this work. We received two submissions:
>
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
>
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of 
> why the mechanism in [1] may not be needed and may be problematic. Since the 
> second draft does not define a protocol mechanism we are not considering it 
> for adoption, but we request that working group members review both documents 
> and use [2] as input into determining whether we should adopt [1] as a 
> working group item.  Adoption as a working group item means the working group 
> has change control over and can modify it as necessary; an adopted document 
> is only a starting point.  Please respond to this thread if you think the 
> document should be adopted as a working group item. If you think the document 
> is not appropriate for adoption please indicate why.  This adoption call will 
> close on February 7, 2025.  Also please remember to maintain professional 
> behavior and keep the discussion focused on technical issues.
>
>
> Thanks,
>
>
> Sean, Deirdre and Joe
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 2:08 PM Andrei Popov 
wrote:

>
>- Did you mean the number of people attending a particular meeting ?
>
> My understanding is that consensus is not determined by meeting
> participants; it’s always determined on the mailing list. Are you
> suggesting that a certain minimum percentage of mailing list subscribers
> have to be in favor?
>

I have not been talking about how the current consensus process works. I
started with some change suggestions for you to consider.  Please read my
first email(s) first.

Regards,
Quynh.


>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 11:01 AM
> *To:* Andrei Popov 
> *Cc:* Tim Bray ; tls@ietf.org
> *Subject:* Re: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
> You don't often get email from quyn...@gmail.com. Learn why this is
> important 
>
>
>
>
>
> On Wed, Jan 15, 2025 at 1:50 PM Andrei Popov 
> wrote:
>
> In the absence of a roster of participants, how can a percentage of votes
> be determined?
>
> We don’t have WG membership registrations, AFAIK.
>
>
>
> Did you mean the number of people attending a particular meeting ?
> Requiring them to sign in using the online tools. For the people who
> don't sign and they attend another meeting, they can send their IETF
> registration for that day or for the whole week to the chairs and their
> votes can be cast within a week or so after the IETF ends.
>
>
>
> That would be an easy task I think and I don't think we should talk about
> it now.
>
>
>
> Regards,
>
> Quynh.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Quynh Dang 
> *Sent:* Wednesday, January 15, 2025 10:44 AM
> *To:* Tim Bray 
> *Cc:* tls@ietf.org
> *Subject:* [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation
>
>
>
> You don't often get email from quyn...@gmail.com. Learn why this is
> important 
>
>
>
>
>
> On Wed, Jan 15, 2025 at 1:26 PM Tim Bray  wrote:
>
> On Jan 15, 2025 at 11:37:58 AM, Quynh Dang  wrote:
>
>
>
> 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.
>
>
>
> No it wouldn’t
>
>
>
> Why do you think it wouldn't take care of the problem I described?
>
>
>
> Regards,
>
> Quynh.
>
>
>
> and no we (speaking as former co-chair of two WGs) wouldn’t.
>
>
>
> I’m not sure why we’re relitigating the works-pretty-OK process of
> consensus calls from the chair and potential appeals.
>
>
>
>  -T
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

[Bas Westerbaan]

Do the chairs have an update to share on this thread?

I'm asking explicitly as your recent message [1] could be interpreted as
one.

Best,

 Bas

[1] https://mailarchive.ietf.org/arch/msg/tls/yufDcbR8yXQUuAtldXLWTax5z8c/



On Mon, Dec 16, 2024 at 11:01 PM Sean Turner  wrote:

> Note that there are three parts to this email; the “ask” is at the end.
>
> Requests:
>
> Ciphersuite discussions in this WG often turn nasty, so we would like to
> remind everyone to keep it civil while we explain our thinking WRT recent
> requests for WG adoptions of some PQ-related I-Ds.
>
> Also, the chairs are trying to gather information here, not actually do
> the calls. If we decide to do them we will do them in the new year.
>
> Background:
>
> Currently, the TLS WG has adopted one I-D related to PQ:
> Hybrid key exchange in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
> This I-D provides a construction for hybrid key exchange in the TLS 1.3.
> The I-D has completed WG last call and is about to progress to IETF LC.
>
> There are a number of Individual I-Ds that specify PQ cipher suite for TLS
> currently being developed that specify either “pure” PQ or composite/hybrid:
>
> ML-KEM Post-Quantum Key Agreement for TLS 1.3;
>   see
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
> PQ hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,
>   see https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
> Use of Composite ML-DSA in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
> Use of SLH-DSA in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
>
> The IANA requests for code points in the I-Ds (now) all have the same
> setting for the “Recommended” column; namely, they request that the
> Recommended column be set to “N”. As a reminder (from RFC 8447bis), “N”:
>
>   Indicates that the item has not been evaluated by the IETF and
>   that the IETF has made no statement about the suitability of the
>   associated mechanism.  This does not necessarily mean that the
>   mechanism is flawed, only that no consensus exists.  The IETF
>   might have consensus to leave  items marked as "N" on the basis
>   of it having limited applicability or usage constraints.
>
> With an “N”, the authors are free to request code points from IANA without
> working group adoption. Currently, five code points have been assigned; 3
> for ML-KEM and 2 for ECDHE-MLKEM.
>
> While there have been calls to run WG adoption calls for these I-Ds, the
> WG chairs have purposely NOT done so. The WG consensus, as we understand
> it, is that because the IANA rules permit registrations in the
> Specification Required with an I-D that there has been no need to burden
> the WG; there is, obviously, still some burden because the I-Ds are
> discussed on-list (and yes there have been some complaints about the volume
> of messages about these cipher suites).
>
> There are a couple of other reasons:
>
> * The ADs are formulating a plan for cipher suites; see
> https://datatracker.ietf.org/doc/draft-pwouters-crypto-current-practices/.
>
> * There are a lot of different opinions and that likely leads to a lack of
> consensus. Based on discussions at and since Brisbane, we do not think
> there will be consensus to mark these ciphersuites as "Y" at this point,
> however the working group can take action to do so in the future.
>
> * There have been a few calls to change the MTI (Mandatory to Implement)
> algorithms in TLS, but in July 2024 at IETF 120 the WG consensus was that
> draft-ietf-tls-rfc8446bis would not be modified to add an additional
> ciphersuite because the update was for clarifications.
>
> * Adopting these or some subset of these I-Ds, will inevitably result in
> others requesting code points too. The WG has historically not been good
> about progressing cipher suite related I-Ds, either the discussion rapidly
> turns unproductive or interest wanes during the final stages in the
> publication process. So while there is great interest (based on the number
> of messages to the list) about these I-Ds, we are unsure how to avoid the
> inevitable complaints that would follow failure to adopt or not adopt a
> specific I-D based on different requirements of different individuals.We
> know some of you are thinking that that’s “tough”, but if we do not need to
> have this fight, see the previous paragraph, we do not see the harm in
> avoiding these complaints.
>
> The chairs would also like to note that currently the WG consensus is to
> NOT port PQ cipher suites back to (D)TLS 1.2.
>
> Ask:
>
> Is the WG consensus to run four separate adoption calls for the individual
> I-Ds in question?
>
> The Chairs,
> Deirdre, Joe, and Sean
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing

[TLS] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:

> Quynh Dang writes:
> > D. J. Bernstein  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] Re: Changing WG Mail List Reputation

[Alicja Kario]

On Wednesday, 15 January 2025 18:37:58 CET, Quynh Dang wrote:

On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein  wrote:


Quynh Dang writes: ...


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 ? 


Precisely, we may all agree on what's the issue, what are the facts, but
if we assign different weights to different parts of the solution
we might arrive at different solutions being the best one.

--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Changing WG Mail List Reputation

[Tim Hollebeek]

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  
Sent: Wednesday, January 15, 2025 1:04 PM
To: Ted Lemon 
Cc: tls@ietf.org
Subject: [TLS] Re: Changing WG Mail List Reputation

 

 

 

On Wed, Jan 15, 2025 at 12:47 PM Ted Lemon 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 mailto:quyn...@gmail.com> > wrote:

 

 

On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein mailto:d...@cr.yp.to> > wrote:

Quynh Dang writes:
> D. J. Bernstein 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

[TLS] Re: Changing WG Mail List Reputation

[Quynh Dang]

On Wed, Jan 15, 2025 at 1:26 PM Tim Bray  wrote:

> On Jan 15, 2025 at 11:37:58 AM, Quynh Dang  wrote:
>
> 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.
>>
>
> No it wouldn’t
>

Why do you think it wouldn't take care of the problem I described?

Regards,
Quynh.


> and no we (speaking as former co-chair of two WGs) wouldn’t.
>
> I’m not sure why we’re relitigating the works-pretty-OK process of
> consensus calls from the chair and potential appeals.
>
>  -T
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Andrei Popov]

In the absence of a roster of participants, how can a percentage of votes be 
determined?
We don’t have WG membership registrations, AFAIK.

Cheers,

Andrei

From: Quynh Dang 
Sent: Wednesday, January 15, 2025 10:44 AM
To: Tim Bray 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS] Re: Changing WG Mail List Reputation

You don't often get email from quyn...@gmail.com. 
Learn why this is important


On Wed, Jan 15, 2025 at 1:26 PM Tim Bray 
mailto:tb...@textuality.com>> wrote:
On Jan 15, 2025 at 11:37:58 AM, Quynh Dang 
mailto:quyn...@gmail.com>> wrote:

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.

No it wouldn’t

Why do you think it wouldn't take care of the problem I described?

Regards,
Quynh.

and no we (speaking as former co-chair of two WGs) wouldn’t.

I’m not sure why we’re relitigating the works-pretty-OK process of consensus 
calls from the chair and potential appeals.

 -T
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Roman Danyliw]

Hi!

From: Quynh Dang 
Sent: Wednesday, January 15, 2025 3:22 PM
To: Andrei Popov 
Cc: tls@ietf.org
Subject: [TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

Warning: External Sender - do not click links or open attachments unless you 
recognize the sender and know the content is safe.


On Wed, Jan 15, 2025, 2:45 PM Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:

  *   I started with some change suggestions for you to consider
Understood; the suggestion that consensus should be determined at the meetings 
has been opposed by others, I don’t need to repeat the arguments.
Even as an employee of a large business, I cannot rely solely on the 
(increasingly more expensive) meeting attendance to participate in the IETF 
consensus process.
One can pay for 1 day participation to join in a meeting, see my second email 
on this thread.

[Roman] To add more on the topic of meeting cot – in addition to onsite 
participation, there is a remote participation option.  If one is unable to pay 
the remote meeting fee, there is an unlimited, “no questions asked” fee waiver. 
 See https://www.ietf.org/meeting/registration-fee-waivers/.

Regards,
Roman

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption Call for Trust Anchor IDs

[Andrew Chen]

I support adoption.

My interest is particularly in the WebPKI space, where annual removals of
web trust bits starting this year will make finding common trust amongst
clients an exponentially harder problem over time. I’m sure we’ll discover
inefficiencies and problems as we debate the details of this draft, but I
think this group is the best one to work through those issues.

I’m looking forward to a collaborative discussion.

Andrew

On Wed, Jan 15, 2025 at 8:01 AM Joseph Salowey  wrote:

> At the trust tussle Interim in October we had consensus that the working
> group was interested in working on the following problem:
>
> “Avoid client trust conflicts by enabling servers to reliably and
> efficiently support clients with diverse trust anchor lists, particularly
> in larger PKIs where the existing certificate_authorities extension is not
> viable”
>
> After IETF 121, we asked for submissions for possible working group
> adoption as a starting point for this work. We received two submissions:
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> 
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> 
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of
> why the mechanism in [1] may not be needed and may be problematic. Since
> the second draft does not define a protocol mechanism we are not
> considering it for adoption, but we request that working group members
> review both documents and use [2] as input into determining whether we
> should adopt [1] as a working group item.  Adoption as a working group item
> means the working group has change control over and can modify it as
> necessary; an adopted document is only a starting point.  Please respond to
> this thread if you think the document should be adopted as a working group
> item. If you think the document is not appropriate for adoption please
> indicate why.  This adoption call will close on February 7, 2025.  Also
> please remember to maintain professional behavior and keep the discussion
> focused on technical issues.
>
>
> Thanks,
>
>
> Sean, Deirdre and Joe
>
> ___
> 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] Re: Adoption Call for Trust Anchor IDs

[Ryan Hurst]

As someone with experience building and managing many CAs, running a root
program, and building out platform technology to enable TLS use cases, I
believe this work is important and fully support its adoption. Today’s
manual, out-of-band management of trust anchors not only holds the web back
but also unnecessarily exposes users to trust anchors that are not
essential for enabling TLS on the web. This proposal provides a credible
path to address this lack of agility. While it’s clear that this
slow-moving and fragile approach is already problematic, it will only
become more challenging as time goes on. As with all specifications,
adoption remains the key challenge, but I believe this draft offers a
practical solution to these issues without disrupting existing systems.

Ryan Hurst

On Wed, Jan 15, 2025 at 8:00 AM Joseph Salowey  wrote:

> At the trust tussle Interim in October we had consensus that the working
> group was interested in working on the following problem:
>
> “Avoid client trust conflicts by enabling servers to reliably and
> efficiently support clients with diverse trust anchor lists, particularly
> in larger PKIs where the existing certificate_authorities extension is not
> viable”
>
> After IETF 121, we asked for submissions for possible working group
> adoption as a starting point for this work. We received two submissions:
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> 
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> 
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of
> why the mechanism in [1] may not be needed and may be problematic. Since
> the second draft does not define a protocol mechanism we are not
> considering it for adoption, but we request that working group members
> review both documents and use [2] as input into determining whether we
> should adopt [1] as a working group item.  Adoption as a working group item
> means the working group has change control over and can modify it as
> necessary; an adopted document is only a starting point.  Please respond to
> this thread if you think the document should be adopted as a working group
> item. If you think the document is not appropriate for adoption please
> indicate why.  This adoption call will close on February 7, 2025.  Also
> please remember to maintain professional behavior and keep the discussion
> focused on technical issues.
>
>
> Thanks,
>
>
> Sean, Deirdre and Joe
>
> ___
> 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