> Yes, but neither labelling 4491 "Historic" (rather than both "Historic" and "Obsoleted By", nor updating RFC 3279, solves the problem of how an implementor of RFC 3279 is to find the current list of algorithms that are valid/deprecated/forbidden. They will be consulting Russian specifications, not IETF documents. > In some ways that is an orthogonal problem, but relying on all implementors to be attentive readers of the relevant IETF mailing lists is not a solution. It is *completely* an orthogonal problem. No version of GOST, Streebog, etc., is required by any IETF standard. 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
