[TLS] Re: Request to the Working Group Chairs (according to RFC 2026 Section 6.5.1 in conjunction with RFC 2418 Section 3.4) – Re: Improving the quality of the discussion on the TLS email list

Ken Kubota <ietf@kenkubota.de> Sun, 02 August 2026 22:03 UTC

Return-Path: <ietf@kenkubota.de>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 271B712269652; Sun, 2 Aug 2026 15:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785708203; bh=BWtaYXmAIM+ekETGnimVj9mI7U/TVrskMOnY2evha0A=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=A8bXlXqSYvyuTuTEfjTYmG8W+RdRRftM6AgO7alak2yffwfiJVESaUESfw35PntVD Xx4BDhV7huMCTWKKcI/eljSpaziDBOJJ0F46UiCZlccMKrKLYSBsWFR0PvZqroIbdG p0dGxzD5mxMKw+BrvFG/sAo9/EQ+wBoIJ842Q3dI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=kenkubota.de
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7VFjZJu3ZUZ; Sun, 2 Aug 2026 15:03:22 -0700 (PDT)
Received: from plasma4.jpberlin.de (plasma4.jpberlin.de [80.241.57.33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2B1741226964A; Sun, 2 Aug 2026 15:03:21 -0700 (PDT)
Received: from spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) by plasma.jpberlin.de (Postfix) with ESMTP id 422EFAC1B7; Mon, 3 Aug 2026 00:03:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kenkubota.de; s=MBO0001; t=1785708197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7jeHZ91jcZcdxT8AgvdDIRNBXdlmQdfpNj26CiwFQW8=; b=DrNQvfFLZhl5OH4OmuUVtj2ePG5XgMWyqX8ZoeQN+/DJ6ISPhmSyufxz+kOZEZW4ntJafW LUEA2i00ewRj9q8styZ1DrM8ZmgDYI9JmNaX/jSyKqCY+53DBaKCkbtL49/4+eLQOjrBm5 e9GuU4hicYlC+WQISI6ML8io5hLJ0x1SVr7FmGxOfaHe3buLCIIuxO3etVfxS2EvFL+L7w 2BHP+WULSNxXD0XcMSEK9VSl+nE9kotJ9SPr1pvCBqIMz6ltj5eOPh6MVinB7SocIrtL3X tISsbQUIh9+LUberHCruUTiWjfFiBX9SH8RKbW6CvZZmfO4zeT4DwGgMs4sLwA==
Received: from plasma.jpberlin.de ([80.241.56.68]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id fJj3xOAnU9Mw; Mon, 3 Aug 2026 00:03:11 +0200 (CEST)
Received: from smtpclient.apple (unknown [37.19.200.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ietf@kenkubota.de) by plasma.jpberlin.de (Postfix) with ESMTPSA id 04F46AC248; Mon, 3 Aug 2026 00:03:07 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
From: Ken Kubota <ietf@kenkubota.de>
In-Reply-To: <CAGgd1Od38b-JLscbCYBfK_xuS09CA6pXx+jgc7hPwrbVKKiLHQ@mail.gmail.com>
Date: Mon, 03 Aug 2026 00:02:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <25F94EAE-AA8D-4F40-A6C3-EB97CE19B411@kenkubota.de>
References: <CAEzBKQ4fymnSeo8tgqMLOfKopvMGk4xnDq=SQJKf-RBL4-uh6g@mail.gmail.com> <CAEEbLAbhZUpempA9Rvjhm1qrLfBWXa_2ntdfpO20cqDu0h5fbQ@mail.gmail.com> <CAEzBKQ6NOzQc66T+SEdSvLa2gxjtO77DYUUWuTfr99zV_a-Ofg@mail.gmail.com> <c8a74833-35cd-44a0-8992-e5463a82aa8f@dennis-jackson.uk> <F95592F7-6E60-4835-B21C-B5B1954084F7@kenkubota.de> <b3321e23-5f9b-4f8a-8bd9-d2cca2800d67@lear.ch> <amypaHNTh0Ya7XF+@ein.win.tue.nl> <538b6162-6cbb-4051-9810-601b29f880fe@app.fastmail.com> <CAA+_yBYWP_3MOcTM8FH8wjiif_L_WLOPVHKnp8nVmGJzFiCCpQ@mail.gmail.com> <f5cb425b-6fd4-48f2-aec0-5272e9ff30fe@app.fastmail.com> <0F869FB6-FAF9-4DBB-A046-3ABEA0A14C44@joseon.com> <MN2PR17MB40315611A5F4FD712F362BA9CDC82@MN2PR17MB4031.namprd17.prod.outlook.com> <8A9729C8-6F3A-4CC5-8313-27B415146C74@kenkubota.de> <MN2PR17MB4031AD772BC0B7E14DE91B3CCDD72@MN2PR17MB4031.namprd17.prod.outlook.com> <1DE383DF-E53D-406E-A722-FE210D157A4B@kenkubota.de> <CAGgd1Od38b-JLscbCYBfK_xuS09CA6pXx+jgc7hPwrbVKKiLHQ@mail.gmail.com>
To: Deb Cooley <debcooley1@gmail.com>
Message-ID-Hash: QG7FZJHJHHJW7MR6F3XK3SUFXGCOXZL4
X-Message-ID-Hash: QG7FZJHJHHJW7MR6F3XK3SUFXGCOXZL4
X-MailFrom: ietf@kenkubota.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; header-match-tls.ietf.org-1; header-match-tls.ietf.org-2; header-match-tls.ietf.org-3; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: tls-chairs@ietf.org, tls-ads@ietf.org, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Andrew Lee <andrew@joseon.com>, Orr Dunkelman <orrd@cs.haifa.ac.il>, "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Request to the Working Group Chairs (according to RFC 2026 Section 6.5.1 in conjunction with RFC 2418 Section 3.4) – Re: Improving the quality of the discussion on the TLS email list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kcAcS15Y5ieQoj-r9PzXZIis8Jk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Firstly, the previously asked questions remain unanswered.
As mentioned in [1] and [2], your warning email from a few weeks ago [3] prima facie constitutes a violation of RFC 3934 Section 2 [4].
Please address Questions 1 through 4, which were stated in [1] and referred to in [2].

Secondly, your current interference now appears to constitute a repeated violation of the IETF Code of Conduct.
As you have not indicated any other role than previously cited in [3], you are acting in the capacity of Area Director.
RFC 2026 Section 6.5.1 [5] specifies that the first level of the escalation ladder [6] involves the "Working Group's chair(s)" only, whereas the "Area Director(s)" are to be involved at the second level.
At this first level, any objection, including those concerning non-compliance with formal requirements, solely lies within the responsibility of the Working Group's chair(s).

Thirdly, your involvement at this first level of the escalation ladder compromises your role as an Area Director.
RFC 2026 Section 6.5.1 [5], which specifies four levels of escalation, implies that at each subsequent level the decision can be reconsidered without bias, and hence without prior involvement.
Through your behavior, this second level, and consequently the independent review of the matter and the fair consideration of the subject as a whole, is jeopardized.
For this reason, I am also sending this message to the address tls-ads@ietf.org listed in [7] to ensure that all Area Directors (Deb Cooley, Christopher Inacio) receive it.

Kind regards,

Ken Kubota

____________________________________________________

Ken Kubota
https://doi.org/10.4444/100



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

[2] https://mailarchive.ietf.org/arch/msg/tls/UDvPmpd0jIpcFkLgoZZSWlcH6Ok/

[3] https://mailarchive.ietf.org/arch/msg/tls/hBFfH4lHo-cLPNfikGfxkoV6hAY/

[4] https://datatracker.ietf.org/doc/html/rfc3934#section-2

[5] https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.1

[6] https://mailarchive.ietf.org/arch/msg/tls/ByLJ7Kf1EbP2fESF5R4KRhkKPsE/

[7] https://datatracker.ietf.org/wg/tls/email/



> Am 02.08.2026 um 17:35 schrieb Deb Cooley <debcooley1@gmail.com>:
> 
> Hi, 
> 
> It is unclear, to me, what the purpose of this email is.  
> 
> Are you filing a complaint (sometimes called an appeal) to the chairs?  If so, this is done in accordance with RFC 2026, Section 6.5.1.  You need to state what your complaint is, clearly and concisely.  And you can attempt to request a resolution date, but that is not binding on the chairs.
> 
> Or is there another purpose?  I encourage you again to be clear and concise.
> 
> I also suggest you take a look at RFC 7282, Sections 5-7 (especially 7) [0]
> 
> 
> 
> [0] https://datatracker.ietf.org/doc/html/rfc7282
> 
> 
> 
> 
> On Sun, Aug 2, 2026 at 8:35 AM Ken Kubota <ietf@kenkubota.de> wrote:
> [Request to the Working Group Chairs (according to RFC 2026 Section 6.5.1 in conjunction with RFC 2418 Section 3.4)]
> [Response to Rich Salz]
> 
> In the event of a conflict, the first step in the escalation ladder involves the WG Chairs [1, 2].
> 
> Attempting to bypass this step (your second suggestion) by filing an appeal now would lead to an automatic rejection of the appeal, as outlined in [2].
> Similarly, attempting to discuss this directly without the WG Chairs (your first suggestion) will waste time and resources, yet yield no resolution regarding the decision in question.
> 
> If you are genuinely concerned about resolving this conflict, please also urge the WG Chairs to fulfill their responsibility in actively resolving the issue by participating in the discussion on this mailing list.
> 
> Numerous complaints have been lodged by experts from academia, industry, and government.
> The decision based on an alleged "rough consensus" [3] was announced on "Sun, 19 July 2026 11:31 UTC" [3].
> To comply with the two-month deadline for complaints, an appeal must be filed no later than
>     September 18th
> ("All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged." [4]).
> 
> Due to the protracted standard escalation process [1], the relatively tight deadline, and the lack of response from the WG Chairs -- not only to the many complaints, but also to my email sent on 17 July [5] --, it has now become incumbent upon the Chairs to participate in this discussion here on this mailing list.
> 
> For this reason, I am forwarding this message to the address tls-chairs@ietf.org listed in [6], to ensure all Chairs (Deirdre Connolly, Joseph A. Salowey, Sean Turner) [7] receive it.
> 
> To resolve this highly contentious issue in a constructive and fair manner, the WG Chairs are requested to reply by
>     Sunday, August 9, 2026
> to all open emails, rather than providing merely summarizing statements, ensuring that all objections are fully addressed.
> 
> Kind regards,
> 
> Ken Kubota
> 
> ____________________________________________________
> 
> Ken Kubota
> https://doi.org/10.4444/100
> 
> 
> 
> [1] https://mailarchive.ietf.org/arch/msg/tls/ByLJ7Kf1EbP2fESF5R4KRhkKPsE/
> "    ... going through the standard escalation ladder
>     Working Group's chair(s) -> Area Director(s) -> IESG -> IAB [1]
>     prior to escalating to a higher instance
>     (according to RFC 2026 Section 6.5.1 in conjunction with RFC 2418 Section 3.4) ...,"
> 
> [2] https://datatracker.ietf.org/group/iesg/appeals/artifact/315
> "taken in specific instances by WG Chairs should be raised through the conflict resolution practices outlined in Section 3.4 of RFC2418 and Section 6.5 of RFC2026."
> 
> [3] https://mailarchive.ietf.org/arch/msg/tls/tPe7m_vpmDco43588yVW3JWrb8U/
> 
> [4] https://www.rfc-editor.org/info/rfc2026/#section-6.5.4
> 
> [5] https://mailarchive.ietf.org/arch/msg/tls/ZEmoMBkoOu9uLeZe0zcettVy5qY/
> 
> [6] https://datatracker.ietf.org/wg/tls/email/
> 
> [7] https://datatracker.ietf.org/wg/tls/about/
> 
> 
> 
> > Am 01.08.2026 um 14:16 schrieb Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>:
> > 
> > On 7/31/26, 8:24 PM, "Ken Kubota" <ietf@kenkubota.de> wrote:
> > 
> > Please show me where in 2026 and/or 2418 where it says that the reasoning behind all decisions must be made public.  Perhaps take a look at the definition of formal record in [1] and the discussion of how to determine consensus at [2].
> > 
> > If you don’t like the decision the chairs have made, you can appeal it. The appealing body will look at the evidence and decide who is right. This is not a court of law, there is no testimony, diaries, notes about discussions, or the like.
> > 
> > [1] https://www.rfc-editor.org/info/rfc2026/#section-8
> > [2] https://www.rfc-editor.org/info/rfc2418/#section-3.3
> > _______________________________________________
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-leave@ietf.org
> 
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org