Re: AD Sponsorship of draft-moonesamy-recall-rev

Eric Rescorla <ekr@rtfm.com> Tue, 23 April 2019 02:19 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDD312014B for <ietf@ietfa.amsl.com>; Mon, 22 Apr 2019 19:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 tXo_D1r-MGef for <ietf@ietfa.amsl.com>; Mon, 22 Apr 2019 19:19:52 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 3932912012F for <ietf@ietf.org>; Mon, 22 Apr 2019 19:19:52 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id d12so10447216lfk.6 for <ietf@ietf.org>; Mon, 22 Apr 2019 19:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LHN3NF1eHALlB1SHpNA2Ae0jzBtx0Tb61YapJ6ydO8U=; b=fQqGsLeFZuifW5g605sAPMV8bPOnPns8ti7IbiJS5kTBXQVsl1XthohFWv0b98TOJh NwPPFoDFuxjuPz8gLDgNC3jaOrqTm39Tey4ajQBIojnEqFDr7FM/y2sQUdYXcqfxGzQP 1D5eG6vD9WRLJSFweI+95aP+v0u6Hl8p+g4mVJb7mtLRJV5OAE9N1l8uOIdEVD1mgjPn 004wN9GVGUVawmyu8HmD8Rzn6UoOQce7LXqOwgJgZdN41t5JP+wziJkDoUBI2ca1+IHo 96eM9jDPTy8R8jCSIHHKjN4MSHiQxrEcZiLjmB2VqvDo4fsnj+LfaRMNZ1C7tpUvItQX cOPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LHN3NF1eHALlB1SHpNA2Ae0jzBtx0Tb61YapJ6ydO8U=; b=JDLkfOyq3VB50RtMAx4ILEPJRYKpODH+vCMwIltM4EMUv3M49CcMi+ctY7GIbebE2i FVsZhf5poEMUSkKSCRJ2ecZRfeDr0h230hTeM8aRwif+oeI/R4ZSAHf7oGWNXo7iqYnx ZxPtTzmwyiJquCAT+hrs8UqwMQTc1i2+2c4E3vvlgBwhdyV3H738atfJplS2Eoa1vOtY HY65P+5p+fiLcZJpmB50o22XalezTMQR59+Nn0zkUATn37culSwR1FTeV1UeWG3MV2Bv BtQiknYNmG2L63WmBs1K4Qwx9/iB4VIRMt7cHQL0j9zQTKfpBk46DEFMj2/W4WuXhufq V14g==
X-Gm-Message-State: APjAAAX1mNBypAKqkkYxxZC9C2VDOpiSTCpCvy4EHZb+FzszcFSMOv5Y 5GXPuJcrm1bWNSgdT9jDGZtDGvSM4EWLhlk+iMxjqw==
X-Google-Smtp-Source: APXvYqzsbKmviJ9Jqg4P76mp/0QnctJlJo0jcqKpOuW+YojzCOFBI1HOFAdUlzlmBzRr4A/qIpmGBsSLKAatFZmrXdg=
X-Received: by 2002:ac2:4355:: with SMTP id o21mr12826474lfl.123.1555985990443; Mon, 22 Apr 2019 19:19:50 -0700 (PDT)
MIME-Version: 1.0
References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <033d01d4f52f$c6f2dca0$54d895e0$@olddog.co.uk> <C7274EAB-7DDC-491F-9DD2-0CFFADB13CA9@cooperw.in> <72f00d0b-7ec6-ba6a-b17b-97879d457ae3@comcast.net> <CAKKJt-fOMMdM-mkbJaYpsH6XPCpatUkwZY-d_A+MaNa3nhaNDg@mail.gmail.com>
In-Reply-To: <CAKKJt-fOMMdM-mkbJaYpsH6XPCpatUkwZY-d_A+MaNa3nhaNDg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 22 Apr 2019 19:19:12 -0700
Message-ID: <CABcZeBNdaWU4wwOK_MnWC5hOr7Lu3osmC_6_KKxB5fHuHVHyTw@mail.gmail.com>
Subject: Re: AD Sponsorship of draft-moonesamy-recall-rev
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Michael StJohns <mstjohns@comcast.net>, IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003c7df6058729384c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/g6D6xM463ulHFIOuRRBKTliYt1Y>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Apr 2019 02:19:55 -0000

On Fri, Apr 19, 2019 at 8:33 AM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> I'm actually enjoying this more than I should be ...
>
> On Thu, Apr 18, 2019 at 12:03 PM Michael StJohns <mstjohns@comcast.net>
> wrote:
>
>> On 4/18/2019 12:31 PM, Alissa Cooper wrote:
>> > Hi Adrian,
>> >
>> >> On Apr 17, 2019, at 11:10 AM, Adrian Farrel <adrian@olddog.co.uk>
>> wrote:
>> >>
>> >> Thanks for this email, Alissa. It's interesting. I presume it means
>> that the IESG is unanimous, because it only takes one AD to AD sponsor a
>> draft.
>> > I asked the IESG. I did not get responses from everyone, but of the
>> people who did respond none of them volunteered to AD-sponsor.
>>
>>
>> In the past, what's worked for dealing with small things is the
>> formation of a design team to look at the problem and figure out if
>> there's a document or two to be had.  Perhaps that's a better approach
>> than WG forming BOFs or even trying to find a sponsor for this one
>> little piece of the problem?
>>
>
> And the reason Mike knows this, is that he (and something like the first
> 10 Nomcom chairs) were on a design team that Russ Housley formed to look at
> issues that had recurred across Nomcoms, which we don't really have much
> visibility because there's not a lot of overlap of Nomcom membership over
> time.
>
> The report that design team produced is at
> https://www.ietf.org/archive/id/draft-dawkins-nomcom-3777-issues-00.txt.
> It resulted in most of the updates to RFC 3777 before they were all
> obsoleted by https://datatracker.ietf.org/doc/rfc7437/.
>

Thanks for pointing us to this document. Useful to avoid reinventing
the issues list.

In that vein, I think it would be useful to get crisp about the
problem statement. It seems to me that this document implicitly makes
two arguments:

- It's too difficult to initiate a recall (because the threshold
  is too high and because members of the leadership who might have
  special knowledge are excluded) [S 2.1, 2.3]

- It's unfair to exclude remote participants [S 2.2]

I'm not sure how persuaded I am by the second argument, but I think
the overall thrust of the first argument has some merit. However,
I tend to agree with Alissa that the main obstacle isn't so much
the number of people or excluding leadership, but rather the
reputational risk to people of signing the petition, especially
if the recall fails [0].

So, if the idea is to make recalls easier, then it seems to me
that the easiest thing to do would be to make the signatures
on the petition anonymous; the Secretariat can still verify them,
of course, and the recall proceedings themselves would still
be conducted in our usual fashion.

-Ekr


[0] "If you come at the king, you best not miss".
[1] It's also possible to build a system that allows third party
    verification that the right number of sigantures were provided
    while not identifying the signers, but the amount of crypto
    required seems somewhat prohibitive.










>
> Do the right thing, of course :D
>
> Spencer
>
>>
>> Asa general model, people leave "elected" positions due to term
>> expiration, resignation, expulsion (not IETF), recall, death, or
>> disability (partial IETF - self-reporting yes as a resignation,
>> non-self-reporting no).   It may make sense to fill out the full score
>> card while we're updating the recall process.
>>
>> Later, Mike
>>
>>
>>