Re: BCP97bis

John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 03: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 70BFD3A0DF9 for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 20:38:44 -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 bQT8RMmPUYSF for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 20:38:39 -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 886143A0DF1 for <ietf@ietf.org>; Sun, 17 Oct 2021 20:38:39 -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 1mcJTw-000ORk-A9; Sun, 17 Oct 2021 23:38:36 -0400
Date: Sun, 17 Oct 2021 23:38:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Murray S. Kucherawy" <superuser@gmail.com>
cc: ietf <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <D5C01AEA720DF1352E815B62@PSB>
In-Reply-To: <26583.1634525060@localhost>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.c om> <15645.1634416152@localhost> <CAL0qLwaBgTVFahe58GJZ6z3+sh-Ny8gKSEr9z747=DHgDvVzrQ@mail.gmail.com> <26583.1634525060@localhost>
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/LdwWpxw8e32_2tDK5iyDtTlpyCc>
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:38:45 -0000


--On Sunday, October 17, 2021 22:44 -0400 Michael Richardson
<mcr+ietf@sandelman.ca> wrote:

>...
>     > Really how you go about getting it is somewhat
> orthogonal to the point     > we're trying to address with
> this update, which is: If you're going to make     > a
> normative reference to something access to which is
> restricted, that has     > to be resolved somehow before it
> goes to the IESG; we (and any other     > reviewers, e.g., the
> review teams) need the referenced material to be able     > to
> do our jobs.
 
> If people who work on ITU-T,3GPP,IEEE,ANSI documents come to
> us with a document for us to publish, it seems like they ought
> to make all the background available to us.

I'm trying to get my head together around a specific and
constructive suggestion, but, in the interim, I think the above
misses something and that is that there are really two sets of
cases:

(1) Someone is involved in working on a spec in one of those
SDOs, or something like them, or maybe in an industry consortium
that doesn't do standards as we normally understand them.  They
then want the IETF to adopt a specification that depends on that
external one.  Certainly they should be able (and willing) to
make any needed background available to us.  They may or may not
be able to make the actual standard freely available (and/or
available for free); that may be tied up with other issues.

(2) There is a standard out there, typically a well-known and
well-established one, that we want to reference as part of our
own work.  We may have no involvement in its creation, but we
are smart enough to understand that trying to fork it with our
own competing spec would not be good for anyone.  Because, as
Carsten pointed out, it is the only spec from that era (long
pre-IETF among other things) that we are still using, let me
take RFC 20 as an example.  There are now, and were then, many
supplemental references that accurately describe what ASCII is
all about but there was really one authoritative one from which
everything else was derived and it was the ANSI/X3
specification.  I am quite confident that Vint was not one of
the people who participated actively in creating the ASCII spec,
so the "people who work on... come to us" bit does not apply.  

So, assuming that ANSI's rules about selling documents circa
1968 were still in effect today as was their occasional
inclination at the time to pursue copyright violation lawsuits,
but we were processing the document for the first time today,
what would you have had him do?  Make the requirement that he go
out and buy up enough copies to supply the IESG, the document
shepherd, and maybe everyone who claimed to be active in a
particular WG, and perhaps a few dozen more people?  Point to
one of the many freely available summaries of that document and
its tables rather than the authoritative source?  Sometime else?

Before you answer, remember that details of the definition of
ASCII (including its name) were changed between 1968 (and 1969)
and the present, that ANSI has traditionally been very reluctant
to make copies of superceded standards available (even for a
fee) and that the vast majority of the descriptions, excerpts,
and summaries of that standard are not too fussy about keeping
track of its status at any particular time before the present.

And while the ASCII Standard is a relatively short and
inexpensive document, consider RFC 2156 ("MIXER") as another
example.   I'd guess that the list of CCITT (ITU) and ISO
documents it references could easily have costs hundreds of US
dollars or equivalent for a set of copies for each of those
reviewers.  Should we have told those working on that what
became 2156 that the price for having it considered was to
promise to put up several tens of thousands of dollars as an
admission fee?   Or that, because ISO and ITU had not decided to
make all of their standards available for free, the RFC could
not be published?

I'm all in favor of putting whatever pressure we reasonably can
on other standards bodies to make their documents freely
available and free.  But we've best be very careful that we
don't shoot ourselves in the foot in the process.

   john