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
- BCP97bis Murray S. Kucherawy
- Re: BCP97bis Russ Housley
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis David Farmer
- Re: BCP97bis Brian Carpenter
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Russ Housley
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and Informational-as-Standard Michael Richardson
- RE: BCP97bis Larry Masinter
- Re: BCP97bis Joel M. Halpern
- Re: BCP97bis Michael Richardson
- Re: BCP97bis Brian E Carpenter
- RE: BCP97bis Larry Masinter
- Re: BCP97bis John Levine
- Re: BCP97bis Scott Bradner
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Brian E Carpenter
- Re: BCP97bis Russ Housley
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis John C Klensin
- Re: BCP97bis Michael Richardson
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis tom petch
- RE: BCP97bis mohamed.boucadair
- RE: BCP97bis ned+ietf
- Re: BCP97bis John C Klensin
- BCP97bis and "freely available" John C Klensin
- RE: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- RE: BCP97bis mohamed.boucadair
- Re: BCP97bis a process problem tom petch
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Lars Eggert
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Salz, Rich
- Re: BCP97bis and "freely available" Scott O. Bradner
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis John C Klensin
- Re: BCP97bis and "freely available" Michael Richardson
- Re: BCP97bis and "freely available" John C Klensin
- BCP written by another AD [was Re: BCP97bis] Brian E Carpenter
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and "freely available" Sandy Wills
- Re: BCP97bis and "freely available" Michael StJohns
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Randy Presuhn
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis and "freely available" Salz, Rich
- Re: BCP97bis a process problem Michael Richardson
- Re: BCP97bis and "freely available" Michael Richardson
- RE: BCP97bis ned+ietf
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis and "freely available" tom petch
- Re: BCP97bis a process problem tom petch
- Re: BCP written by another AD [was Re: BCP97bis] Erik Kline
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy