Re: [admin-discuss] Next steps towards a net zero IETF

Lars Eggert <lars@eggert.org> Wed, 05 April 2023 06:19 UTC

Return-Path: <lars@eggert.org>
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 6E5FFC151536; Tue, 4 Apr 2023 23:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDsGk1uQRODK; Tue, 4 Apr 2023 23:19:39 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C21C151535; Tue, 4 Apr 2023 23:19:38 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:89cd:4d4c:ee0e:1782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 0F9CE20808; Wed, 5 Apr 2023 09:19:12 +0300 (EEST)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Lars Eggert <lars@eggert.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [admin-discuss] Next steps towards a net zero IETF
Date: Wed, 05 Apr 2023 09:19:12 +0300
Message-Id: <29D4E3D7-EF76-44E3-BE4C-9026E788379D@eggert.org>
References: <7CB821C8D8A5EF575EDA43EE@PSB>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, admin-discuss@ietf.org, ietf@ietf.org
In-Reply-To: <7CB821C8D8A5EF575EDA43EE@PSB>
To: John C Klensin <john-ietf@jck.com>
X-MailScanner-ID: 0F9CE20808.A782B
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/iGhcq3xlCUcNu6myXj6cBjbDXec>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <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: Wed, 05 Apr 2023 06:19:39 -0000

Hi,

On 4. Apr 2023, at 21:34, John C Klensin <john-ietf@jck.com> wrote:
> So that takes us back to variations on the
> suggestion Eliot made earlier and a question to the IESG: I
> understand "wanting" more session time but do you have a clear
> sense --ideally one on which you can report to the community --
> about rationale and need?  When those sessions occur, are they
> about presentations, status reports on what the WG is doing, or
> discussions of open issues?  Of the latter, what fraction of
> them are issues that have been thoroughly discussed on mailing
> lists but remain unresolved rather than, e.g., ones that have
> been deferred to or saved for f2f discussions.  And, for those
> WG's who have asked for and gotten more than a one-hour slot,
> what is the evidence that the additional time was actually
> marginally productive in issue-resolving or problem-solving?

We've always trusted the WG chairs to make that determination, and use the different available participation venues (mailing list, in-person and remote interims, in-person meetings, etc.) in ways that is most effective for their WG for their current work items. While some chairs are certainly better than others in doing this, I believe this decentralized approach has a lot of value and is generally working OK.

Involving the ADs in this process might seem attractive in terms of oversight and/or to establish a common approach - but it also further increases the AD workload (c.f. the current discussion on the that). There are severe downsides to that.

Thanks,
Lars