Re: [Iasa20] IASA 2.0 outcome properties

Alissa Cooper <alissa@cooperw.in> Mon, 24 April 2017 01:08 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 848E6127010 for <iasa20@ietfa.amsl.com>; Sun, 23 Apr 2017 18:08:25 -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, HTML_MESSAGE=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=cooperw.in header.b=PnhXbeve; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=St1cflff
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 0jAPfuWHoG8L for <iasa20@ietfa.amsl.com>; Sun, 23 Apr 2017 18:08:23 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2011B1204DA for <iasa20@ietf.org>; Sun, 23 Apr 2017 18:08:23 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 76CB720B95; Sun, 23 Apr 2017 21:08:22 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Sun, 23 Apr 2017 21:08:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :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=VlPzwXJk+sSaeBUT4wAZd/pxrH4mMAWLc/AcN8DkT y0=; b=PnhXbeveO+i9qgI83+3DIlwlYamdh5zdZ1lajSm3h8pqj62vgqTTy4etz Exvnw3etS9Kbo48VlDwjewAsCw9GLeL6SlwGkM3/qwSYxVHNDUOXhIm+AatNyni4 UFMTCf6bRmKfYklJvUch/A/vOAGHRTFzxhiRN0LW33qNaFFVYmm4nKJpmi5vqJRG v8CRE9iIcjUj+j82shutG5b09mKLU1I2Ga6AgYo4xbVvL73LLDEjSjiEZJQ9kvB3 mnnBcpKZ/LIF1pBoTA2WeTgOHq5bec01ZE/Eg+aixtkjoQn+fQFXJNyubaXzx3xD WX+GH2hMBPUpGqg+G7qAEbhhy1doA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=VlPzwXJk+sSaeBUT4w AZd/pxrH4mMAWLc/AcN8DkTy0=; b=St1cflffcDgQKnFjZeJsLYiHNZ4yiVlK8F kEV2vejV1gp4rVpnm2Ny1r5Yfx3ykAVo927sJu/t5u+wyNjAKL/Ztnl3bSOiZAuR IeOvoP6iVzqUVFeITxCS2P7rEAsChobJywlQi55jBT6LH9voMSfoCh5f4G1z/+kb a5YKgQG86mzD6YKDf5iuDwPbl/cJGOd4CSa4+BaW8sl8WV1ACU3eMfse3Yge9CKf c/C92fGtX4V8OFeKhidDeB3+VBeayiJfJZTrS3k5soDAYU+RCIqnZShUB4zpFni0 BGzU2a4hMmPONiTeffvb5QV6LzzjluFqWe/KShhj+RFjNqhuYOwA==
X-ME-Sender: <xms:BlD9WLnxRkqLu3AUfRXV18IrtHE02oq5DkqfmO9qnEE9D9uVEOYfIA>
X-Sasl-enc: BPvLLo8Tzu82mB+2qjSdfBAqV+qCPYIPaZLcRY5hF7Cj 1492996101
Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.187]) by mail.messagingengine.com (Postfix) with ESMTPA id 7840A24370; Sun, 23 Apr 2017 21:08:21 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6C2D15DD-B70A-4F69-A5A7-FE51D5520887"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <CA+9kkMAMQajOEX6bpuH2t5AF8VaiKT2oPZRDayogf7BXpPSikg@mail.gmail.com>
Date: Sun, 23 Apr 2017 21:08:20 -0400
Cc: iasa20@ietf.org
Message-Id: <279811B9-6789-4898-B03E-6FBBF967644D@cooperw.in>
References: <42E39015-D0B6-4464-8792-9F3A7089975F@cooperw.in> <CA+9kkMAMQajOEX6bpuH2t5AF8VaiKT2oPZRDayogf7BXpPSikg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/ulJY3J0XEWwc7es1LFNmoZ7AnYo>
Subject: Re: [Iasa20] IASA 2.0 outcome properties
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: Mon, 24 Apr 2017 01:08:25 -0000

Hi Ted,

> On Apr 19, 2017, at 3:03 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> Thanks for starting the thread.  Some thoughts below.
> 
> On Wed, Apr 19, 2017 at 8:39 AM, Alissa Cooper <alissa@cooperw.in <mailto:alissa@cooperw.in>> wrote:
> As noted at IETF 98, it seems that one reasonable next step here is to articulate some properties of the desirable end state of this work -- what Jonne called the target. What are the properties of the outcome that we want? I've put together the list below, reflecting the discussion in Chicago, the drafts that were written beforehand, and some material from BCP 101.
> 
> I don't think we need to nitpick on the details or wordsmith this per se, but it would be good to get a general sense of whether this captures the properties of the outcome that we're collectively looking for here. So please send feedback on whether you think the list below meets that bar. If we get to a place where there seems to be some agreement about a list of this sort, it will make it easier to start discussing solution options for the present set of problems.
> 
> Below the list, I've included a couple of notes (just from my individual perspective) to try to provide a little more context.
> 
> == List ==
> 
> Administration
> 
> 1. For each of the following functions, it should be clearly defined and documented who is responsible for executing the functions and who is responsible for overseeing those that do the execution. In cases where execution or oversight are done by paid staff, contractors, ISOC, or any paid entity, the mechanisms for obtaining community input and involvement should be clearly defined and documented.
> 
> - Administrative support
> - Budgeting
> - Contracting
> - Accounting
> - Development (including fundraising)
> - Meeting planning
> - Legal support
> - Communications
> - Outreach
> - IT support
> 
> (In the rest of this list, I refer to these functions and those executing them collectively as "administration" for short.)
> 
> You have a separate line below for funding.  It seems to me that "Development (including fundraising)" needs to go into that bucket, as it has different transparency properties and may need to respond to goals set by different parts of the community than would oversee other parts of the administration. 

Perhaps you could expand a bit by what you mean by “into that bucket” because it’s not quite clear to me. Are you saying that you think development needs to be administered differently than the other functions? Or overseen by different people? 

> I'm also a little unclear what you mean by outreach here, and for some versions of it I would take it out of administration/IASA entirely. 

I would put the kinds of things that Olaf presented in Chicago <https://www.ietf.org/proceedings/98/slides/slides-98-iasa20-isoc-contributions-00.pdf <https://www.ietf.org/proceedings/98/slides/slides-98-iasa20-isoc-contributions-00.pdf>>, in his slides #5-8, in that bucket. 

> 
> 
> 2. Administration should have no influence over the technical decisions of the IETF or over the technical contents of IETF work. (By implication, suggestions for changes to standards development processes, technical leadership, technical leadership appointments, open participation, etc., are out of scope for this discussion.)
> 
> 3. Administration should operate transparently, within the limits of business confidentiality. Budgets should be transparent.
> 
> 4. Administration should be able to incorporate participation from community volunteers, but its functioning should not be dependent on community volunteers. In other words, the number of paid staff and contractors should be able to dynamically grow and shrink to suit the administrative needs of the IETF, including by accommodating those needs entirely with paid staff if volunteers are not available.
> 
> 
> Oversight
> 
> 1. Oversight over administration should be community-led.
>  
> 
> I know you don't want wordsmithing, but point 1 seems far too vague; oversight isn't defined and community-led isn't either.  Between the two, there's no way to tell if two random IETFers agree that some particular system fits this or not.  Can we say something more direct like "IETF Participants will select those overseeing this activity and will have access to the information relevant to that oversight within the limits of business confidentiality" to subsume this and point 2?

This is indeed hard to specify in the abstract, but I thought what I was hearing in Chicago was that folks wanted to maintain the idea that volunteers from the community continue to be the primary people conducting the oversight of IETF administrative activity. Community-led is perhaps a poor way to phrase that, but that’s what I was going for, which is a little stronger than saying that those doing oversight will be selected by the community. 

> 
>  
> 2. Oversight should be conducted transparently, within the limits of business confidentiality.
> 
> 3. For personnel who are dedicated full-time or nearly full-time to IETF administration, the oversight function should include hiring and firing the personnel, reviewing the performance of the personnel, and setting the compensation of the personnel. (Text inspired by https://tools.ietf.org/html/bcp101#section-3 <https://tools.ietf.org/html/bcp101#section-3>).
> 
> 4. For personnel whose employment responsibilities include IETF administration as well as contractors, the oversight function should include reviewing the performance of those personnel and contractors.
> 
> 
> Funding
> 
> 1. IETF funds should reside in their own independent financial account(s) with independent governance.
> 
> 2. An organization that funds the IETF should have no more influence over IETF standards development outcomes than any other organization.
> 
> 3. Funding for IETF operations should be derived from multiple sources.
> 
> 4. The IETF funding strategy should incorporate both short-term/just-in-time and long-term fundraising vehicles.
> 
> 
> I am not sure why we want to describe the timelines of the funding strategy in detail.  I think this might be a proxy for something about the output of the IETF, specifically that its output can be seen to be sufficiently useful when the users of that output fund it.  If that is correct, it seems to implicitly contravene point 2; if it is not correct, I don't understand it.

This is drawn from Jari’s draft. My understanding is that historically, there has been a preference to raise money over short cycles, e.g., to obtain sponsorships for the next few meetings, but not to do much in the way of longer term fundraising sustainability. With the introduction of the global host program and the endowment that has changed somewhat, and the point of stating this as a objective would be to capture that shift in strategy explicitly, rather than sliding into it implicitly. 

> 
>  
> 5. Long-term funding vehicles should have greater emphasis than short-term ones to reduce the overhead associated with obtaining sponsorships meeting-by-meeting and to allow for experimentation with new initiatives within the IETF.
> 
> 
> == Discussion ==
> 
> Out of the list above, I think we do not currently meet the following ones, or we at least have room for improvement: administration #1, 3, and 4; oversight #2, 3 and 4, and funding #1, 4, and 5. Most of the rest were mentioned at IETF 98 or in the drafts and seem like things that people wanted to document to make sure they won't change going forward.
> 
> Regarding oversight #3 and 4, the point here is to align individuals' employment objectives with the administrative objectives of the IETF. If we have administrative roles designed for people to be spending their paid work time on IETF administration, it makes sense that people from the IETF community would have some role in reviewing their performance. This is not the case today for a number of ISOC staff who provide administrative support to the IETF. And for individuals who spend the majority of their work time on IETF administration, it makes sense that people from the IETF community would have some additional role in selecting those individuals and setting their compensation (or that community participants would be able to choose to delegate those tasks, at least). Our documented process establishes that this is what we should be doing for the IAD and for contractors (assuming that establishing contract values and selecting firms are the equivalent steps for contractors) already
>  . But this is not what we are doing for communications or fundraising.
> 
> 
> Given that this involves compensation and hiring, I think we have to shift "people from the IETF community" to "selected by the IETF participants to oversee this function." or we can't meet the normal business confidentiality rules.

Fair enough.

Thanks,
Alissa

> 
> Thanks again for starting this conversation,
> 
> Ted
>  
> Alissa
> 
> 
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org <mailto:iasa20@ietf.org>
> https://www.ietf.org/mailman/listinfo/iasa20 <https://www.ietf.org/mailman/listinfo/iasa20>
>