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

"Leslie Daigle" <ldaigle@thinkingcat.com> Fri, 16 February 2018 21:57 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 83F58124205 for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 13:57:10 -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 hbCXvSAOyPJc for <iasa20@ietfa.amsl.com>; Fri, 16 Feb 2018 13:57:08 -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 C13DD1241F3 for <iasa20@ietf.org>; Fri, 16 Feb 2018 13:57:08 -0800 (PST)
Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 14E20201702C6; Fri, 16 Feb 2018 13:57:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=w NSTcOdI65HNzlb/kjdu6qP14qQ=; b=W+GJGLVHF9WPCglJl6ZHdkXoK4/EkXzef xMF0jwSzPqH11u3PPM55OdZ0x/0HMRpLWJDy2rQgGAZ0EjrEpq+kuyEmSN5jcTJF Mh9BsWGeLI6NZ9GsGUpl7fHUcIxTPjc5jSfB9pTmSAxzv2+6RcyR8vhE4wNivPRU gEEsY2eQUg=
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 36497201702C2; Fri, 16 Feb 2018 13:57:07 -0800 (PST)
From: Leslie Daigle <ldaigle@thinkingcat.com>
To: Brian Carpenter <brian@cs.auckland.ac.nz>
Cc: Eric Rescorla <ekr@rtfm.com>, Michael Richardson <mcr+ietf@sandelman.ca>, iasa20@ietf.org
Date: Fri, 16 Feb 2018 16:57:05 -0500
X-Mailer: MailMate Trial (1.10r5443)
Message-ID: <065C95EE-2FCA-4E0C-9B4F-5C3177D6E851@thinkingcat.com>
In-Reply-To: <cbc363ac-960d-1719-9ca3-9501360ef179@cs.auckland.ac.nz>
References: <4483006c-1652-7340-19f8-8d0579af8213@cdt.org> <20182.1518727709@obiwan.sandelman.ca> <C77B41DA-268D-4F0E-8AC8-F2E292E38B14@cooperw.in> <9631.1518800971@obiwan.sandelman.ca> <be961111-9bed-086e-a0ab-b220125a438d@cs.auckland.ac.nz> <CABcZeBNBXW1SVDDmaLg+-ZX_3WhaWtwEYFiXC8KBUpCXFVjB6g@mail.gmail.com> <cbc363ac-960d-1719-9ca3-9501360ef179@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_F5DA8320-D232-45BF-8A72-032B3C0D1183_="
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/d7Dhp1JYFt9Yxz2RrDuKGpveDgY>
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:57:11 -0000

I think the IAD and IAOC have been doing their job well if this appears 
to IETF participants to be an occasional and minor hassle.

In practical terms, it is neither.

As noted during the last IASA 2.0 session, it’s hard to expose all the 
experienced examples in the detail that you might find compelling, for 
the simple reason that it is (somebody else’s) business and it’s not 
polite.

But, the bottom line, as expressed at the last IASA 2.0 meeting 
(including the support of the ISOC CEO and the ISOC Board Chair), is 
that the current relationship no longer fits — either organization.  
This is a positive sign of growth — for both organizations.


Leslie.

-- 

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

On 16 Feb 2018, at 14:02, Brian Carpenter wrote:

> On 17/02/2018 07:54, Eric Rescorla wrote:
>> On Fri, Feb 16, 2018 at 10:50 AM, Brian Carpenter 
>> <brian@cs.auckland.ac.nz>
>> wrote:
>>
>>> On 17/02/2018 06:09, Michael Richardson wrote:
>>> ...
>>>> 1. I think that we want our own bank account.
>>>
>>> I have seen no consenus call to that effect. Personally, I think
>>> that we have no need of a bank account. It appears that we are in
>>> need of a primer for potential sponsors explaining how moneys sent
>>> to ISOC are applied to IETF needs.
>>> ...
>>>
>>>>
>>>> 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.
>>>
>>> Why? When did the IETF ever suffer as a result of its contracts 
>>> being
>>> signed by ISOC?
>>>
>>
>> See, for instance:
>> https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-01#section-3.1.3
>>
>> "
>>
>>  For example, due to IETF's lack of legal status, contractual
>>    agreements must be signed by ISOC on behalf of the IETF.  There 
>> are
>>    occasions when a decision that is right for the IETF and desired 
>> by
>>    IETF leadership cannot be executed due to constraints posed by 
>> what
>>    ISOC can and cannot agree to itself.  For example, when IETF 
>> sought
>>    to acquire a recent piece of software for business purposes, ISOC
>>    would initially not agree to entering into an agreement with the
>>    software provider.  Ideally, IETF could make decisions free from
>>    operational and other constraints imposed by its relationship with
>>    ISOC."
>
> OK. So we'd trade off that very occasional sort of hassle against a 
> new
> Board to staff, a new Advisory Council to staff, and all the overheads
> of running a separate accounting, auditing and tax return setup.
>
>     Brian
>
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20