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-perso
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 d
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
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" ye
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 wor
* 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 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
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
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 solut
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 t
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 s
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
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
co
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:
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 relit
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
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."
-
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 ex
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 us
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 spec
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 minim
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 ar
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
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
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 tho
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'
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 Li
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.
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
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 a
30 matches
Mail list logo
