Re: [Iasa20] Memo exploring options for IASA 2.0 models

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 15 February 2018 00:01 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC0A126DFB for <iasa20@ietfa.amsl.com>; Wed, 14 Feb 2018 16:01:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 5_i7xSLI_l-3 for <iasa20@ietfa.amsl.com>; Wed, 14 Feb 2018 16:01:02 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4DD126C22 for <iasa20@ietf.org>; Wed, 14 Feb 2018 16:01:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9F009BE51; Thu, 15 Feb 2018 00:01:00 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIe32b_9_eu5; Thu, 15 Feb 2018 00:00:59 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E0B9FBE39; Thu, 15 Feb 2018 00:00:58 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518652859; bh=YTXSORQDC30w5Xfuxxh3yfubxwJcrBKTtvAwdzF5nME=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=3M+XNrghoo9Y6kP3iMwsR9k4DZlx17wXLayIE30iQ+Ek8pbLZlvwER/zqHPKQZSnu WI7aHzgz7vBb56kqvGCDXTjQb0ETdK5CANUM1mn3KKHB3vPlQMpnqRxTt8yyQ7ap04 rSPwjPz5PSJrP325us6fZBlWoCy3IyUWZKjU/XFU=
To: Joseph Lorenzo Hall <joe@cdt.org>
Cc: iasa20@ietf.org
References: <4483006c-1652-7340-19f8-8d0579af8213@cdt.org> <ac8f3a00-b22a-ff84-ba81-14e824697148@cs.tcd.ie> <CABtrr-Wo7Laxvcvf+rwJ9Yip9-T78tA2dGqborcWd4gt1FM9eQ@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <059560d3-d697-7057-61ed-dd60d2e39e40@cs.tcd.ie>
Date: Thu, 15 Feb 2018 00:00:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CABtrr-Wo7Laxvcvf+rwJ9Yip9-T78tA2dGqborcWd4gt1FM9eQ@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="TWByqQCIz3TEH8EFP1DJhCFqwARLIwJVV"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/xj3ZY3G6qfqwpU9Zwa_add9ZkMg>
Subject: Re: [Iasa20] Memo exploring options for IASA 2.0 models
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Feb 2018 00:01:05 -0000

Hiya,

On 14/02/18 23:48, Joseph Lorenzo Hall wrote:
> No, we haven't explicitly considered that and this is definitely specific
> to US law. Are there promising hybrids you'd suggest, 

Not doing it would be my "hybrid" suggestion:-)

> or is this just to
> point out (rightly) how complex the design space is?

That, but also to point out that "investigate only US-based"
would itself be a decision that'd need to be made, presumably
before significant effort was devoted to US-based scenarios
for new organisational structures. So it's not just a complex
design space, but also one where there could be numerous points
at which consensus calls would be needed, each of which has
the potential to be tricky, even with everyone on the same
page, more-or-less.

S.


> 
> On Wed, Feb 14, 2018 at 18:44 Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> 
>>
>> Hi Joe,
>>
>> I'm generally not in favour of most of the "forming a
>> new organisation" propositions, but am nonetheless
>> curious as to why all of the options here are US-based.
>> Did the DT not consider any other jurisdictions?
>>
>> Sorry if I'm forgetting if that was previously discussed,
>> and it'd be entirely reasonable if this is considered the
>> easiest thing to check first, but I wondered.
>>
>> Ta,
>> S.
>>
>> PS: One of the reasons I'm not that much in favour of
>> the "forming a new organisation" options is that that'd
>> lead to a bunch of questions like the jurisdiction one,
>> each of which may take some time to handle.
>>
>> On 14/02/18 23:29, Joseph Lorenzo Hall wrote:
>>> Greetings,
>>>
>>> I am writing on behalf of the IASA 2.0 Design Team to update you on
>>> progress since Singapore.
>>>
>>> The Design Team and Alissa, Sean Turner, and Richard Barnes (ISOC Board
>>> members) asked ISOC's tax law counsel at the law firm Morgan Lewis to
>>> examine the options we are considering in a new IASA 2.0 structure, in
>>> terms of governance, finances, and administrative complexity.
>>>
>>> The response memo is attached, covering the spectrum of options from the
>>> status quo to increasingly independent models. The memo covers four
>> options:
>>>
>>> 1. Substantial independence: an independent 501(c)(3) org;
>>> 2. Significant independence: a 501(c)(3) Type 1 Supporting Org;
>>> 3. Weak independence: an LLC that is a "disregarded entity"; and,
>>> 4. Status quo: continuing as an activity of ISOC.
>>>
>>> Note that the design team has some additional questions that we hope to
>>> clarify including the implications of the public support test, board
>>> composition and control, and potential costs (sunk/ongoing) of a
>>> transition to each model. We'd like to hear from all of you as to your
>>> thoughts, either in terms of clarification or if this analysis affects
>>> which model you prefer.
>>>
>>> If questions emerge around particular themes we can work with ISOC on
>>> clarifications.
>>>
>>> thank you,
>>>
>>> Joe (writing on behalf of the DT)
>>>
>>>
>>>
>>> _______________________________________________
>>> iasa20 mailing list
>>> iasa20@ietf.org
>>> https://www.ietf.org/mailman/listinfo/iasa20
>>>
>>
>> --
>> PGP key change time for me.
>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
>> NewWithOld sigs in keyservers.
>> Sorry if that mucks something up;-)
>>
>>
>>
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa20

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)