[TLS] Re: FATT Process Updates

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Tue, 21 April 2026 23:57 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.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 9498CE06C512 for <tls@mail2.ietf.org>; Tue, 21 Apr 2026 16:57:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776815831; bh=29RHHUrrWMeT0TIXTK0ZVb8h5bc/Zsg3ssANuaMSHAE=; h=Date:Subject:To:References:From:CC:In-Reply-To; b=XXnUOHOq5nwVuMMB3F3q3zH9mSIOt29iGd9QwuvGsX8cyaF6a0gqQOuTeZ+EfiH6Z DJ36EAwr0IMIbXiHj6jmmRuZTUVQDkZyFDgsoXVHvJCKmTeBEyzuQH0HDdjcoYlW1Q X+KMhcvNf6n/fXWEbt9yvbO/Hw1858xT/6pKANM4=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.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 w0ZbQN83XRe2 for <tls@mail2.ietf.org>; Tue, 21 Apr 2026 16:57:11 -0700 (PDT)
Received: from mailout7.zih.tu-dresden.de (mailout7.zih.tu-dresden.de [141.76.32.220]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B8451E06B949 for <tls@ietf.org>; Tue, 21 Apr 2026 16:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:CC:From:References:To :Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=33vGYvuuvetGIliXXBBPr/0OmjRvRE7sdl5l9dr+I18=; b=zSiWInxIRABxyXQyGvp5ESZ0QC 3WM4f966ENwa57cpFPSPGuK/ndOQAaxY+rgIqemq2viTL0Okpo/1EweEyUJ5iJipVpMCLlmuY1G8z 8hF72gmoE1I0swXG3AdzLoKOCY6B6yDqby2hmRLEGNJEAmAba/dyp/vN48SiYjrFDuFfCzIEO97ky DAy0lEqviUmXxaXaco9vxCEoTVVTLsW5Ahhi8mfrJe2iQjOVm7fKTlYTRZiUEWCQd2EUm/FqRbYms VV5Uyr98vIDX6VZjYBs+ndO1kUv1x80FWhXrdIpp9i86jtO83mhW7blEq5VNAGDeWNbq82oz7rFhT 6nzR854A==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout7.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1wFKoe-009HV5-1Z; Wed, 22 Apr 2026 01:47:44 +0200
Received: from [10.12.5.228] (141.76.13.149) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Wed, 22 Apr 2026 01:47:39 +0200
Message-ID: <9759b289-15aa-4cae-a306-258873b90f07@tu-dresden.de>
Date: Wed, 22 Apr 2026 01:47:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Sean Turner <sean@sn3rd.com>
References: <143FA1BF-280A-4469-ADE0-7CAE3867DB88@sn3rd.com>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <143FA1BF-280A-4469-ADE0-7CAE3867DB88@sn3rd.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms040600000805080208070901"
X-ClientProxiedBy: MSX-L416.msx.ad.zih.tu-dresden.de (172.26.34.136) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout7.zih.tu-dresden.de
Message-ID-Hash: EIR35WYTWVKKXN2ILTMKA3TBFZA5S6U2
X-Message-ID-Hash: EIR35WYTWVKKXN2ILTMKA3TBFZA5S6U2
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: TLS List <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: FATT Process Updates
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/7Xu8qAPa29BrcuJOHdY3mz---8s>
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>

Dear Deirdre, Joe, and Sean,

Following up with a new PR [0].

On 10.04.26 16:00, Sean Turner wrote:
> There were other suggestions at IETF 125, but I do not remember much support for them.

I believe some things don't really need any support. Some things already 
have consensus and are already part of the process ([1] explains this 
one specifically; so won't repeat here), for which we have spent 
significant amount of time a couple of years ago in debating on list, in 
meetings and even in an interim. So this needs folks to stand up and say 
that they oppose it, rather than someone supporting it.

TBH, I will be very surprised if there is even a single member of the WG 
who would like to get emails like [1] to be "informed" that a new FATT 
member has been added; and this is not the first time this has happened.

I am not trying to be difficult, but it's unfortunate that I have to 
repeat the same thing every time new FATT is added. I am just trying to 
think of ways to make it easier for you not to forget it. For instance, 
when you add FATT member next time, the table in [0] will remind you 
that you might like to at least inform us instead of just adding FATT 
and approving PR.

FATT addition is not frequent. IIRC we had two new in two years. So I am 
confident to say that it will not be much effort to maintain it in 
future. Nevertheless as the other PR, I am happy to volunteer to help 
maintain it in future.

It may not be super important for others, but it is for me since I kind 
of directly work with them under their guidance. I need to know who is 
in FATT; who to contact for which draft etc.

Thank you for your consideration in making it more transparent and 
keeping WG in the loop.

Sincerely,

-Usama

[0] https://github.com/tlswg/tls-fatt/pull/20

[1] https://mailarchive.ietf.org/arch/msg/tls/6usy24RJ3FQS-EwS79gd-3UEqak/