Re: BCP97bis

John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 03:03 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 AE9CC3A0D74 for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 20:03:29 -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 5-NtB5JgNNnu for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 20:03:23 -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 EDD4E3A0D77 for <ietf@ietf.org>; Sun, 17 Oct 2021 20:03:20 -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 1mcIvl-000OPP-N7; Sun, 17 Oct 2021 23:03:17 -0400
Date: Sun, 17 Oct 2021 23:03:11 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
cc: Russ Housley <housley@vigilsec.com>, Carsten Bormann <cabo@tzi.org>, IETF <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <83AD1335BACA41ECF5901300@PSB>
In-Reply-To: <CAL0qLwbtJ=ueVbnJaSsp7m9okXJayLDmvKngDq4dfAKnCFPz0g@mail.gmail.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <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> <6803AC5BAEB3D637D13658B7@PSB> <CAL0qLwbtJ=ueVbnJaSsp7m9okXJayLDmvKngDq4dfAKnCFPz0g@mail.gmail.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/TjXQrzI8CYy7vD5keeqppbd8zBQ>
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 03:03:30 -0000


--On Sunday, October 17, 2021 19:04 -0700 "Murray S. Kucherawy"
<superuser@gmail.com> wrote:

> On Sun, Oct 17, 2021 at 3:45 PM John C Klensin
> <john-ietf@jck.com> wrote:
> 
>> 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.

Good... and consistent with what I had understood and expect.

> I'm fine with strengthening this language if the community
> thinks it's necessary, but I thought I'd mention that there's
> a document on an upcoming telechat with a DISCUSS on it
> specifically because there's a normative downref to something
> that deserves consideration for advancement, so at least the
> current IESG is observing the preference BCP 97 already states.

My concern is not with the current IESG.  If they did not agree
with the principles you are describing, I assume that the I-D
would go nowhere.  But, if the text is not crystal clear, I
think it is reasonable to be concerned about someone or
something coming up in the future and insisting on a downref as
a shortcut.  If (or more likely when) that happens, it would be
good for that future IESG to have as much reinforcement as
possible for saying "no, we are going to Do The Right Thing".

And, fwiw, what started my thinking in that direction was
precisely Russ's "trivial" comment.  It would have been trivial,
but it would be the wrong thing to do.  At least IMO, reinforced
by your text and the current BCP 97 text.

   john