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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 16 February 2018 17:09 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 6B223126BFD for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 09:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 t5MtSwSTSRZ3 for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 09:09:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC661205F0 for <iasa20@ietf.org>; Fri, 16 Feb 2018 09:09:32 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9D0D20090 for <iasa20@ietf.org>; Fri, 16 Feb 2018 12:16:36 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6F93980BCE for <iasa20@ietf.org>; Fri, 16 Feb 2018 12:09:31 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: iasa20@ietf.org
In-Reply-To: <C77B41DA-268D-4F0E-8AC8-F2E292E38B14@cooperw.in>
References: <4483006c-1652-7340-19f8-8d0579af8213@cdt.org> <20182.1518727709@obiwan.sandelman.ca> <C77B41DA-268D-4F0E-8AC8-F2E292E38B14@cooperw.in>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 16 Feb 2018 12:09:31 -0500
Message-ID: <9631.1518800971@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/-dxNCSYUWiTMgQ7JBXaXFc5Ek1I>
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 17:09:34 -0000

Alissa Cooper <alissa@cooperw.in> wrote:
    >> On Feb 15, 2018, at 12:48 PM, Michael Richardson
    >> <mcr+ietf@sandelman.ca> wrote:
    >>
    >>
    >> Joseph Lorenzo Hall <joe@cdt.org> wrote:
    >>> I am writing on behalf of the IASA 2.0 Design Team to update you on
    >>> progress since Singapore.
    >>
    >> Thank you!
    >>
    >>> 3. Weak independence: an LLC that is a "disregarded entity"; and,
    >>
    >> Having read the document, this seems like the clear win to me.

    > Could you say a few words as to why?

I didn't say only a few words, because I felt I would just be copy and
pasting the document.  But let me try:

1. I think that we want our own bank account.
   Only Option IV, status quo, doesn't legally give us that.
   As I understand the transition to having AMS do the book-keeping, that
   a new bank account was created.  But, it's still ISOC's account.
   So sponsors can write "IETF" on their checque rather than "ISOC"

2. Options I and II come with additional administrative/tax-filing burden,
   and not really any clear advantage.  So basically costs.
   While we can mess with the rules sufficiently to allow IETF process to
   populate the board, it's essentially because ISOC wants us to do that.  I
   have no qualms about's ISOC's good will, but it seems that some people do.

   Options III would have ISOC, as the controlling entity, write into the
   bylaws that it follows the IETF process, and only if we outright mutiny,
   do they have to step in.

3. I think that under Option III, that we would very CLEARLY be able to sign
   our own contracts.  Be they Executive Director, Secretariat, RFC-editor,
   or tools development.  I don't know that the community thinks this is
   high priority, but I think that it does matter.
   I guess that would include Hotel contracts too!


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-