[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