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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 March 2017 20:41 UTC

Return-Path: <brian.e.carpenter@gmail.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 0410A1292CE for <iasa20@ietfa.amsl.com>; Tue, 21 Mar 2017 13:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BWJuEBk0P2Lc for <iasa20@ietfa.amsl.com>; Tue, 21 Mar 2017 13:41:52 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 8F89C12EA7A for <iasa20@ietf.org>; Tue, 21 Mar 2017 13:41:49 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id l7so55568548ioe.3 for <iasa20@ietf.org>; Tue, 21 Mar 2017 13:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=h5KyUJUoAag88JuE+7XlvvQXgrHogyidUxaWk/rttjA=; b=hQggU9kEnmA/Ig+D7fzHxgXlvRbBeVMWJMDr0LMdwEUpt48QaiEL9L6w9y7D7lPYiI 1Rqn0WplE3yD4i6CWjH2GoqZk7xHhmOHH6U118NmWRxkVsxCi/ww59P2PzZpW3xzflpo Qf57yQvJn9Zlm9ACyo06e569GxGO46GILTMGYBM8CElMN+/ZgQBR57ogZCQ3f6XiLSn1 Oa7px4ZsjL5lIX235oT8rkOFbT9A+61ZH1T719+3L1rnASR9Aq80IFWvBz8TRmAE7u+m isx5F3oZyiBm0ZSHhkXAqTQuaRrn9jkBHz0PujpZAdpdGdWMtfHIunUdz472qRYII22a kg7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=h5KyUJUoAag88JuE+7XlvvQXgrHogyidUxaWk/rttjA=; b=RcgOvdryGL2DjkHz29gd265KNy7XhBvFCqXB77U+l7T3soSwpSnWJDLb5enMGY5VAY uTf045WcSwMrV0mW8d8nixBABqCeNey6/3myX+dZ+zmPA+9Zd/IzzeZyrFOWWJ2oXE1k HF0CLsiQuoxEg1HFyXXxoh8RdSjJOEXchRH7pltHimb5PkJdsSi09oP2QhKn+aO0zT/w zb2s1HTOJoKPQ88rHjVv7WTg0Wuxu9PRl0JCuqunnzgLvWAnKJ6CH1eTYzpUl+LC2k9U WxhY1R6xOlTI39bOV6iGPyRJA0/l0rpXAGRtoN2zCkddgoBZkBTloHYNEN6eHD8E42pD tO+A==
X-Gm-Message-State: AFeK/H1oIAv0t89c6DwvDeIjqxX7ZASFrI0LeENlRJnYiaoUCD/MjvvzmL8jbd7nrGQ95g==
X-Received: by 10.107.53.170 with SMTP id k42mr38064545ioo.176.1490128908722; Tue, 21 Mar 2017 13:41:48 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id d12sm5504071iog.41.2017.03.21.13.41.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 13:41:47 -0700 (PDT)
To: Alissa Cooper <alissa@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> <DD56809C-A31F-4ECC-B292-D285D40FEAFB@cooperw.in>
Cc: iasa20@ietf.org
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <60a4a582-6ad6-91de-746c-cf8605d4cd99@gmail.com>
Date: Wed, 22 Mar 2017 09:41:51 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <DD56809C-A31F-4ECC-B292-D285D40FEAFB@cooperw.in>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/BQIKgfv0lS4_DqA98oo4biDKCWw>
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:41:55 -0000

Excuse front posting, but this is kind of a general comment on this whole discussion. Alissa wrote:

> 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.

Who is "we"? That decision seems dead centre in IASA's responsibility, overseen by the IAOC.

Let me repeat: I'm all for clarifying the administrative boundaries and costs, and adjusting things as appropriate. But that seems like part of the job we delegated to IASA 10 years ago. It seems to me that from the IETF point of view, our main concern should be whether IASA (=IAD+IAOC+Trust) is constituted in the best way for current & future conditions. For example, I'm sympathetic to the point that the IAOC skill-set is different from the Trust skill-set.

One new thing that I've seen is the need to clarify responsibilities for PR/fund-raising, which was definitely *not* delegated to IASA.

Regards
   Brian

On 22/03/2017 09:10, Alissa Cooper wrote:
> 
>> 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
> 
>