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