[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

["D. J. Bernstein" <[e-mail]>]

Sean Turner writes:
> Joe and I, as WG chairs and with Deirdre recusing as she is an author,
> declared consensus to adopt draft-connolly-tls-mlkem-key-agreement. We
> did this because there is clearly sufficient interest to work on this
> draft.

Thanks for your message.

"Sufficient interest to work on this draft" is ambiguous (sufficient for
what?), and in any case clearly not the correct criterion for declaring
consensus to adopt a draft.

As an extreme example, this criterion would allow a draft to be adopted
over amply justified objections of almost all WG participants, simply
because the chairs and a few participants say they have enough interest
in working on the draft! That's more extreme than what happened here,
but it shows that the criterion stated above is procedurally improper.

So I'm guessing that you had some further points in mind in deciding
that there was consensus to adopt this draft. For transparency, can you
please, without omissions, say why you declared consensus to adopt? Or,
if the above really is the complete explanation, can you please say so
explicitly, to enable an appeal saying that this was improper? Either
way, can you please clarify what "sufficient" is referring to? Thanks
in advance.

> Different working groups have different styles with respect to
> how much work is done by the individual author, versus how much work
> is done by the WG after adopting the work.

This generic background information about WG work allocation seems off
topic (the topic being the disagreement regarding consensus). Certainly
this background information doesn't say anything about the draft at
hand. If I'm missing some connection, please elaborate.

> Now that the draft is a WG draft, we will follow WG process by
> discussing concerns, already raised and new ones, under IETF change
> control and progressing after there is consensus.

This also isn't addressing the consensus question, plus it seems to be
denying the existence of the active RFC 2026 Section 6.5.1 procedure
challenging the chairs' decision to adopt in the first place.

---D. J. Bernstein