Re: [Iasa20] IASA 2.0 outcome properties

Alissa Cooper <alissa@cooperw.in> Wed, 03 May 2017 14:34 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 68CF81293F9 for <iasa20@ietfa.amsl.com>; Wed, 3 May 2017 07:34:01 -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=R2ZFJFz9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cR4x0/0g
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 HWTjn8LOzhm2 for <iasa20@ietfa.amsl.com>; Wed, 3 May 2017 07:33:59 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E9E129AC4 for <iasa20@ietf.org>; Wed, 3 May 2017 07:31:26 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9CC3020AD9 for <iasa20@ietf.org>; Wed, 3 May 2017 10:31:25 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 03 May 2017 10:31:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= 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=iv8PvD78p7RzwK/cME A6MB1MmQlrLDT1qjyTd/rMlrQ=; b=R2ZFJFz9vTfs+rLtX9rsxAVKzMOkPTFm1o Sy5khjWYat7syXr26lS6FRXnceP2FPqpLDmbxdolcgiVcfDJrHhmRTSb9yZNrJJW BR391S1fFh9S/JSXCrDYV0ChWwonmO2JEfxSkj7MeTVHqnsESyIC2PXT3Sm1MKM5 YDhuIhIng3cVp/tfkn03PbQYBWPf5Kzfr9J5cca8O864SG9Hn7/xVo8Hxx2qXeTp IQ7XpOJI8uCIz1iJrNkW/BIIfDnEsSH0WNWOlUZP0KGQc0VKQRGRPtGb4frknRb4 P/TfXvXldK+4HMILE/06N8KjNuK1WI7eVHk+SqMkVbPhlUlT108w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=iv8PvD78p7RzwK/cMEA6MB1MmQlrLDT1qjyTd/rMlrQ=; b=cR4x0/0g qgPd4N78OOKw79FWpbKcOXMSPnp9C05iUoNbOVwrnc0tmDsoPG8ZvLUtQRLxGDOK nEng6PDdjYn26ESBZpV85jYE7EQ/Qq5luA1IO0N/KWTLENZSfhjs5JreGpEn1MFj y6L6w0VCUddF3glH6KLsHurNb4nZOwrh6G05w3jvWUtJsWlgo+zglcXHhLHSxKt/ frbvAGBjDDsqps4F+n3tCdg05YXCt+cDEHVPBrfrSPyD8NG3q2FS2SA/KEu+HpD2 haYyU9WVwdWp09QByOEw2q6LVjwTaRMeYYf/TgGf6vuMK1u10MfH2VqpA0wiE79V xC9mouEUWFR51g==
X-ME-Sender: <xms:vekJWYKetsnU8uLNug3UdLg8sGXGmt7Ai_AojREAKleSk4vxYs6Wyg>
X-Sasl-enc: xFQ6WFCoXyakJUeJ0VC/BzjjpfMEG33hkM7vHBW7TR1N 1493821885
Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.176]) by mail.messagingengine.com (Postfix) with ESMTPA id 03F84248B4 for <iasa20@ietf.org>; Wed, 3 May 2017 10:31:24 -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: <42E39015-D0B6-4464-8792-9F3A7089975F@cooperw.in>
Date: Wed, 03 May 2017 10:31:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B2F82F88-1505-44DD-BA24-68E97FBB9570@cooperw.in>
References: <42E39015-D0B6-4464-8792-9F3A7089975F@cooperw.in>
To: iasa20@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/WRcs1fXUzlC9cSKNmjTyDuoj3to>
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: Wed, 03 May 2017 14:34:01 -0000

I’ve taken another cut at this based on the list discussion. New text is below. Couple of notes:

The only change in the Administration section is an additional sentence about the nomcom process in #2, per Randy and Jason. I think Michael’s point is addressed in Administration #1. 

I refactored the Oversight section based on the comments from Stephen and Ted. Hopefully this is clearer now.

The Funding section is unchanged. I think Brian’s concerns are addressed by Funding #2.

How is this looking to folks?

——

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

2. Administration should have no influence over the technical decisions of the IETF or over the technical contents of IETF work. The structure of the existing nomcom process should remain unchanged. (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 by default, 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. The IETF community should have mechanisms available for holding paid personnel accountable for the work they are expected to perform. Such mechanisms might include setting contract terms, conducting performance reviews, hiring and firing, or setting compensation. Whether to delegate these or other oversight tasks should be the choice of the IETF community.  

2. Oversight should be conducted transparently by default, within the limits of business confidentiality.


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. 

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.

Alissa


> On Apr 19, 2017, at 11:39 AM, Alissa Cooper <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.)
> 
> 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. 
> 
> 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). 
> 
> 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. 
> 
> 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.
> 
> Alissa
> 
> 
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20