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

Michael StJohns <msj@nthpermutation.com> Thu, 16 May 2019 21:31 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 D4235120315 for <eligibility-discuss@ietfa.amsl.com>; Thu, 16 May 2019 14:31:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 fVXkDiUpDYe0 for <eligibility-discuss@ietfa.amsl.com>; Thu, 16 May 2019 14:31:09 -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 5B4FA120318 for <eligibility-discuss@ietf.org>; Thu, 16 May 2019 14:31:09 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id i26so5700236qtr.10 for <eligibility-discuss@ietf.org>; Thu, 16 May 2019 14:31:09 -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=XDCmVCrZhIwNcOiQd0QtsfFluT5CzNFZ7dvlXPM11Y0=; b=pkMztC3ZfQhV34UDV/ZXNTGPdNCrxS6HwaY471rEuPHfGtZZ3DiZcGjHmmTWw5tJPn dZTQIjIS4faE4k/bUQTjt/KZz8QFAsrrasXSuAWTiQxWflncEvvbIQXOHBTFgEogCNS1 hRve2cqxMG7bV3+tStxchqoDyp2yJSMi3Sb0nonv1a50FCisbpz8S5pOYwzSGu7c07u/ aaFHJ4CwIdzPOctSoevgrqrWFw151jSzs5HCgcyQXjUswa8/vgTStCCJuCGofQfPth8O s0sUj/XNKRFXeo8eY3ifjIrnw3iO8rpOwFke4xY+veYJ4jj72t5HRyEO+8C6GbyR/csv 89DA==
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=XDCmVCrZhIwNcOiQd0QtsfFluT5CzNFZ7dvlXPM11Y0=; b=iH8IiQobXVJXw+pDIAMg8WoZ4MCEnvHanAs+omBiRAFlx75B8kkQv7sWF+GEijQnP9 o9Yip6LsZUMFHOEAeicHZ8CSfb5SbLs2JOxJcfrPyQ4dvxLvPzEV831ZSL2NcWZAbe9O sIzii4MYhldldDcbfgoywDccY0dYTXfCSk1dCtS40HcMYJcwdW1N6ETz71ef42fu4Y5a jCR0Vi9nIDTF9rXEZWf1sRhS4b6qXdukgWEPi2kqkz4kHL+TKs4oms48NRzXv4Zt7KmX THtOOz/tQuK9DSmJTBRnxXr5kNdjKoAiJaaUZB9TiY3RB/nNKBokaHEjDP7D567kMZrv GVKg==
X-Gm-Message-State: APjAAAWAjZR3CB6ZmdKVHHswkvahuj/GmQVOOhz7TUwPIRQrInYAF+9V hPT9liKxl+D/SYS0zgUN14rheAU6Em0=
X-Google-Smtp-Source: APXvYqzC8IanuTWaKksGwhMtShSOS1Vdj230rzXI+nPGYTNSyroJABJsWXheTj3Bn1VjxPEtiNxdMg==
X-Received: by 2002:ac8:8c4:: with SMTP id y4mr45139835qth.334.1558042267713; Thu, 16 May 2019 14:31:07 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:437c:8855:cbde:6c65:110c? ([2601:152:4400:437c:8855:cbde:6c65:110c]) by smtp.gmail.com with ESMTPSA id l47sm3605543qtk.22.2019.05.16.14.31.06 for <eligibility-discuss@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 14:31:06 -0700 (PDT)
To: eligibility-discuss@ietf.org
References: <0C4BD2C959F7FC53CAEAC85F@PSB>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <d8b5a2e4-aad7-fe1d-6bc7-a4238ec2cd82@nthpermutation.com>
Date: Thu, 16 May 2019 17:31:04 -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: <0C4BD2C959F7FC53CAEAC85F@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/q1SG4--EylhJw9UX-_z50VtZFOU>
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 21:31:12 -0000

Since I suggested some of this text... comments in line.

On 5/16/2019 3:50 PM, John C Klensin wrote:
>
> 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?

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.

>
> * 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.


>
> * 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.


>
> * 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.

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.

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.

Later, Mike


>   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
>
>