From: Simon Josefsson <simon@josefsson.org>
To: Richard Barnes <rlb@ipv.sx>
In-Reply-To: 
 <CAL02cgTob3hYSMmhOgiMiUZu0MfLRM-hV-4zQeAXp3Su=7ckCw@mail.gmail.com>
	(Richard Barnes's message of "Mon, 23 Feb 2026 14:55:41 -1000")
References: 
 <177189438640.2182161.16660142956175423236@dt-datatracker-6ff7c68975-7k42g>
	<CAL02cgTob3hYSMmhOgiMiUZu0MfLRM-hV-4zQeAXp3Su=7ckCw@mail.gmail.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE;
 url=https://josefsson.org/key-20190320.txt
Date: Sun, 01 Mar 2026 15:21:52 +0100
Message-ID: <875x7ftytb.fsf@josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"
Message-ID-Hash: QTSOVISDDZAFN6IQTSTXFKIRXAIBMPRW
CC: "<tls@ietf.org>" <tls@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Fwd=3A_New_Version_Notification_for_draft-barnes-t?=
 =?utf-8?q?ls-this-could-have-been-an-email-00=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/qWhUXSSI4o7IYCvS1xCjuGb65iU>

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1

I suggested to publish the non-hybrid ML-KEM document outside of the TLS
WG, and your proposal turns that into the new general rule.

In fact, I'd go further to suggest that we go back to the olden time
without the 'Recommended' column.  Anyone can register stuff at the
IANA.  Only RFCs turn registered algorithms into recommendations.
Everything else is not recommended implicitly.

I never understood/agreed with the justification for the 'Recommended'
column, and it seems to have consumed a significant amount of time in
both the TLS WG and SSHM WG.  Introducing it looks indistinguishable
from a successful attack on the use of IETF engineering time.

/Simon

Richard Barnes <rlb@ipv.sx> writes:

> 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: <internet-drafts@ietf.org>
> Date: Mon, Feb 23, 2026 at 2:53=E2=80=AFPM
> Subject: New Version Notification for
> draft-barnes-tls-this-could-have-been-an-email-00.txt
> To: Richard Barnes <rlb@ipv.sx>
>
>
> A new version of Internet-Draft
> draft-barnes-tls-this-could-have-been-an-email-00.txt has been successful=
ly
> 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-be=
en-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 -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmkS4AUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFosQXAQD8wauq7zEX
/F3jlCkDZi44BmVPH+3cIXAJ5Eo/60QtzgEA+69CsZJrax2WA6/UDwuinn0ORLc4
eVYn4ihAl306DAk=
=qRRi
-----END PGP SIGNATURE-----
--=-=-=--