--On Sunday, January 9, 2022 01:57 +0000 "Salz, Rich" <rsalz@xxxxxxxxxx> wrote: > In a separate message on this thread, John wrote > >> and going forward, etc. It would not be hard to write IANA >> Considerations or other text for such a document that would >> make it easy for any national or international standard to >> make it into the registry (we could decide whether English >> translation was a requirement) but to require some sort of >> IETf action to annotate the registry entry with a >> recommendation status) > The issue is not as simple as the above implies. National > standards (Russian GOST, Chinese SM2/3/4, Korean SEED or Aria, > etc) tend to be written in their own language. Requiring > English adds a burden, especially when it's translating > cryptographic work; while it makes sense for IETF documents, > who is going to do the work to get high-quality accurate > English translations, and for what purpose? The > "recommendation status" suggestion is another potential > minefield. The TLS WG spent a lot of time refining the > "recommended" column for ciphers (it now says YES or > NO-ANSWER), and is looking at revising it again, now. As one > of the three designated experts of those registries, I would > HATE for us to put anyone other than IETF Consensus in charge > of making that recommendation. Certainly IANA is not competent > to do so. Please read what I wrote. To repeat in different language: * Any national cryptograph standard should make it into the registry associated with RFC 3279, _without_ any inherent recommendation status. * I was talking only about 3279. Whether that should apply to TLS, or that TLS should use the same registry, is an entirely separate question. * The question of whether an English translation should be required (for registration, just for positive (or positive and negative) recommendations, or neither) would be a decision to be made by the IETF in specifying such a registry. (For reasons similar to the ones you give, I would personally recommend against it, certainly for anything but the "recommended" ones.) * The use of "RECOMMENDED" and "NOT RECOMMENDED" for an Applicability Statement comes straight out of RFC 2026, not anything associated with TLS or any recent set of specific specs. And because Applicability Statements are Standards Track documents, the _only_ way those assignments can be made is by IETF Consensus. In addition, given that documents have recently been published saying "stop using that, it is obsolete" for TLS, if the TLS registry does not have provision for something equivalent to "NOT RECOMMENDED" in addition to "YES" and "NO ANSWER", then I suggest the revision effort should be considering that if it is not already. So I think that probably we are in complete agreement. If we are not, one of us is seriously confused. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
