Re: [Eligibility-discuss] New draft: draft-rescorla-istar-recall-00
John C Klensin <john-ietf@jck.com> Fri, 17 May 2019 08:15 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 24904120344 for <eligibility-discuss@ietfa.amsl.com>; Fri, 17 May 2019 01:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 X3rBeIE0cX69 for <eligibility-discuss@ietfa.amsl.com>; Fri, 17 May 2019 01:15:22 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 CC2731202CC for <eligibility-discuss@ietf.org>; Fri, 17 May 2019 01:15:21 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hRY1P-0007po-LI; Fri, 17 May 2019 04:15:19 -0400
Date: Fri, 17 May 2019 04:15:13 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael StJohns <msj@nthpermutation.com>
cc: eligibility-discuss@ietf.org
Message-ID: <8D3BBA27427075D16A750E60@PSB>
In-Reply-To: <d8b5a2e4-aad7-fe1d-6bc7-a4238ec2cd82@nthpermutation.com>
References: <0C4BD2C959F7FC53CAEAC85F@PSB> <d8b5a2e4-aad7-fe1d-6bc7-a4238ec2cd82@nthpermutation.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@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/7w40wTFAn13v0x0q8QQnuG26bhc>
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: Fri, 17 May 2019 08:15:24 -0000
Michael, Thanks. Comments inline... --On Thursday, May 16, 2019 17:31 -0400 Michael StJohns <msj@nthpermutation.com> wrote: > Since I suggested some of this text... comments in line. > > On 5/16/2019 3:50 PM, John C Klensin wrote: >... >> * why should the IETF Chair be exempt? > > Because AFAICT the IETF chair, while a member of the IESG, is > not there solely as the chair of the IESG but as the chair of > the IETF process. E.g. the chair is not simply first among > equals (cf the IAB chair), but has a role outside the > constraints of the IESG. Having the IESG be able to remove the > chair seems to me to be the wrong approach. IMO, the > appropriate remedy for the IETF chair misbehaving is recall or > simply not renewing them. If you want an expulsion > possibility for the IETF chair, then you probably need to have > both the IAB and IESG vote and agree by body and have the > appeal go to the ISOC board. My alternate perspective is that the mechanism you and ekr are proposing (for which I have a lot of sympathy) is needed primarily because the recall model is either completely useless except for the threat of public embarrassment or so hopelessly slow as to be useless except in cases of the most gross abuse of authority and maybe even then. Were that not the case, the notion of the IAB or IESG removing one of their own membership would not be needed because we could rely on the community-based recall mechanism supplemented by letting IESG or IAB members initiate recalls. That could be done by taking advantage of the additional flexibility in draft-moonesamy-recall-rev (through -02 at least) or by creating a variation of the model of RFC 7776 so that, e.g., the IAB or IESG could vote to initiate a recall of one of their own members without the petition process. Because the actual decisions would be made in the recall process, that move might not even require a supermajority. However, if we agree that the recall process isn't useful, then immunizing the IETF Chair would appear to be an invitation to monarchy. I'm unconvinced, given the seriousness of this procedure and the situations that would motivate it, that the IETF Chair position really requires different treatment that other ADs. I'd hope we could count on the other IESG members to treat an action against the IETF Chair with special seriousness but, if the conclusion was that the IAB needed to vote too, I'd be ok with that. Actually, I'd be happy if removal of any IESG member required a supermajority of the IESG and a majority of the IAB and vice versa, which (given adequate transparency) would eliminate the need for an appeals process and the delays it might imply. >> * 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? > > At various times over the years I've suggested fairly specific > rules and constraints on various topics, but the push back was > "no need to legislate the corners, we can work in the broad > strokes" and I've mostly come to accept that approach. > That said, my earlier email had the following as language > which may be a reasonable set of broad guidelines: > >> 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. > > To put it another way - if you're going to expel a member you > ought to make damn sure that the community is going to at > least be accepting of the rationale. I certainly agree with that principle, but note that it is inconsistent with keeping the action (and presumably the votes) as secret as possible and the reason for it completely secret, which is the intent as I understood it from reading the I-D. The I-D's model seems to be closer to expecting the community to accept whatever is done because we trust that the the other members of the relevant body wouldn't be doing this unless it was necessary. >> * 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. > Fair point - coming from someone who might have been subject > to this during my last term on the IAB. That's at least > somewhat why the appeal path is there. I don't actually > recall the discussion in Poised, but its been 25 years since > then. Possibly time to readdress this. My memory of Poised (and even Poisson, which I think I chaired for a while) is quite vague but it is clear from the results that the community didn't think it was desirable enough to allow bodies to kick their own members out (or for the IAB and IESG to kick each other's members out) to make provision for that. >> * 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. > Not going any deeper here - but really suggested this as a way > of keeping some of the nastier forms of politics from creeping > in and having another 1000 or so emails show up on the IETF > mailing. There is transparency in the process - after the > conclusion - and that should be sufficient. But the latter is what I didn't see. I see confidential deliberations, confidential votes, confidential numbers of votes and confidential information about who voted which way, confidentiality of any appeal, and confidentiality about whether an action was attempted if it failed. As I read the document, it is not even clear that an announcement that X was expelled, only that the position was then vacant and open for nominations. I suppose the IETF community could figure out that the person involved had not died in office but the action would otherwise be indistinguishable from a voluntary resignation unless the removed member chose to make an announcement to that effect: it is not clear that even that is permitted although, unless IESG and IAB members are required to sign NDAs upon assuming the positions, it would be hard for the IETF to enforce silence at that point. I don't even see permission to disclose that the action occurred, who initiated it, and how people voted to the next Nomcom -- information to which I think we would certainly want them to have access, especially if avoidance of the potential to re-litigate the previous nomcom is a goal as the Introduction suggests. So, if there is post-conclusion transparency, where do you see it in the above? I don't even think it would prevent the nasty politics and thousand email messages from showing up. If I were a member of either body, saw an expulsion effort mounted against me (especially with the implication of "major misconduct" because I had not disappeared), and wanted to fight it, I'd probably go public with my version of the story (again, no NDAs -- what is the body going to do, expel me?). Because the members of the body would be prohibited from commenting by the specification (unless they wanted to invite public shaming or recall by violating the rule), the result would probably be a free-ranging collection of claims and counter-claims by members of the community with a lot of assumptions, little information, and no way to refute the assumptions. Probably not a good idea. The _only_ case in which I imagine would work well would be if someone had essentially disappeared ("total member checkout"), been asked to resign using mechanisms which the body was fairly sure had reached them, didn't respond to such a request, and needed to be pushed out involuntarily before their absence caused more damage. Of course we've seen a situation that could be described that way --once-- but it wasn't with an IAB or IESG member. Let's not put energy into fighting the last war. Or, if we think possible a recurrence of that situation, but involving an IESG or IAB member, is a major concern, let's design a procedure around it and limit the discretion of a potential cabal to initiate an action against someone they see as a dissenter, possibly an effective one (especially to do it secretly). I also think it is easy for the appeal model outlined in the I-D and its extremely short timeouts to be maliciously gamed, but let's save that for another day. > For your suggestion below - probably not. Think about how > much you know about the current internal workings and > relationships of either the IESG or the IAB and whether you'd > expect to get useful comments from the community rather than > simple beauty contest "I like him/her - don't expel" or > "he/she was rude to me after I asked 10000 questions - of > course you must expel" type comments. Indeed. I just don't see the procedure you suggest preventing that. Under some circumstances, I'd even expect the affected member to go to the ombudsteam and complain that a cabal within the relevant body was conspiring against them, saying nasty and untrue things in secret, perhaps to force them to take particular positions or to stop dissenting from others, and generally engaging in bullying-type behavior. Unless you define an exception by which other members of that body could explain their point of view to the ombudsteam, that creates a first-class mess. And remember the ombudsteam can initiate recalls and might have to do so as the only way to get such a (claimed) situation under control. > The other reason to keep the process secret is the same reason > we keep the obudsman stuff secret - this is reputation and > legally fraught. The mere suggestion of an attempt to expel > - can have adverse affects on the expellee, the person or > persons suggesting the expulsion, the process, etc. Of course. But, if the entire process is required to be kept secret before, during and after the fact, and especially if the member is successfully expelled but doesn't silently creep off into the darkness or lie by claiming they resigned, we'd almost certainly have the same problems, only driven by speculation since no one involved other than the ex-member would be able to say anything. And, if you really want to contemplate a nightmare situation, suppose the member(s) who were expelled put their names forward as candidates for the vacancy (something, IIR, the recall procedure permits), even if only to protect their reputations from the speculation about what happened. And suppose the Nomcom --possibly the same Nomcom that selected them initially-- made "we thought they were the right selection the first time and still do" decisions? And yes, it is legally fraught. It would get at least as much so if the member saw the expulsion attempt (successful or not but especially if it succeeded) as an effort to damage their reputation, concluded that rumors about the action were likely to be as or more damaging than the truth, and approached the legal system with claims of conspiracy to deprive them of a livelihood and/or (probably "and") libel. IANAL, but I'd assume that one of the first things that would be attempted would be to bring down the confidentiality requirements and, if records of, e.g., voting had not been kept, to claim that was further evidence of conspiracy. On the "whole has the deep pockets" theory, I'd also assume that an attempt would be made to drag in the employers of anyone who had advocated the action within the body and we've get to see how long the "participating only as individuals" model would hold up. I have no opinion about whether such an attempt would succeed, but I wonder how long (or if) the IETF's insurance would cover it. I suspect learning the answers to the questions of what would and would not hold up would be really painful for the IETF. The more I think about it, the more I think that, especially if secrecy is required, this procedure, as specified in the I-D, is just a bad 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