Re: [Eligibility-discuss] Questions about I* bodies removing their own membership

Michael StJohns <msj@nthpermutation.com> Tue, 29 October 2019 20:03 UTC

Return-Path: <msj@nthpermutation.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 EB202120137 for <eligibility-discuss@ietfa.amsl.com>; Tue, 29 Oct 2019 13:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 SrRA9PvUkfHh for <eligibility-discuss@ietfa.amsl.com>; Tue, 29 Oct 2019 13:03:11 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 5E6F21200A3 for <eligibility-discuss@ietf.org>; Tue, 29 Oct 2019 13:03:11 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id y39so16774226qty.0 for <eligibility-discuss@ietf.org>; Tue, 29 Oct 2019 13:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=6cfI1h5pZ1nsdTs5aXH5ubiSEV9Y7zs8A5V5JKF/960=; b=cXgFZVvd9m02wnadCIhMcCQ8Pf6m5V2FAYIx/camUJxGxMxx2nqDYiaYO30LZWAmk1 o6Wi05T2wGgJHzPYQjzpatQd0Jessmh4jH1tiYNyEXk/TV9sAwP3b6ZEf25/Xe2/NdY/ 1nQjQXwYl+V6Vm6j1M1KNntg6+OnNX3ifVkCFqrIiNdv7LX4qlQsrAPUqTuBkpnrAvXD j1Z+8Lw7P+Bh6NU+2FynzkNC5kq4v+frsuBgbucS/EJLT6qrJTbsxQ2rOi8fEJ+iKpOn AnSTlrrJ0n6mP8BPQSHXoHFJXqyaSQiRDnz25xUeXyffXiEIqsAIb5SClPG0dh1VLHIt b3yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6cfI1h5pZ1nsdTs5aXH5ubiSEV9Y7zs8A5V5JKF/960=; b=ncHqOJdSBBDFZ9XUfrqpbPt4oAuJ8YJRUgV6b5LYzZhzOe3k07YmUGTmGpftLvFhAr RovUFAgVoDONa+VbIdzomiTMLccNsR+Ytt4dHd5PkivrBpjy8tnI0wQG54LDmC/fAjji UFw/X4IV7VeO+VCXCkY8ENacurnl2D7Exf1jV6AxYHg0V1+ejyXd7qfmRJyuNi6byHi7 HrV/tjvLrSg64BkkqMV//ZrxGeZ6dBMCZg4SesjSY7kGbWiBMjVuarKLpdwCTbxdQvCh JrqDSHYSaT6//fUmBG26t2YnekqrKzhDFMDC9x3JRFPD/OpxwG4ZzRMRcZ7y2dE1KpXA IMog==
X-Gm-Message-State: APjAAAXxjnP+owUVdJcZlP3Gv6Rp4fK3v1XGiReGGVBIX2I1XGJEk0aR /Bf/QqaIsaeYzL9FIGD0e/o8cDa6LeI=
X-Google-Smtp-Source: APXvYqzyALHAXQe72eB/CBV0GXJhpKvtE8lKh7Ov5ThEZIpHdwAurrkoHLxZt+8UN4gzt0E5/AuK2Q==
X-Received: by 2002:ac8:2a38:: with SMTP id k53mr953384qtk.387.1572379389831; Tue, 29 Oct 2019 13:03:09 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:437c:8542:998c:670d:7fca? ([2601:152:4400:437c:8542:998c:670d:7fca]) by smtp.gmail.com with ESMTPSA id j10sm8510658qtb.34.2019.10.29.13.03.09 for <eligibility-discuss@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Oct 2019 13:03:09 -0700 (PDT)
To: eligibility-discuss@ietf.org
References: <99234A93-2224-47F1-AA65-C71DC5DA3CD3@episteme.net> <69DFC9FF020C06F8353314B2@PSB> <BD6598AF5EC96F4BD8BCBAC8@PSB>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <3c1c80dd-a4d4-62b0-c67b-cd02a234dcc0@nthpermutation.com>
Date: Tue, 29 Oct 2019 16:03:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <BD6598AF5EC96F4BD8BCBAC8@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/sYIo0V6CI6yQdSVDOk1E9iBtKuo>
Subject: Re: [Eligibility-discuss] Questions about I* bodies removing their own membership
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: Tue, 29 Oct 2019 20:03:14 -0000

Hi John - sorry for the top post - but my original idea for the 
expulsion process was mainly to provide a few different light-weight 
ways of dealing with the problem where a member goes AWOL.  I.e. the 
only actual semi-worked case for the recall process.

Taxonomy wise the mostly complete ways a member may leave their position 
for a given body (and I'm being more general than the IETF here) are:

1) Upon term expiration  (covered in the current Nomcom documents)
2) Upon resignation (covered in the current documents)
3) Upon recall - a community action (covered - albeit poorly - in the 
current documents)
4) Upon death (not covered explicitly, but covered implicitly as a 
objectively identifiable vacancy)
5) Upon disability (not covered - think US 25th amendment)
6) Upon abandonment (not covered - we have no agreed upon way of 
measuring this)
7) Upon expulsion  - a body initiated action (not covered - EKRs draft).

Ideally, if we're going to open up recall to revision, I'd like to see 
about adding 4-7 above.

More inline.

On 10/29/2019 2:41 PM, John C Klensin wrote:
> Hi.  I've been thinking about the idea of the I* bodies being
> able to remove one of their own members and how to combine that
> with adequate safeguards.  Let me make a specific suggestion to
> see if it gets enough traction for me to draft some text that
> could be dropped into the "equity" I-D.
>
> Suppose we followed the example already set by the ombudsteam
> and allowed those bodies, perhaps even by a simply majority
> vote, to initiate a recall process, bypassing the petition
> process.  The rest of the recall process would run normally
> (modulo any changes we might make in the future).

I had to think hard about this approach.  Basically, this is mixture of 
both the recall process and the expulsion process and I'm not sure it 
would work.  Here's the problem I see.  Expulsions tend to be for 
egregious failures where the relationship between the member and the 
body is pretty much irretrievably poisoned. Imagine if you will that you 
follow this process, but the recall failed.  I don't know how you put 
everyone back to a point where they can continue to work together.

While your approach does prevent the I* body from being somewhat 
self-selecting, I think the side effects of the result where the I* body 
says "we can't work with this person any more" and where the community 
says "suck it up" may not be the best result for the community.

>
> Would that be sufficient and mitigate at least most of the
> concerns?
>
> I'm a little fascinated by the possibility of applying Mike's
> suggestion to this, requiring each I* member voting "yes" to
> initiate the recall process to put down a significant deposit
> that would be refunded if the recall committee did not agree
> that the person should be removed.

"did agree" not "did not agree" I think you mean?

> Or, perhaps even more
> effectively, requiring each I* member who was going to vote
> "yes" to sign a letter of resignation, creating a vacancy
> immediately and taking effect as soon as a replacement could be
> seated if the recall committee did not remove the person in
> question.   "You want to fire an I* member, you put your
> position on the line if the recall committee disagrees" has a
> certain charm.  But I'm not yet persuaded that either would be a
> good idea.

Me either.  The deposit idea was more to deal with DOS with possibly 
unknown people rather than a "me or them" type thing.

The "recall or resign" model has two interesting side effects: 1) It 
forces the recall committee to balance the subjective and possibly 
widely differing judgements of the I* body and the recall committee as 
to "egregious behavior" against the possibility of decapitating the 
organization.  2) and the actual possibility of decapitating the 
organization.  If we went through with this model though, I'd suggest a 
slight modification just to keep us from shooting ourselves in both 
feet: one person shall be randomly selected from the set of I* members 
voting for recall and removed if the recall fails.  I think I'd also 
prohibit the chair of any given body from signing on to a petition.

In the draft I wrote a long while back that originally suggested 
expulsion, I had included some form of confirming body for that 
expulsion decision.  When I commented on EKRs draft, I think I provided 
text dealing with the appeal of the expulsion as a possibility.  Now 
that I've considered it further, I would remove the text for the same 
reason I stated above related to the body-originated recall model you 
suggested: once the well is so poisoned as to cause a majority or 2/3s 
to vote for expulsion or recall of a member, forcing them to continue to 
work together seems like a very bad idea.

It may be that any expulsion or body-initiated recall approach is just 
inherently flawed, given how the IETF is constituted, and shouldn't be used.

Mike

>
> best,
>     john
>