Re: [Eligibility-discuss] New draft: draft-rescorla-istar-recall-00

John C Klensin <klensin@jck.com> Thu, 16 May 2019 19:50 UTC

Return-Path: <klensin@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 6A7601200FA for <eligibility-discuss@ietfa.amsl.com>; Thu, 16 May 2019 12:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham 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 IjKNlF0Kz_bs for <eligibility-discuss@ietfa.amsl.com>; Thu, 16 May 2019 12:50:44 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0E0120288 for <eligibility-discuss@ietf.org>; Thu, 16 May 2019 12:50:32 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1hRMOa-0006e4-7u; Thu, 16 May 2019 15:50:28 -0400
Date: Thu, 16 May 2019 15:50:23 -0400
From: John C Klensin <klensin@jck.com>
To: Eric Rescorla <ekr@rtfm.com>, eligibility-discuss@ietf.org
Message-ID: <0C4BD2C959F7FC53CAEAC85F@PSB>
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
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: klensin@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/uF8WRWhWwsXp-whGOX-6gt24j1w>
Subject: Re: [Eligibility-discuss] New draft: draft-rescorla-istar-recall-00
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: Thu, 16 May 2019 19:50:48 -0000


--On Thursday, May 16, 2019 06:16 -0700 Eric Rescorla
<ekr@rtfm.com> wrote:

> Hi folks,
> 
> I've just posted a fleshed out version of the proposal that MSJ
> made a while back of allowing a body to recall its members.
> Here's the rationale:
> 
> This document proposes an alternate structure which is designed
> to deal with just egregious cases (e.g., total member checkout,
> major misconduct) but is also faster because it doesn't involve
> spinning up the nomcom machinery (twice, once to recall and
> once to replace). In this structure, the IAB/IESG would vote to
> expel the offending member with consent from the other body.
> The rationale here is that the body themselves is in the best
> position to know when a member really needs to be removed.

EKR,

With your exchange with Joel in mind, but with the understanding
that my comments are mostly orthogonal, I've got some concerns
about this.  In no particular order:

* why should the IETF Chair be exempt?  Occupants of that
position have more power to abuse than other ADs or IAB members,
there is no reason I can think of that would make them less
likely to fall victim to any of the issues that would cause
someone to completely drop out, selection of someone to that
position doesn't require a higher degree of consensus on the
Nomcom for selection, we still don't have Kings, etc.  If the
visibility and importance of that position (or others) makes the
other IESG or IAB members less inclined to try to remove them,
so be it, but that isn't a reason for an exemption from this
procedure.

* If removal is supposed to occur only for specific reasons or
under specific criteria (not just reading the document, but
anticipating where your exchange with Joel might go), how is the
community to reassure itself that those principles are being
complied with and/or to enforce those provisions?  Given the
many times when the IESG and IAB have acted in concert with
shared opinions (unsurprising given that their members are
selected by the same group) rather than asking as checks on each
other with mild tensions between them, hoping that the
confirming body will provide a sufficient check is not really a
satisfying answer, especially given that...

* There is a criterion that is not on the list in the document
(and should not be).  There has often been a role on the IESG
and IAB in which one person takes on the responsibility for
raising uncomfortable or difficult issues rather than letting
things slide through.  Often that role rotates, with different
people taking it on at different times but sometimes someone
stands out in the role, someone who is then eligible to be
considered, by other members of the body, as a major pain in the
(ahem) neck.  I'm familiar with the role because I've been in
it; my impression is that you have too.  Unless there are other
issues, e.g., if the behavior spills over into being clearly
obstructionist for its own right, removing a person in that role
is not in the best interest of the community (especially if the
Nomcom knew what it was getting into with the choice) even (or
especially) if he or she has managed to thoroughly annoy all of
the rest of the IAB and IESG.  My vague recollection is that the
potential for this being an issues was a key part of the reason
the IESG and IAB were not given the authority to remove their
own (or the other body's) members during the discussions on
POISED and its successors.

* For some of the points above, our usual remedy is openness and
transparency -- requiring that things be done in sufficient view
of the community to discourage abuse and to give the community
access to remedies if abuses occur.    The secrecy (before,
during, and after the removal process) suggested by the I-D
seems completely inconsistent with that model and our usual
practices.  If there are sufficient problems within the IESG or
IAB to justify kicking someone off, their effects are probably
visible to the community and trying to hide the effects (or
causes) from the community would appear to me to be contrary to
the IETF's interest.  Even if a privacy case can be made for not
exposing the fact that such an action, or the reasons for it,
are being considered, if someone is actually ejected, certainly
the fact of having done that would be fairly obvious (if nothing
else, the IESG or IAB would need to go back to the Nomcom to
fill the new vacancy).    Consider the following as one possible
example of a plausible compromise :

(i) The relevant body takes a preliminary vote, in private,
about removing one of their number.   If the vote succeeds (by
whatever percentage is chosen; I'd think it should probably be
near-unanimous except for the victim), an announcement is made
to the community about the intention to remove the individual
with an explanation about the reasons and the community given a
short time (a couple of weeks?) to comment.  If the vote fails,
the idea of removing that individual using this method quietly
disappears and cannot be re-initiated for some reasonable period
(months? a year or so? the rest of the term?).

(ii) Once the period for community comment is over, the body
votes again.  If the vote is successful, the person is removed,
the justification (presumably but not necessarily identical to
the explanation given the first time), the name of the person
who initiated the removal effort, and the list of members and
their votes is made public and posted.   At their discretion,
those members could also post explanations.   If the second vote
fails, the removal process stops and goes away and again cannot
be reinitiated for some reasonable period.

In that model, if a person is removed and the community believes
the action was inappropriate, the situation would provide very
strong grounds for recall, using long-standing mechanisms, of
the members of the body who pushed the action.

That would probably provide reasonable protection against abuse,
particularly the removal of someone whose crime was being far
outside whatever constituted the mainstream in the relevant body
and who was insistent on having that perspective considered.

You may, of course, have better ideas, but I think some
considerable transparency and checks on abuse need to be present
for this to be a good idea.

best,
   john