From nobody Fri Apr 26 04:05:35 2019 Return-Path: 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 751281201B7; Fri, 26 Apr 2019 04:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 buziNOGclmUi; Fri, 26 Apr 2019 04:05:23 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 52699120116; Fri, 26 Apr 2019 04:05:20 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id m137so1609519qke.3; Fri, 26 Apr 2019 04:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ijd1NjNhIk/hpI8FmdHWiCKXyUW/r+rD9EGViz4pC/0=; b=Qzzf0nuuYZxNI9qSL9RX/yKhScUru/83Ud3LZxauWXyFKvQBqskzG8WHs5zR/5nUqO 2P48i8VSLjlEwW9dggjRqIgAfsNeh26raj/a6FA8GdfleyZMhUMyK2i6qurO1PE0Klj0 ZquZfHjBnXaxaalNxnMtwmi8cibeto9kA4JaY2an+jD79zsvXez4fTdTaSojOAa05H+l 0NzdTWiTnhfm15XJ8mVmQ731IzCVfnc2I1WkYRAlHIIqW+EEMLfkVNIFK0M25/N6nL4a cK9gwMR7LppFjVGbB3mcz/d3XqDQMYhiNIkgkjOk/Da3OH9qxqckzF2RLdLc2xYc5uSG +jYA== 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=ijd1NjNhIk/hpI8FmdHWiCKXyUW/r+rD9EGViz4pC/0=; b=hpdVp5K5DZ8H/cnZQxyBuT4Scdt67ufZGfnE/G1xMnpeBpDaSy6mcTuZbiMFgeI6/e 30adkoKj5DjgqtQfHTu4V4S8JqYk2vRBXt91NrOL0DzJlyIGllp85SKr4kCzwWXJNqHl GPI3ufuDh2MfuX2WgNf7IbUw2nC1XDIZ4FYJuasz6kPNSEl9HB2MXo6WaxUQ0hs5ag+T 6WSMY3gK9mUMDAZTlkfomD9kyr8o+StM396clrkFc75pzuL/niNldxhsietBdx7riegW Mg7jHSqpin8MzdPPCHi0kLyr0E1wur6/BNW8nn3xIpP6nKuWOKHnz5cjWxJjSMv2XkyA OJzQ== X-Gm-Message-State: APjAAAX0Ab+nMEi5ba8It/EQSI0ZkdxwY7myIHca7KUs9j94rBw0V0S/ aKsCc5vUhXLQ65vA1UfSwaavhK+3MlxnK97SCfo= X-Google-Smtp-Source: APXvYqxQ5I021O+qVRram2eVkl3LPyIWLv5LNwgoCACCvq2O+QzVOE2FIvIvjZhZ6TV9qwuTy4/wrRJa2DpcqObZRxY= X-Received: by 2002:a37:7f84:: with SMTP id a126mr33500055qkd.231.1556276719301; Fri, 26 Apr 2019 04:05:19 -0700 (PDT) MIME-Version: 1.0 References: <6.2.5.6.2.20190424095017.13cdadc8@elandnews.com> <51068F13-E90F-42A2-8AE2-627D5E18B145@akamai.com> <20190424201939.GM3137@localhost> <6.2.5.6.2.20190424134823.0c9faf68@elandnews.com> <20190424211123.GO3137@localhost> <6.2.5.6.2.20190424144539.0cabcde0@elandnews.com> <20F28A58-4D1D-40D7-8513-2DA7A4A8778C@akamai.com> <07b301d4fb40$84b0b940$8e122bc0$@olddog.co.uk> <20190426010940.GQ36553@kduck.mit.edu> In-Reply-To: <20190426010940.GQ36553@kduck.mit.edu> From: "Andrew G. Malis" Date: Fri, 26 Apr 2019 07:05:07 -0400 Message-ID: To: Benjamin Kaduk Cc: IETF Discussion , S Moonesamy , eligibility-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000006b6cf05876ce97e" Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 11:05:26 -0000 --00000000000006b6cf05876ce97e Content-Type: text/plain; charset="UTF-8" Ben, Thanks for your clarification of the use of the main ietf list (I had forgotten that detail from RFC 3005) and also note the formation of eligibility-discuss@ietf.orgfor the discussion. Cheers, Andy On Thu, Apr 25, 2019 at 9:10 PM Benjamin Kaduk wrote: > On Thu, Apr 25, 2019 at 10:47:42AM -0400, Andrew G. Malis wrote: > > I agree with Stewart, I think a BOF is overkill for this particular short > > I'm not sure that we need to focus too much on "BoF" -- I don't see many > people specifically pushing for a BoF, whether virtual or in Montreal, when > work could get done on a non-WG mailing list as well. > > > and focused draft. Even absent current AD sponsorship, discussion and > > refinement of the draft can continue on this list. If general community > > I respectfully disagree: RFC 3005 is pretty explicit that the general > discussion list is only for "initial discussion only [...] unless the issue > is one for which the working group needs wider input or direction". The > IESG is working on a place to continue this discussion and work through any > complications and/or subtleties of this and related topics, before it > returns to the general list for IETF LC and the wider input from the > community. > > > consensus around a future revision of the draft can be shown on the list > > (as usual, by the absence of continued commenting following a new > > revision), it may then be more difficult for the IESG to not find at > least > > one member to sponsor the publication process, including IETF last call. > > Indeed. I note that, per my understanding of > https://trac.ietf.org/trac/iesg/wiki/AreasDescription, an AD sponsoring a > draft should have personally reviewed that document and believe it ready > for publication as-is. Given the continued discussion regarding this > document, I believe that a conclusion that the document is not ready for > publication "as-is" is justified, but I'm happy to see the discussion > progress. > > -Ben > > --00000000000006b6cf05876ce97e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

Thanks for your clarification of t= he use of the main ietf list (I had forgotten that detail from RFC 3005) an= d also note the formation=C2=A0of=C2=A0eligibility-di= scuss@ietf.orgfor the discussion.

Cheers,
Andy


On Thu, Apr 25, 2019 at 9:10 PM Benjamin Kad= uk <kaduk@mit.edu> wrote:
On Thu, Apr 25, 2019 a= t 10:47:42AM -0400, Andrew G. Malis wrote:
> I agree with Stewart, I think a BOF is overkill for this particular sh= ort

I'm not sure that we need to focus too much on "BoF" -- I don= 't see many
people specifically pushing for a BoF, whether virtual or in Montreal, when=
work could get done on a non-WG mailing list as well.

> and focused draft. Even absent current AD sponsorship, discussion and<= br> > refinement of the draft can continue on this list. If general communit= y

I respectfully disagree: RFC 3005 is pretty explicit that the general
discussion list is only for "initial discussion only [...] unless the = issue
is one for which the working group needs wider input or direction".=C2= =A0 The
IESG is working on a place to continue this discussion and work through any=
complications and/or subtleties of this and related topics, before it
returns to the general list for IETF LC and the wider input from the
community.

> consensus around a future revision of the draft can be shown on the li= st
> (as usual, by the absence of continued commenting following a new
> revision), it may then be more difficult for the IESG to not find at l= east
> one member to sponsor the publication process, including IETF last cal= l.

Indeed.=C2=A0 I note that, per my understanding of
https://trac.ietf.org/trac/iesg/wiki/AreasDescr= iption, an AD sponsoring a
draft should have personally reviewed that document and believe it ready for publication as-is.=C2=A0 Given the continued discussion regarding this<= br> document, I believe that a conclusion that the document is not ready for publication "as-is" is justified, but I'm happy to see the di= scussion
progress.

-Ben

--00000000000006b6cf05876ce97e-- From nobody Fri Apr 26 08:11:15 2019 Return-Path: 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 3C896120416 for ; Fri, 26 Apr 2019 07:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 W4wyPi_WMTQr for ; Fri, 26 Apr 2019 07:59:29 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977481203F0 for ; Fri, 26 Apr 2019 07:59:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 820637DBBF67 for ; Fri, 26 Apr 2019 09:59:25 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2VzcTaAO1dm for ; Fri, 26 Apr 2019 09:59:24 -0500 (CDT) Received: from [172.16.1.18] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 671557DBBF5D for ; Fri, 26 Apr 2019 09:59:24 -0500 (CDT) From: "Pete Resnick" To: eligibility-discuss@ietf.org Date: Fri, 26 Apr 2019 09:59:23 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 26 Apr 2019 08:11:14 -0700 Subject: [Eligibility-discuss] To find the IETF list discussion... X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 14:59:31 -0000 For those who want a quick link to the original discussion(s) on the = IETF list: https://mailarchive.ietf.org/arch/search/?qdr=3Da&email_list=3Dietf&q=3Ds= ubject%3A(draft-moonesamy-recall)&as=3D1&so=3Ddate pr -- = Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best From nobody Fri Apr 26 13:02:47 2019 Return-Path: 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 457761205E6; Fri, 26 Apr 2019 13:02:38 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=AlxNtaEt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s2NCQG4n 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 tz8tyB0YqaBN; Fri, 26 Apr 2019 13:02:36 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB261205D0; Fri, 26 Apr 2019 13:02:36 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6576D21E97; Fri, 26 Apr 2019 16:02:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 26 Apr 2019 16:02:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=5 PBPKG5g+hEhw4EBhpczpQyGqM1uVopr0/apl7J3QMc=; b=AlxNtaEtwozRLO0c/ +ZE8cAxXK+GdEpKvEMIhiL5g7hAES/Omt3pbCv0wVbF9DmhPy9rzFNlLK6PDDwMb 39eB7KIvzNdUQVvALvcc/Ki6yOtKQ4qkV/G8oUlTovFE2DJ54RAtkxDzF9H8soqP 0xSC9/XtLi7x7QkpHnfN5HNfLsWaCx6O+VAaqKhizqYpRttxRu1mc+RCDUOnnn8c 5pR9sP5OOSQxDFx5+5jWrp3Zc80yepnHOdnz+cx/e3EPYoIuyvYPvDhFe8kPq5Ez Rj+6K5GYO3JpaBMe4VcSU83QyQqwcW/sKLkBNGh5m1jWWt1DyOCSK0dakLP4VM9o DZrcw== 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=fm2; bh=5PBPKG5g+hEhw4EBhpczpQyGqM1uVopr0/apl7J3Q Mc=; b=s2NCQG4n/JP6lUsdc8VWhP2oQuHDsJ5+jAbKlgZSUmVCLb4gA01S1Ul4q POvOhcjUKlQSX11A1qCEORVH612SwUIFyO2Y++uojnceGIAxDGZ2XIz7HXls76gQ 504/W2a0VtINx38IN8UcE5CgUuI8GgRQhnKcoT99tiJza+MN/kiX3V3IF3MjDz7e gpZNacZRpHp8TIvrOWIQXNVLhFIQwphofBi6cFkvndsB4XsbigzMwXsRT52TpX6q uxQEzZxlwotlWRlvCheJPOK7Lq2vcvwN8Pq1xjgbHl7X+h1eF/dKFyCcAJvnRcj0 3dcPiL6uq7yNTIBn+zsEyuEXYnomg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheeigddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceorghlihhsshgrsegt ohhophgvrhifrdhinheqnecukfhppedujeefrdefkedruddujedrkeejnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsthgv rhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id BE841E4173; Fri, 26 Apr 2019 16:02:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <6.2.5.6.2.20190418115734.0dffb680@elandnews.com> Date: Fri, 26 Apr 2019 16:02:33 -0400 Cc: IESG , John C Klensin , eligibility-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A8EB85F-9A5A-4E33-AC82-78B49A3D8BE1@cooperw.in> References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <6.2.5.6.2.20190418115734.0dffb680@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 20:02:46 -0000 Hi SM, > On Apr 19, 2019, at 10:06 PM, S Moonesamy = wrote: >=20 > Hi Alissa, > At 07:46 AM 17-04-2019, Alissa Cooper wrote: >> I discussed this with the IESG and our recommendation is for you to = submit a BOF proposal if you'd like to pursue this further. We think = these kinds of changes to the IETF's governance structure need the more = in-depth problem statement discussion and broader review that a = chartering process and working group would provide. >=20 > Thank you for discussing the request with the IESG. >=20 > There is currently a working group discussing the governance structure = of the IETF. I doubt that the draft would be in scope for that working = group given that its charter specifically sets "the standards process" = as outside its scope. =20 If you are referring to IASA2, I think that WG is explicitly not about = the governance structure of the IETF, but rather its administration. > Is the IESG recommending an in-depth problem statement about the = Internet Standards Process? We did not make that recommendation. I believe what we are looking for = is a clear articulation of the underlying problem(s) that the draft and = the resutling community discussions are seeking to address. Alissa >=20 > Regards, > S. Moonesamy=20 From nobody Fri Apr 26 13:04:16 2019 Return-Path: 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 8391D120322; Fri, 26 Apr 2019 13:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Ek+dSfat; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FaTbEC3I 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 yyY3P24cxp6R; Fri, 26 Apr 2019 13:04:06 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782C81202AA; Fri, 26 Apr 2019 13:04:06 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 754A922178; Fri, 26 Apr 2019 16:04:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 26 Apr 2019 16:04:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=u FdsrB0fzZzwEyfMI2i70ewVxmDGpK/t4e8MKjb2ftg=; b=Ek+dSfat9wpRirtHk xrG5vZ9Ma1/DziJJw7WSiKSZqmN3n9LUPBqtNPJJv3zDDyjuy07r3L+/Ro1YKzNa 83SoTH+Fkkj5h6MJMy8noykH1gfxSmFTan97feuMVUhhO773WQP2F1Q+ymcKv2jR uhw9Q1TaKShV33KwC87BwmKYoU6+Cp5vxrz+ZyPzRTdTW05+bKz5eCVkUuRy8ltW jG6HBusMHPsr1+Lkj0EcYwhoJYAcKRdbrJSUPG5vUQmPnUKSHFN0s0RYAWt9D4z0 ASwsM8nThoUXUn2VIF8/IuI1DzEs/iZ38W5jzr8tX3RSaogrr5jvVaIRg7TL+BdO 3QiQw== 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=fm2; bh=uFdsrB0fzZzwEyfMI2i70ewVxmDGpK/t4e8MKjb2f tg=; b=FaTbEC3IBbLsYbAITJxyZ45vg8SFR6w9QHhdX34Prw+7COcEhhmqkulLH 4nWKU5jDWkdZHmfvOgzjDgN/50Ez2MugHGUVK1+Il1Bg39nc+J2u5uHeEpZbCkmK +TRBnaz8UlfOKBLc+v8c8QJ5tha6M/PB3669yxnXuL2fK8nWav5SUXO2dqAQr6yw GdBjpZ8BuTVGN9S2lW8SfJ7zqYl4/9DOQB4pyCh1hYGV91H8us8lwO9AT4in3PaS 8mv10naOyqtsY+Za0HA54AKwDt9k/WGt3mNRbAWxlppET7xmYqfABVQ+Kc/r6b+5 JRcAwbZnrizikhCKZ+JRaHVr8z83g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheeigddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepud ejfedrfeekrdduudejrdekjeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgr segtohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 08EAAE4122; Fri, 26 Apr 2019 16:04:03 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <6.2.5.6.2.20190419223655.108e5998@elandnews.com> Date: Fri, 26 Apr 2019 16:04:02 -0400 Cc: IESG , Adrian Farrel , Aaron Falk , eligibility-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <033d01d4f52f$c6f2dca0$54d895e0$@olddog.co.uk> <6.2.5.6.2.20190419223655.108e5998@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 20:04:08 -0000 Hi SM, > On Apr 20, 2019, at 2:07 AM, S Moonesamy wrote: >=20 > Dear Internet Engineering Steering Group, > At 09:50 AM 18-04-2019, Alissa Cooper wrote: >> I can only speak for myself and will let other ADs chime in if they = want to. >>=20 >> I think the problem statement definition and the breadth of the = changes to be proposed are intertwined, and require the depth of = discussion we can get through a working group process. The underlying = problem(s) that the draft seeks to address appear broader than the = solutions proposed. Is the statement of the problem that the IETF = process or its governance are unfair to remote participants? If so, the = proposal in this draft is an incomplete solution to that problem. Is the = statement of the problem that the recall process is dysfunctional = because of barriers to using it? If so, the proposal in this draft is an = incomplete solution to that problem and IMO misses the most compelling = reason why recall petitions are not issued, which is that the perceived = reputational risk to petitioners outweighs the perceived potential gain = from issuing a recall petition. >=20 > =46rom what I understand, the governance part of the IETF is done by = the IETF LLC. =20 I guess it depends on your interpretation of governance, but as I said = in my other mail I don=E2=80=99t think the IETF LLC has to do with the = IETF=E2=80=99s governance, which is done by the community itself. > The draft does not get into IETF LLC matters. A person conversant = with corporate affairs would likely understand the legal aspects of = that. >=20 > The proposal does not mention the word "dysfunctional". This is a = sentence from Section 2.2: 'Restricting signatories to those who are = "nomcom qualified" disenfranchises active remote participants who reside = in emerging countries as they lack the extensive travel resources = required to seek redress=E2=80=99. People who participate exclusively remotely are disenfranchised from = seeking redress in a number of ways, not limited to the recall process. = If the community views the disenfranchisement of remote participants = from seeking redress as a problem to be rectified, it would be useful to = know that and to use it to guide solution discussions. >=20 > As for reputational risk, does the reputation of a person who can = afford to spend USD 10,000 outweigh the reputation of a person who = actively participates even though he or she does not attend IETF = meetings? I don=E2=80=99t understand the premise of this question. My point is = that I believe the key reason the recall process does not get used is = because it creates reputational risk for the petitioners. Changing the = pool of potential petitioners, assuming they would still be IETF = participants, wouldn=E2=80=99t change this for individual petitioners. >=20 >> The proposal in this draft can also be trivially gamed by a single or = small handful of individuals creating a set of 10 email accounts, = registering them to participate remotely, and having them join remote = sessions. Even if all this would result in is a series of recall = committees being forced to be constituted to deal with recall petitions = that get rejected, this could be a significant tax on our community. I = think analyzing the countervailing benefits of this proposal against = this tax or analyzing the costs and benefits of doing identity = verification to overcome it are important tasks that would require the = kind of discussion a WG can provide, and also require a clear = understanding of what the problem statement is. >=20 > Does the above mean that the Internet Engineering Steering Group = (IESG) is aware that BCP 78/79 can be easily "gamed=E2=80=9D? No. As I said in my mail, I was only speaking for myself. And I made no = comment on BCP 78 or 79. Alissa >=20 > Regards, > S. Moonesamy=20 From nobody Fri Apr 26 19:25:06 2019 Return-Path: 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 C7BC412001B; Fri, 26 Apr 2019 13:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 d7uLnxMWWzq7; Fri, 26 Apr 2019 13:30:37 -0700 (PDT) Received: from mail-it1-f178.google.com (mail-it1-f178.google.com [209.85.166.178]) (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 B225612048C; Fri, 26 Apr 2019 13:30:37 -0700 (PDT) Received: by mail-it1-f178.google.com with SMTP id x132so7884041itf.2; Fri, 26 Apr 2019 13:30:37 -0700 (PDT) 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:content-transfer-encoding; bh=r4OegbFPtaf0PZqKsWMXI/wr0GLHMC1i33Vmjz5Gzrw=; b=ITWDIe+LHFa8wrNAwWktsrysqupYug2cph5eR/LLPBPiAwuHUlcshkcvmih43totzl u7eQpH4VQwbZTNN3G0bz96a3U1LBFrZ3M4/V36cLm2mKUY2sPFbhNh1nXV4n3OxQkXom yo4EXJFWr17J11SSXl/TsKVaBc7vUJQ0hJ/WTYYLRfSDbucCMB3S6o5Tz0EpySRTqrcs LP+NKcPR2Y69lA5xq7oqNPHVDWK5uY2sMbNCgkrxOYpeWsLhWQiLwSAUplHE5zMPhVgw t2G56MDRFS8a0Isf5xNpUWSnyfk51S6jESXJ708NFHiBDy/OzxsnTjg1h1UQYGmdYNRN Lq7w== X-Gm-Message-State: APjAAAX9OHwsXNx+DckawwCjAYCrBbcqaW7iBEMoP6L8kDT1/gbpUyth b/YCG9xJffKejWTlMKooBIWGdFSbYcgHAWj6GxA= X-Google-Smtp-Source: APXvYqwm+L5ziJGJa33vubmKH/d/YTVXcplgEszYxZt1sP489kcXzTLbcmiY63uMgSWICNhHv9eEgdQCyxVRdQUR4O0= X-Received: by 2002:a05:6638:214:: with SMTP id e20mr6631619jaq.59.1556310636532; Fri, 26 Apr 2019 13:30:36 -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> <6.2.5.6.2.20190419223655.108e5998@elandnews.com> In-Reply-To: From: Barry Leiba Date: Fri, 26 Apr 2019 16:30:25 -0400 Message-ID: To: Alissa Cooper Cc: S Moonesamy , Adrian Farrel , Aaron Falk , IESG , eligibility-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 26 Apr 2019 19:25:03 -0700 Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 20:30:39 -0000 > > From what I understand, the governance part of the IETF is done by the = IETF LLC. > > I guess it depends on your interpretation of governance, but as I said in= my other mail > I don=E2=80=99t think the IETF LLC has to do with the IETF=E2=80=99s gove= rnance, which is done by the > community itself. I agree with Alissa: the aspects of what one might call "governance" that the LLC is responsible for are the financial and contractual ones, and that is explicitly designed as "administration" in everything we say about the LLC. What I normally consider a governance role as deals with day-to-day running of the organization -- leadership to achieve the organization's goals. The LLC explicitly does not get involved with that. There is, of course, a connection through the finances, but I think there are enough checks to keep that clean. > > from Section 2.2: 'Restricting signatories to those who are "nomcom qua= lified" disenfranchises > > active remote participants who reside in emerging countries as they lac= k the extensive travel > > resources required to seek redress=E2=80=99. > > People who participate exclusively remotely are disenfranchised from seek= ing redress in a number > of ways, not limited to the recall process. If the community views the di= senfranchisement of remote > participants from seeking redress as a problem to be rectified, it would = be useful to know that and > to use it to guide solution discussions. Again, I agree with Alissa. SM, I know you had tried at some point to set up a path for nomcom eligibility for remote participants, and that didn't happen. I think that is a much broader, more significant, more useful way to enfranchise remote participants. If this effort is an alternative to that which comes out of not being able to get the broader issue addressed, then I suggest we look at the broader issue again instead. But to know whether that's the approach to take, it's important to properly and fully understand the reasons we're looking at this current effort. > My point is that I believe the key reason the recall process does not get= used is because it > creates reputational risk for the petitioners. Actually, I quite hope that is not "the key reason". It's surely a concern, and we can (and perhaps should) develop ways to mitigate that. But as I see it, the *key* reason we have never recalled an AD or IAB member is that we view it as a very serious thing to do, and something that should be reserved for only the most egregious situations. And, while there have been rumblings in the past about kicking off a recall, our (correct, as I see it) aversion to using the process has kept it from actually happening. *For the most part*, a bad situation with an AD or IAB member can and should wait the less than two years it takes to have the next nomcom unseat that member. I hope we don't move in the direction of turning recalls into more normal actions than what I describe above. I'm not averse to adjusting the process, but in the end I still want it to be fairly much in the realm of dropping a major bomb. Barry From nobody Fri Apr 26 19:25:12 2019 Return-Path: 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 32874120611; Fri, 26 Apr 2019 13:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=UgG0SgTg; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=W8R0lBi4 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 WLtSnzPMiWZ2; Fri, 26 Apr 2019 13:58:36 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8A9120139; Fri, 26 Apr 2019 13:58:35 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.55.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id x3QKwFnj020744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2019 13:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1556312309; x=1556398709; bh=DqnLRIvJU37M1uNlNInYvskVVi3T/X0lI0G0hF+2zVc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UgG0SgTgI/XaDD4yr/0U0SeeMj8iM9Oo8n8RPxWq18B7v7hVPK48SmiJHthOJhSSh 4rt9GRVNLtI2HDOo5z9yJRoy9kqByXlfh0lU9I6kwno9CTyuZKEzAgMOulLHh2ZALx CKMRmyBafy45peMvOv6jwO41iBM+8v2VAiidcgVg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1556312309; x=1556398709; i=@elandsys.com; bh=DqnLRIvJU37M1uNlNInYvskVVi3T/X0lI0G0hF+2zVc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W8R0lBi4qTPmyfAFYUmApuWz8czAYKnEVLBXDxjdIliwL5fW/ENWlQvIGkBKpW/4C BiJqJLXgPOx7x2FD4hqyz9I2LvnisNnWDEQ6NDA9vF2EnB4WCBZQJKgsEgyQPNkuoj hq3I7aBG5CilRsicAfjfJcKNjzH2PQkII9GxAmYI= Message-Id: <6.2.5.6.2.20190426131519.0c8b0a88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2019 13:48:40 -0700 To: Alissa Cooper From: S Moonesamy Cc: iesg@ietf.org, Adrian Farrel , Aaron Falk , eligibility-discuss@ietf.org In-Reply-To: References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <033d01d4f52f$c6f2dca0$54d895e0$@olddog.co.uk> <6.2.5.6.2.20190419223655.108e5998@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-Mailman-Approved-At: Fri, 26 Apr 2019 19:25:03 -0700 Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 20:58:37 -0000 Hi Alissa, At 01:04 PM 26-04-2019, Alissa Cooper wrote: >I guess it depends on your interpretation of governance, but as I >said in my other mail I don't think the IETF LLC has to do with the >IETF's governance, which is done by the community itself. There was a response [1] from the IAB to UNDESA which provided updated information on the role of the IETF in Internet governance. The IETF LLC is, if I am not mistaken, part of the internal organization of the IETF. I viewed "governance" in terms of structures and processes. There are probably different interpretations of it depending on the context. Thank you for replying to the query about decisions [2]. Regards, S. Moonesamy 1. https://www.iab.org/wp-content/IAB-uploads/2011/03/2010-03-15-IETF-response-UN-enhanced-cooperation-v2.pdf 2. https://mailarchive.ietf.org/arch/msg/ietf/2TDJecox71yR_L_RhVhPbzKA12A From nobody Fri Apr 26 19:25:18 2019 Return-Path: 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 12F6112006F; Fri, 26 Apr 2019 15:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=SrkqNrUq; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=tw/HldbS 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 msJwE_ynDPHJ; Fri, 26 Apr 2019 15:41:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A48F3120044; Fri, 26 Apr 2019 15:41:53 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.55.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id x3QMfSJv023861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2019 15:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1556318504; x=1556404904; bh=HKfFdSweVASMy+r6wJ/1ec/xQgTLqRTwQr3kQ3o0wE8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SrkqNrUquvYEFd/7ZsKDHxpqxRqdFq+yD3/G+IgkNl0+uRjxwJ/KYXJTs3Zzax0k7 tbUNFkP1S5hSX2BELM0/1Eisj4fbmLpPgHWPMFiLufmezAT5ruK5HSW94rDeki+dFz /lGTbSzmmO6mZ/55OjYtzQ7MHFMm6UqPEz7qcoyM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1556318504; x=1556404904; i=@elandsys.com; bh=HKfFdSweVASMy+r6wJ/1ec/xQgTLqRTwQr3kQ3o0wE8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tw/HldbSuKjwFyeDksI45mEUB2LQUMXSejxoGv/5/KjyMrVT3zcgmzQkRZ47C8RW0 yJJQhBZ2cFmCLBHAWE8zihvq0S6/mGHWOOoJMtEr5Nxk+wOnX31NJNQwrnJxAoS6Pj w2DavgO/TRyQoaTGey0UYoEZg7J9i5rrEKix2D/Q= Message-Id: <6.2.5.6.2.20190426135349.0c8aff00@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2019 15:41:04 -0700 To: Barry Leiba From: S Moonesamy Cc: S Moonesamy , Adrian Farrel , Aaron Falk , iesg@ietf.org, Alissa Cooper , eligibility-discuss@ietf.org In-Reply-To: References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <033d01d4f52f$c6f2dca0$54d895e0$@olddog.co.uk> <6.2.5.6.2.20190419223655.108e5998@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-Mailman-Approved-At: Fri, 26 Apr 2019 19:25:03 -0700 Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 22:41:55 -0000 Hi Barry, At 01:30 PM 26-04-2019, Barry Leiba wrote: >Again, I agree with Alissa. SM, I know you had tried at some point to >set up a path for nomcom eligibility for remote participants, and that >didn't happen. I think that is a much broader, more significant, more >useful way to enfranchise remote participants. If this effort is an >alternative to that which comes out of not being able to get the >broader issue addressed, then I suggest we look at the broader issue >again instead. But to know whether that's the approach to take, it's >important to properly and fully understand the reasons we're looking >at this current effort. I was part of the Diversity Design Team which was set up by an IETF Chair. If I recall correctly, the effort was related to that. This draft was related to a point which was raised during a discussion about the change of affiliation ( https://mailarchive.ietf.org/arch/msg/ietf/qoucwrKWsVc-knBCsf34mj331S4 ). The draft is narrow in scope as the broader issue would, in my opinion, entail several years of effort. Regards, S. Moonesamy From nobody Sat Apr 27 15:19:05 2019 Return-Path: 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 9EE311200F4 for ; Sat, 27 Apr 2019 15:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=HnEAJjjs; dkim=pass (1024-bit key) header.d=yitter.info header.b=UAh/hPzN 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 UhZRa-SoB-pW for ; Sat, 27 Apr 2019 15:19:01 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62D5120121 for ; Sat, 27 Apr 2019 15:19:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8B894BCC66; Sat, 27 Apr 2019 22:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1556403539; bh=OBUlEKfGnQoAmhtlJvxlmdbowiNmeW8oKiSofXFQYqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HnEAJjjsn3r+p442h3wOGpW7lnYETLtqPj6oHhalkbo5je+uEj0DdW6Vgl/ZUK58J wc5FYqSKP/zXjzFSKNaxgFGYVRjhUDc+uTYgaG0vP9kOXpkmVIDMZm+YGgWCRNoxMG o0IIrXeBK5Hmi6XmSFAuOCikAXyVYQEyTqux9tfM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV0c13HoG9Vw; Sat, 27 Apr 2019 22:18:57 +0000 (UTC) Date: Sat, 27 Apr 2019 18:18:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1556403537; bh=OBUlEKfGnQoAmhtlJvxlmdbowiNmeW8oKiSofXFQYqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UAh/hPzNsJIexypZB4FJrbPcimvZ21cDwForJ1SAOCIc/s1AgjcHZX7ZUZlyq7Dv/ IxPDs9D4IU5P04qsvNpB4Q43AJh+UJZ+piGl3wB878/exQfzg5lI6rTN8RlWXP/bZ0 iHxwddsB0m+4THFVO1hrPcXNdZhHYsfnL7NnRw4o= From: Andrew Sullivan To: S Moonesamy Cc: eligibility-discuss@ietf.org, Adrian Farrel , John C Klensin Message-ID: <20190427221856.sxr46qr7j5niwrk4@mx4.yitter.info> References: <20190424201939.GM3137@localhost> <6.2.5.6.2.20190424134823.0c9faf68@elandnews.com> <20190424211123.GO3137@localhost> <6.2.5.6.2.20190424144539.0cabcde0@elandnews.com> <20190424234334.GQ3137@localhost> <11F97591808485C30AD98A22@PSB> <20190426150436.v4svwa67xja6267r@mx4.yitter.info> <0a1e01d4fc6c$10b93df0$322bb9d0$@olddog.co.uk> <20190427155921.i32pftxdbkvv7ist@isoc.org> <6.2.5.6.2.20190427094440.12099d10@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20190427094440.12099d10@elandnews.com> Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 22:19:04 -0000 Hi, I've changed the destination list on this. Again, no hat. On Sat, Apr 27, 2019 at 12:16:45PM -0700, S Moonesamy wrote: > > The draft does not make any change to the section about the Internet Society > President. Yes, I'm aware. > There is the following sentence in the Note Well: "By participating in the > IETF, you agree to follow IETF processes and policies". Signatories are > "expected to be familiar with the IETF processes and procedures, which are > readily learned by active participation ..." It is the up to a signatory to > show that he or she participated in those IETF meetings. That does not clarify the issue of "participation" at all. We can't have it be a criterion of eligibility if it does not have a well-defined public meaning. > Please see draft-sullivan-mtgvenue-decisions-00 as it discusses about > different types of attendees. I don't see how that is relevant. > From what I recall, it only took one appointee to negatively impact the work > of the administrative support activity. Russ explained why it was not > possible for the body to exercise the recall process option. Sure, and in the end we solved that problem and then did not actually have a problem gettinh the signatures together, from what I recall. In any case, the evidence is that we were in fact able to persuade the person to leave which meant that we didn't actually need to exercise the entire procedure. > There are 10 random persons who choose the so-called "leadership" each year. Actually, there are 10 randomly-chosen people from a pool of people who have been qualified from a well-defined meaning of having participated in the processes of the organization. Whether that definition is adequate might be up for debate, but it is a clear and complete definition, which is not what's in the current draft. > The persons do not have to have to participate on this mailing list even > though this is usually the place where IETF policies are discussed. What is > the difference between them and 10 random persons who participate remotely? One difference is how they are qualified. Another difference is that their decisions are subject to confirming bodies. A third difference is that they are selecting among possible candidates or none in a process that has multiple turn off points. > Is an accountability mechanism a way to hold the so-called "leadership" to > ransom? It can be, if it is poorly suited to purpose. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Apr 28 01:34:26 2019 Return-Path: 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 5CC091201AB for ; Sun, 28 Apr 2019 01:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=oi/IwWnf; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=TO8UW8hX 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 cufCylZu1-Td for ; Sun, 28 Apr 2019 01:34:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 592A31201AA for ; Sun, 28 Apr 2019 01:34:11 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.55.122]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id x3S8Xpvu007100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Apr 2019 01:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1556440446; x=1556526846; bh=SdojHr8WlRoHcWfOxxulQiIMGu1BpFuNI2xpAnplXcw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oi/IwWnfJcavOC6IoXXGozMzHYHpmqQ/0wJorhl/25KPFanDmKlkL4cjOVJex7S1+ rEtXKtHx+aY6SUwp6yXzj/YWmckhDd+pKuNvfRCrOZgJV4GFTwpR01LuE/isuhJq2G k0PPtM4Cbo0GqU4RRba9r2PaX4y4sAffTLgvYeNQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1556440446; x=1556526846; i=@elandsys.com; bh=SdojHr8WlRoHcWfOxxulQiIMGu1BpFuNI2xpAnplXcw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TO8UW8hXgH6+tY4iaFjMEpgn+Fj7Q93CmlorN1R3sk0Vu7K+wlLGXh5ey1pwuo73+ ikE4upUgHJT6pBYwn0Aos/rfZwU1y3ClIYVyMoHe47ooh/E6wWsPSi3sVhoRscsXVt FLFwEYLGl6f0hpu6jasFoBULxiLr7ZouYrNxv8gA= Message-Id: <6.2.5.6.2.20190428003615.0b9aebd8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 28 Apr 2019 01:27:31 -0700 To: Andrew Sullivan From: S Moonesamy Cc: eligibility-discuss@ietf.org, Adrian Farrel , John C Klensin In-Reply-To: <20190427221856.sxr46qr7j5niwrk4@mx4.yitter.info> References: <20190424201939.GM3137@localhost> <6.2.5.6.2.20190424134823.0c9faf68@elandnews.com> <20190424211123.GO3137@localhost> <6.2.5.6.2.20190424144539.0cabcde0@elandnews.com> <20190424234334.GQ3137@localhost> <11F97591808485C30AD98A22@PSB> <20190426150436.v4svwa67xja6267r@mx4.yitter.info> <0a1e01d4fc6c$10b93df0$322bb9d0$@olddog.co.uk> <20190427155921.i32pftxdbkvv7ist@isoc.org> <6.2.5.6.2.20190427094440.12099d10@elandnews.com> <20190427221856.sxr46qr7j5niwrk4@mx4.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 08:34:24 -0000 Hi Andrew, At 03:18 PM 27-04-2019, Andrew Sullivan wrote: >That does not clarify the issue of "participation" at all. We can't >have it be a criterion of eligibility if it does not have a >well-defined public meaning. There was a paper about "In-Person and Remote Participation Review at IETF: Collaborating Without Borders" [1]. The paper mentioned that "the remote participant was able to participate and interact by voice and text". There was a presentation [2] by the IETF Security Area Directors in which the following is mentioned: "IETF-wide meetings are held three times a year, participation can be in person or remotely". There is also an IETF Chair report [3] in which remote participation is mentioned. According to the IETF Chair, "We're getting good participation from our remote folks". > > Please see draft-sullivan-mtgvenue-decisions-00 as it discusses about > > different types of attendees. > >I don't see how that is relevant. The current discussion is about the criterion of eligibility. Please see below. >Actually, there are 10 randomly-chosen people from a pool of people >who have been qualified from a well-defined meaning of having >participated in the processes of the organization. Whether that There is "having participated" what you wrote. However, the definition used in RFC 7437 is about attendance. draft-sullivan-mtgvenue-decisions-00 discusses that in Section 3.2. Regards, S. Moonesamy 1. https://arxiv.org/abs/1805.09140 2. https://www.itu.int/en/ITU-T/Workshops-and-Seminars/ict-sec-chaldc/Documents/Presentations/S6P2%20Kathleen%20Moriarty.pdf 3. https://datatracker.ietf.org/meeting/103/materials/minutes-103-ietf-201811071730-00 From nobody Mon Apr 29 13:33:55 2019 Return-Path: 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 293FF12016A; Mon, 29 Apr 2019 13:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 n4D3eFyS5kGt; Mon, 29 Apr 2019 13:33:36 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12581200FA; Mon, 29 Apr 2019 13:33:35 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3TKXO79012343; Mon, 29 Apr 2019 21:33:25 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A897F22044; Mon, 29 Apr 2019 21:33:24 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 935FE22042; Mon, 29 Apr 2019 21:33:24 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.228.68]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3TKXNIc025488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Apr 2019 21:33:23 +0100 Reply-To: From: "Adrian Farrel" To: Cc: "'Andrew Sullivan'" , References: <6.2.5.6.2.20190424095017.13cdadc8@elandnews.com> <51068F13-E90F-42A2-8AE2-627D5E18B145@akamai.com> <20190424201939.GM3137@localhost> <6.2.5.6.2.20190424134823.0c9faf68@elandnews.com> <20190424211123.GO3137@localhost> <6.2.5.6.2.20190424144539.0cabcde0@elandnews.com> <20190424234334.GQ3137@localhost> <11F97591808485C30AD98A22@PSB> <20190426150436.v4svwa67xja6267r@mx4.yitter.info> <0a1e01d4fc6c$10b93df0$322bb9d0$@olddog.co.uk> <20190427155921.i32pftxdbkvv7ist@isoc.org> In-Reply-To: <20190427155921.i32pftxdbkvv7ist@isoc.org> Date: Mon, 29 Apr 2019 21:33:21 +0100 Organization: Old Dog Consulting Message-ID: <024701d4feca$c9fae920$5df0bb60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMb9m0E0UarrleNsIqsxdXzHaRPpgE9IEVTAV5K0TUCC3Cw1AGcBF9dAl+CA0cCP1Vv7wGfmKmvAgN5ZUoBSe399QGWOyuXozcoOMA= Content-Language: en-gb X-Originating-IP: 87.112.228.68 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24582.002 X-TM-AS-Result: No--20.062-10.0-31-10 X-imss-scan-details: No--20.062-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24582.002 X-TMASE-Result: 10--20.061600-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbLmR+C0l9vjVZa7LkubQvj/agsZM0qVv15OS w8t5HglHHmR//j0uskKl9Qu635f1KKHNozT622Z4XSKcwPTzq/IsCc2iFTIxrcM5LQWFwBdKSBv OV1d2isfW4QQu9bJ733+RiR0z4E6ckR56L2uUKWP6daZahG7qsUrCzBY4ZVGj+Cckfm+bb6Dk/S TXlNO1nlK50ScIKuW/B//la8VuHYYCdQeZ7qFiGTPDkSOzeDWWE3NxsGztrMuVOdKEtLXOZCxZE Jq+ukPCZqweXLgpmrZrAFiVMijft1GKFfTA3wZ+RsqQuQlRTh8R5c83KIxTThjQD3m2MCf7dmu5 Abn/U/uRKqZvxrWxLGiz3IFUtmP/njMUlhTO8+WXXOyNnX/prF5ALR9IgmTsLO3j+XDwlkOmRE7 f7OYxUod0LZL0rRWxXEPxV8mxOOblJVGNa7KLRCAFt0Rns3ahUXlp1FHYSPVtPXRTHBlYsIaPTn lFiCaK1+IZ+CvITcqvnk7fmgYwv0c/OrB7F0954Sd4Go/o60NY8mfhSYy5UjDJ9a3KikGoA4eV6 z+cHCfaFM5TPGLdCE6nIMfjRtNUdLTHjoswkhpt/kxH58njbxkqnRJng/51IQ4GXoHsAHW+Ru8Y +xhPef8RcEkM/eSJSWAGBUzMUE8wtv7QCGDWkry5hnFzVM+XcW+VwHmrYOWHwGEm+CpYGcOpfMZ V+vayfn118ITGa+Y2OrICH2A/Xqcfn+6/NDlnAEgqTc4LS4SSeMExjuIoEl6AkmKlDIzQ75T4BP uNkdqitiouylJVoAozQslBEGKeTQ6eVrUUN6yeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg/cUt5lc1lLgtT4piLWpY7p+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 20:33:39 -0000 Andrew, Apologies for a delayed response, I was working the last couple of days. Thank you for your time and careful thought. It's really insightful and helpful. And, of course, the care and effort you put into selecting Nomcom chairs is really appreciated - I suspect most members of the community just see it as "something that happens". I wonder whether we need to break up this discussion into different topics (threads?) so that the bleed-over doesn't get in the way of our conversation. I see a number of separate topics. Of course they are related, but I think we might try to keep them distinct as much as possible. We should qualify this with the knowledge that a recall is very-much a position of last resort, but with the understanding that the very existence of the possibility of a recall is an important part of the structure of the IETF. Just like appeals, a recall is an element that allows us to trust the operational management of the IETF. It is not the use of these mechanisms, it is their availability. The topics are: 1. Should members of the IESG and IAB (and other Nomcom-appointed people) be allowed to sign recall petitions? 2. Should seated Nomcom members be allowed to sign recall petitions? 3. How do we qualify "participation" at IETF meetings? 4. Should remote participants at IETF meetings be qualified to sign recall petitions? 5. What should be the number of signatories on a recall petition? 6. What is the right number of recall petitions? Let's run through these in some more detail. 1. Currently serving Nomcom-appointed people are excluded from being able to sign a recall petition. Several people have suggested that the IESG might be in a position to police itself, and it does seem that there might be cases where the IESG or IAB is uniquely positioned to know of issues that make a recall a realistic option. I don't suppose that adding two dozen people to the list of potential signatories makes a big difference to the potential of a recall being initiated. I don't see any harm in this change and there seems to be some small potential benefit. 2. Currently seated Nomcom members are allowed to sign recall petitions. There seems to be general agreement that this would be a poor idea subject to concerns about Nomcom confidentiality. It may be an oversight in the original specification and is easy to fix. It doesn't seem that this change would have a substantial impact on the pool of people who may sign a recall petition, and the clarification looks like a good idea. 3. There is another thread running about how we might qualify people as having participated in IETF meetings. Currently we judge this by looking for those who have registered, paid and picked up badges: there is no actual measure of participation. So there is a theoretical puppetry that could occur, but it comes at a price. For remote participants we have several tools available: registration and Meetecho logs are the most obvious; physical presence at a remote hub is also a possible. 4. I think that this whole thing started with consideration of whether we should give more attention to the rights of remote participants. Let's set this in a couple of contexts: - Nomcom qualification requires physical participation in 3/5 meetings with the belief that only people who have recent and full experience of the IETF can properly make decisions about what the community wants/needs. - All IETF decisions and the majority of discussions happen remotely (i.e., on mailing lists). - The IETF (supported strongly by ISOC) has been working to extend the level of remote participation through increased tooling and the establishment of remote hubs. Part of that process is intended to enable new people with the appropriate skills to be as active as possible in the IETF. Part of it is to enable participation from parts of the world where the cost of physical attendance at IETF meetings may be prohibitive. - The IETF has a strong ethos of non-discrimination: we work hard to make the only thing that counts be the reasoned discussion of technology. The IETF is well aware that it is not just the reality of fairness that counts, but the appearance of fairness. Considering these points, the current draft proposes to allow "qualified remote participants" to sign recall petitions. Obviously the question of qualification depends on point 3, and further discussion of that is necessary. But supposing we work out the element of qualification, the proposal seems to leave some concerns: - It is easier to have "fake" signatories than with physical attendance. This is true, but we have only very slight evidence that there has ever been any attempt to subvert any other part of the IETF process by these means, and they are equally vulnerable. I conclude that the risk is both manageable and small. Furthermore, if this ever became a problem, it could be addressed by a subsequent reversal of the proposed change. - There would be an increase in the pool of qualified signatories and so an increase in the number of petitions. I don't think much effort has been put into working the numbers here: I think I saw a count of 700 Nomcom-qualified people, all of whom can currently sign a petition. IIRC we have around 400 remote participants at any one IETF meeting, so we could *guess* that that might yield another 200 potential signatories. Of course, given that we have never had a recall committee formed, it is hard to guess what impact this change would have 9/7 of nothing is still nothing. - Participants who have only attended remotely don't fully understand the IETF and are not in a position to make requests for recall. This case can certainly be argued as it is for Nomcom, but it is also true that (unlike Nomcom) the signatory of a recall petition is not making any fundamental change: that change is left to the recall committee. What this boils down to, then, is that there may be more work to do in terms of more petitions to handle. That argument can be looked at several ways: - If petitions are needed, then having them is a good thing - Each properly formed petition requires a recall committee and chair: that is work to set up and administer, and a strain on the ISOC President - There is a risk of attack that could be harmful although we have no reason to believe we will be attacked, and we do understand how to shut it down if it happens. 5. Once upon a time the number of signatures required for a recall petition was 1. There were no attempts at recall, but this was increased to 20. There may be no value in researching why that change was made and why the number 20 was selected. To me it seems that 1 was a fragile situation in a growing organisation, but that 20 reflects an abundance of caution. We have never had a recall and that could be because we have never needed one or because it has been too hard to form one. I'm not sure that discussing that point will get us anywhere but if we continue to not need any recalls, then lowering the number will not matter, while if it has been too hard, lowering the number of signatures needed will help. Of course, the risk is that lowering the number makes us vulnerable to recall petitions that have to be serviced. If they are valid, that is a price we have to pay for good governance. I would argue that if the petitions had a good case to answer but did not lead to a recall, that would still be good governance. If it led to a number (any number) of frivolous, fatuous, or otherwise spiteful petitions, then we would have empirical evidence that increasing the number to 20 again would be wise. 6. You said, "In order to show that you need a threshold change, you'd need an argument that there was a case that should have caused a recall, but that didn't because the threshold couldn't be met." I doubt that this is a conversation that can be had on a public mailing list: we don't want to open up the horrors of trial in the court of public opinion. And it is pretty likely to be anecdotal in any case. But, as I said above, the right number of actual recalls is the number we actually have: I someone needs to be recalled then they need to be recalled. And part of the price of getting that right is having a recall process that can be started and executed even if it doesn't always deliver. The cost of having no recall process or one that is hard to execute is that we lose credibility for having sound governance. One last point from me that might be applicable to the discussion of fractiousness. I don't think any of this discussion comes about because anyone is trying to form a recall petition. I don't think there is anyone expressing such extreme discontent or agitating to remove anyone. To the contrary: the best time to discuss and work on the backstop procedures is precisely when they are not needed. Could all or some of this be put into a/the draft? Unquestionably. Is the current draft perfect? No, but it is an early revision. Should the ideas be split into separate drafts? Well that all depends on how smoothly the discussion goes since history teaches us that the IETF is very good at using one issue to block progress on the resolution of other issues. Let's move forward. But you raised one other point. That we shouldn't look at anything that makes the process for starting a recall easier without also looking at the whole procedure. I think the two can be decoupled, but I also think that if you have concerns about the recall procedure (and clearly not just limited to your responsibility to appoint a recall committee chair) you should document them (probably in a draft) so that we can all work on them. Thanks, Adrian >> Well, doesn't the draft offer three areas of concern, and address >> them with specific proposed changes: >> - Eligibility of IAB and IESG members and other Nomcom appointees > > It simply deletes this consideration, yet it quite explicitly notes > how unseemly it is that an appointing nomcom member could > participate. > So it doesn't address the issue it raises. > >> - Eligibility of remote participants > > Only sort of. It allows registered remote participants to count > (good) but then sets up a rule in which people "have participated > physically or remotely" without defining that term. If ever there > were an opportunity for confusion and arguments over what constitutes > "participation", I'd like to hope that its first official duty would > not be in determining how we pick everyone else to manage the > organization. The existing arrangement is quite clear: you register > for and attend the meetings. The new proposal adds a notion of > participation that is at least in serious need of unpacking. > >>> The main thing it does is make the procedure >>> easier to start, but it also doesn't adjust the procedure at all. >> >> I think that questioning the first of these has an interesting oppositional >> view: do you propose making it *harder* to start the procedure? Perhaps we >> could say all signatories must have first names starting with the letter A >> :-) > > I think this is a false alternative: it simply doesn't admit of the > possibility that the _status quo_ is ok. In any case, no, I do not > propose making it harder. What I oppose is making it easier without > thinking about the procedure itself. > >> But seriously, what in the last n years suggests that starting the >> procedure has been "easy enough"? Have we already been overrun >> with recall petitions? > > This puts the burden of proof entirely in the wrong place. In order > to show that you need a threshold change, you'd need an argument that > there was a case that should have caused a recall, but that didn't > because the threshold couldn't be met. To show _that_, you'd at least > need a definition of "should have caused a recall" that was > uncontroversial. None of that argumentation has been made. Without > it, I don't understand why anyone argues for a change in the required > number. > > In other words, we have no evidence whether the procedure is "easy > enough", but we have exactly the same evidence that it is hard enough > or too hard. It seems to me that most of the IETF wants to get their > work done, and that they'll do that under many circumstances until the > structure is manifestly unfit for purpose, at which point finding 20 > people ought to be a trivial hurdle to clear. > > This is also completely unrelated to the question of equity for remote > participants, which AIUI is what got all this going. > >> That is true. And it must be weighed against the damage caused by an >> unaddressed need for a recall. >> We actually don't have any evidence on either side of this issue and so must >> aim to strike a balance letting it be "reasonably" possible to start a >> recall process > > I am not sure what to make of a defence of a change in the rules that > starts with the proposition that there is no evidence for any of it. > I will certainly grant the proposition that there is evidence neither > of a need to change nor of adequacy of the current arrangement. > >> We have no knowledge of how this works. But if I was on a recall committee >> and the petitioners sent me mail to say that they had changed their mind, I >> might talk to them and possibly conclude that the petition can be deemed to >> have failed. > > You might do anything at all, of course, and another person might do > something else yet again. The point is that good organizational > procedures intended to be triggered frequently ought to be well > understood. The current draft proposes that 10 random people who sign > up for free remote participation 3 times and "participate" in some > unspecified way can hold the entire IETF so-called "leadership" to > ransom, and we have no idea how those demands would be processed. It > seems like the sort of decision that requires careful community > deliberation. I don't see that this document has reached that > threshold. > >> I tend to believe that resistance to fractiousness is best achieved by open >> accountability. > > And yet, here we are. We have an organization that by any measure is, > compared to just about anything I can name, super open and > accountable. Yet it appears to be beset by fractiousness. One might > be forgiven for thinking that the effort to lower the threshold for > recall signatures is an effort that will aid that fractiousness. > >> For the other points we could consult some people a little older than us. >> Was it an abundance of caution or a deliberate attempt to make it "too hard >> to execute"? > > Experience by scholars of history suggests that asking people who did > a thing why they did it will quite often (but unpredictably) yield > justifications that were not made explicit (or were even contradicted) > at the time the thing happened. We cannot invite the testimony of > those who were there; we can invite only the testimony of those who > remember being one of the people there. Memory is imperfect. > >> But, assume there is a real need for a recall: in that case, I guess you >> would be more than pleased to appoint a recall committee chair. > > No, but I would do my duty. > > It is a _lot of work_ to find a nomcom chair. I have to canvass a lot > of people. I have to describe what I'm looking for. And I have to > use such reputation as I have to cajole people into accepting. > > A recall chair would be more contentious without the upside of the > nomcom chair (e.g. that one appointed the right person). So it is not > clear to me how easy it will be to fill this position, and that seems > like something we ought to take into account if we are going to make > it easier to trigger this procedure both by increasing the class of > people who can participate in the triggering and by lowering the > numbers needed. > >> And, since there is a potential for a recall petition at any time > > Sure. My very point was that the draft made that situation easier to > happen without evidence about why such a change ought to happen. > >> Do you have some suggestions for a vermicide? > > No, but it seems to me that this is a good example of why a WG needs > to work on this. > >> I think applying "the right care" is absolutely spot on. > > I'm glad we're in agreement. > >> I disagree with you about a recall petition being a nuclear option. > > Lots of people do. But a one-step procedure that moves from "20 > people support this" to "committee decides to fire or not" without > intermediate steps is the sort of thing that works well when there are > lots of informal, functioning ways for people to come to agreement. > The excitement among some to reduce the threshold of signatures needed > to invoke this procedure suggests to me that the informal, functioning > ways may be fraying under current community strain. From nobody Tue Apr 30 10:50:40 2019 Return-Path: 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 4368212032D for ; Tue, 30 Apr 2019 10:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RvGHjmQh0ugl for ; Tue, 30 Apr 2019 10:50:29 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 4FB2C12031E for ; Tue, 30 Apr 2019 10:50:29 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id v143so6175529itc.1 for ; Tue, 30 Apr 2019 10:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HJvoFnHkSo79nlwKkfbUcTO0LX03Etx3j6zRX948Wrs=; b=AfmD26kyuZDe+cRkkYoCwQEhNK88F+W2hFcfaerzjMJV1sy1vRcQ45MsOyz3zGWbwM odaE2gfPZ8ay9JJ4SLJsF9Lsl5BN7kcSzxTWzf+QnygdYWL+9ZWqBU4qYhVRCztEXm/b 6ghNX2c8anis3TaZRr1Y4WR7Qs+Ts7X1vDPVOfVB2CAYNm217g4qKAFqByPLp11cm7TR mJDrQDJLtfYCpxypKlJhX2dh/Vs1rNFpG5Ps/mBw9xbZUtjSBEnMTHzN5WokxlOixReC YRV0l55DEJZfvtWw6HgNfLaexDja28A6JEZX0qJffainP0DiA97PqgjcJ1OacvTlpf6Z xgLg== 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=HJvoFnHkSo79nlwKkfbUcTO0LX03Etx3j6zRX948Wrs=; b=Dkcy40u63G/H57Bjf6dAoVkkRmHceYbL8+V77XOqZxRPHy5AEb2Bwa9rsjvA+S5tRW Jh6k+nYb3yZltL9T5qwgT8SBlyHXE7wrLgzxz7aMqxMnccnMfqMCo1RcCOp4KMBK4APs Dv8EyexSU/VuphwcroxPjfT+PxLqdYHSSvZSR7QRBIlls88IQCcJx7kGU0uIVKV+7DlZ P/2GW+zoJ3DWuZPMxNAPgsXDzPIAUWfz8Pb8urLTelTbgUPRXEagwsDUQjgRew9O0ozY 4dksIwiqp9Fj1/r+x3GdnT5yMR3Ot2tBxUXNphgPk49r9xO5QsTAtdT9U00eDQUIKC/k DYEQ== X-Gm-Message-State: APjAAAVXdXe90jy+4jCpYGsS5pjMl88zCU8DQf92uf+ZNheh7met3fUC hE/xtf4w2i5uSrraOlNxsYln+aqigLJNvv+rK9NAfulS X-Google-Smtp-Source: APXvYqzBS7apiNZJqx+rfAgj4/ASLsCwADhQM/YGvb1FRFCRh33udcQbUW+m+smKQVNBcQmcd0QQyfLE17KPUI8Ud5A= X-Received: by 2002:a24:6252:: with SMTP id d79mr4687058itc.100.1556646628553; Tue, 30 Apr 2019 10:50:28 -0700 (PDT) MIME-Version: 1.0 References: <6.2.5.6.2.20190424095017.13cdadc8@elandnews.com> <51068F13-E90F-42A2-8AE2-627D5E18B145@akamai.com> <20190424201939.GM3137@localhost> <6.2.5.6.2.20190424134823.0c9faf68@elandnews.com> <20190424211123.GO3137@localhost> <6.2.5.6.2.20190424144539.0cabcde0@elandnews.com> <20190424234334.GQ3137@localhost> <11F97591808485C30AD98A22@PSB> <20190426150436.v4svwa67xja6267r@mx4.yitter.info> <0a1e01d4fc6c$10b93df0$322bb9d0$@olddog.co.uk> <20190427155921.i32pftxdbkvv7ist@isoc.org> <024701d4feca$c9fae920$5df0bb60$@olddog.co.uk> In-Reply-To: <024701d4feca$c9fae920$5df0bb60$@olddog.co.uk> From: Loganaden Velvindron Date: Tue, 30 Apr 2019 21:50:16 +0400 Message-ID: To: Adrian Farrel Cc: eligibility-discuss@ietf.org, Andrew Sullivan Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:50:34 -0000 On Tue, Apr 30, 2019 at 12:33 AM Adrian Farrel wrote: > > Andrew, > > Apologies for a delayed response, I was working the last couple of days. > > Thank you for your time and careful thought. It's really insightful and > helpful. And, of course, the care and effort you put into selecting Nomcom > chairs is really appreciated - I suspect most members of the community just > see it as "something that happens". > > I wonder whether we need to break up this discussion into different topics > (threads?) so that the bleed-over doesn't get in the way of our > conversation. > > I see a number of separate topics. Of course they are related, but I think > we might try to keep them distinct as much as possible. We should qualify > this with the knowledge that a recall is very-much a position of last > resort, but with the understanding that the very existence of the > possibility of a recall is an important part of the structure of the IETF. > Just like appeals, a recall is an element that allows us to trust the > operational management of the IETF. It is not the use of these mechanisms, > it is their availability. > > The topics are: > > 1. Should members of the IESG and IAB (and other Nomcom-appointed people) be > allowed to sign recall petitions? > 2. Should seated Nomcom members be allowed to sign recall petitions? > 3. How do we qualify "participation" at IETF meetings? > 4. Should remote participants at IETF meetings be qualified to sign recall > petitions? > 5. What should be the number of signatories on a recall petition? > 6. What is the right number of recall petitions? > > Let's run through these in some more detail. > > 1. Currently serving Nomcom-appointed people are excluded from being able to > sign a recall petition. Several people have suggested that the IESG might be > in a position to police itself, and it does seem that there might be cases > where the IESG or IAB is uniquely positioned to know of issues that make a > recall a realistic option. I don't suppose that adding two dozen people to > the list of potential signatories makes a big difference to the potential of > a recall being initiated. I don't see any harm in this change and there > seems to be some small potential benefit. > > 2. Currently seated Nomcom members are allowed to sign recall petitions. > There seems to be general agreement that this would be a poor idea subject > to concerns about Nomcom confidentiality. It may be an oversight in the > original specification and is easy to fix. It doesn't seem that this change > would have a substantial impact on the pool of people who may sign a recall > petition, and the clarification looks like a good idea. > > 3. There is another thread running about how we might qualify people as > having participated in IETF meetings. Currently we judge this by looking for > those who have registered, paid and picked up badges: there is no actual > measure of participation. So there is a theoretical puppetry that could > occur, but it comes at a price. > For remote participants we have several tools available: registration and > Meetecho logs are the most obvious; physical presence at a remote hub is > also a possible. > I help organize an IETF hub in Mauritius. However, most of the participants of our hub tend to be around 16-22 years old. Their interest leans more towards implementation rather than contribution to working group specs. Does remote ietf hackathon count as participation if running code is available at the end ? From nobody Tue Apr 30 15:46:06 2019 Return-Path: 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 E7BC812031D for ; Tue, 30 Apr 2019 15:46:04 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=AS9BLW30; dkim=pass (1024-bit key) header.d=yitter.info header.b=H1ErZOzp 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 kPmVO3NBLoEn for ; Tue, 30 Apr 2019 15:46:02 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34751200A0 for ; Tue, 30 Apr 2019 15:46:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D0932BCC66; Tue, 30 Apr 2019 22:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1556664361; bh=OjCvXxR1XX9dZggVw8DhYJlRAiyBNKpKBhpqq/QVJmQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AS9BLW30h8Pf1XxULnUeGNH3nYJ6nqJhtu3gQ6rCQHB//hw5jlbpbSpVK7tm9+MtT ct3t+BIWgFjKTmB41Q8mkcKr1DhR4xjcIuVgLY4YJ6YXcQhHNcU7KXxD+pKWOkUbR6 iDLmVHDX0gFQk2HnIh3IXLYtRcoCfPH/Fa2OEjRc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ROxi6tBfPA; Tue, 30 Apr 2019 22:46:00 +0000 (UTC) Date: Tue, 30 Apr 2019 18:45:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1556664360; bh=OjCvXxR1XX9dZggVw8DhYJlRAiyBNKpKBhpqq/QVJmQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=H1ErZOzp3hLjKWQkntpnIzF0VSKp1SPc/27u52t7ldGnP/0qywKfBWuInC6ENZg+j ch5tjqp/ZMqd7VRmULTmBhWCxIWtE51r6GcGk2SKZpMaF4QtinRKsugG8GyL1v3JfK Eq6OX1kNkNjVsbCMkVG36KiI6VVnC99ylac+7UwM= From: 'Andrew Sullivan' To: Adrian Farrel Cc: eligibility-discuss@ietf.org Message-ID: <20190430224557.gxbfioixczabatnz@mx4.yitter.info> References: <20190424201939.GM3137@localhost> <6.2.5.6.2.20190424134823.0c9faf68@elandnews.com> <20190424211123.GO3137@localhost> <6.2.5.6.2.20190424144539.0cabcde0@elandnews.com> <20190424234334.GQ3137@localhost> <11F97591808485C30AD98A22@PSB> <20190426150436.v4svwa67xja6267r@mx4.yitter.info> <0a1e01d4fc6c$10b93df0$322bb9d0$@olddog.co.uk> <20190427155921.i32pftxdbkvv7ist@isoc.org> <024701d4feca$c9fae920$5df0bb60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024701d4feca$c9fae920$5df0bb60$@olddog.co.uk> Archived-At: Subject: Re: [Eligibility-discuss] AD Sponsorship of draft-moonesamy-recall-rev X-BeenThere: eligibility-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 22:46:05 -0000 Hi, I dropped ietf@. No hat. Apologies for the short post, but I'm unfortunately quite pressed for time this week & can't devote the cycles to this it deserves. But I think there's one critical point I ought to make. On Mon, Apr 29, 2019 at 09:33:21PM +0100, Adrian Farrel wrote: > I wonder whether we need to break up this discussion into different topics > (threads?) so that the bleed-over doesn't get in the way of our > conversation. We could definitely figure out a way to tease these different issues apart. Nevertheless, I think the overall point I was originally trying to make is amply demonstrated: > The topics are: > > 1. Should members of the IESG and IAB (and other Nomcom-appointed people) be > allowed to sign recall petitions? > 2. Should seated Nomcom members be allowed to sign recall petitions? > 3. How do we qualify "participation" at IETF meetings? > 4. Should remote participants at IETF meetings be qualified to sign recall > petitions? > 5. What should be the number of signatories on a recall petition? > 6. What is the right number of recall petitions? This is a list of topics of sufficient breadth and sensitivity that I think it needs unpacking and exploration. I am not sure I agree with your conclusions about obvious changes, but that's the sort of discussion that I think is best had across the community. And that was really the point I was originally trying to make: this requires the kind of care this community takes when it is going to make sensitive or fundamental changes. The way one does that in the IETF, usually, as I understand it, is to form a working group, so that seems to me to be the best path for this. > One last point from me that might be applicable to the discussion of > fractiousness. I don't think any of this discussion comes about because > anyone is trying to form a recall petition. I don't think there is anyone > expressing such extreme discontent or agitating to remove anyone. To the > contrary: the best time to discuss and work on the backstop procedures is > precisely when they are not needed. I could not agree more, and I think it would be entirely correct that now, at a time when the IETF has started to work out its new path for administrative arrangements and with a newly-arrived IESG, the WG to undertake this effort be formed and get to work. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com