Re: BCP97bis

John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 02:42 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 6A9393A0CA5 for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 19:42:10 -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 y-aL1mteU6fm for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 19:42:05 -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 4B0A93A0CA2 for <ietf@ietf.org>; Sun, 17 Oct 2021 19:42: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 1mcIbB-000ONk-8g; Sun, 17 Oct 2021 22:42:01 -0400
Date: Sun, 17 Oct 2021 22:41:55 -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: <64733AD195E66632EA57F9E2@PSB>
In-Reply-To: <CAL0qLwYY7mRwPz=bYnKN66tNmj4agaf5eEOd8-yMh3phEGmyGA@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> <CAL0qLwYY7mRwPz=bYnKN66tNmj4agaf5eEOd8-yMh3phEGmyGA@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/RtGVNPrGPDOHvIrlroavXlNquIE>
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 02:42:11 -0000


--On Sunday, October 17, 2021 18:53 -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.
>> 
>> 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.
>> 
> 
> Describing the registry's current structure and maintenance is
> easy enough.  I'll add that.

Thanks.

> It would probably be a nightmare to add that retroactively for
> the entries already present, but the publication of this
> revision to BCP 97 could stipulate that, going forward, the
> reason for downref permission needs to be recorded and made
> visible for future entries, and who the responsible AD was.

Works for me.  I think it is far more important that we avoid
creating additional messes in that future than that we clean up
ones that have been there for years.

> What did you mean by "in which document's categories the
> reference falls"?

In essence, the descriptions in your sections 4.2, 5, and 6
create categories of downrefs. I'd be inclined to divide 6 into
two subcategories, one for what we have called "recognized
standards bodies" in other contexts and one for other types of
external references.  Either way, I think that categorization
could be very helpful going forward and I was suggesting that it
should be included in the registry.

best,
   john