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

S Moonesamy <sm+ietf@elandsys.com> Thu, 10 October 2024 21:23 UTC

Return-Path: <sm@elandsys.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 49304C15152E for <ietf@ietfa.amsl.com>; Thu, 10 Oct 2024 14:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.705
X-Spam-Level:
X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
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 sQgWePoc1lG8 for <ietf@ietfa.amsl.com>; Thu, 10 Oct 2024 14:23:45 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D1DC14F747 for <ietf@ietf.org>; Thu, 10 Oct 2024 14:23:45 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.117.82.0]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 49ALNLm7017114 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2024 14:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elandsys.com; s=mail; t=1728595414; x=1728681814; i=@elandsys.com; bh=GE9UCNWDy+CH6k3DYSIRBP+ZeUTDPFsLm/IvTGDuI+c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0fALR8ljiidO5QMvNuC/h/bzEmU8s70RfibPmJfBFY8upHueaeu17lUcFFTh4EmVD zNGQC0olHt4BhUzfIGZepY+R+yNbvzkW3q0qGGtPppmiar9HumQiKadVXw6cyx8n9i SwZL/Wpw6KLA/Vs4SsYpD2LoFRkynaljoGfqytF4=
Message-Id: <6.2.5.6.2.20241010130129.1206ab78@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 10 Oct 2024 14:17:03 -0700
To: John C Klensin <john-ietf@jck.com>, ietf@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: Telechat reviews [Re: Tooling glitch in Last Call announcements and records]
In-Reply-To: <bdb100c0-ebf1-4bdc-b02d-1d78be442487@gmail.com>
References: <F7B93DDC2E7F9D09E14CA72C@PSB> <14f24c98-f7da-477c-8ea6-892ee5ad4413@nostrum.com> <CE0F9F2237EE32F4806538EC@PSB> <bdb100c0-ebf1-4bdc-b02d-1d78be442487@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID-Hash: DKAFQPPMDHTFDMUHTPQEJT27DF7QHIFE
X-Message-ID-Hash: DKAFQPPMDHTFDMUHTPQEJT27DF7QHIFE
X-MailFrom: sm@elandsys.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
X-Mailman-Version: 3.3.9rc5
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/7ptJuwzVZlxbtK-mAqx4Fxy5WOE>
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>

Hi John,

Thanks to Brian for moving the thread and changing the subject line.

At 12:53 PM 10-10-2024, Brian E Carpenter wrote:
>[moved from tools-discuss]
>
>On 11-Oct-24 08:06, John C Klensin wrote:
>
>On Thursday, October 10, 2024 13:23 -0500 Robert Sparks
>><rjsparks@nostrum.com> wrote:
>
><snip>
>
>>
>>>The practices of directorates continuing to change assignments or
>>>provide comments after last call is something I'll leave to the
>>>IESG to steer. Note, however, that almost all of the directorates
>>>also provide telechat reviews, not just last-call reviews.
>>(That brings us to an issue that I thought to mention in my earlier
>>note, decided against it, and may regret mentioning now.  If this is
>>worth pursuing, it should probably be on the IETF list, not here.
>>At least in principle, there is a difference between (i) Last Call as
>>a community discussion mechanism whose effect is to inform the IESG
>>about community consensus and (ii) Last Call as a mechanism to feed
>>information, opinions, and other advice into the IESG so the ADs can
>>determine what they think is the right decision for the Internet.  If
>>those directorate/area reviews are given privileged status -- input
>>into the telechats that ordinary IETF participants don't get, more
>>flexibility about deadlines, etc. -- then the "treat this like any
>>other review" boilerplate of most of those reviews becomes a joke or
>>worse.  It would be somewhat different if those really were
>>directorate or area reviews -- reviews that were written (or
>>finalized) only after specific discussion about the document within
>>that area or directorate and that represented consensus in that
>>group.  But they often are not -- they are more often the opinions of
>>an individual who comes up in rotation or draws a short straw.  If
>>the latter is the case, the community should probably be insisting
>>that reviews that claim to be (or are treated as) representative of a
>>group rather than that of the author as an individual be posted
>>several days before a Last Call ends so that other IETF participants
>>can comment on whatever is said.
>>So telling me/us that directorates provide telechat reviews in
>>addition to or instead of Last Call reviews is a source of concern,
>>not comfort.

I was a bit confused by the mention of "telechat reviews".  I guess 
that it means having a review ready before the IESG evaluation.  The 
practice I was familiar with was for the review to be public and for 
it to be sent to the relevant area mailing list.  The subscribers to 
that mailing list had the ability to complain if there had any 
concerns.  Those reviews were for the Area Directors instead of the 
entire IESG.  The practice was for the authors to have adequate time 
to address the review.  There is some administrative work to get all 
that lined up.  A review can only represent the views of the person 
writing it.  Anything else might cause administrative complications.

Last Call reviews were different from those reviews.  For example, I 
would say "no issue" for a draft from IPv6 if it is not be relevant 
to what is usually discussed within the Area.

I got to appreciate the effort of each of the reviewers who 
volunteered to do the reviews.  The results of their work was 100% 
coverage of the drafts that gets to IESG evaluation.

Regards,
S. Moonesamy