Re: BCP97bis

John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 14:39 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 CCE9A3A1448 for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 07:39:58 -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 DSrRMGf1EKHB for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 07:39:54 -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 52A4A3A1447 for <ietf@ietf.org>; Mon, 18 Oct 2021 07:39:54 -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 1mcTnp-000PGJ-Md; Mon, 18 Oct 2021 10:39:49 -0400
Date: Mon, 18 Oct 2021 10:39:43 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Salz, Rich" <rsalz@akamai.com>, Larry Masinter <LMM@acm.org>, 'Russ Housley' <housley@vigilsec.com>, "'Murray S. Kucherawy'" <superuser@gmail.com>
cc: 'IETF' <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <F0A355493905AE563D3E6F89@PSB>
In-Reply-To: <C953ACA2-28C4-4DD4-B995-C16114FC95BC@akamai.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> <A7AD43FD-0117-44E7-9AB2-CDE3CB8682E1@akamai.com> <7FD4ED52C043B31F774E9381@PSB> <C953ACA2-28C4-4DD4-B995-C16114FC95BC@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/QwdJFxBd4pAb8VIro5nwNYh-AdE>
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 14:39:59 -0000


--On Monday, October 18, 2021 14:00 +0000 "Salz, Rich"
<rsalz@akamai.com> wrote:

>     > Or add text "retrieved on xxx xxx xxx" like Wikipedia
>     > often does.
> 
>     That makes it clear what is being referenced, which is
> good.     Absent other provisions/ requirements, it does
> nothing to     guarantee that the content will be there when
> someone goes     looking for it years (or decades) later.
> 
> The only thing certain in this world is uncertainty, as
> someone has said.  Putting a date-link in a URL is no
> guarantee either. And of course publications have been known
> to go out of print :)

And some out of print publications are in libraries, including
repository libraries, all over the world and some are not.

Hmm.  It occurs to me that a great deal of this discussion is
ultimately about the question of what constitutes a "stable
reference".  The criteria have traditionally been an RFC Editor
Function decision.  For the edge cases, there have (at least
usually) been discussions with the RFC Editor, not unilateral
actions by the IESG.  Part of the reason for that has been an
assumption that "stability" is actually an assessment requiring
some expertise, expertise the RFC Editor was expected to have
and the IESG might not.

I don't know whether the assumption that the RFC Editor Function
is the best place to make those decisions given the evolving
"future" plans.   However, if we assume that and hope for the
best, this I-D could kick much of this discussion down the road
by saying that all downward references (just like all other
normative references) are required to met RFC Editor criteria
for stability and availability.   That would not eliminate the
need to pin down whatever addition requirements we might have
for "free" or a special definition of "freely available", but
would, I think, get rid of other parts of this discussion...
including ones about books going out of print, SDOs collapsing,
and even documents changing in situ.   At worst, we could have
that discussion in one place rather than trying to settle it for
downrefs and then doing it again for other kinds of normative
references.

best,
    john