[Mod-discuss] Re: Éric Vyncke's Abstain on draft-ietf-modpod-group-processes-14: (with COMMENT)

John C Klensin <john-ietf@jck.com> Tue, 23 December 2025 00:29 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: mod-discuss@mail2.ietf.org
Delivered-To: mod-discuss@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 159229E16A38 for <mod-discuss@mail2.ietf.org>; Mon, 22 Dec 2025 16:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPMreLDQX9hZ for <mod-discuss@mail2.ietf.org>; Mon, 22 Dec 2025 16:29:28 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id 6F92A9E16A33 for <mod-discuss@ietf.org>; Mon, 22 Dec 2025 16:29:27 -0800 (PST)
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 1vXqGp-00076n-L2; Mon, 22 Dec 2025 19:28:59 -0500
Date: Mon, 22 Dec 2025 19:28:54 -0500
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Eliot Lear <lear@lear.ch>, Nico Williams <nico@cryptonector.com>
Message-ID: <3A4D1263121B3CAAC81973CD@PSB>
In-Reply-To: <46ab52c3-5ce8-4fc3-b0cc-9b887a315161@gmail.com>
References: <EEACF655F3055E9E9EF6FF9E@JcK-HP5> <aUjTeCxhKAylfj/J@ubby> <391C3403C77F32BB0C174303@JcK-HP5> <52c38265-9071-4274-ae0b-572caa4b900e@lear.ch> <39BD6E14463F762FA668D5EA@JcK-HP5> <46ab52c3-5ce8-4fc3-b0cc-9b887a315161@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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: BVFEABGP4HXMGXHJRKGEBGH5QAMO5ER3
X-Message-ID-Hash: BVFEABGP4HXMGXHJRKGEBGH5QAMO5ER3
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mod-discuss.ietf.org-0; header-match-mod-discuss.ietf.org-1; header-match-mod-discuss.ietf.org-2; header-match-mod-discuss.ietf.org-3; header-match-mod-discuss.ietf.org-4; header-match-mod-discuss.ietf.org-5; header-match-mod-discuss.ietf.org-6; header-match-mod-discuss.ietf.org-7; header-match-mod-discuss.ietf.org-8; header-match-mod-discuss.ietf.org-9; header-match-mod-discuss.ietf.org-10; header-match-mod-discuss.ietf.org-11; header-match-mod-discuss.ietf.org-12; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Pete Resnick <resnick@episteme.net>, mod-discuss@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Mod-discuss] Re: Éric Vyncke's Abstain on draft-ietf-modpod-group-processes-14: (with COMMENT)
List-Id: Discussion list for IETF moderation policies and practices <mod-discuss.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mod-discuss/eb6mR8zqr1vqYYNjVKJ2dImE5iY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mod-discuss>
List-Help: <mailto:mod-discuss-request@ietf.org?subject=help>
List-Owner: <mailto:mod-discuss-owner@ietf.org>
List-Post: <mailto:mod-discuss@ietf.org>
List-Subscribe: <mailto:mod-discuss-join@ietf.org>
List-Unsubscribe: <mailto:mod-discuss-leave@ietf.org>

--On Tuesday, December 23, 2025 08:36 +1300 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> Strawman:
> 
> The IESG shall regularly monitor the operation of the mechanisms
> defined in this memo and evaluate any feedback about the mechanisms
> from the community. In the event of judging that there is evidence
> of a serious defect in these mechanisms, the IESG shall take
> corrective steps, such as chartering a working group to review and
> update the mechanisms.
> Regards/Ngā mihi
>     Brian Carpenter

Brian,

The problem with that strawman proposal is that there are handful of
hypotheses and claims floating around that would turn it into a
"feel-good" exercise that would be useless in practice.  I see some
of them as plausible whether I'm completely convinced or not.  They
include the beliefs that the problems that set the current effort in
motion involved abuses of authority by some people in the leadership
and the concern that most, if not all, of the problems with BCP 83
lay in mismanagement or misinterpretation of it by the IESG.  They
also include acceptance of claims that the IESG --including but not
limited to the IETF Chair-- are overworked and stretched too thin
and, perhaps as a corollary, that one key reason the IESG set us on
this path was to relieve them of as much responsibility and workload
in area of control of bad behavior as possible.

If any of that were true and turned out to be important, and problems
actually occurred, it would be plausible for some future IESG to turn
the monitoring process into a pro-forma exercise, avoiding actually
digging into any issues until they had lots of spare time on their
hands.  One might even extrapolate from "we trust our WG chairs" to
"we trust the moderation team".   And we could all spend a lot of
bikeshed time discussing whether the IESG failing to monitor things
as aggressively as some participants might like or being dismissive
about feedback would constitute appealable events.

By contrast, something more similar to the appeals model would not
require the IESG to do anything unless a problem arose and was
identified by a sufficient number of community members.  It wouldn't
prohibit that either -- as I read it, the current document allows
them to intervene if they considered that appropriate and/or got an
appeal about a specific action/ decision by the Moderator Team and/or
an Administrator.  But, if a sufficient number of IETF participants
said "this has become a problem, please step in", the would be
obligated to do that.   And if, as many predict, there was never a
significant problem or, borrowing from Eliot's comment, it took 16 -
20 years for problems to become clear, it would save the IESG a huge
amount of time monitoring (and debating how often is "regularly").

   john


> 
> On 23-Dec-25 06:38, John C Klensin wrote:
>> 
>> 
>> --On Monday, 22 December, 2025 17:29 +0100 Eliot Lear
>> <lear@lear.ch> wrote:
>> 
>>> Hi John,
>>> 
>>> On 22.12.2025 10:59, John C Klensin wrote:
>>>> Or a mandatory review after some period of time that was
>>>> chosen now.  At least IMO, either would work although I'd
>>>> prefer a trigger mechanism in case things went bad before a
>>>> specified sunset interval.
>>> 
>>> I think this would have worked well for the RSWG, and if
>>> memory serves you suggested it then, and that suggestion
>>> didn't get adopted.  The problem here would be selecting the
>>> period of time for the review.  There are, essentially 2.5
>>> different types of cases one would want to review:
>>> 
>>>    * Disruptions where an admin would have acted, but for the
>>> new policy;
>>>    * Disruptions where admins did act
>>>        o small actions
>>>        o big actions
>>> 
>>> It took us, depending on how you count, 16 – 21 years to
>>> figure out BCP 83's limitations on big actions.  The process
>>> largely worked prior to then.  So what period of time would
>>> you set the review for?
>> 
>> And that, in a nutshell, is why I have a preference for some
>> sort of "detect serious problem and them review and fix" model
>> rather than something analogous to a sunset with a fixed period.
>> 
>> 
>> It occurs to me now that we might draw inspiration from the
>> recall procedure, i.e., specify that a petition or request to
>> the IESG from some reasonable (but not trivial) number of people
>> pointing out actual (rather than speculative) problems in need
>> of remediation might do it.  The IESG's would figure out the
>> details of how to respond to such a petition/request with a
>> general understanding that dismissing it out of hand would be
>> looked upon with disfavor by the community.  And their decision/
>> action would be subject to the usual appeal procedures.   Not
>> perfect, but probably reasonable and good enough.
>> 
>>     john
>> 
>> p.s. Our analyses / opinions about what went wrong with BCP 83
>> are somewhat different, but this is probably not the time or
>> place to debate that.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Mod-discuss mailing list -- mod-discuss@ietf.org
>> To unsubscribe send an email to mod-discuss-leave@ietf.org
> _______________________________________________
> Mod-discuss mailing list -- mod-discuss@ietf.org
> To unsubscribe send an email to mod-discuss-leave@ietf.org