> “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.

The GOST cipher, which is Russia's AES equivalent, is also in an RFC:

* https://datatracker.ietf.org/doc/html/rfc9189

* https://en.wikipedia.org/wiki/GOST_(block_cipher)

Is the IETF validating its use?

The GOST document is categorized in the same way as the one currently being debated/discussed: Informational. It also has "N" under the "Recommended" column (like ML-KEM-only will have):

* https://www.iana.org/assignments/tls-parameters/tls-paramete...

▲

ekr____ 20 hours ago | parent [-]

In fairness, I do think that this situation is somewhat different. As I noted above (https://news.ycombinator.com/item?id=48812792), there are two main routes to an Informational RFC of this kind.

* Through the IETF

* Through the Independent Stream

The GOST documents went through the Independent Stream and therefore do not have IETF imprimateur. These documents are proposed for the IETF Stream and therefore require IETF Consensus to publish.

I know this is all super confusing. The basic problem is that the vast majority of RFCs come out of the IETF and so people often act as if all RFCs do. This is of course in part why people pursue Independent Stream publication rather than just publishing things on their own..

▲

throw0101d 18 hours ago | parent [-]

I have gotten flack for giving ULA+NPTv6 as a possible solution to an IPv6 multi-homing issue because the RFC that describes it was 'only' "Experimental":

* https://datatracker.ietf.org/doc/html/rfc6296

When I pointed out that the NAT(44) RFC (1631/3022) was 'only' "Informational" I got radio silence:

* https://datatracker.ietf.org/doc/html/rfc1631

▲

ekr____ 17 hours ago | parent [-]

I have no opinion on ULA+NPTv6, other than Experimental doesn't mean you shouldn't use it. How else would people experiment. It does mean that the level of vetting by the IETF is potentially lower.

WRT IPv4 NAT, I'm not sure how much we can infer from the status. Many people at IETF were (and some still are) very anti-NAT, in part because they felt that IPv6 was the right solution. As a result, the IETF really avoided doing anything that looked like it was endorsing NAT, even though it's obviously just a fact of the Internet.

	▲	throw0101d 10 hours ago \| parent [-]
		My general point is that the category or track of an RFC may mean different things to different people (assuming they're even aware of them at all).