Re: BCP97bis and Informational-as-Standard
Michael Richardson <mcr+ietf@sandelman.ca> Sat, 16 October 2021 20:38 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7518F3A0CB7 for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 13:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNr4PUC7CBnI for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 13:38:38 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2292A3A0CB5 for <ietf@ietf.org>; Sat, 16 Oct 2021 13:38:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AF180181A3; Sat, 16 Oct 2021 16:39:02 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j7-4mYWNLTyB; Sat, 16 Oct 2021 16:39:02 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1124A1808D; Sat, 16 Oct 2021 16:39:02 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CB846236; Sat, 16 Oct 2021 16:38:35 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Russ Housley <housley@vigilsec.com>, "Murray S. Kucherawy" <superuser@gmail.com>, IETF <ietf@ietf.org>
Subject: Re: BCP97bis and Informational-as-Standard
In-Reply-To: <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com> <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 16 Oct 2021 16:38:35 -0400
Message-ID: <18086.1634416715@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/077oxz6E32IeotzOakRzyTe9R6Y>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Oct 2021 20:38:44 -0000
Russ Housley <housley@vigilsec.com> wrote: > I have on concern and a few editorial suggestions. > CONCERN > Section 4.1 says: } o A note is included in the reference text that indicates that the } reference is to a target document of a lower maturity level, that } some caution should be used since it may be less stable than the } document from which it is being referenced, and, optionally, } explaining why the downref is appropriate. > There are many cases where cryptographic algorithms are specified in > Informational RFC, and then a Standards-Track document is used to > specify protocol conventions for using that algorithm. the algorithm > specification is not unstable, and requiring a note like this sends the > wrong message to the reader. I think that this is really a process/RFC2026 process bug that maybe we could find a way to slightly amend RFC2026 about. (How many gendispatches ago was the 2026 revision discussion...?) I think that we document cryptographic algorithms as Informational because it is not the IETF's goal to take change control over the algorithm. It's not that we don't think of them as Standards-Track, it's that our standards track rules say that can't unless we have change control. The IETF RFC, because it's accessibility, often become the defacto industry reference. It is cited way beyond being cited in some other RFC. Why doesn't the industry (and the IETF?) cite the original NIST, etc. document? Well, historically, because the documents predate the WWW, we had RFC-by-FTP-email, and NIST didn't. My thoughts are: a) create some new category which is pseudo-authoritative standards track, which the IESG can annoit a document with. b) cite the original documents/papers/NIST-etc. publications more often. Perhaps CFRG has already struggled with this question before. At this point, what I see is that there is significant original work being brought to the CFRG *first*, that a CFRG RFC is becoming authoritative for some algorithms. (No, I don't have an example.) -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- BCP97bis Murray S. Kucherawy
- Re: BCP97bis Russ Housley
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis David Farmer
- Re: BCP97bis Brian Carpenter
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Russ Housley
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and Informational-as-Standard Michael Richardson
- RE: BCP97bis Larry Masinter
- Re: BCP97bis Joel M. Halpern
- Re: BCP97bis Michael Richardson
- Re: BCP97bis Brian E Carpenter
- RE: BCP97bis Larry Masinter
- Re: BCP97bis John Levine
- Re: BCP97bis Scott Bradner
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Brian E Carpenter
- Re: BCP97bis Russ Housley
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis John C Klensin
- Re: BCP97bis Michael Richardson
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis tom petch
- RE: BCP97bis mohamed.boucadair
- RE: BCP97bis ned+ietf
- Re: BCP97bis John C Klensin
- BCP97bis and "freely available" John C Klensin
- RE: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- RE: BCP97bis mohamed.boucadair
- Re: BCP97bis a process problem tom petch
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Lars Eggert
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Salz, Rich
- Re: BCP97bis and "freely available" Scott O. Bradner
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis John C Klensin
- Re: BCP97bis and "freely available" Michael Richardson
- Re: BCP97bis and "freely available" John C Klensin
- BCP written by another AD [was Re: BCP97bis] Brian E Carpenter
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and "freely available" Sandy Wills
- Re: BCP97bis and "freely available" Michael StJohns
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Randy Presuhn
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis and "freely available" Salz, Rich
- Re: BCP97bis a process problem Michael Richardson
- Re: BCP97bis and "freely available" Michael Richardson
- RE: BCP97bis ned+ietf
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis and "freely available" tom petch
- Re: BCP97bis a process problem tom petch
- Re: BCP written by another AD [was Re: BCP97bis] Erik Kline
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy