Re: [Eligibility-discuss] Virtual BoF for draft-moonesamy-recall-rev

John C Klensin <john-ietf@jck.com> Sun, 26 May 2019 15:30 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 92C1712019C for <eligibility-discuss@ietfa.amsl.com>; Sun, 26 May 2019 08:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, URIBL_BLOCKED=0.001] autolearn=no 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 veH5gzeJJjpm for <eligibility-discuss@ietfa.amsl.com>; Sun, 26 May 2019 08:30:00 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F231C120134 for <eligibility-discuss@ietf.org>; Sun, 26 May 2019 08:29:59 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hUv5q-000M47-UN; Sun, 26 May 2019 11:29:50 -0400
Date: Sun, 26 May 2019 11:29:45 -0400
From: John C Klensin <john-ietf@jck.com>
To: Eric Rescorla <ekr@rtfm.com>, Adrian Farrel <adrian@olddog.co.uk>
cc: eligibility-discuss@ietf.org, "Eliot Lear (elear)" <elear@cisco.com>
Message-ID: <1669AFBCC1B86369530B56FB@JcK-HP5.jck.com>
In-Reply-To: <CABcZeBOEWNPETpd-cTajhd+3uzztJzGJqMKHf17h=V9NUHscww@mail.gmail.com>
References: <6.2.5.6.2.20190525144314.0e72bb68@elandnews.com> <FDDEFD82-E276-4874-896E-490397EDA735@akamai.com> <6.2.5.6.2.20190525151934.0c0099e0@elandnews.com> <7D195412-2A8E-44FC-9144-B7C48F33EE5C@cisco.com> <067001d513ad$09739f60$1c5ade20$@olddog.co.uk> <CABcZeBOEWNPETpd-cTajhd+3uzztJzGJqMKHf17h=V9NUHscww@mail.gmail.com>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/ZT6KfVNHvzXSdv3h3BSzYw2P0vk>
Subject: Re: [Eligibility-discuss] Virtual BoF for draft-moonesamy-recall-rev
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: Sun, 26 May 2019 15:30:01 -0000


--On Sunday, 26 May, 2019 05:20 -0700 Eric Rescorla
<ekr@rtfm.com> wrote:

> On Sun, May 26, 2019 at 3:23 AM Adrian Farrel
> <adrian@olddog.co.uk> wrote:
> 
>> Well, if a WG is needed/desirable, you have captured the
>> process. Although (of course?) if EKR wants his draft to
>> continue, he would need to request a BoF.

> Well, maybe.. BOFs and WGs are scoped to a problem statement,
> not an document, and Mike and my draft would be clearly in
> scope for a BOF on "revisit the procedure for removing I*
> members", whether I request a BOF or not.

And that is one of the places where we have controversy.  I
haven't seen SM's BOF proposal yet, but, if I were writing the
problem statement for it, it would reflect what he, I, and
others, have said multiple times: having people who are
qualified according to the qualifications for the Nomcom able to
seek to remedy problems using the recall procedure, while those
who participate actively, perhaps even more actively than those
who are Nomcom-eligible prevented from doing so, is unreasonable
and reduces the credibility of the IETF as providing open and
equal treatment to all participants.
draft-moonesamy-recall-rev, in this current form, addresses two
specific categories of participants who are not now eligible to
initiate recalls, those who attend too few f2f meetings to meet
the present  nomcom eligibility criteria and those whose
exclusion by those criteria is due to their holding specific
nomcom-selected positions.

Now that is (deliberately, I believe) a very narrow change and
discussion.  It is a change that is worth making if we care
about either fairness or the perception of unfairness with the
procedures we have.

It puts/leaves the following out of scope:

(i) Whether the recall model works well or poorly as a means for
IETF participants, especially those who are not part of the
leadership to seek to correct a nomcom decision that, in
retrospect, turned out to be a bad one.   If it works poorly,
whether we have proposals for a good alternative and what those
proposals are.

(ii_ Whether the current nomcom eligibility model, based
entirely on paying registration fees and showing up at meetings,
is fair and reasonable.  To the extent to which it is a
surrogate for participation and/or knowledge, I think we all
know that it is a rather poor one (and I suggest it is getting
worse).  In particular, the original assumption that the nomcom
would be a representative sample of the participant community,
based on who could and did volunteer, that assumption becomes
progressively more false as the number of remote participants
rises.   On the other hand, even if we conclude that those
eligibility criteria work poorly, I'm not aware of any serious
proposal for other approaches (even though there has been talk
from time to time about allowing mostly-remote participants to
qualify).

(iii) Whether it is desirable that the recall model, voluntary
resignations, and, presumably, death in office be the only
mechanisms for removing members of the leadership.  There are
clearly cases in which the community should be able to fast
track a removal.   Using the one public example we have, if it
is obvious to everyone who is paying attention that someone has
basically stopped functioning in a particular position, maybe we
need a procedure in which non-response to several attempts to
notify someone and get a statement from them constitutes a
resignation.  Maybe we need something closer to ekr's proposal
(although I'd hope, a lot more transparent and allowing
community input).  Maybe we need both.  But those would almost
certainly be in addition to the recall mechanism  (or some
equivalent, community-initiated one), not instead of it.

I think all of those would be worthy topics.  But they have
nothing to do with the scope of draft-moonesamy-recall-rev as
proposed or the very narrow problem it is intended to address,
nor does that proposal in any way preempt addressing any or all
of the above if an when the community decides to do that.

>...
>> Again speaking personally, I don't think a working group is
>> necessary to work the issue in SM's draft,
 
> As I noted in my initial comments on SM's draft, it's not
> clear to me what "the issue in SM's draft is" (or, for that
> matter, whether it's a real issue) so the first thing that
> would be required is to flesh out the problem statement.

See above.

best,
   john