Re: AD Sponsorship of draft-moonesamy-recall-rev

Michael StJohns <mstjohns@comcast.net> Tue, 23 April 2019 03:33 UTC

Return-Path: <mstjohns@comcast.net>
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 6CE0F120136 for <ietf@ietfa.amsl.com>; Mon, 22 Apr 2019 20:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 QXdSwOc5Tyiv for <ietf@ietfa.amsl.com>; Mon, 22 Apr 2019 20:33:01 -0700 (PDT)
Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B5F120075 for <ietf@ietf.org>; Mon, 22 Apr 2019 20:33:00 -0700 (PDT)
Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-07v.sys.comcast.net with ESMTP id IlyghQe2Be39RImB2hl6XV; Tue, 23 Apr 2019 03:33:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1555990380; bh=psDa/QhXcdcmnbnlFtG+hu1qjBXXx6QEp3D3GfYHGmg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=DJKyWT4x0tE1KhQbMdM9D75XuZMxoEh8ra+D+u3foLYJQep/MMThmCjanxZ1Wp0r+ Km4cZWaQky93xH1ZQOQPnEN9opjk8mnLFajnKAeSPDS0C1MBRZM0Y/gsZtGoJ1Hvuf Xc7oAEA0URIIvKGwH9WmUNe7oAiR2AwJTJpChhzHgIWgJH4Yvix6UlKLY+o3vP49PV P+yU8lIJi/r387GqaHwy4Q+fUkd1d8nPtoVNDwUpkNuWBmgWHFpwyWVZC2LKTkcUIi BIdCsl8GkuRYt/vWRC5I7JjrzJDWC02aX8b1odfSQ1sRlYDwmjyr8kasbjq/aQRHpz rJnNPXqeMpx9w==
Received: from [IPv6:2601:152:4400:437c:ac6d:adcb:e959:c9f0] ([IPv6:2601:152:4400:437c:ac6d:adcb:e959:c9f0]) by resomta-po-16v.sys.comcast.net with ESMTPSA id ImB0h7Lhf12HVImB1hwKaM; Tue, 23 Apr 2019 03:32:59 +0000
X-Xfinity-VMeta: sc=-100;st=legit
Subject: Re: AD Sponsorship of draft-moonesamy-recall-rev
To: Eric Rescorla <ekr@rtfm.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: IETF list <ietf@ietf.org>
References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <033d01d4f52f$c6f2dca0$54d895e0$@olddog.co.uk> <C7274EAB-7DDC-491F-9DD2-0CFFADB13CA9@cooperw.in> <72f00d0b-7ec6-ba6a-b17b-97879d457ae3@comcast.net> <CAKKJt-fOMMdM-mkbJaYpsH6XPCpatUkwZY-d_A+MaNa3nhaNDg@mail.gmail.com> <CABcZeBNdaWU4wwOK_MnWC5hOr7Lu3osmC_6_KKxB5fHuHVHyTw@mail.gmail.com>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <23d54797-5c94-aa00-ec55-3f2c4fdfcfae@comcast.net>
Date: Mon, 22 Apr 2019 23:32:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBNdaWU4wwOK_MnWC5hOr7Lu3osmC_6_KKxB5fHuHVHyTw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5333252CE1F58C1D128A437A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/40Ws0req-wNgMCCdVZVAXaK1_mg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Apr 2019 03:33:04 -0000

On 4/22/2019 10:19 PM, Eric Rescorla wrote:
>
>
> On Fri, Apr 19, 2019 at 8:33 AM Spencer Dawkins at IETF 
> <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>> 
> wrote:
>
>     I'm actually enjoying this more than I should be ...
>
>     <deleted several levels of response>
>

>     The report that design team produced is at
>     https://www.ietf.org/archive/id/draft-dawkins-nomcom-3777-issues-00.txt.
>     It resulted in most of the updates to RFC 3777 before they were
>     all obsoleted by https://datatracker.ietf.org/doc/rfc7437/.
>
>
> Thanks for pointing us to this document. Useful to avoid reinventing
> the issues list.
>
> In that vein, I think it would be useful to get crisp about the
> problem statement. It seems to me that this document implicitly makes
> two arguments:
>
> - It's too difficult to initiate a recall (because the threshold
>   is too high and because members of the leadership who might have
>   special knowledge are excluded) [S 2.1, 2.3]
>
> - It's unfair to exclude remote participants [S 2.2]
>
> I'm not sure how persuaded I am by the second argument, but I think
> the overall thrust of the first argument has some merit. However,
> I tend to agree with Alissa that the main obstacle isn't so much
> the number of people or excluding leadership, but rather the
> reputational risk to people of signing the petition, especially
> if the recall fails [0].
>
> So, if the idea is to make recalls easier, then it seems to me
> that the easiest thing to do would be to make the signatures
> on the petition anonymous; the Secretariat can still verify them,
> of course, and the recall proceedings themselves would still
> be conducted in our usual fashion.
>
> -Ekr
>
>
> [0] "If you come at the king, you best not miss".
> [1] It's also possible to build a system that allows third party
>     verification that the right number of sigantures were provided
>     while not identifying the signers, but the amount of crypto
>     required seems somewhat prohibitive.
>
>
The more I listen to this thread, the more I'm thinking that the whole 
concept of recall as described in the appropriate documents makes little 
sense for the IETF/IAB as currently constituted.  It certainly makes no 
sense for any of the other entities for which the Nomcom proposes 
candidates (e.g. the LLC and Trust) for which the appropriate remedies 
implicate various laws or contractual issues.

The ONLY time we've ever come close to running a recall, it was for the 
IAOC and it was to deal with the fact that we hadn't created procedures 
to deal with abandonment of a position or disability of a member 
especially where we had (with one person AWOL from a normal set of 5 
members) a potential quorum problem.

When the problem occurred, it took only about a day to get 20 members to 
sign the petition once it was decided to handle it via recall.  The 
member in question ended up resigning quickly enough that the recall 
committee was not formed. (I think I've got this timing correct...)   It 
would have taken something like 6 weeks or so to get the recall 
committee up and running and then more time to actually complete the 
recall, then another 4-6 weeks to fill the spot - call it 2-3 months to 
fix a problem.

Instead, I'd like to propose that we move to an expulsion model for the 
IAB and IESG where the members of the organizations are able to remove a 
member under certain circumstances:  Behavior inconsistent with a 
fiduciary (e.g. acting for your company or contracting entity to the 
detriment of the standards process); behavior that adversely affects the 
standardization process (IESG) or behavior that adversely affects the 
general operation of the IAB (e.g. things like harassment); abandonment 
of the position or lack of communication from the member.

2/3 of the permanent members can vote to remove.   For the IETF chair, a 
majority of both the IESG and IAB (e.g. two groups each with majority 
approvals) are needed.

This would at least be a lot faster to resolve if there is a great 
enough issue.

If we still want to talk about recalls, let's talk about *why* we might 
want to recall someone?  Is there a current or potential (within the 
next year or so) reasonable scenario that we need to address?  Once we 
figure out what the possible offenses are, we can figure out if recall 
is the remedy or if we need to think about something else.  I'm still 
puzzled as to why we need to make recalls easier to accomplish and 
whether there is an actual issue with not allowing remote participants 
to trigger a petition.

Later, Mike