Re: BCP97bis
John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 15:38 UTC
Return-Path: <john-ietf@jck.com>
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 D789F3A09F0; Mon, 18 Oct 2021 08:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 CR6towQxkIDE; Mon, 18 Oct 2021 08:38:05 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FF33A08F8; Mon, 18 Oct 2021 08:38:04 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1mcUiB-000PNS-21; Mon, 18 Oct 2021 11:38:03 -0400
Date: Mon, 18 Oct 2021 11:37:56 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>
cc: Carsten Bormann <cabo@tzi.org>, ietf <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <83AE1023E61C0D81DA726D6B@PSB>
In-Reply-To: <890A4965-D847-4606-849C-A0C8D8FD3B0C@akamai.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.c om> <CAL0qLwa4ChOsuMkmoP_sAGv3Wn2AcSz1OkijmxZzP+MGvnwviA@mail.gmail.com> <849D7F9E-8AD4-4CE8-A66C-358FB1F2E6AE@tzi.org> <3AC61568-DBDC-4ADB-9935-9C53333AE7E2@akamai.com> <CAL0qLwZvCq7R=WBFsrwf51CKSN8ur0Yj-F=VOHnP=hQD0ooj-A@mail.gmail.com> <890A4965-D847-4606-849C-A0C8D8FD3B0C@akamai.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/5PSF-7dn5YidfgcO6J--ytL2PRo>
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: Mon, 18 Oct 2021 15:38:10 -0000
--On Monday, October 18, 2021 14:36 +0000 "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org> wrote: > * The IESG has had multiple cases during my time there > where we haven't had access to some normative reference, and > so we can't do our job. This has added long delays to > document processing. That's what we're trying to address here. > > I believe it is far more common for the IESG to review and > progress documents without having all normative references > tracked down and read. Murray, I think Rich is right. Maybe it should be different, but when I have written, been shepherd for, or otherwise been heavily involved with documents that make normative references outside the RFC Series in recent years, I think it has been unusual if even one IESG member other than the responsible AD studied all of the references documents carefully. Another distinction may be worth making. There are two kinds of normative reference to documents outside the RFC Series. We encountered an important example earlier this year although I did not figure out how to formulate the distinction until now. In one case, the referencing document actually contains everything one needs to know to implement whatever is being specified. RFC 20 is a perfect example of that: it contains copies of the relevant tables and the definitions that were considered relevant. X3.4-1968 is a normative reference (even though we did not make the distinction at that time), but the reference is needed only to identify the authority for what the RFC says. If one needed to actually read and understand X3.4-1968, it would only be to verify that its relevant contents are accurately portrayed. Depending on definitions that, AFAIK, have never been spelled out explicitly enough that one could use them to split hairs, one could even argue that reference is Informative and not Normative. At the other extreme, we've seen documents that essentially say "to do X, go look at [BigDoc] and do what it says" where [BigDoc] is, e.g., something more than 1000 pages long and hard for non-specialists to read, much less fully understand references to specific sections (so even "[BigDoc] Section 999" would not be of tremendous help). Clearly a Normative reference, but anyone claiming to have reviewed the proposed RFC who has not studied [BigDoc] and understood the specification there and its implications... well, really has not done so. The solution to the latter type of situation is not to be sure free copies of [BigDoc] are available to anyone who might (or should) be interested in the hope they will read them, but for the IESG to push things more in the direction of RFC 20 and good summaries about exactly what the actual requirements are in practice. There are many much more recent examples that have done just that. And, if we could separate this issue from the contents of the I-D, this document and the discussions of it would get easier. Unfortunately, the requirement for that separation is that the IESG become clear about the distinction and push back aggressively on shortcuts like the "just look over there" one implied by the second case. best, john
- 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