[TLS] Re: Draft THURDAY minutes are at

--===============9158376994070626408==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0C582C84-C524-437C-92D0-DF453789BBC1"


--Apple-Mail=_0C582C84-C524-437C-92D0-DF453789BBC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Ted,

I have not disputed that my technical position is in the minority. I =
said so explicitly. [1] RFC 7282 [2] governs rough consensus on =
technical decisions, and I accept its implications in that domain.

What I have raised separately is a concern about process, specifically, =
chair conduct during this WGLC. That is a distinct matter, and one that =
rough consensus doctrine does not and was not designed to govern. Using =
it to address the second question by way of the first is an =
understandable shortcut, but not quite right.

I also don=E2=80=99t know if your =E2=80=9Cdenial of service=E2=80=9D =
characterization really captures the full context here. I worry that we =
toss this term around as a thought-terminating clich=C3=A9 these days. =
Anything that takes issue with a process that some would like concluded, =
wrapped and stored is suddenly =E2=80=9Cdenial of service=E2=80=9D. =
=E2=80=9CDenial of service=E2=80=9D often presupposes bad faith or =
dilatory intent. I have raised a specific technical objection and a =
specific process concern, both in good faith. I would ask that the =
framing be reconsidered.

I take the point about mailing list friction seriously. I have not, and =
will not press the technical matter further on-list, as I=E2=80=99ve =
already indicated in [1].

I think it=E2=80=99s important to focus on what I=E2=80=99m actually =
raising here and not bundling me with matters raised by others who =
happen to overlap with me on some positions, or their understood intent.

[1] =
https://mailarchive.ietf.org/arch/msg/tls/O5tgVST_oEtwC5-PvoD-xaMEKRk/=20=

[2] https://datatracker.ietf.org/doc/html/rfc7282=20

Nadim Kobeissi
Symbolic Software =E2=80=A2 https://symbolic.software

> On 23 Jul 2026, at 12:34=E2=80=AFPM, Ted Lemon <[email protected]> =
wrote:
>=20
> Nadim, fundamentally, you can always read documents to support your =
own perspective. That's human nature.=20
>=20
> What you are seeing in this discussion is that a massive majority of =
working group participants believe that your perspective is mistaken. =
You can of course continue to insist that it is not, and this is your =
right and privilege. But what you are hearing is that we, the working =
group, would really like to stop being bombarded by repeated messages =
where someone who is in the rough (go read RFC7282 if you don't know =
what that phrase means) insists on re-litigating a point that's been =
resolved to the satisfaction of the working group.
>=20
> This amounts to a denial-of-service attack, and works very much =
against the open process in the iETF. Most of us do IETF standards work =
in support of a day job where we are paid to write software or maintain =
systems, not to endlessly debate standards. So this behavior makes it =
too expensive for us to participate.
>=20
> This is really important, Nadim. I've done both sorts of jobs=E2=80=94I =
had a job for a long time that paid me to do standards work as my main =
task, and I could spend as much time as I wanted discussing what I =
thought. Now I have a job where I'm building things. I think the quality =
of my work has improved a lot as a result of this, but at the expense of =
my ability to participate when working groups turn toxic as a result of =
these denial-of-service attacks. The IETF needs practitioners, not just =
standards wonks. No criticism to either group: this is a pracitcal =
matter.
>=20
> So when you read that document, please, keep this in mind. There is a =
HUGE cost to the kind of discourse that we've had on the TLS mailing =
list the past month. You seem to be a considerate person, and I think =
you're doing your best, but there's a reason the consensus on =
"draconian" moderation came out the way it did, and you really should =
pay attention and not just assume we're all jerks who are out to =
suppress your opinions.
>=20


--Apple-Mail=_0C582C84-C524-437C-92D0-DF453789BBC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">Hi Ted,<div><br></div><div><div>I have =
not disputed that my technical position is in the minority. I said so =
explicitly. [1] RFC 7282 [2] governs rough consensus on technical =
decisions, and I accept its implications in that =
domain.</div><div><br></div><div>What I have raised separately is a =
concern about process, specifically, chair conduct during this WGLC. =
That is a distinct matter, and one that rough consensus doctrine does =
not and was not designed to govern. Using it to address the second =
question by way of the first is an understandable shortcut, but not =
quite right.</div><div><br></div><div>I also don=E2=80=99t know if your =
=E2=80=9Cdenial of service=E2=80=9D characterization really captures the =
full context here. I worry that we toss this term around as a =
thought-terminating clich=C3=A9 these days. Anything that takes issue =
with a process that some would like concluded, wrapped and stored is =
suddenly =E2=80=9Cdenial of service=E2=80=9D. =E2=80=9CDenial of =
service=E2=80=9D often presupposes bad faith or dilatory intent. I have =
raised a specific technical objection and a specific process concern, =
both in good faith. I would ask that the framing be =
reconsidered.</div><div><br></div><div>I take the point about mailing =
list friction seriously. I have not, and will not press the technical =
matter further on-list, as I=E2=80=99ve already indicated in =
[1].</div><div><br></div><div>I think it=E2=80=99s important to focus on =
what I=E2=80=99m actually raising here and not bundling me with matters =
raised by others who happen to overlap with me on some positions, or =
their understood intent.</div><div><br></div><div>[1]&nbsp;<a =
href=3D"https://mailarchive.ietf.org/arch/msg/tls/O5tgVST_oEtwC5-PvoD-xaME=
KRk/">https://mailarchive.ietf.org/arch/msg/tls/O5tgVST_oEtwC5-PvoD-xaMEKR=
k/</a>&nbsp;</div><div>[2]&nbsp;<a =
href=3D"https://datatracker.ietf.org/doc/html/rfc7282">https://datatracker=
.ietf.org/doc/html/rfc7282</a>&nbsp;</div><div>
<meta charset=3D"UTF-8"><br>Nadim Kobeissi<br>Symbolic Software =
=E2=80=A2&nbsp;https://symbolic.software<br>
</div>
<div><br><blockquote type=3D"cite"><div>On 23 Jul 2026, at 12:34=E2=80=AFP=
M, Ted Lemon &lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>Nadim, fundamentally, you =
can always read documents to support your own perspective. That's human =
nature. <br><br>What you are seeing in this discussion is that a massive =
majority of working group participants believe that your perspective is =
mistaken. You can of course continue to insist that it is not, and this =
is your right and privilege. But what you are hearing is that we, the =
working group, would really like to stop being bombarded by repeated =
messages where someone who is in the rough (go read RFC7282 if you don't =
know what that phrase means) insists on re-litigating a point that's =
been resolved to the satisfaction of the working group.<br><br>This =
amounts to a denial-of-service attack, and works very much against the =
open process in the iETF. Most of us do IETF standards work in support =
of a day job where we are paid to write software or maintain systems, =
not to endlessly debate standards. So this behavior makes it too =
expensive for us to participate.<br><br>This is really important, Nadim. =
I've done both sorts of jobs=E2=80=94I had a job for a long time that =
paid me to do standards work as my main task, and I could spend as much =
time as I wanted discussing what I thought. Now I have a job where I'm =
building things. I think the quality of my work has improved a lot as a =
result of this, but at the expense of my ability to participate when =
working groups turn toxic as a result of these denial-of-service =
attacks. The IETF needs practitioners, not just standards wonks. No =
criticism to either group: this is a pracitcal matter.<br><br>So when =
you read that document, please, keep this in mind. There is a HUGE cost =
to the kind of discourse that we've had on the TLS mailing list the past =
month. You seem to be a considerate person, and I think you're doing =
your best, but there's a reason the consensus on "draconian" moderation =
came out the way it did, and you really should pay attention and not =
just assume we're all jerks who are out to suppress your =
opinions.<br><br></div></div></blockquote></div><br></div></body></html>=

--Apple-Mail=_0C582C84-C524-437C-92D0-DF453789BBC1--


--===============9158376994070626408==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp
bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0
bHMtbGVhdmVAaWV0Zi5vcmcK

--===============9158376994070626408==--