Hi. I don't think I have a problem with this but it does seem to raise multiple other issues including the one Brian Carpenter's identified (this note was started a few hours before his arrived). If we have already waited two years since use was "forbidden" and eight years since the relevant GOST specs were deprecated, would harm be done by delaying this until those issues can be sorted out (see below)? Hence a few questions, all mostly out of curiosity as well as a bit of concern that, if we are changing any precedents, we do so explicitly and not by side-effect and do not leave loose ends. (1) I can guess, but who is doing the "forbidding" and is that any more binding on potential users of international voluntary standards or binding national standards outside that country than a SDO requirement that something should be used? Should that be reflected in the tracker notice? (2) Did the revised GOST standards and/or the deprecation or "forbidding" actions provide technical explanations of why continuing use of the specifications is a bad idea? If so, should the documents containing that explanation be referenced in the tracker notice and/or the ISE and authors of the new document strongly encouraged (especially since IESG review seems to be in progress -- see below) to include explanations and/or references? Adrian, consider yourself encouraged :-( (3) If there is a document "being progressed in the Independent Submission Stream" (I assume, after a quick search, draft-deremin-rfc4491-bis-10, now in IESG review), is there some reason to not delay the action of this Last Call and corresponding explanation until that document is approved and assigned an RFC number (at least a pre-publication one) so that RFC or other document can be cited? Since the I-D has not yet been approved for publication, there is, at least in principle, a possibility that it will never be published. In that case, part of the explanation would become retroactively incorrect. ...Perhaps more important substantively and longer-term: (4) RFC 4491 is identified as updating RFC 3279. Given Brian's question and multiple controversies on other lists (most recently ART) that I would characterize as about the risk that moving documents to Historic may leave other specifications that they update or reference in confusing and/or silly states, has that been considered? I believe it is not the case here and that 4491 just added to the list of IETF-recognized algorithms that should be included in the 3279 list. However, if that is the case, should the explanation of this change explicitly identify that? The collection of updates that add some algorithms, deprecate or modify others, and move still others to Historic without explicit metadata links from 3279 (see, e.g., RFCs 6149 and 6151) and the similar collections for RFC 3121 (itself referenced from 3279) appear to be creating a hard-to-follow, spaghetti-threaded collection for 3279 that is strongly reminiscent of the motivation for the NEWTRK ISD proposal. Assuming the IESG is not inclined to reopen that issue and proposal, is it time to replace 3279 with a version that sorts the issues out and perhaps puts more reliance on a registry of applicable specifications and/or an Applicability Statement (see below)? Such an RFC3279bis could handle the assorted new, Obsolete and Historic specs in a way that would much more clearly define their status and role (including the "IETF Endorsement" issue discussed below). (5) When we publish references to, translations, or explanations of documents from other standards bodies in the RFC Series, I believe we have precedent for both publication as Standards Track, IETF Stream Informational, and Independent Stream Informational. Especially when there are interactions with Standards Track specifications, the decisions as to how to treat them are normally made after due consideration by the community. Such a decision was presumably made when RFC 4491 was put on the standards track and as updating 3279. The abstract of draft-deremin-rfc4491-bis-10, includes "This document does not imply IETF endorsement of the cryptographic algorithms used in this document". While 4491 is a Proposed Standard, implying precisely that endorsement of earlier versions of GOST R 34.10 and 34.11. If the combination of this action and that document is intended to actually deprecate recognition of these GOST specifications as part of the RFC 3279 package, that feels like a Big Deal on the IETF's part, not a simple move of an obviously obsolete specification to Historic. Such a Big Deal clearly (at least to me) needs documentation, especially if "we" have concluded that the GOST specs are not technologically appropriate and should not be recommended. Of source, RFC 2026 strongly implies that attaching "Not Recommended" to a specification requires an Applicability Statement. Those need IETF Last Call and RFC publication. Such an A/S would be a reasonable alternative to replacing 3279 and would perhaps be an even easier way to explain the status of the assorted documents that have attached themselves to it as "updates". Assuming the IESG does not just pause this document waiting for either 3279 or that A/S for it and related documents, would it not be more appropriate for the IESG to move 4491 from Standards Track to Informational (explaining the reasons for downgrading the lineage in the process) and then use draft-deremin-... to explain how the GOST specs are used for those who choose to use them despite not being part of the 3279 collection any more? Of course, if draft-deremin-rfc4491-bis were published in the IETF stream, those steps, including further updating 3729 if appropriate, could be handed cleanly with a single Last Call (or almost as cleanly by the ISE being given permission to obsolete an IETF stream Informational document and then asking for an advisory call on its approval). best, john --On Friday, January 7, 2022 09:08 -0800 The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from an individual participant > to make the following status changes: > > - RFC4491 from Proposed Standard to Historic > (Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R > 34.11-94 Algorithms with the Internet X.509 Public Key > Infrastructure Certificate and CRL Profile) > > The supporting document for this request can be found here: > > https://datatracker.ietf.org/doc/status-change-old-gost-pkix-t > o-historic/ > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the last-call@xxxxxxxx mailing lists > by 2022-02-04. Exceptionally, comments may be sent to > iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The affected document can be obtained via > https://datatracker.ietf.org/doc/rfc4491/ > > IESG discussion of this request can be tracked via > https://datatracker.ietf.org/doc/status-change-old-gost-pkix-t > o-historic/ballot/ > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
