So I will respond on list with the gist of what we just discussed on the telechat with the authors and chairs: my position, which is (for now) supported by other ADs, is that there should be no harm in copying the text that defines the Recommended=N choice for the benefit of both readers of the future RFC so the comparison of texts isn't so different when their values are the same, and and benefit of document authors who take a dependency on this. This has been left to Deb's response when she returns from time off with no decision being made.
To your specific point about =N being the default: that makes sense to me as an IETF process, but I'm not convinced this is so obvious to someone reading the registry, especially the nuance about pre and post 9847 values having different implications. > > On Jul 2, 2026 at 07:52, John Mattsson <[email protected]> wrote: > > > Tommy Jensen wrote: > > >As it stands, I cannot in good faith agree this document is ready for > publication when the only other RFC (9963) to define Recommended=N values in > this registry not published through ISE (and therefore lacks the "IETF > doesn't endorse this" language) went to great lengths to explain why it is > =N, but this document says absolutely nothing about it. That creates a very > obvious difference in the documents with =N entries, where all but one > explicitly tell the reader it isn't endorsed or it normatively must/should > not be used in the default case. > > > > I don't think an ISE document should set any precedent for working group > documents. > > > > This is also not the first working group document to use RECOMMENDED = N. > draft-ietf-tls-ecdhe-mlkem, the first working group document to be published > after RFC 9847, does the same. RFC 9847 significantly revised the definitions > of Y and N and introduced RECOMMENDED = D, so registrations made before RFC > 9847 have limited relevance. > > > > People may have different views, but my view is that RECOMMENDED = N does > not require any explanation, whereas RECOMMENDED = Y and RECOMMENDED = D do. > I see RECOMMENDED = N as the new default. > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ > > https://datatracker.ietf.org/doc/html/rfc9847 > > > > > Cheers, > > John Preuß Mattsson > > > > > > > > From: Tommy Jensen <[email protected]> > Date: Thursday, 2 July 2026 at 16:04 > To: Salz, Rich <[email protected]>; Bas Westerbaan <[email protected]> > Cc: The IESG <[email protected]>; draft-ietf-tls-mldsa > <[email protected]>; tls-chairs <[email protected]>; tls > <[email protected]> > Subject: [TLS] Re: Tommy Jensen's Discuss on draft-ietf-tls-mldsa-04: > (with DISCUSS and COMMENT) > > > > Thank you for the list reference. I agree with Eric that a comparison is > unnecessary. I'm not interested in seeing this document stack ranking itself > against other documents. What I am asking for is an explanation as to why it > is =N, which can be done without making any comparisons. > > > > For those following along on email, the rejected text was a simple reference > to Section 9.1 of draft-ietf-lamps-pq-composite-sigs, saying it "considers > when a PQ/T could be preferred": > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19#section-9.1 > > > > My concern unfortunately is not mitigated by the change being contentious. As > it stands, I cannot in good faith agree this document is ready for > publication when the only other RFC (9963) to define Recommended=N values in > this registry not published through ISE (and therefore lacks the "IETF > doesn't endorse this" language) went to great lengths to explain why it is > =N, but this document says absolutely nothing about it. That creates a very > obvious difference in the documents with =N entries, where all but one > explicitly tell the reader it isn't endorsed or it normatively must/should > not be used in the default case. > > > > This could be as simple as explaining exactly what you just stated: this > Informational standard was adopted by the WG because it saw value in > standardizing the mechanism, but did not have consensus to set Recommended=Y > because there was disagreement at publication time that pure PQ algorithms > have sufficient experience in deployment to be recommended. Note that there > is no need to then proceed to explain "because <pure PQ versus hybrid > debate>", though it circles back to the concern other ADs have about maybe > Experimental being a better fit for this. > > > > > > > > > > On Jul 2, 2026 at 05:54, Bas Westerbaan <[email protected]> wrote: > > > > > > Adding some words on composites has been proposed, and got pushback, eg. > > https://mailarchive.ietf.org/arch/msg/tls/7TDHk9yQQ_LvXFwMG7dJmsC9YEs/ > > > > > > On Thu, Jul 2, 2026 at 2:50 PM Salz, Rich <[email protected]> wrote: > > > > > > > > There is not WG consensus to recommend pure-PQ algorithms at this time. > > > I doubt further clarification is needed, and adding any words runs the > > > risk of restarting the flame wars that have enveloped the WG on this > > > issue. > > > > > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
