Re: [Iasa20] I-D Action: draft-hall-iasa20-workshops-report-00.txt

Alissa Cooper <alissa@cooperw.in> Tue, 21 March 2017 20:10 UTC

Return-Path: <alissa@cooperw.in>
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 C47651294B5 for <iasa20@ietfa.amsl.com>; Tue, 21 Mar 2017 13:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ZzTrBfdq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j3MNBC6E
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 Lh1wtpUztXOd for <iasa20@ietfa.amsl.com>; Tue, 21 Mar 2017 13:10:47 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4627A127286 for <iasa20@ietf.org>; Tue, 21 Mar 2017 13:10:47 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B4A9920994; Tue, 21 Mar 2017 16:10:46 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 21 Mar 2017 16:10:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ejF7KJ4oWrFi05P8XW Xx4i0Ja5r89qB3itW+Hh9OmTs=; b=ZzTrBfdq4ybdc+qamZm2RMPb3eWW0D+G2O JaouoY+dITJ6btejADu0FCoWUstkM2x9+yZbWx9iqLwD8kIs4X1nXwx6GfXlLpo/ iVZSj+OMKTnl7nxN0vUtVuBXVvBN5jZLohDoWt5cP8LiXMr5/+WDyDTroijHxxnP KZzOyWVMhKW7V5Rjmf8CUrZ0zx/P3j4fwEYGctVpNAYb7/X3yT80XMx+hD1f7Jg0 sdVZyWKnU9/L1eDs1gqIv45OFSSWHVKuv0+K5brp1lpGDRILUEWbF73fkBJ8Dw8s fAKfQYVx+y7mFNqw2ix8lTNfp/Hom2j8sIRSn+fhJ8PNOq2D4SUA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ejF7KJ4oWrFi05P8XWXx4i0Ja5r89qB3itW+Hh9OmTs=; b=j3MNBC6E NPEcQuShTehpummiRMP9Fu1rgStF/LE7OqvWuDOyLVr8cOwcbCV5jXzBzodxN576 7e3EUzL4JTMkc7karMIzyOsEZc7SPxhHsxbBkmmJLHObv8rWTN9GUYy603RnWzX0 eti2USXzM3B17ObV7uoW39YQ7HZBtE6hNh0/QB5dfoQjluUylgJKxZ6Z8XdassEy EwsxA9EjfhjffDhGzQNDELXCX1vAU8zB07VhdXXoXspSly/tiVvAc+9qs7Y66vXp PjQdWCyl6UPGWW9tIL1RSf8GpiqReQb+YhUvTMn0VH8fZSzSXBMuU61i7qbUHg7c h8tG23jNV7RUvg==
X-ME-Sender: <xms:xojRWAkLsWYXfLzqUhKBaSkKHLvYSUHvHKMeLBKs3UllzQ1MwUB3FQ>
X-Sasl-enc: 6SI7iujlKEowGqAJ/v/wWTLtvXV+wZkp/F8yAgZvFjur 1490127046
Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.164]) by mail.messagingengine.com (Postfix) with ESMTPA id 02C867E695; Tue, 21 Mar 2017 16:10:45 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <b70c1e1b-1e9d-e7cc-5ffa-ccc69cd9c50e@gmail.com>
Date: Tue, 21 Mar 2017 16:10:43 -0400
Cc: iasa20@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD56809C-A31F-4ECC-B292-D285D40FEAFB@cooperw.in>
References: <148941528136.16867.3807046327704023886@ietfa.amsl.com> <2938563f-6ad6-57a8-122f-805b8cf41ed5@gmail.com> <A3C09A9E-AB39-4ABD-8B0B-76C7F3249C45@cooperw.in> <b70c1e1b-1e9d-e7cc-5ffa-ccc69cd9c50e@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/tp36Inpknf-nKn0TOYPZfDzABjI>
Subject: Re: [Iasa20] I-D Action: draft-hall-iasa20-workshops-report-00.txt
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: Tue, 21 Mar 2017 20:10:49 -0000

> On Mar 20, 2017, at 6:31 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
>> 
>>> 
>>>> which has led to issues around transparency, 
>>> 
>>> Why has the lack of a clear line done that?
>> 
>> One reason (of several) is the fact that the IAD is an ISOC employee means that we end up relying on a multitude of ISOC staff and resources solely for the purpose of administering the IETF, and much of that reliance is not described or accounted for anywhere. If you asked the average IETF participant how many ISOC staff the IAD consults with or relies on for support of various kinds, what do you think the answer would be? 
> 
> Extrapolating from my out of date experience, I would guess at least 20 (but of course only for a fraction of their time). But I don't think that has much to do with the lack of a clear line.

But if the line were clear(er), this wouldn’t be a problem. Just to come back to the communications example for convenience, if there were staff on the IETF “side” whose specified responsibilities included communications, we never would have been in a situation where an ISOC staff person just naturally started taking on those responsibilities, because they would have been taken care of by the IETF. Instead, we sort of slid gradually into a situation where ISOC staff was doing it and it wasn’t being accounted for anywhere.

> IASA is *supposed* to be professional, so surely we always expected the IAD to call on professional help.

There is an additional problem with this model, which is that it assumes that ISOC’s priorities and resources will always be available and aligned with whatever the IAD feels he needs to get the job done. It seems like that does not actually work seamlessly in practice without a lot of coordination between ISOC management and the IAOC. For example, let’s say there are 20 ISOC employees who spend some part of their time supporting the IETF, some of whom do it because the IAD comes and asks them for help — is that reflected in those people’s performance goals and evaluations? Is input collected from the IAOC or the committees so that those people’s managers can assess how well they’re doing in those functions? If not, is that fair to them? As new people are hired by ISOC to meet the growing workload required to support both the IETF and ISOC’s other activities, does anyone on the IETF side have any input into those hiring processes? Should they?

> 
>> I think the confusion arises because there are items that are in direct support of the IETF that are not accounted for in the IETF budget, and there are ISOC-affiliated activities which relate to the IETF but for which there is not clarity in the ISOC budget. We are working on getting more clarity around both of these, but right now they’re not clear.
> 
> If some labour costs incurred by ISOC staff are not being accounted as an in-kind contribution to IASA, that could be fixed in the accounts, by all means. But it will not change anything in reality, except maybe make the ISOC Board scrutinise the details.

Per my comments above, I think it could change a lot in reality. We could decide that we’d rather contract out some of these functions that previously were not accounted for anywhere, or that we need more full-time ISOC staff to support the IETF. On the ISOC side, they could decide to incorporate IETF-related work into people’s performance goals, or to reorganize their own personnel to better accommodate the workload/expense that they are putting in.

> 
>>> 
>>>>                     and how donations can be guaranteed to be
>>>>        dedicated to the IETF, and
>>> 
>>> That seems like a trivial accounting matter.
>> 
>> Again here I would be interested to understand better how you see this working. The IETF does not have a bank account open for accepting donations independent of ISOC. Rules of procedure and governance have been created to reassure donors that funds will be directed to the IETF, but ultimately the responsibility for adhering to those rules (and not changing them in the future), lies with the ISOC Board, to which the IETF community appoints a minority of members. 
> 
> Yes. If we can't trust the ISOC on this, we are in trouble.

But this isn’t about “us” (depending how you define it), it’s about potential new sponsors and donors having that trust.

> But that's not new; this is a large part of why ISOC was created.
> 
>> 
>>> 
>>>>  ...we do ourselves a disservice by this long-
>>>>  standing confusion about whether IETF is an organization; they felt
>>>>  that people within the community know what is meant by the IETF and
>>>>  that more formality is not necessary.  
>>> 
>>> I am totally unaware of this confusion. In fact, it confuses me.
>> 
>> I would say it’s highly unusual to find an SDO — or really any organization of the size and complexity of the IETF — that is not a legal entity or was not created by a contract of some sort. People who have a passing familiarty with the IETF or are just getting to know the IETF assume that it is a legal entity. Unless one has a specific reason to know, it wouldn’t usually be people's first guess that the IETF is actually just an activity of another organization.
> 
> Yes, the IETF is highly unusual in this regard; IMHO it's the IETF's greatest strength in resisting capture by vested interests. But it isn't actually hard to discover for newcomers, is it? It's stated at the bottom of the home page, and the newcomer's page, the Tao (and RFC2028, cited in the Tao) should clarify things.

For some folks on the other end of a sponsorship pitch, the Tao is not really a suitable place to start.

Alissa