Yes, in all honesty, one must admit that the chairs deserve some credit. There 
is always room for improvement, but that’s a given in all cases.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 6 May 2026, at 4:41 PM, Tim Hollebeek 
> <[email protected]> wrote:
> 
> Thanks Deirdre, Joe, and Sean for all your hard work, and being willing to 
> serve in roles that might be a strong contender for hardest chair role at 
> IETF.
> 
> -Tim
> From: John Mattsson <[email protected]>
> Sent: Wednesday, May 6, 2026 10:36 AM
> To: David Benjamin <[email protected]>; Sean Turner <[email protected]>
> Cc: TLS List <[email protected]>
> Subject: [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3
>  
> Agree, thanks Deirdre, Joe, and Sean for your hard work and leadership!
> 
> From: David Benjamin <[email protected]>
> Date: Wednesday, 6 May 2026 at 15:20
> To: Sean Turner <[email protected]>
> Cc: TLS List <[email protected]>
> Subject: [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3
> 
> -- 
> 
> Thanks, Deirdre, Joe, and Sean, for all your hard work in navigating these WG 
> discussions!
> 
> On Wed, May 6, 2026 at 9:09 AM Sean Turner <[email protected] 
> <mailto:[email protected]>> wrote:
> Replying to the original consensus call message.
> 
> RFC 2418 Section 3.3 lays out the criteria for “rough consensus”:
> 
>    Working groups make decisions through a "rough consensus" process.
>    IETF consensus does not require that all participants agree although
>    this is, of course, preferred.  In general, the dominant view of the
>    working group shall prevail.  (However, it must be noted that
>    "dominance" is not to be determined on the basis of volume or
>    persistence, but rather a more general sense of agreement.) Consensus
>    can be determined by a show of hands, humming, or any other means on
>    which the WG agrees (by rough consensus, of course).  Note that 51%
>    of the working group does not qualify as "rough consensus" and 99% is
>    better than rough.  It is up to the Chair to determine if rough
>    consensus has been reached.
> 
> In this case, during WGLC there was an almost 4:1 ratio for progressing this 
> draft, which we judge fits within the numeric “more than 51% and less than 
> 99%” range suggested by this text for “rough consensus” and represents the 
> “dominant view of the working group”.
> 
> In assessing rough consensus, we also considered the nature of the 
> objections. In reviewing the list traffic, the majority of objections related 
> to the status of pure MLDSA versus composite MLDSA-ECC, including (1) we 
> should not publish a pure MLDSA specification at all; (2) we should recommend 
> composites over pure MLDSA; (3) we should publish the composite and pure 
> MLDSA specifications concurrently. While there was substantial disagreement 
> on these points, we believe that the discussion on-list sufficiently aired 
> the respective points of view and that the right approach is fundamentally a 
> judgement call based on weighing various technical factors, which each WG 
> participant needs to make for themselves. We see no reason to believe that 
> participants were not able to make informed judgements.
> 
> Conclusion: The chairs believe there is consensus to proceed with publication 
> of this draft as an RFC with Recommended=N for those people that want to use 
> this algorithm, and a future Standards Action will be needed to make a change 
> to Recommended=Y, if anyone has the willingness to undergo this heated 
> discussion again.
> 
> For transparency purposes, the chairs note that we received a 
> complaint/appeal about the consensus call. The message was moderated due to a 
> previous notice of moderation; see [1], and the complaint/appeal contains a 
> derivative work notice. As a result, the message was not sent to the mail 
> list and we will not process the complaint/appeal as-is. If the message is 
> resubmitted without the notice, the message can be posted to the mail list 
> and we will process the complaint/appeal.
> 
> The Chairs,
> Deirdre, Joe, and Sean
> 
> [1] https://mailarchive.ietf.org/arch/msg/tls/no0lW8r_wIPGF1ZXWB3EaGywh9Q/ 
> <https://url.avanan.click/v2/r01/___https://mailarchive.ietf.org/arch/msg/tls/no0lW8r_wIPGF1ZXWB3EaGywh9Q/___.YXAzOmRpZ2ljZXJ0OmE6bzo1MDE2ZjM5NjQ0Y2E5M2ViODdhMjQxNDFmYjMxNDFhMjo3OjUxNGE6OTkyYmQzYjEzMmY0YmM1MjY4NDg2ZTMyYmExYjhlZjNhMGE3YzA3N2QzZjRiOGE3NTc4MTk5YzY5Yjc5NTMzMzpoOlQ6Rg>
> 
> On Apr 28, 2026, at 16:24, Sean Turner <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> Hi! The chairs have judged that there is consensus to progress this I-D. We 
> will work with the authors to get a new version submitted and we will get to 
> work on the Shepherd Write-Up.
> 
> The Chairs,
> Deirdre, Joe, and Sean
> 
> On Apr 9, 2026, at 15:30, Sean Turner <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> This is the working group last call for Use of ML-DSA in TLS 1.3. Please 
> review draft-ietf-tls-mldsa [1] and reply to this thread indicating if you 
> think it is ready for publication or not. If you do not think it is ready 
> please indicate why. This call will end on April 23, 2026.
> 
> REMINDER: If you have not done so recently, review the TLS WG's Mail List 
> Procedures; see [2].
> 
> The Chairs,
> Deirdre, Joe, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/ 
> <https://url.avanan.click/v2/r01/___https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/___.YXAzOmRpZ2ljZXJ0OmE6bzo1MDE2ZjM5NjQ0Y2E5M2ViODdhMjQxNDFmYjMxNDFhMjo3OjY1NDg6NzljOWU4ZmYxZDhiMWI4ODQ0MDEwNTk2MzVhOTdmZGQ0Y2VlMTk5ZWQ3NzgzYmFmMWU0NDU1YjdhNzIzNjVjYjpoOlQ6Rg>
> [2] https://mailarchive.ietf.org/arch/msg/tls/ucdImHExlbOf4Q3BCG81gjzi2xE/ 
> <https://url.avanan.click/v2/r01/___https://mailarchive.ietf.org/arch/msg/tls/ucdImHExlbOf4Q3BCG81gjzi2xE/___.YXAzOmRpZ2ljZXJ0OmE6bzo1MDE2ZjM5NjQ0Y2E5M2ViODdhMjQxNDFmYjMxNDFhMjo3OjhlNGE6Zjc2ZTk4ZDc2MTZjZTg4NDdkNjJiNTNlOTBmMWI1ZmU0YzZmNDAwZTVmNGM4YjczNWM1YjM0YTQ4NmZjNjVlYzpoOlQ6Rg>
> 
> 
> _______________________________________________
> TLS mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected] <mailto:[email protected]>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to