[Iasa20] Some comments on draft-haberman-iasa20dt-recs-01
Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 08 November 2017 21:40 UTC
Return-Path: <ajs@anvilwalrusden.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 5CAFF126D85 for <iasa20@ietfa.amsl.com>; Wed, 8 Nov 2017 13:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Z42/VYEc; dkim=pass (1024-bit key) header.d=yitter.info header.b=iKU8nDRC
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 xUehnjYUhomQ for <iasa20@ietfa.amsl.com>; Wed, 8 Nov 2017 13:40:45 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0EE1252BA for <iasa20@ietf.org>; Wed, 8 Nov 2017 13:40:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id C96D4BF56B for <iasa20@ietf.org>; Wed, 8 Nov 2017 21:40:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510177214; bh=OTm6PtwDSEIM3Ok0uZo3GKQEifw/8nATmcT8X5Qunss=; h=Date:From:To:Subject:From; b=Z42/VYEcgD64tf9T/Uhqt5knicfX0nIdoA3VwRRJyqtlrdP/jqj7bpfcc1UDdkLqq 8uikfQwhMU9vfcO5tv/wLzywiYt4mDwiUOdqrkqPe5TDA12CWafZmBlG/AOV3nwtbi 27RWZxoycyYBUssbYUjgn3AXrMzvuvVIm9SuUnsY=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxDCoszufeLo for <iasa20@ietf.org>; Wed, 8 Nov 2017 21:40:12 +0000 (UTC)
Date: Wed, 08 Nov 2017 16:40:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510177212; bh=OTm6PtwDSEIM3Ok0uZo3GKQEifw/8nATmcT8X5Qunss=; h=Date:From:To:Subject:From; b=iKU8nDRCqPOdKLd2cne67sOP4T7atQ4rn6KYo6BY4nOQOftkf7dkjkimxovjxpL57 rzA9+qL2q2tuPWhgi50FqIDy3h6X8No/BU3cmUV36nYggBtOO6B4dBFpXBylRyzMi1 FeRuxQU/h+mw5z4FBmuW07stmJ4lREFUSQkpmtTQ=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: iasa20@ietf.org
Message-ID: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/L-29VSP57ZBadIpYQZCkOYlNJtI>
Subject: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01
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, 08 Nov 2017 21:40:48 -0000
Dear colleagues, I have read draft-haberman-iasa20dt-recs-01. I have some comments. These focus mainly on the "three alternatives" questions for now, mostly because that seems to be the most pressing set of questions. TL;DR: I do not think that IASA++ delivers what we need, and I don't think it's good for ISOC either. Given the ways in which the IETF and ISOC have both grown, it is not obvious to me that the historic close link is one that needs to be maintained, and the cleanest approach would obviously be to set up a new separate organization. For practical reasons (including the lack of obvious organizational expertise and the reality of available funds for the IETF), I don't think that is a good idea, and so I am left with the subsidiary organization choice by default. Finally, I think that in tackling all of this there remain some internal IETF-only organizational knots that have never been unwound, and I think they need to be as well. Supporting arguments below. 5.1.1 describes IASA++. There is a critical sentence in that subsection that describes a central issue: "The IETF needs to be able to make its own administrative decisions independent of ISOC." If we take this to be true, then IASA++ is simply not an option. As the draft illustrates, the present IASA structure (and therefore any IASA++ approach) has the automatic problem that, structurally, the IETF simply cannot possibly be in control of what it is doing. This is not to cast aspersions on the good work, positive effects, or correct intentions of anyone who has been involved in IASA for the past 10 years. But ISOC employees are going to be measured according to ISOC requirements, not those of the IETF. ISOC contractual terms are going to be determined by ISCO requirements, not those of the IETF. And so on. We put both ISOC and the IETF in an awkward position when we try to pretend that one of them doesn't exist and doesn't have independent needs. I am particularly concerned about the staffing issue. The IAOC's current job is oversight of the IAD and under IASA++ it might get more such oversight responsibilities. But the difficulty is that the IAOC is not ultimately able to make the normal decisions a supervisor can: hiring and firing, promotion and pay. For many years the IETF was fortunate to have a dedicated person filling that staff role, but there's nothing guaranteed about that and the resulting chain of responsibility does not meet the community need for transparency -- particularly when IAOC terms may be only two years long. I also don't see how this model serves ISOC well. ISOC has to face its own pressures to evolve, and it has legal and policy imperatives that the IETF (which in this model doesn't have them) will likely fail to comprehend. There may be one advantage of that legal fiction, however, that is worth attending to. Effectively, because the IETF is just "an activity" rather than an organisation of ISOC, the lack of independent legal existence means that legal issues tend to entangle the IETF less directly than they otherwise might. If the above reasoning stands, then it seems obvious that in a perfect world the IETF would set up its own organization and carry on from there. There would be no bar to collaboration with ISOC wherever it was appropriate, and indeed such collaboration could well be more effective than the state of affairs today. (In my experience dealing with "the outside world" as IAB chair during the IANA stewardship changes, way too many conversations ended up in a ditch trying to explain the organizational boundaries. The distinctions might well be plain to us, but they are foreign and strange to others; in the worst cases, our views were dismissed as just another iteration of the same ISOC positions people had already heard. But more on this below.) At the same time, the sometimes awkward ties that exist because of the administrative arrangements could be done away with, freeing both organizations to work in ways that are best for each. But it would be perverse to imagine that the IETF is in any way prepared to undertake that sort of task. First, it's a lot of work, and that's work that we would not spend on pressing technical and architecutral issues also facing the network. (Not to put too fine a point on it, I did not want to spend most of my time on the IAB thinking about the dark corners of inter-organizational theory in the face of some unco-operative community or constituency. That was the straw I drew, but I wouldn't wish it on others.) Second, it requires a realistic and long-term plan for financing the effort, and we are nowhere near a position to do that. Finally, we would need evidence that we have the people required to make it work. I don't think we do: filling the IAOC positions has not been easy for some years now, and several of them are filled automatically by virtue of some stuckee being in another seat. I am therefore persuaded that an ISOC subsidiary would be better. A subsidiary can conclude agreements with the parent organization pretty easily, which means that some of the transition could be undertaken relatively painlessly (by contracting explicitly for services the IETF already gets implictly through its relationship with ISOC). Such an approach allows the two organizations also to formalize a number of the improvements that would be required for IASA++ anyway; and by formalizing them, we get additional transparency into how that part of the relationship works. It also allows the two organizations to develop the policies and procedures necessary for each, thereby permitting continued evolution in appropriate directions. And it sets up clear boundaries of responsibility, so that the next time we need to analyze our administrative arrangements our first problem isn't to pick apart which arrangements are ours and which are someone else's: the definition will be in contracts. The challenges of governance of this new subsidiary remain a problem, but again the appointment of a board gets a certain amount of benefit from being a subsidiary: I'd expect any subsidiary to get some board members appointed directly by the parent, and I should imagine the same would happen here. It's the parent's money, after all. Finally, I think it is important in tackling this work to note that there are some blurry lines entirely under our own control, and if we're going to fix the administrative arrangements we're going to have to clean those up too. Some of these are referred to in draft-daigle-iasa-retrospective-01. In general, I think there is a problem of responsibility and authority between IASA and the IESG (or on a couple issues the IAB), and it would be nice if we made those interfaces a little cleaner while we're in there. (For instance, I can think of at least once where IASA was blamed for meeting imperatives that were not its own creation: IASA gets the responsibility, but it doesn't always have the authority to act independently.) If we are going to set up a corporation with a board, we are not going to be able to allow that to persist without having some nasty fights. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
- [Iasa20] Some comments on draft-haberman-iasa20dt… Andrew Sullivan
- Re: [Iasa20] Some comments on draft-haberman-iasa… Bob Hinden
- Re: [Iasa20] Some comments on draft-haberman-iasa… Brian E Carpenter
- Re: [Iasa20] Some comments on draft-haberman-iasa… Andrew Sullivan
- Re: [Iasa20] Some comments on draft-haberman-iasa… Andrew Sullivan
- Re: [Iasa20] Some comments on draft-haberman-iasa… Richard Barnes
- Re: [Iasa20] Some comments on draft-haberman-iasa… Bob Hinden
- Re: [Iasa20] Some comments on draft-haberman-iasa… Richard Barnes
- Re: [Iasa20] Some comments on draft-haberman-iasa… Brian E Carpenter
- Re: [Iasa20] Some comments on draft-haberman-iasa… Bob Hinden
- Re: [Iasa20] Some comments on draft-haberman-iasa… Ted Hardie
- Re: [Iasa20] Some comments on draft-haberman-iasa… Andrew Sullivan
- Re: [Iasa20] Some comments on draft-haberman-iasa… Andrew Sullivan
- Re: [Iasa20] Some comments on draft-haberman-iasa… Brian E Carpenter
- Re: [Iasa20] Some comments on draft-haberman-iasa… Jari Arkko