Re: Telechat reviews [Re: Tooling glitch in Last Call announcements and records]

John C Klensin <john-ietf@jck.com> Thu, 17 October 2024 17:15 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 EA050C14CF18; Thu, 17 Oct 2024 10:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMymzt-YtpD3; Thu, 17 Oct 2024 10:15:24 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 687F4C14F6AB; Thu, 17 Oct 2024 10:15:24 -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 1t1U5b-000Lwc-8T; Thu, 17 Oct 2024 13:15:07 -0400
Date: Thu, 17 Oct 2024 13:15:01 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Barry Leiba <barryleiba@computer.org>
Subject: Re: Telechat reviews [Re: Tooling glitch in Last Call announcements and records]
Message-ID: <D2A1416CDFDE441C3318859A@PSB>
In-Reply-To: <LV8PR11MB85361A9905FA2DF21577E56BB5462@LV8PR11MB8536.namprd11.prod.outlook.com>
References: <822159B0D390905C0A194997@PSB> <e8a0b44b-8ecf-4b24-94d4-9c79ddd26d41@amsl.com> <F3ACA29EAAC4DE9FE06EDA21@PSB> <CAL0qLwaKw8P7CGXXXHM5Hh6YvkMMqeN8OOgpv2v7Yrob5QsQ7A@mail.gmail.com> <CAC4RtVDqmcyjmbTZz3CU3zUXXtrQwfXZUS=PBhgtGK+NChhPtw@mail.gmail.com> <LV8PR11MB8536614B239A214C0E9D6981B5462@LV8PR11MB8536.namprd11.prod.outlook.com> <CALaySJK_ZZOgs+BjMMWA-vLO8n0ogy-WyDFCmOtGepjuohsGJQ@mail.gmail.com> <LV8PR11MB85361A9905FA2DF21577E56BB5462@LV8PR11MB8536.namprd11.prod.outlook.com>
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
Message-ID-Hash: ORWIWPCY23VBJF7HVQ2CWIXEPNNWWSN2
X-Message-ID-Hash: ORWIWPCY23VBJF7HVQ2CWIXEPNNWWSN2
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: iesg@ietf.org, ietf@ietf.org
X-Mailman-Version: 3.3.9rc6
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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DlxyYAbpdiqS8oSDCxwPgoUuh1U>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>


--On Wednesday, October 16, 2024 18:14 +0000 "Rob Wilton (rwilton)"
<rwilton@cisco.com> wrote:

> My suggestion is to automatically kick off the reviews as soon as
> it reaches WG "Submitted to IESG for Publication" state, rather
> than Last Call, which should be immediately after the shepherd
> review and writeup has been completed.  I.e., before the AD has
> done anything with the document.

Rob,

I think that might work, would be helpful, and would facilitate
having general IETF participant review after those Area ones and in
some cases, even a revised document.   And it would presumably be no
harder to automate than the current setup, just triggered by a
different state change.

_However_ as I more or less said earlier, if those are review
_requests_ rather than commitments of the start of work, it could
provide significant opportunities for delay.  If the AD waited to
initiate IETF Last Call until a significant fraction of those reviews
came in, the many concerns about how long it often takes between a WG
requesting publication of a document and that document getting into
the hands of the RFC Editor might be replaced by nostalgia for the
present system as things got much, much worse.

So I think any change, or even a decision to stick with the status
quo, probably should be accompanied by guidance to ADs and review
team leaders and participants about a window after "assignment"
during which someone could decline and a period after that in which,
if reviews don't come in, the relevant AD(s) are obligated to either
do the review themselves or vote "no objection".  There are probably
many reasonable variations on that theme but the current system has
sometimes turned, however unintentionally, into a DoS attack on
progress in WGs, their leadership, and authors/editors.  It would be
really unfortunate to make that worse.

   john