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

"Alexey Melnikov" <aamelnikov@fastmail.fm> Tue, 11 June 2019 12:50 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 06BD7120099 for <eligibility-discuss@ietfa.amsl.com>; Tue, 11 Jun 2019 05:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=aXUoiO49; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zMc4N4gS
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 TtcoOJkVTAd3 for <eligibility-discuss@ietfa.amsl.com>; Tue, 11 Jun 2019 05:50:55 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B06B120047 for <eligibility-discuss@ietf.org>; Tue, 11 Jun 2019 05:50:55 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3E022220C9; Tue, 11 Jun 2019 08:50:54 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Tue, 11 Jun 2019 08:50:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=cp9eE rdgxSaSyHiXOxl7JL64Kd4eFe4asBYVDrMpxr8=; b=aXUoiO49IUeTQRpbakhDf SaFrRfJRgUyUn5w/StVmfAhnoSclJNWqnG9WWobOP0JRpD0ZiG2uHYE3GOU+Tgg+ ab8l/MVgxz1xS1e6ZavWGLu0GUhMmj/HY3V5m7pdXu+VOM43W477tLd7wCsr9ZpA qaaBpNUYTpXS0eZIYfL2ZNpRPEt14Mm8H0uCP70o+IXytqKqieQwqfTRqCqHLXnw JtE1uZjd6PFcnM8JrPMDxmeKml4MWrCD+SURY7Kq3L+fKnjtI4b+rr5OAsSUvUoy kKuoM2g+Ioj4gcovBu8UwRKeU90vZ9e5NKJ3CnCd/QuEklHKKn4c2RjQYR7Us3UM w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=cp9eErdgxSaSyHiXOxl7JL64Kd4eFe4asBYVDrMpx r8=; b=zMc4N4gSCXkPha8s3VeT3HW762yy44w/ILudmBEkaOngigOdLXJd+ubKi h/gDyWSFKUMv83Ia0NGKfdwnUEoAGVnFpqDmVb6rMQ2aL/51RFgx6qXn4oyJiZqq Yjv6RTQOLf+KMAl13dcMxUq24XBCnaMlf1wRtTdd3l2rwdLIbLjCoLZNsdn9AMlr 6ZzRnj/U6YJ336dDDKML115/zERmkeeuzjFzd9mSgQXLZJKOXlwxZ6fvcVqHB4ZK n3iuxumd1cAPvTDiSMFKS1MAbZi0olZG2EGMLz6xGK+4m6lOhyxKS51bWTz6J7WL INcifv/JGD5VNmkI1FHAep0bPbtlA==
X-ME-Sender: <xms:raP_XClpmOPRGPZviQrZwmbWIg6sui9RX3Hi7coJ06RgXpmg_etiRg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehhedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghs thhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:raP_XF2a4zbJiI9DzKJ77Ul5HGpgA5SZNklii9efj-OGiSOKTdiXmw> <xmx:raP_XC2YF1LvYCHb9xcCAfEz8zsuPSdCU9v1x2YuMr7r06wXOh2n-w> <xmx:raP_XHoZ9KjwMAItsAcf6nbT4vnmqsE1qr0D0yTqAimEh1XulzB3eA> <xmx:rqP_XD7n44atU9wBTSN3n-loUIrLwy8Au9y8qjIpqbEu0drM7IgNjg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 45122C200A3; Tue, 11 Jun 2019 08:50:53 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1
Mime-Version: 1.0
Message-Id: <d64a1e12-f802-4ec4-bf72-d75f56f22684@www.fastmail.com>
In-Reply-To: <06BAD820-C035-4822-B908-51992E24DE5A@gmail.com>
References: <6.2.5.6.2.20190525144314.0e72bb68@elandnews.com> <6.2.5.6.2.20190601204707.0bf89070@elandnews.com> <D58B591C-9140-4273-AA11-59E2EBD101FE@gmail.com> <6.2.5.6.2.20190604124032.0c2f0ca0@elandnews.com> <35ECCB711814EE331938E6C7@PSB> <06BAD820-C035-4822-B908-51992E24DE5A@gmail.com>
Date: Tue, 11 Jun 2019 13:50:41 +0100
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Suresh Krishnan <suresh.krishnan@gmail.com>, John C Klensin <john-ietf@jck.com>
Cc: S Moonesamy <sm+ietf@elandsys.com>, Warren Kumari <warren@kumari.net>, eligibility-discuss@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/l4WEYlEwDJVu84e1_4GldZ7-NBY>
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: Tue, 11 Jun 2019 12:50:57 -0000

Hi John,

On Fri, Jun 7, 2019, at 4:14 AM, Suresh Krishnan wrote:
> Hi John,
> 
> > On Jun 5, 2019, at 10:10 AM, John C Klensin <john-ietf@jck.com> wrote:
> > 
> > Suresh (and Alexey and Warren),
> > 
> > It seems to me that there are two, quite different, possible BOF
> > proposals and that the community could use a little guidance
> > from the three of you about what the IESG is looking for.
> 
> Just speaking for myself here. I do have my preference (see below), but 
> I will leave it up to the proponents to decide which way they want to 
> go.
> 
> > 
> > One is the result of the direction in which Subramanian seems to
> > be heading and that reflects the actual content of
> > draft-moonesamy-recall-rev.  That is a very narrow set of
> > changes to fine-tune the existing recall procedure to allow a
> > set of people who do not meet the "Nomcom eligibility"
> > requirement because they do not attend sufficient f2f meeting no
> > matter how active they are in the IETF, to reduce the number of
> > signatures required to initiate a recall because the current
> > number is seen as burdensome (especially for people who can't
> > collect them by, e.g., passing a sheet of paper around at a
> > plenary), and by allowing people in the leadership to initiate
> > recall efforts (not only for the bodies on which they sit but
> > for other bodies).  The latter, which has almost nothing to do
> > with remote participants, could easily be dropped if there was
> > no support for it but I note that, draft-rescorla-istar-recall
> > is largely orthogonal to the change proposed in the present
> > draft: even if it were adopted, the proposed change would still
> > be worth careful consideration for cases in which, e.g., the
> > IESG felt there was a serious problem in the LLC Board.  The
> > proposal doesn't "fix" the recall procedure, it merely tunes its
> > first step a bit.
> > 
> > My personal opinion is that, if the scope is as narrow as the
> > "fine-tune the recall procedure in that way" implied above, a
> > BOF, virtual or otherwise, would be a waste of time -- there has
> > already been enough discussion to indicate community interest
> > and we should move forward to discussing the draft (and not
> > procedures for doing so).  If you are convinced that needs a
> > short-lived WG to, e.g., avoid getting sidetracked, we should be
> > working on a charter for that WG with the expectation that its
> > approval will be expedited, not going through an elaborate set
> > of rituals that are not required by IETF procedures.  On the
> > other hand, if you are convinced that a quick virtual BOF would
> > be helpful, let's get on with it.
> 
> This would be my preference. As I said in my earlier mail, if we can 
> separate the three pieces of the draft and see how the community feels 
> about each of them, I think we will be in a good spot to looking at 
> writing a narrowly scoped charter for a WG.

I agree. When I read the draft I couldn't quite figure out why it included certain changes and not others. Instead of arguing about the whole collection of changes IETF community should decide which ones should be worked on. (If all of them ended up having rough consensus, that would be fine with me.).

> > 
> > At the other extreme, perhaps the posting of this draft has
> > convinced the IESG that it is time to open up the entire
> > candidate selection and removal process and review it.  That
> > would (or at least might) include the nomcom eligibility
> > criteria; questions about whether the nomcom model itself is
> > appropriate in a contemporary IETF for which the implied
> > assumption that most of the nomcom members would have personal
> > knowledge of most of the candidates is no longer valid;
> > questions of term lengths, limits (or preferences), and
> > incumbent preferences; questions of whether, as the number of
> > bodies and slots for which the nomcom is expected to make
> > appointments has risen, having a single body do all of that work
> > in a single cycle is still appropriate; examination of whether,
> > in the environment of the IETF LLC having the ISOC President and
> > CEO appoint the Nomcom (and Recall Committee) chairs is still
> > appropriate both practically and from the standpoint of optics;
> > whether we can devise a mechanism for mid-term removal of people
> > who have misbehaved that is faster and more plausible than the
> > present petition, chair appointment, and two consecutive
> > committee model (or whether no such procedure is needed); and
> > perhaps even some issues that overlap into the old NEWTRK
> > effort.   That is obviously not a complete list: I'm confident
> > that you could add some things to it and that, given a few
> > hours, I probably could too.   
> 
> Just my personal opinion with no hats at all. I think this will be a 
> “boil the ocean” effort and I am not at all confident about its odds of 
> success.

Agreed. I am very happy to work on a small problem (or a small collection of related problems) once there is agreement to work on it.

> > If that is the BOF proposal/charter you and the rest of the IESG
> > want, then it probably would benefit from a f2f discussion and
> > some of us should see if we can get a proposal for a BOF in
> > Montreal together within the next 48 hours.  However, any of us
> > who have either tried writing I-Ds that propose adjustments in
> > those areas or who have been through opening up some of the
> > issues in WGs know that it will be a long, time and resource
> > intensive, trek with many passionately-expressed opinions.
> > Based on experience with POISSON, I think it would be
> > unrealistic to expect a WG with that task list to converge and
> > complete its work in less than two or three years. Even were
> > that much time to be available, it would be nearly impossible to
> > get to significant conclusions without enthusiastic IESG support
> > for reviewing things and making changes as needed, support that
> > would need to be independent of whatever changes the WG and
> > community select.   Unless you can assure us that the conviction
> > and enthusiasm exist, even holding a BOF, much less chartering a
> > WG, would, IMO, be a waste of time that the IETF could better
> > spend on technical work.
> 
> I whole-heartedly agree with you that this would probably be a waste of time.

+1.

> > Even if a BOF proposal for this larger effort were wanted and if
> > only because how long that effort would take, I think there is a
> > very strong case for addressing the fine-tuning proposal now and
> > getting it done with.  They really are separate efforts even
> > though we might reasonably expect the larger one to make changes
> > that would obsolete some or all of the smaller and faster one.
> > 
> > So, what would you like to see and how are you and the IESG
> > thinking about this?
> > 
> > Just my opinion but, perhaps unfortunately, one that is informed
> > by experience.
> 
> Much appreciated. I agree with you that a tightly scoped effort is more 
> likely to succeed. 

+1.

Best Regards,
Alexey