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

"Leslie Daigle" <ldaigle@thinkingcat.com> Fri, 16 February 2018 21:56 UTC

Return-Path: <ldaigle@thinkingcat.com>
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 6C670124205 for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 13:56:34 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 ZdeWXe8E1qrC for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 13:56:25 -0800 (PST)
Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA401241F3 for <iasa20@ietf.org>; Fri, 16 Feb 2018 13:56:25 -0800 (PST)
Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 0EE54201702C8; Fri, 16 Feb 2018 13:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=d /PJI7ZLxNkXKrt0P1LBID5GyaI=; b=M3TaTMzU9M8il4cM0olHFbMQXvIu0tJfX uYXfZ7fJbSFzlSoxbc4CcztgMTH/pK3LmKBiVcBuhJlzoGDvudLRaxjpbkmZgIyE Hji4e/fjzKF0XPqUA1MFVhwzsRfp8nYq09NSlWcfkYzjL5+84Ahp87xTxWoXKUBA OWgD1VuFMY=
Received: from [192.168.1.94] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 6D687201702C2; Fri, 16 Feb 2018 13:56:24 -0800 (PST)
From: Leslie Daigle <ldaigle@thinkingcat.com>
To: iasa20@ietf.org
Date: Fri, 16 Feb 2018 16:56:22 -0500
X-Mailer: MailMate Trial (1.10r5443)
Message-ID: <D1766267-C86B-4BF0-AE20-BAEF0AC921F1@thinkingcat.com>
In-Reply-To: <0ac3fbe1-aab6-a32a-951e-a9211ac14ab8@cs.auckland.ac.nz>
References: <4483006c-1652-7340-19f8-8d0579af8213@cdt.org> <ac8f3a00-b22a-ff84-ba81-14e824697148@cs.tcd.ie> <CABtrr-Wo7Laxvcvf+rwJ9Yip9-T78tA2dGqborcWd4gt1FM9eQ@mail.gmail.com> <0ac3fbe1-aab6-a32a-951e-a9211ac14ab8@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_9AFC780B-4B7F-444C-8912-56D0E9E0429C_="
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/WrW13Odf0Unnbhjrl0JSAa0g0vI>
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: Fri, 16 Feb 2018 21:56:34 -0000

At the session in Singapore, we reviewed the categories of problems the 
IETF faces today with its administration, and outlined the possible 
paths forward in general detail.

My personal perspective is:  the design team has reviewed the 
requirements and does not see a way to meet both the IETF’s stated 
challenges and ISOC’s admitted desire for the relationship to evolve 
without creating a new organization with some relationship to ISOC.

I think the useful discussion going forward has to focus on one or some 
of:

1/ A better option (separate organization or not) that addresses all the 
issues and considerations brought forward (e.g., in Singapore) at least 
as comprehensively as these proposals do.

2/ Ways in which these options are somehow internally flawed and can 
themselves be improved.

3/ Additional insight into why one of these models is better than the 
others expressed herein.

Saying “I don’t want a new organization”  is informative, but not 
normative, at this point.

Change is going to happen.  It’s going to be complex, and it is going 
to take work.  And it’s going to take onward discussion to make sure 
it gets implemented and continues to function to the needs of the IETF.




Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------

On 14 Feb 2018, at 20:25, Brian Carpenter wrote:

> I'm with Stephen, setting up a new org of any kind is unnecessary
> and costly (in many ways). But absolutely certainly if we did go that
> way, setting it upoutside US jurisdiction must be considered and is 
> probably
> preferable. Switzerland or the Netherlands are two obvious choices, 
> but
> of course the field is broad.
>
> Regards
>    Brian Carpenter
>    Department of Computer Science
>    The University of Auckland
>    http://www.cs.auckland.ac.nz/~brian/
>
> (I am currently sending all mail from this address
> due to a Gmail bug. I can still receive via Gmail.)
>
> On 15/02/2018 12: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, or is this just 
>> to
>> point out (rightly) how complex the design space is?
>>
>> 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
>
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20