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
- [Eligibility-discuss] New draft: draft-rescorla-i… Eric Rescorla
- Re: [Eligibility-discuss] New draft: draft-rescor… Joel M. Halpern
- Re: [Eligibility-discuss] New draft: draft-rescor… Eric Rescorla
- Re: [Eligibility-discuss] New draft: draft-rescor… Eliot Lear
- Re: [Eligibility-discuss] New draft: draft-rescor… John C Klensin
- Re: [Eligibility-discuss] New draft: draft-rescor… Michael StJohns
- Re: [Eligibility-discuss] New draft: draft-rescor… John C Klensin
- Re: [Eligibility-discuss] New draft: draft-rescor… Brian E Carpenter
- Re: [Eligibility-discuss] New draft: draft-rescor… Brian E Carpenter
- Re: [Eligibility-discuss] New draft: draft-rescor… Eric Rescorla