RE: BCP97bis

ned+ietf@mauve.mrochek.com Tue, 19 October 2021 14:01 UTC

Return-Path: <ned+ietf@mauve.mrochek.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 458143A003C for <ietf@ietfa.amsl.com>; Tue, 19 Oct 2021 07:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 jnANrkmQKOS4 for <ietf@ietfa.amsl.com>; Tue, 19 Oct 2021 07:01:41 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EDC3A0877 for <ietf@ietf.org>; Tue, 19 Oct 2021 07:01:40 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S55BOW0EQO00KSWW@mauve.mrochek.com> for ietf@ietf.org; Tue, 19 Oct 2021 06:56:11 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S55ACBN72O005PTU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Tue, 19 Oct 2021 06:56:06 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Cc: ned+ietf@mauve.mrochek.com, Larry Masinter <LMM@acm.org>, 'Michael Richardson' <mcr+ietf@sandelman.ca>, 'IETF' <ietf@ietf.org>
Message-id: <01S55BORVJO4005PTU@mauve.mrochek.com>
Date: Tue, 19 Oct 2021 06:33:31 -0700
Subject: RE: BCP97bis
In-reply-to: "Your message dated Mon, 18 Oct 2021 09:55:13 -0400" <9509675E82588103BD336B24@PSB>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.c> <om@mrochek.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> <00cf01d7c2f5$3a43fff0$aecbffd0$@acm.org> <01S53VFTRVD6005PTU@mauve.mrochek.com> <9509675E82588103BD336B24@PSB>
To: John C Klensin <john-ietf@jck.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/myXW0Y4QRyYYkCE25Q2hCADykd4>
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: Tue, 19 Oct 2021 14:01:47 -0000

> --On Monday, October 18, 2021 05:49 -0700
> ned+ietf@mauve.mrochek.com wrote:

> >...
> > Speaking as a media type reviewer, I require free access to
> > the relevant standards before I'll review a media type in the
> > standards tree. This has led various special arrangements to
> > access specifications that would otherwise cost $$$.

> Presumably, if someone lent you a copy for the duration of your
> review process, that would suffice.  Correct?

Yes, that's correct.

I should also add that having the specifications available is essential to
doing proper review, even when all we're looking at is a media type. There was
a registration recently that seemed like it made sense, but without the
specifications I couldn't tell what the security considerations were. But after
getting some of the relevant standards - which wasn't easy - it became clear
that the registration actually made no sense at all: They were attempting to
register what amounted to an entire protocol stack as a media type.

> We had some discussions a long time about about the RFC Editor
> requiring copies of everything outside the RFC Series that was
> normatively referenced and then maintaining their own
> repository.  For better or worse, the idea never went anywhere
> but it would have made all of these documents freely available
> and reading them free if only one could get to Marina del Rey or
> somewhere on the USC campus.  Easier for you than for me, I
> suppose :-).

> > Note that this doesn't mean that free access is required for
> > everyone. The requirements for media types in the standards
> > tree are that there be a  stable, publicly available
> > specification. Free availability is not part of it.

> Right.  And there is a huge difference between one copy,
> available without cost to a media type reviewer, perhaps for a
> limited time and, e.g., requiring that copies be distributed to,
> or otherwise available for free to, the entire IESG, the
> document shepherd, the relevant WG, and potentially anyone who
> might want to do a Last Call review.

> We need to be very careful about how we define and scope
> requirements in this area.

I wasn't advocating using the media types approach for other IETF review
processes, but now that the idea has been broached, I don't see why this
wouldn't work in cases where it's a small group doing the review.

Extending it to, say, last call reviews is another matter. Some of
the other standards bodies I've dealt with likely wouldn't have a problem
with making the specification publicly available for a limited time -
and recognizing that the genie can't really be put back in the bottle - but
others most certainly would.

And this isn't always about the money, at least not in the way you'd think. In
some cases we're dealing with a draft specification for something in a highly
competitive area. Early release of such documents could potentially lead to
serious interoperability problems in the event someone jumps the gun
on implementation and late changes need to be made.

> >...
> > While I'm not aware of it happening, it's theoretically
> > possible for a standards organization to fail and take all of
> > its specifications with it, just like any other organization.
> >...

> Yes, but if the work of that standards organization was widely
> enough used that we should have taken them seriously in the
> first place, there would presumably be copies of the relevant
> documents in libraries and other repositories all over the
> world.  Having the SDO fail would be very bad for any
> expectations about maintenance of those documents and probably
> for their credibility but would have little impact on
> availability of archival copies.

Seriousness is more or less what the IESG is looking for.

				Ned