On Mon, Feb 23, 2026 at 5:52 PM Deirdre Connolly <[email protected]>
wrote:
> Oh ho ho so we do need RFCs!
>
Sometimes. As Section 3 says:
The registry policies in [RFC8447] define a few specific things that
require working group action.
* Initial registration with Recommended=Y
* Changing the value of the Recommended column to "Y" or "D" from
something else
* Changing the value of the Recommended column from "Y" or "D" to
something else
The point is that we don't otherwise need RFCs.
-Ekr
> On Mon, Feb 23, 2026 at 8:51 PM Eric Rescorla <[email protected]> wrote:
>
>>
>>
>> On Mon, Feb 23, 2026 at 5:47 PM Deirdre Connolly <
>> [email protected]> wrote:
>>
>>> > If others agree that this is a good policy, then I think we should
>>> enact
>>> i> t with retroactive effect, which is to say:
>>>
>>> > 1. Make ECHDE/MLKEM Recommended=Y (as also suggested by
>>> Bas's draft).
>>> > 2. Decline to publish draft-ietf-tls-mlkem
>>>
>>> Why not claw back -ecdhe-mlkem?
>>>
>>
>> That would be another alternative, but I think it should be Recommended=Y
>> and
>> that requires an RFC at Standards Track.
>>
>> -Ekr
>>
>>
>>>
>>> On Mon, Feb 23, 2026 at 8:03 PM Eric Rescorla <[email protected]> wrote:
>>>
>>>> I strongly support this draft. One of the main reasons for relaxing the
>>>> registration rules and introducing the Recommended column was to
>>>> avoid spending time debating the merits of new algorithms that everyone
>>>> knew weren't going to be standardized, and yet a huge fraction of the
>>>> mail on the list over the past few months is doing precisely that.
>>>>
>>>> The obvious objection to this draft is that there might be some work
>>>> required to refine how an algorithm is used and that an I-D might not be
>>>> enough for that. I have two responses to that:
>>>>
>>>> - Recent history does not seem to indicate that is the case. We're
>>>> busily debating parts of the specification that have no impact on
>>>> the wire format.
>>>> - If an algorithm isn't important enough to have Recommended=Y,
>>>> then it's not worth WG time to refine it.
>>>>
>>>> If others agree that this is a good policy, then I think we should enact
>>>> it with retroactive effect, which is to say:
>>>>
>>>> 1. Make ECHDE/MLKEM Recommended=Y (as also suggested by
>>>> Bas's draft).
>>>> 2. Decline to publish draft-ietf-tls-mlkem
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> On Mon, Feb 23, 2026 at 4:56 PM Richard Barnes <[email protected]> wrote:
>>>>
>>>>> Hi TLS folks,
>>>>>
>>>>> Those who have worked with me know that I hate doing unnecessary
>>>>> work. It occurred to me that the TLS WG has been doing a lot of
>>>>> unnecessary work on drafts that just register crypto algorithms. This
>>>>> draft proposes that we shouldn't do that.
>>>>>
>>>>> Submitted for your consideration,
>>>>> --Richard
>>>>>
>>>>> ---------- Forwarded message ---------
>>>>> From: <[email protected]>
>>>>> Date: Mon, Feb 23, 2026 at 2:53 PM
>>>>> Subject: New Version Notification for
>>>>> draft-barnes-tls-this-could-have-been-an-email-00.txt
>>>>> To: Richard Barnes <[email protected]>
>>>>>
>>>>>
>>>>> A new version of Internet-Draft
>>>>> draft-barnes-tls-this-could-have-been-an-email-00.txt has been
>>>>> successfully
>>>>> submitted by Richard Barnes and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Name: draft-barnes-tls-this-could-have-been-an-email
>>>>> Revision: 00
>>>>> Title: Stop Doing Cryptographic Algorithm Drafts when Email to IANA
>>>>> is All You Need
>>>>> Date: 2026-02-24
>>>>> Group: Individual Submission
>>>>> Pages: 5
>>>>> URL:
>>>>> https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-email-00.txt
>>>>> Status:
>>>>> https://datatracker.ietf.org/doc/draft-barnes-tls-this-could-have-been-an-email/
>>>>> HTML:
>>>>> https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-email-00.html
>>>>> HTMLized:
>>>>> https://datatracker.ietf.org/doc/html/draft-barnes-tls-this-could-have-been-an-email
>>>>>
>>>>>
>>>>> Abstract:
>>>>>
>>>>> People keep pitching drafts to the TLS Working Group where the only
>>>>> thing the draft does is register a code point for a cryptographic
>>>>> algorithm. Stop doing that. It's unnecessary. Write an email to
>>>>> IANA instead.
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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]
>>>>
>>>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
