Hi Richard, I can say with a high degree of certainty, and I agree with John that almost all of our vendors and SDOs (3GPP, GSMA) rely on IETF RFCs especially those pertaining to TLS, IKE/IPSEC, EAP....
Regards, Vinod On Tue, Feb 24, 2026 at 8:57 AM Richard Barnes <[email protected]> wrote: > Hi John, > > I'm confused. Are you saying that external SDOs aren't able to use a TLS > ciphersuite unless the TLS WG publishes an RFC on it, even if there's a > registered IANA code point? Even if that's the case, it seems like a them > problem and not an us problem. Like, get out of your own way, man. > > If they need Recommended=Y, that's a different question, and one that the > draft already accommodates. Clearly WG action is required for that. > > --Richard > > On Tue, Feb 24, 2026 at 12:46 AM John Mattsson <john.mattsson= > [email protected]> wrote: > >> Completely agree that this type of policy should be in the charter and >> not in a draft. >> >> I am against any changes in this direction until TLS WG has tried to >> understand the needs of external SDOs using TLS and made sure that we can >> improve (and sustain) the applicability and suitability of the TLS family >> of protocols for use in emerging protocols and use cases. >> >> At IETF 125, I would like to discuss sending an LS to SDOs relying on TLS >> asking them if this kind of major change would work for them and if not >> explain why. >> >> John >> >> *From: *Nadim Kobeissi <[email protected]> >> *Date: *Tuesday, 24 February 2026 at 11:11 >> *To: *Felix Linker <[email protected]> >> *Cc: * >> <[email protected]> >> *Subject: *[TLS] Re: New Version Notification for >> draft-barnes-tls-this-could-have-been-an-email-00.txt >> >> Yes, true! >> >> Nadim Kobeissi >> Symbolic Software • https://symbolic.software >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__symbolic.software&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=T9099nIA_oiCc_COALXVeia5pNzKTBSnVzH-WnfMMEw&m=AJYcl7laPWcVJ6pE2cN4WSNYfQFPj2rQjAZ_-p5YViNk8qcy8wcSVMchK01dpqHh&s=qxZs1gQwNR2wCVilojP1E3ZozasPIKEvQjnxY2sG1xg&e=> >> >> On 24 Feb 2026, at 10:25 AM, Felix Linker <[email protected]> wrote: >> >> Hi everyone, >> >> Sorry to be pedantic, but shouldn't the charter define what can and >> cannot be adopted? Adding 1-2 sentences to the charter paragraph starting >> with "The third goal..." could have the same effect as this document, but >> be one document less. >> >> Best, >> Felix >> >> Am Di., 24. Feb. 2026 um 01:56 Uhr schrieb Richard Barnes <[email protected]>: >> >> 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dbarnes-2Dtls-2Dthis-2Dcould-2Dhave-2Dbeen-2Dan-2Demail-2D00.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=T9099nIA_oiCc_COALXVeia5pNzKTBSnVzH-WnfMMEw&m=AJYcl7laPWcVJ6pE2cN4WSNYfQFPj2rQjAZ_-p5YViNk8qcy8wcSVMchK01dpqHh&s=gWbRCh7Q2f7JV7ZX_qCn0yeOhJRSEsEwJ3ohsz_SLAo&e=> >> Status: >> https://datatracker.ietf.org/doc/draft-barnes-tls-this-could-have-been-an-email/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbarnes-2Dtls-2Dthis-2Dcould-2Dhave-2Dbeen-2Dan-2Demail_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=T9099nIA_oiCc_COALXVeia5pNzKTBSnVzH-WnfMMEw&m=AJYcl7laPWcVJ6pE2cN4WSNYfQFPj2rQjAZ_-p5YViNk8qcy8wcSVMchK01dpqHh&s=jIWJIzWuo-8UDfi8g71yj15JIvHLNKK7XePGtnTVC2g&e=> >> HTML: >> https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-email-00.html >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dbarnes-2Dtls-2Dthis-2Dcould-2Dhave-2Dbeen-2Dan-2Demail-2D00.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=T9099nIA_oiCc_COALXVeia5pNzKTBSnVzH-WnfMMEw&m=AJYcl7laPWcVJ6pE2cN4WSNYfQFPj2rQjAZ_-p5YViNk8qcy8wcSVMchK01dpqHh&s=_ooZCgJJlgxksD9ozw-pJTR-DEVDSLFB4HsuQcp7WHw&e=> >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-barnes-tls-this-could-have-been-an-email >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbarnes-2Dtls-2Dthis-2Dcould-2Dhave-2Dbeen-2Dan-2Demail&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=T9099nIA_oiCc_COALXVeia5pNzKTBSnVzH-WnfMMEw&m=AJYcl7laPWcVJ6pE2cN4WSNYfQFPj2rQjAZ_-p5YViNk8qcy8wcSVMchK01dpqHh&s=9tOu149awh8rABUp57wDgQMk4UFL6XJz_S95ncCP-wo&e=> >> >> >> 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] >> > _______________________________________________ > 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]
