Re: [admin-discuss] [rfc-i] Public archival of AUTH48 communications

Carsten Bormann <cabo@tzi.org> Sat, 26 February 2022 22:21 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: admin-discuss@ietfa.amsl.com
Delivered-To: admin-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0213A07E4; Sat, 26 Feb 2022 14:21:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 QEHB5mEQGxzf; Sat, 26 Feb 2022 14:21:22 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DEC3A07E6; Sat, 26 Feb 2022 14:21:21 -0800 (PST)
Received: from smtpclient.apple (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K5h1n3R0mzDCbW; Sat, 26 Feb 2022 23:21:17 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <EEF0F457622EDF74E090BC66@PSB>
Date: Sat, 26 Feb 2022 23:21:16 +0100
Cc: Working Group Chairs <wgchairs@ietf.org>, admin-discuss@ietf.org, "HANSEN, TONY L" <tony@att.com>, IETF <ietf@ietf.org>, RFC Interest <rfc-interest@rfc-editor.org>, IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA6590CD-1EBC-497D-9D12-6D789245466B@tzi.org>
References: <164574145917.13799.12710132950530774405@ietfa.amsl.com> <CA+9kkMC+vkyMPbt755Bu0cZHfmY-Pz6CdU1-J+8sBa8cPkA0dg@mail.gmail.c om> <CABcZeBMeRFOU+az=b8QJmD+-4GHivwZenMHEXsrbnamuoEmwEA@mail.gmail.com> <CA+9kkMAg_xbTODu=UE288uxTVhL=+r18p5ywC6ZGaUvpyXO8bA@mail.gmail.c om> <7C442BD6-F634-4129-9764-1BE29382D629@att.com> <8129A65C40CD88E0B5C94AA8@PSB> <7BC3F808-434B-48CF-B96B-0CF7D8B9F3A7@tzi.org> <EEF0F457622EDF74E090BC66@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/admin-discuss/v02q6VP10-A5AOEhXqGQtoWpNYg>
Subject: Re: [admin-discuss] [rfc-i] Public archival of AUTH48 communications
X-BeenThere: admin-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for IETF LLC administrative issues <admin-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/admin-discuss>, <mailto:admin-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/admin-discuss/>
List-Post: <mailto:admin-discuss@ietf.org>
List-Help: <mailto:admin-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/admin-discuss>, <mailto:admin-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Feb 2022 22:21:26 -0000

> 
> Or maybe we postpone spending energy on new lists and tooling --
> both of which tend to create inertia for keeping “experiments”

Wow.

I’ll shut up now, but not before pointing out the absurdity.

The original proposal by the IESG, as agreed to by the other streams, was a simple stopgap measure to obtain additional transparency in the AUTH48 process by an absolutely minimal amount of procedural and technical change.  Create a mailing list, start adding that to the RFC editor AUTH48 mails.  Can be implemented (business sense) in an afternoon, can be stopped in an afternoon if it breaks in unexpected ways.

Beautiful engineering, and something that doesn’t need to be flogged to death (also because it already is agreed).

Those of us that have been using the AUTH48 process for a couple decades now know that we need to improve the process on at least two major fronts:

1 — giving the authors and the other process participants better tools, in particular a way to continue to work on AUTH48 with the same tooling that was used in the WG and IESG segments of the document development (git and GitHub, domain-specific automation, authoring tools).
2 — giving the WG a better stance in the process, without derailing the process by encouraging relitigating WG dissent during the completion of an approved document (and without creating further process steps that impede the improvements usually provided by the RFC editing process from approved document to RFC).

Yes, we should work on these work items in the new structure we are now creating.
These will be multi-year processes, not the least because it will be hard to achieve continuous improvement in a structure that favors turning everything into grand endeavors.
Which is a great reason to make a small continuous improvement step now.

And, by the way, the stopgap would actually be very useful in generating real-world data that can inform 2.

Grüße, Carsten