Re: BCP97bis

John C Klensin <john-ietf@jck.com> Sun, 17 October 2021 22:45 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 027753A135B for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 15:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 35ILPSIRWOvn for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 15:45:27 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 22C223A1389 for <ietf@ietf.org>; Sun, 17 Oct 2021 15:45:25 -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 1mcEuA-000O6f-Qw; Sun, 17 Oct 2021 18:45:22 -0400
Date: Sun, 17 Oct 2021 18:45:17 -0400
From: John C Klensin <john-ietf@jck.com>
To: Russ Housley <housley@vigilsec.com>, Carsten Bormann <cabo@tzi.org>
cc: IETF <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <6803AC5BAEB3D637D13658B7@PSB>
In-Reply-To: <A117413E-065D-478E-A1CA-3421D5FB0D12@vigilsec.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.c om> <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com> <CAL0qLwbLqyWSqFGL2x-FpXXD19QG9-eZkrnTVm_fxt3tUfZSgg@mail.gmail.com> <C92D456E-63ED-453B-8F33-3AAECA40D1DA@vigilsec.com> <27721119-D39D-427D-8EEE-C5027DA15B06@akamai.com> <007c01d7c2dc$9090c780$b1b25680$@acm.org> <5385fd6f-b7a7-3baa-1374-f4d8d87216fd@joelhalpern.com> <6454.1634428177@localhost> <6702b78c-037f-f5fd-78a6-901a999dab54@gmail.com> <7E25FC36-0757-45EA-AB12-76F6818C797C@sobco.com> <B6BBF8C8788D1ECEACF549C0@PSB> <D290EE8C-6709-4A08-A827-41F7494D4E58@tzi.org> <A117413E-065D-478E-A1CA-3421D5FB0D12@vigilsec.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/MtGDW0sedqilo-y0k3_hz5afGkc>
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: Sun, 17 Oct 2021 22:45:35 -0000


--On Sunday, October 17, 2021 15:52 -0400 Russ Housley
<housley@vigilsec.com> wrote:

> 
> 
>> On Oct 17, 2021, at 8:54 AM, Carsten Bormann <cabo@tzi.org>
>> wrote:
>> 
>> On 2021-10-17, at 14:47, John C Klensin <john-ietf@jck.com>
>> wrote:
>>> 
>>> FWIW, I have no idea whether permission was obtained to
>>> extract and reproduce material from X3.4-1968 to act as the
>>> basis for RFC 20 or whether the conclusion at the time was
>>> that it was not necessary.  
>> 
>> (Random fuzzy recollection: I seem to remember that what made
>> me start campaigning for RFC 20 to be a STD was that I wanted
>> to stop people from referencing X3.4 just in order to avoid a
>> downref.)
>> 
>> We should do this more often.
> 
> Wouldn't it have been trivial to add RFC 20 to the downref
> registry?  Of course, there is no need to do it now that it is
> a standard.
> 
> 0020 ASCII format for network interchange. V.G. Cerf. October
> 1969.      (Format: TXT, PDF, HTML) (Also STD0080) (Status:
> INTERNET STANDARD)      (DOI: 10.17487/RFC0020) 

Carsten's memory is almost certainly better than mine, but I
think we may have moved it to full standard, probably given its
age from "UNKNOWN" long before the downref registry was an
established practice.  Also, from my perspective, we shouldn't
be making decisions like that on the basis of what might or
might not be trivial.   Or, from a different perspective,
reclassifying it to Internet Standard more accurately reflects
the status of ASCII on the Internet and should have been equally
trivial: I can't imagine anyone being about to make a serious
claim either that it has not been implemented, that it is not
widely deployed, or that there have been any issues with
interoperability (except with things that don't claim to be
ASCII).

I actually think that suggests something that should probably be
considered for BCP97bis: that the downref procedure and registry
should be used only when there are substantive reasons why the
relevant document cannot be upgraded or that doing so would
require an unreasonable amount of effort.  That would strengthen
the text that now appears in the last paragraphs of Murray's
Sections 4.2 and 5 but even the current text suggests to me that
"trivial" is not a good enough reason for the use of that
registry.

I also just noticed that the draft does not appear to describe
the contents and format of that registry, what entity is
responsible for keeping it, and where.  Especially if we take
the position that, once something is in that registry, no
special procedures (or different procedures) need be followed to
use the reference in another document, the registry should
record why downref permission was granted, in which the
document's categories the reference falls, and any additional
explanation that seems necessary -- that information should not
just be in the Last Call.  My instinct tells me that the RFC
Editor Function should be responsible for the registry itself,
but that might raise issues I have not thought of yet.

best,
   john


    john