Re: [Iasa20] draft-haberman-iasa20dt-recs-00.txt

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 18 July 2017 08:04 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 DBDF612ECF0 for <iasa20@ietfa.amsl.com>; Tue, 18 Jul 2017 01:04:02 -0700 (PDT)
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=YpwcYuLK; dkim=pass (1024-bit key) header.d=yitter.info header.b=L9bCQGcR
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 qUaqskECqiWd for <iasa20@ietfa.amsl.com>; Tue, 18 Jul 2017 01:04:00 -0700 (PDT)
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 B09F812ECC0 for <iasa20@ietf.org>; Tue, 18 Jul 2017 01:04:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 6D664BD996 for <iasa20@ietf.org>; Tue, 18 Jul 2017 08:03:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500365009; bh=5iIuOJ0J1SybUXsLXyzjcLJi4uLnOIK2imho9sLr5ZQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=YpwcYuLKPdrG56OtQwz0o3td4qLNXMnpUvVxHAybCixiOoY0xSMTCmLuiLq6Q4nMr r7+g+RG4zgn0OfqfDdcgMbeT1Nm4DWT5r4pcTV1KwpNJVHLteJknyYxvdlrlVzWrf2 aRkAILv1WEQXKWwny1I9D67INCsKAUbIjxUv8f9c=
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 GxWhSu02QmVX for <iasa20@ietf.org>; Tue, 18 Jul 2017 08:03:28 +0000 (UTC)
Date: Tue, 18 Jul 2017 04:03:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500365008; bh=5iIuOJ0J1SybUXsLXyzjcLJi4uLnOIK2imho9sLr5ZQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=L9bCQGcRg6O3Vz81M9r69Yr6i7Z4URt7fAN/J2YGQEUsr2iv0+ax0LEuEffNjm0OB Buab3zqnWvS15aWb3GIvaggoDJt8IFEO2TYL3njcpC9Myfug86ZDGFFPIDac3TsLlH Qc474Ss664+8M0OzU7V2KKZY8cJzb6TxDL/h4nco=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: iasa20@ietf.org
Message-ID: <20170718080236.tslrblyi3cas6izg@mx4.yitter.info>
References: <CABtrr-VtbzvTuBxV1y8910m8zPNi53CWVKd9NGpvAfprwc8iEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABtrr-VtbzvTuBxV1y8910m8zPNi53CWVKd9NGpvAfprwc8iEA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/o3dB4UcfpEBQYH2wrqIRLyPHTQw>
Subject: Re: [Iasa20] draft-haberman-iasa20dt-recs-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: Tue, 18 Jul 2017 08:04:03 -0000

Dear colleagues,

I'm unlikely to be in the IASA 2.0 BoF today.  I've read the draft and
I have some remarks. 

I want to thank the DT for their work and for getting this together so
quickly.  

On Fri, Jul 07, 2017 at 04:29:53PM +0000, Joseph Lorenzo Hall wrote:

> Feedback on the set of identified possible paths forward or options is the key
> question. Are any potential missed options? Also, feedback on the implications
> of options being considered would be welcome.

I think that the possible options, to a first order of approximation,
are right, but I fear that the trade-off discussion is a little too
flat.  In particular, I fear that the analysis does not place enough
emphasis on the achievability of each potential option, compared to
the advantages that each might bring.  This is in some sense similar
to Bob's worry about financial impact: one might like the advantages
of the most expensive option, but if one doesn't have the money then
one can't have it.  The same is true of time: if the difference in
transition time between two options is measured in years, that seems
like it will be a pretty important factor.  My own sense is that
anything we predict will take more than 18 months is a non-starter,
because of the term length of appointees.

This brings me to a second issue: the document is silent on the term
length of IASA++/board members, but I think that issue has to be faced
squarely.  We have a serious structural problem in that the oversight
function ought to be responsible for longer-term considerations, but
as a practical matter they can't have a horizon of more than 2 or
maybe 3 years because of appointment lengths: nobody who makes a
current plan can say with any assurance that they'll be around when a
plan takes effect.  We already see this problem explicitly in
controversies over meeting site selection, but I think the problem is
a deep one.  If we don't tackle this problem as a first-order one,
we'll miss it in any arrangements that we make.

Finally, and perhaps related to the first issue, I disagree very
strongly with the claim that we should not try to separate the Trust
membership from the IAOC-or-successor membership at the same time we
are making other changes.  On the contrary, I think the linking of the
Trust is a really serious structural problem that could easily hurt
our ability to do something about IASA if we do not plan explicitly to
address it.  The Trust once was responsible only for property that
affected the IETF directly, but that is no longer true.  We need to
avoid creating the conditions under which issues that people have with
the Trust composition constrain our freedom of movement in what we can
do to our administrative support arrangements.  At the same time, the
overloading of the IAOC membership with Trust responsibilities means
that the workload arrangements are quite bad if there is a lot for the
Trust to do; so fixing that overloading ought to be an important goal
in this effort.

I think that the DT draft is a good start, and I look forward to
continued progress.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com