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