Re: [Eligibility-discuss] Handling the fear of "bogus" recall petitions

John C Klensin <john-ietf@jck.com> Mon, 28 October 2019 03:48 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: eligibility-discuss@ietfa.amsl.com
Delivered-To: eligibility-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C3D1200D8 for <eligibility-discuss@ietfa.amsl.com>; Sun, 27 Oct 2019 20:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 pEzcH1oG-ZkD for <eligibility-discuss@ietfa.amsl.com>; Sun, 27 Oct 2019 20:48:00 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C768120044 for <eligibility-discuss@ietf.org>; Sun, 27 Oct 2019 20:48:00 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1iOw0c-000ICw-5H; Sun, 27 Oct 2019 23:47:58 -0400
Date: Sun, 27 Oct 2019 23:47:53 -0400
From: John C Klensin <john-ietf@jck.com>
To: Pete Resnick <resnick@episteme.net>
cc: eligibility-discuss@ietf.org
Message-ID: <A6158553922F4866A5AB3667@JcK-HP5.jck.com>
In-Reply-To: <F5AD56FA-AE72-4A30-8876-617479C1BDF9@episteme.net>
References: <00c801d58a9a$53693c60$fa3bb520$@olddog.co.uk> <CB806045-0E5E-4445-A377-7CD547B9DD90@cisco.com> <010a01d58ac1$c0ab2320$42016960$@olddog.co.uk> <dc3bf13f-0178-8e4c-6680-ae3258ac1a9b@gmail.com> <865BF4B8-CB57-4586-8C2E-34B5218E53E2@episteme.net> <8D2605D0-33F0-4ED3-A063-A3F1469F3685@cisco.com> <B0B0A84A-D47D-475E-B37F-B6D9524A7D64@episteme.net> <CAL02cgQii6iuzh+sXd=S5T7ftOG+LeOcRKdtAkvhiTgVGFDT7w@mail.gmail.com> <F5AD56FA-AE72-4A30-8876-617479C1BDF9@episteme.net>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/izxWMd3K_q-IwN8yzpKVn1lnDxo>
Subject: Re: [Eligibility-discuss] Handling the fear of "bogus" recall petitions
X-BeenThere: eligibility-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <eligibility-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eligibility-discuss/>
List-Post: <mailto:eligibility-discuss@ietf.org>
List-Help: <mailto:eligibility-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 03:48:02 -0000


--On Friday, 25 October, 2019 10:26 -0500 Pete Resnick
<resnick@episteme.net> wrote:

> I took Adrian's proposal as the latter: SM's document assumes
> (maybe) that 3/5 remote registration is a close enough metric
> for skin in the game, and Eliot's concern was that you could
> end up with people with no actual skin in the game initiating
> the petition. Adrian proposed requiring someone under the
> current rule to be on the petition as a backstop for the new
> metric being misused. I think it's reasonable to ask the
> question: Does using such a backstop allay the concern, or is
> there something more to the issue and we really need a better
> metric? This is not about negotiating some compromise.

Pete,

Although I don't have a strong objection to Adrian's proposal,
nor to suggestions that someone not be considered a "remote
participant" (focusing on the "participant" part) unless they
actually sign into Meetecho for one or more sessions (I've even
suggested that a time or two), let me reinforce Any Malis's
observation.  If what we are worried about is DoS attacks, then
anyone wanting to organize one is going to have to start
planning and organizing bots or sock puppets more than a year in
advance.  If their intent is to attack a particular I* member,
that almost guarantees ineffectualness: they would spend a year
getting organized, and then initiate a process that would have
even someone seated at the beginning of that period in front of
the nomcom for renewal (or not) before they could be removed.
If their intent, instead, is to attack the IETF and its ability
to do work, well, there are much easier ways.

While I do not doubt the sincerity of those who are concerned
about DoS attacks and bogus petitions, analyses like the above
cause me to believe that the concerns are somewhat misplaced.

Several people have suggested that, if we cannot completely
reform the recall model, doing anything with the petition
process is a waste of time and energy.  Much as I would like to
see a complete process overhaul, I disagree with that view too.
The problem of remote participants -- even very active ones, not
being able to initiate recalls to seek to control an abusive or
out-of-control I* member is real, it makes the IETF look bad and
less hospitable to such people, to at least a first order
approximation, we know how to solve it.  A complete overhaul of
the recall process is a more complex matter and we don't have
good solutions to several of the issues including the
observation that, if the recall committee is going to work
largely f2f as the Nomcom does, a 3/5 f2f requirement does not
seem inconsistent with the requirements of the role.  That
doesn't mean we can't do better; if does suggest that insisting
on a complete solution as a condition for doing anything at all
is, whether that is the intention of not (and I assume that it
is not) a fairly good way to be sure that nothing happens at
all, at least in the relatively near future.

(and yes, Mike's suggestion of splitting the Nomcom function
itself into two parts is, to me, fascinating and deserving of
more consideration but it seems to me to be completely
orthogonal to the proposal on the table.)

best,
   john