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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 20 March 2017 22:31 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 F1591124B0A for <iasa20@ietfa.amsl.com>; Mon, 20 Mar 2017 15:31:36 -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 MKBlPotnJiTU for <iasa20@ietfa.amsl.com>; Mon, 20 Mar 2017 15:31:34 -0700 (PDT)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 DA4A6124D68 for <iasa20@ietf.org>; Mon, 20 Mar 2017 15:31:33 -0700 (PDT)
Received: by mail-it0-x22f.google.com with SMTP id 190so9045094itm.0 for <iasa20@ietf.org>; Mon, 20 Mar 2017 15:31:33 -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=DPUg5t93FDyuZufGpPnPro6KHLKCOFqIzcRNVsFlVqo=; b=o2/sI28oNL6l53f/+TsYsbPjyo8wK8BJZi+9AzmIWwmtpEOL4su43f7mNO+55iTErL 3SupG/yu94aqEccQkYm39CyHmRT3xy/N3LNMdWcturSDWKhFedFlycI+oIMUKFHzpcH0 MBNwkoHqJKNzEf/N6GJhQ3U5pXzJadLnWEI7bpZkswCGF1A+BOhxm8jyphPMpaUEBEF4 tkBZSqmWh07fg0/VbeqykfMQ1VlZVsa3/0NDCoyXT6PWAOjEZDhZZJARJR7dAkqry0DH EnMEWpL3B0K79txX3h99WjWKYhgrt6c82PRYgX18GsCka4yiqddLJchv2lDxPDUQdN90 0PMA==
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=DPUg5t93FDyuZufGpPnPro6KHLKCOFqIzcRNVsFlVqo=; b=CTM7GwO97zRv1VtL3xLUJl9PpLGsx0mLhGmZPVmK3QLoU0+wC5BscNcYZ/ntr1md0X UvTm153LHy2zQVtVhhn8oImpzcSAVNOryP1pLwHEmF1JKcIq2P6+wy8XhMjU9FHa3Y+F XLMSVR6M/sbvdfDvM3Oi14aC9eEhcedENVD6mJR0AzQECFpqaSgpHp92Zw/w8b4M1Y77 eq+Ue2Q+KkFKkxQnhdQm7R+dvHquZIWkS+I5PjYR8Fm50anYCiWk79YzLjP6Nap05BFw HjQwFckCz6lxro1BhgZfRg0PuCwMyUiptw7RX3fyy2DdgxN+HKbv1UPekKK9R1c87Ou6 HIDQ==
X-Gm-Message-State: AFeK/H28qPItNBZENVEKNDrg/I8rEBdWlPjQ1bel2hGTuPijAJgyCPMvKQH4wVgXPHXXQA==
X-Received: by 10.36.121.136 with SMTP id z130mr408737itc.66.1490049092835; Mon, 20 Mar 2017 15:31:32 -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 i190sm1993160itf.11.2017.03.20.15.31.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 15:31:32 -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>
Cc: iasa20@ietf.org
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <b70c1e1b-1e9d-e7cc-5ffa-ccc69cd9c50e@gmail.com>
Date: Tue, 21 Mar 2017 11:31:34 +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: <A3C09A9E-AB39-4ABD-8B0B-76C7F3249C45@cooperw.in>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/4_P6F2VoC5warN5ZVJs7yRexKNg>
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: Mon, 20 Mar 2017 22:31:37 -0000

On 21/03/2017 09:19, Alissa Cooper wrote:
> Hi Brian,
> 
> Some responses to your comments below. These are directed at the general discussion topics for the list, not meant to be funneled into edits to the workshop report.
> 
>> On Mar 20, 2017, at 9:29 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> Hi,
>>
>> Thanks for this report, very useful for those who couldn't attend
>> the workshops. Here are some personal thoughts, picking on a few points.
>>
>>>   o  The line between the IETF and ISOC is not organizationally clear-
>>>      cut, 
>>
>> Better get used to it. Since the IETF is intentionally not incorporated
>> and intentionally run by a rough consensus process, that line will never
>> be clear-cut.
> 
> You seem to be assuming constraints about what changes may or may not be made as a result of this IASA 2.0 discussion. You might not want the present organizational arrangements to change or you might be of the opinion that they will never change, but that doesn’t mean that such changes are off the table. The present phase is one of problem identification. I don’t think any solution options are off the table, and I wouldn’t say “never” about any particular change at this point.

Fair enough that nothing is off the table, but I'd be prepared to take a side bet about this aspect ;-)

> 
>>
>>> 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. IASA is *supposed* to be professional, so surely we always expected the IAD to call on professional help. Of course, I expect a lot of this is invisible in the budget.

> I can tell you that until a few weeks ago my guess would have been way low. Their work in support of the IETF isn’t documented anywhere, which is natural within the internal context of ISOC because they are co-workers who are working with their co-worker who happens to be the IAD. But because of the organizational blurriness, their work is not transparent to the community.

Yes, that I certainly agree with.

> 
>> I'm not saying there are
>> no transparency issues, but I don't understand why they are caused by
>> the unclear "line".
>>
>>> allocation of staff time and priorities, 
>>
>> Are you saying that the IAD doesn't get enough staff support *due
>> to* the unclear line?
> 
> The point of this is not that the IAD doesn’t get enough support (that’s a different valid point), but that who is deciding about allocations and priorities is not clear and perhaps not optimal. Again just to take an example, after several years of having Greg Wood help out with IETF communications, during which time I’m not sure how clear it was to anyone who was deciding how much time he should spend on that or what he should be devoting that time to, we for the first time have a specific time allocation from him, specific budget, and specific priorities he is working towards, with agreement from his management at ISOC. And his case is far ahead in terms of clarity and agreement between the IETF and ISOC as compared to some other ISOC staff and programs, I would say.

Understood. More light on this would be valuable.

> 
>>
>>> budgeting,
>>
>> Again, why is that  due to the unclear line? The IETF has no budget,
>> since it isn't incorporated. The ISOC holds our budget and it's
>> run by the IAD. I don't see the lack of clarity here.
> 
> If this is really your position, would you argue that the IETF shouldn’t be publishing its own budgets and financial statements at all (as it’s been doing for a dozen years)? If your view is that there is no confusion because it’s all ISOC’s money anyway, there is no point in publishing separate budgets and financial statements for the IETF.

No, not at all, of course they should be published. But the IETF accounts *are* the IASA accounts and that's a subset of the ISOC accounts. 

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

> 
>>
>>> and clarity of who is responsible for what.
>>
>> Yes, I agree that the line between volunteer and staff effort can be
>> unclear - that's a classical (and insoluble) problem in non-profits.
>>
>>>   o  Having ISOC represent the IETF to sponsors and donors -
>>>
>>>      *  creates confusion about why the IETF does not represent itself,
>>
>> Actually I think the issue is a bit more contorted. I don't think that
>> companies are at all confused.
> 
> We have heard from potential donors and from those soliciting donations that they are, indeed, confused about why they are being pitched by one entity to give money to another “entity," albeit not a legally separate one.

Right. That should be explained in the first paragraph of the pitch.

> 
>> It's just that they have mixed motivations.
>> The technical managers want influence in the IETF; the engineers want
>> to help the IETF; the marketing people want publicity. 
>>
>> But indeed, the IETF leadership needs to work hand in glove with
>> ISOC on this. I'm not sure what it has to do directly with IASA, though.
>> IASA's job description doesn't include PR.
> 
> I would be interested to know whose job description in the IETF leadership does include PR, in your view. The IETF Chair has taken on some of this responsibility in the natural course of sponsor/donor relations, but it’s not obvious to me that that is actually specified clearly anywhere in a way that matches reality or the workload that the chair can realistically bear.

I fully agree. But the fact is, and I bet every past chair will confirm it, the outside world sees the IETF Chair as the figurehead, however hard one tries to avoid it. So you are kind of stuck with it, like it or not. And also, as noted in the workshop report, it's essential that whoever does the PR is technically competent. Yet PR does need professional support too, especially the fund-raising part. So this isn't easy to get right. I have no easy answer.

>>
>>>                      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 that's not new; this is a large part of why ISOC was created.

> 
>>
>>>   The
>>>   commentor further asked: who defines the contents of ISOC activities
>>>   that are visible to the outside world?
>>
>> ISOC of course. Who else? ISOC's role is far broader than the IETF.
> 
> I believe the point here was about ISOC’s IETF-related activities. For example, the fellows programs or the sponsorship pitches.

If so, yes, this gets back to my hand-in-glove comment. So we can say
(1) Outreach, PR & fundraising are not part of IASA's defined role
(2) They need both professional support (presumably from ISOC) and IETF leadership input
(3) The outside world must not see any gap between the ISOC and IETF parts of this.
I can see that there's work to do on this.

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

>>
>>>   A participant said that, although IAOC committees are listed on the
>>>   IAOC website (https://iaoc.ietf.org/committees.html), there is a lack
>>>   of documentation about how the committee participants are chosen.
>>
>> And so what? If the IAD and IAOC don't have the right to co-opt their own
>> subcommittees as needed, we are in a funny place. I seem to have seen
>> calls for volunteers from time to time.
>>
>>>   A Workshop participant noted that, in order to understand how the
>>>   committees work, one needs to understand...
>>
>> I don't understand the point of this. Why does the community need to
>> understand how the subcommittees work? They don't answer to the
>> community, they answer to the IAOC.
> 
> The committees are comprised in part of community members, and part of the point of having them is to have more community members able to provide direct input into the IETF’s administration. If most participants don’t understand the committees, it’s hard to find people who can contribute to them.

True. If most participants don't read https://iaoc.ietf.org/committees.html, they won't understand the committees, but whose fault is that, actually, and what more can we do than publish the information?

Rgds
   Brian

> 
> Best,
> Alissa
> 
>>
>> Regards
>>   Brian Carpenter
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Regards
>>   Brian Carpenter
>>
>>
>>
>> On 14/03/2017 03:28, internet-drafts@ietf.org wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>        Title           : Report from the IASA 2.0 Virtual Workshops
>>>        Authors         : Joseph Lorenzo Hall
>>>                          A. Jean Mahoney
>>> 	Filename        : draft-hall-iasa20-workshops-report-00.txt
>>> 	Pages           : 17
>>> 	Date            : 2017-03-13
>>>
>>> Abstract:
>>>   This is the Workshop Report for the IETF Administrative Support
>>>   Activity 2.0 (IASA 2.0) Virtual Workshops, held on 28 February 2017
>>>   at 1100 UT and 1600 UT.  The original IETF Administrative Support
>>>   Activity (IASA) was created ten years ago, and since has been subject
>>>   to some reflection.  In the intervening years, there has been
>>>   considerable change in the necessary tasks of IETF administration and
>>>   in the world around the IETF, and in how the IETF raises funds and
>>>   finances its work.  The IASA 2.0 process seeks to address which
>>>   administrative arrangements will best support the IETF going forward.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-hall-iasa20-workshops-report/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-hall-iasa20-workshops-report-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa20
> 
>