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

Richard Barnes <rlb@ipv.sx> Fri, 16 February 2018 18:35 UTC

Return-Path: <rlb@ipv.sx>
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 B3793126C2F for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 10:35:24 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 zYWYA6ckj6t3 for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 10:35:20 -0800 (PST)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 BDA531200C1 for <iasa20@ietf.org>; Fri, 16 Feb 2018 10:35:19 -0800 (PST)
Received: by mail-wr0-x234.google.com with SMTP id n7so3825010wrn.5 for <iasa20@ietf.org>; Fri, 16 Feb 2018 10:35:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jg16ZRAYypExWoBqg0tkmIu5xF9AWlN8F5CVsBQaujg=; b=ipurM2lLbIHbZY5uu990JR78IiqMtLufOFjKLel+vYLiQLL7G4fGLnf0W8pSpYfDE/ aoWdswQty8/J1dqk0AaPT5BThsykaNMXxndov8tDKcbz1+sygUf70OKsqhsEQggxDxD3 7QOxs6cfKYCpcjTCaJfoNE1Y0peBJpGzCKrgyrLux2odTrKdjoU+xAPndPNfCqArLFwU V8toI51rL+OhsmAP092koicaxg+3xVTB2rTXMa7EWglvsiPR3DbcJ6040MVwd1wtDc0D FzbGtpA/A8jcq067cdhjzceQrEMT2qV9TnN7SNs8opVVH/xTPSNHJ7xI06y/a0KMoWtw V/sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jg16ZRAYypExWoBqg0tkmIu5xF9AWlN8F5CVsBQaujg=; b=fI9QRg8odN6Qjuc9D5LefUcbQPmmMrl9Veri6kwdEvsvEQy9PRKqwPRHAbESHNDIQw TKSqrq1TAFbj0n3lukuuTimpFYSAfS9QqO4tNZbC9ag+8cnx9aTFhuThTq4+XBRwAS9/ zLxrb2mQxuX2tBXRw/DqMi7LSGIajRA8afaYZHSRLS+s7wg7wKcr27udgdjArmmwA0y8 lp4bfreLwl+8sKov6wSy6JTTFecsnLaGkqJW5Hr7jzEx3eLVnsNkcRomGBOyxDDKrIzp PrNt5w7FBiT0oioJ1Mc7/+XghoMwDJkkuWv5U1twtN2J+Py+H/UtYNJfHUNMrh9S9Eeq 9pvw==
X-Gm-Message-State: APf1xPBqg6ptKXF4evoveOcLZy5IbTa0tFY+cTJbFj8kHXLfb5QgVFX1 lXgIE02/CHtfRyUCGXC7I7ugsz6hOKq87+/slnDWzp0z
X-Google-Smtp-Source: AH8x224tNLbWv8XmeZFwHjgvx03P64krjZa0MrgbsnYGu6h97JZG3qUC5XRYUctst0jBDppkYfoJZpHNcUjsvoGAeBA=
X-Received: by 10.223.188.134 with SMTP id g6mr6263909wrh.140.1518806118063; Fri, 16 Feb 2018 10:35:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.20.66 with HTTP; Fri, 16 Feb 2018 10:35:17 -0800 (PST)
In-Reply-To: <CA+9kkMD2YpkPjCEiSGFMAY+w_U6FRYTXoBvMxzEj7AUdw0PLSA@mail.gmail.com>
References: <4483006c-1652-7340-19f8-8d0579af8213@cdt.org> <CA+9kkMBK0YzWmVZqFnRuzKj_mTZeSHy4xhZSgrjjNr7NnO68DQ@mail.gmail.com> <CABtrr-V88xYcRDNMDz8aH_6Jq-fvtDLMwpYxxXFxLZv-S25SSg@mail.gmail.com> <CAL02cgQu-zi_FySTsDX_HbPOt+FrFYypSvPLwY8QfnfffR3QrQ@mail.gmail.com> <CA+9kkMC_BjV4DdxNSk5LrgR0uU1vVF3YDyqobFYc7-t_idx60w@mail.gmail.com> <CAPdOjkhqQiqgeWUeMRb-Q3MzKtk=fEYxzQdmaaWoaGvZsQ8+Bg@mail.gmail.com> <CA+9kkMAQijV+vFZXosFPT3tFen_Azjitjdf=cEEKz2ZRc+tbqQ@mail.gmail.com> <CAL02cgQFg+XVnhKW8FveHv11ZrL85R4Ddjj1T8t00QwR2B3k4Q@mail.gmail.com> <CA+9kkMD2YpkPjCEiSGFMAY+w_U6FRYTXoBvMxzEj7AUdw0PLSA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 16 Feb 2018 13:35:17 -0500
Message-ID: <CAL02cgQ+OD90gddHnWoMgyYRDV8CkMLHoVX7vxrUDbUQ8VLg_A@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Brad Biddle <brad@biddle.law>, iasa20@ietf.org
Content-Type: multipart/alternative; boundary="089e082b3ef02676730565589bb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/LfY_M1CPSmayIGJHGRLbFD9za8A>
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 18:35:25 -0000

On Fri, Feb 16, 2018 at 1:30 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Fri, Feb 16, 2018 at 10:10 AM, Richard Barnes <rlb@ipv.sx> wrote:
>
>>
>> That matches my understanding, i.e., that for tax purposes, the
>> difference between ISOC and the disregarded entity is disregarded;
>> everything looks like ISOC.
>>
>> However, the "for tax purposes" part is important.  For all other
>> purposes, they are separate entities with a limited relationship encoded in
>> the bylaws / operating agreement.  It's just that these separate accounts
>> "roll up" into the same tax statements.
>>
>>
> The issue, though, is which bit will get interpreted by the donors.  It's
> always been easy to tell the difference between an IETF meeting and an ISOC
> effort to build an IX or provide policy advice, but writing the checks for
> the former to the Internet Society has created confusion in the back
> offices of global sponsors.  If this structure still has those checks
> acknowledged by the Internet Society, is the presence of an LLC solving
> this problem?
>

IIUC, people who want to donate directly to IETF would write a check to
IETFAdminOrg (or whatever we call the subsidiary) -- that's the entity that
owns the account where the check is going to get deposited.  ISOC would
just have to do some verification on the back end to make sure that those
contributions are compatible with its tax position.

--Richard


>
> IIUC, the confusion around sponsorship was largely, "Is this sponsorship
>> going to support the IETF or ISOC more broadly?"  Either Option II or III
>> answers that question, since you pay the entity you want to pay; it's only
>> the IRS that disregards the difference.
>>
>>
> Speaking personally, Option II looks more likely to me to avoid this
> confusion.
>
> Ted
>
>
>
>
>> --Richard
>>
>>
>>
>>> From a governance perspective, I also see a difference between
>>> appointing a board and having  the ISOC board retain the right to replace
>>> the LLC management at any time for any reason, which appears to be a
>>> feature of Model.  While the operating agreements may establish a very firm
>>> ground rules here, it's my understanding that this right is a fundamental
>>> feature of the relationship and can't really be waived by agreement.  Is
>>> that correct?
>>>
>>> Thanks for thoughts on this,
>>>
>>> Ted
>>>
>>>
>>> On Fri, Feb 16, 2018 at 5:18 AM, Brad Biddle <brad@biddle.law> wrote:
>>>
>>>> First, for those who don't know me: I'm the new general counsel for
>>>> IETF, stepping into Jorge's role. I'm not engaged on this matter, however
>>>> (Morgan Lewis is providing legal advice), but I thought I'd respond to one
>>>> specific point that Ted raised:
>>>>
>>>> From my reading, though,  I see no advantage to option (III); it seems
>>>>> mostly just to put ISOC into the role of validating the contributions.  If
>>>>> there were specific advantages of that one that were obvious to the design
>>>>> team, I'd appreciate your thoughts.
>>>>
>>>>
>>>> Not to speak for the design team (which I am not on), but FWIW I think
>>>> there is a strong case for Option 3 (the single-member LLC option). The
>>>> article linked at [1] below does a nice job of explaining some of the
>>>> general pros and cons of this framework. As applied to IETF, I think the
>>>> key advantages would be that (a) it would accomplish the goal of giving the
>>>> IETF independent legal existence, enabling independent contracting, bank
>>>> accounts, etc., (b) the existing IETF governance structures could simply be
>>>> imported wholesale into the LLC Operating Agreement (as and if desired), so
>>>> the transition could be essentially invisible to IETF participants, and (c)
>>>> IETF could avoid the significant costs and risks associated with pursuing
>>>> and maintaining its own independent 501(c)(3) status. Also, while Joe's
>>>> original email characterized this option as providing IETF with less
>>>> independence than Option 2 (the Type 1 supporting org option), I don't
>>>> think this is accurate: i.e., for both Option 2 and Option 3 ISOC would
>>>> have to retain some formal control (to protect their own non-profit status
>>>> and otherwise comply with applicable law), but I think both options could
>>>> be structured to protect IETF's independence as a practical matter, and I
>>>> don't think Option 2 is necessarily better than Option 3 on this front.
>>>> Note the descriptions of operational independence in [1] -- it's flagged as
>>>> a potential bug from the perspective of the parent org, but perhaps IETF
>>>> would see this as a feature.
>>>>
>>>> Also, FYI, there are a couple of good examples of the single member LLC
>>>> model being used in the standards and open source context:
>>>>
>>>> 1. The Joint Development Foundation [2] creates independent single
>>>> member LLCs for each separate project; the project participants then manage
>>>> the projects independently under the LLC's operating agreement.
>>>> (Disclosure: I'm on the JDF Board and helped design this legal structure.)
>>>>
>>>> 2. The Linux Foundation just adopted this same legal structure in
>>>> connection with their recently-announced Linux Foundation Networking Fund.
>>>> See [2].
>>>>
>>>> Happy to discuss further, but FYI I'm traveling today and may not be
>>>> immediately responsive.
>>>>
>>>> --Brad
>>>>
>>>> [1] https://www.adlercolvin.com/wp-content/uploads/2017/12/U
>>>> sing-LLCs-in-Fiscal-Sponsorship-Update-on-Model-L-00647565xA3536.pdf
>>>> [2] http://www.jointdevelopment.org/
>>>> [3] https://www.linuxfoundation.org/projects/networking/governance/
>>>>
>>>>
>>>>
>>>> On Wed, Feb 14, 2018 at 9:35 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>>>>
>>>>> So, I can personally read it either way, which is why I asked for
>>>>> clarification; it sounds like that means getting the lawyers to specify.  I
>>>>> note that the text on the "Disregarded Entity" option says this: "Can have
>>>>> members that are not ISOC members, although for tax purposes their dues
>>>>> will be revenue to ISOC and ISOC will need to substantiate their
>>>>> contributions." which seems to contemplate a form of membership that the
>>>>> IETF has never had (we have contributions and participants, not dues and
>>>>> members).
>>>>>
>>>>> On Wed, Feb 14, 2018 at 8:49 PM, Richard Barnes <rlb@ipv.sx> wrote:
>>>>>
>>>>>> I actually have the opposite suspicion, members != participants.  For
>>>>>> those not familiar with the terminology, "participants" in the IETF sense
>>>>>> is basically "whoever joins a mailing list or comes to a meeting", or
>>>>>> similarly "whoever is subject to the Note Well / relevant IPR RFCs"
>>>>>> [0][1].  The IETF has very open participation.
>>>>>>
>>>>>> By contrast, given that this memo was written by lawyers, I expect
>>>>>> that they meant "members" in the legal sense, who are the parties that
>>>>>> legally control the entity (e.g., the shareholders in a for-profit
>>>>>> corporation) [2][3].  So saying that "ISOC must be the sole member" just
>>>>>> means that ISOC legally retains control of the entity, as one would expect
>>>>>> with a subsidiary entity.  That control is manifested, for example, in
>>>>>> their right to replace all or a majority of the board.
>>>>>>
>>>>>
>>>>> While I certainly can read the memo this way, that seems to me to mean
>>>>> that "Can have members that are not ISOC members" is not actually a
>>>>> property we care about, for the reasons Alissa pointed to in the minutes.
>>>>> The structures the hums support are those under the ISOC umbrella. I would
>>>>> expect us, should we choose this option (or the other options where this is
>>>>> feasible) to disallow members other than ISOC.  While ISOC's ability to
>>>>> appoint the majority of the board would always let us avoid capture by a
>>>>> different entity, there seems no good reason at hand to have other members
>>>>> and a good bit of risk that it could slowly change the IETF into a
>>>>> membership organization.
>>>>>
>>>>> Just my own point of view, of course.
>>>>>
>>>>>
>>>>>>
>>>>>> Note, however, that even if ISOC retains ultimate legal control,
>>>>>> there are still differences among options (II), (III), and (IV) (using the
>>>>>> memo's numbering).  In options (II) and (III), ISOC's control is attenuated
>>>>>> compared to option (IV), since basically the only right they have is to
>>>>>> appoint the board; they couldn't, say, direct specific contracting or
>>>>>> personnel decisions.
>>>>>>
>>>>>>
>>>>> I was honestly, expecting the pros and cons for these different
>>>>> structures to be laid out a bit more in terms of the IETF's situation, so I
>>>>> may well be missing something.  From my reading, though,  I see no
>>>>> advantage to option (III); it seems mostly just to put ISOC into the role
>>>>> of validating the contributions.  If there were specific advantages of that
>>>>> one that were obvious to the design team, I'd appreciate your thoughts.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Ted
>>>>>
>>>>>
>>>>>> --Richard
>>>>>>
>>>>>> [0] https://www6.ietf.org/tao.html
>>>>>> [1] https://www.ietf.org/about/participate/
>>>>>> [2] http://info.legalzoom.com/definition-llc-member-4425.html
>>>>>> [3] https://www.legalzoom.com/knowledge/nonprofit/topic/non-prof
>>>>>> it-membership
>>>>>>
>>>>>> On Wed, Feb 14, 2018 at 11:09 PM, Joseph Lorenzo Hall <joe@cdt.org>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm not sure, we should clarify. I believe the type 1 SO here is the
>>>>>>> same as that for PIR, so I suspect it's what we would call participants.
>>>>>>>
>>>>>>> On Wed, Feb 14, 2018 at 19:34 Ted Hardie <ted.ietf@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Joe,
>>>>>>>>
>>>>>>>> Thanks for forwarding this.  I do have one clarifying question.  In
>>>>>>>> the section on the Type 1 supporting organization, it says "Can have
>>>>>>>> members that are not ISOC members." but also says "ISOC must serve as the
>>>>>>>> sole member of the corporation with the right to appoint at least a
>>>>>>>> majority of the directors."  ISOC is the sole member of PIR, and I
>>>>>>>> had made the assumption that it would be the sole member of a new Type 1
>>>>>>>> supporting organization, should that be the path selected.  This, however,
>>>>>>>> seems to contemplate members beyond ISOC, and I'm unsure who or what those
>>>>>>>> could be in our context.   Or does the first usage simply mean what we
>>>>>>>> would call participants in the IETF context, saying that the participants
>>>>>>>> in the supporting organization do not also need to be considered "members"
>>>>>>>> of ISOC?
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> Ted
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 14, 2018 at 3:29 PM, Joseph Lorenzo Hall <joe@cdt.org>
>>>>>>>> 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)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joseph Lorenzo Hall
>>>>>>>>> Chief Technologist, Center for Democracy & Technology [
>>>>>>>>> https://www.cdt.org]
>>>>>>>>> 1401 K ST NW STE 200, Washington DC 20005
>>>>>>>>> <https://maps.google.com/?q=1401+K+ST+NW+STE+200,+Washington+DC+20005&entry=gmail&source=g>
>>>>>>>>> -3497
>>>>>>>>> e: joe@cdt.org, p: 202.407.8825, pgp:
>>>>>>>>> https://josephhall.org/gpg-key
>>>>>>>>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> iasa20 mailing list
>>>>>>>>> iasa20@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/iasa20
>>>>>>>>>
>>>>>>>>> --
>>>>>>> Joseph Lorenzo Hall
>>>>>>> Chief Technologist, Center for Democracy & Technology [
>>>>>>> https://www.cdt.org]
>>>>>>> 1401 K ST NW STE 200, Washington DC 20005
>>>>>>> <https://maps.google.com/?q=1401+K+ST+NW+STE+200,+Washington+DC+20005&entry=gmail&source=g>
>>>>>>> -3497
>>>>>>> e: joe@cdt.org, p: 202.407.8825 <(202)%20407-8825>, pgp:
>>>>>>> https://josephhall.org/gpg-key
>>>>>>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brad Biddle | brad@biddle.law | +1.503.502.1259 <(503)%20502-1259>
>>>> (mobile) | http://biddle.law
>>>>
>>>
>>>
>>> _______________________________________________
>>> iasa20 mailing list
>>> iasa20@ietf.org
>>> https://www.ietf.org/mailman/listinfo/iasa20
>>>
>>>
>>
>