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

S Moonesamy <sm+ietf@elandsys.com> Sat, 20 April 2019 06:18 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCE31200FF; Fri, 19 Apr 2019 23:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.774
X-Spam-Level: *
X-Spam-Status: No, score=1.774 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, RCVD_IN_SORBS_WEB=1.5] 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=uC1hmc+x; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=Iisy84FS
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 nEw9SpCsUL-S; Fri, 19 Apr 2019 23:18:01 -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 0BB821200D6; Fri, 19 Apr 2019 23:18:00 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.55.174]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id x3K6Hhar001642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Apr 2019 23:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1555741078; x=1555827478; bh=963olglkZLoPdhCTqFjNA4MB3BzxHKcSu9rydDtNsLE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uC1hmc+x9sOpAl4cMJrfZkTRMR9+I/OkrzHjyUdWr4v6Mv4mmuh6EchGgx6UPGmdI 68GQbO9tixQafYx+HXlV/B9ad5sD7qIaNa3CAPOLARSMX4f8fR+Gb9jdu6LwFvv2dH I0VoyLQbPd8X9YN1KQGj7d9rp5auhGyQx8iklx4M=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1555741078; x=1555827478; i=@elandsys.com; bh=963olglkZLoPdhCTqFjNA4MB3BzxHKcSu9rydDtNsLE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Iisy84FSH5TnZViZWn4CLjNW0l8X8h6RnfaJ/gVUgK+cvEDlPHkKFWSgF85LlDNOg BN0XwOp1VT1yZz9OwBemr3ktHuvJIJIKabFAc77DFhrHxjSTVFbankmSn1QyvxXyHb s4CN9sCdxrzmFe0x/gLEd03T5r3tgYixfnyugsMw=
Message-Id: <6.2.5.6.2.20190419223655.108e5998@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 19 Apr 2019 23:07:46 -0700
To: iesg@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: AD Sponsorship of draft-moonesamy-recall-rev
Cc: Aaron Falk <aafalk@akamai.com>, Adrian Farrel <adrian@olddog.co.uk>, ietf@ietf.org
In-Reply-To: <A18C5417-F40B-4DC4-B6AB-BA0A592D15D3@cooperw.in>
References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <033d01d4f52f$c6f2dca0$54d895e0$@olddog.co.uk> <BB40F115-46E8-4EF3-ABDE-15ABB33B4ACA@akamai.com> <C11980900F520E0EFCC83CEB@PSB> <A18C5417-F40B-4DC4-B6AB-BA0A592D15D3@cooperw.in>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ns2jC7WoS6v1PC4-maXKJhuuEN8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Apr 2019 06:18:02 -0000

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.
>
>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.

 From what I understand, the governance part of the IETF is done by 
the IETF LLC.  The draft does not get into IETF LLC matters.  A 
person conversant with corporate affairs would likely understand the 
legal aspects of that.

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'.

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?

>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.

Does the above mean that the Internet Engineering Steering Group 
(IESG) is aware that BCP 78/79 can be easily "gamed"?

Regards,
S. Moonesamy