Re: [Iasa20] 6635bis

Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 26 April 2019 14:07 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 457E712051D for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 07:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=jJWrkJ/V; dkim=pass (1024-bit key) header.d=yitter.info header.b=AoOBNxo/
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 j0xWfP9ek5TS for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 07:07:29 -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 A140112043C for <iasa20@ietf.org>; Fri, 26 Apr 2019 07:07:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 5A793BCC66 for <iasa20@ietf.org>; Fri, 26 Apr 2019 14:07:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1556287645; bh=fD+cmeoQ64XnvYkDfgM4aVKbzU+GhEe/siokiwhNVjg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jJWrkJ/VNDBSplbLOtn3FZZX6pWxRH2U21ZazPNSNPevCCF5AAgI64QI9Pie3DjZb 5euNC5HpzJZdYJEbi8xSFvcWc8GM3gcrDwxD647jqoUpinbGxH9V3fp1c2QoggT2Fi aNV1YtjTX51HMdQqGQq5+mgN+TFNEs5xd0UlF+sU=
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 hD15lRkUSpUJ for <iasa20@ietf.org>; Fri, 26 Apr 2019 14:07:24 +0000 (UTC)
Date: Fri, 26 Apr 2019 10:07:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1556287644; bh=fD+cmeoQ64XnvYkDfgM4aVKbzU+GhEe/siokiwhNVjg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=AoOBNxo/FG+Gjo7OaHrjV811wTiXQmpsqg0uLV3GYoxi86ela23cZEzSrmqKQHEo0 JSWTSln/AjYHd3njz2TKXQT1yzYv9Rn8wbWu+LYsK4lF3pFydPiaqYEK+/sr1WfsLV AllKyMyHSXmiqFwnDzLm5m8Ap47jHwSxayFdB3OI=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: iasa20@ietf.org
Message-ID: <20190426140722.ao4ki7hg3wrkm7uu@mx4.yitter.info>
References: <CCCFB260-660F-4CB9-AA4F-60F8B88465CB@sn3rd.com> <0A8ABED3-77B1-487C-BCCA-F1A4523DB9CF@gmail.com> <e1d5c5fe-42ff-91d7-ed77-7192fde27cd5@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e1d5c5fe-42ff-91d7-ed77-7192fde27cd5@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/YVTDkkBjciql1hp9DsGdJZOaXFE>
Subject: Re: [Iasa20] 6635bis
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 26 Apr 2019 14:07:43 -0000

Hi Brian,

No hat.

On Fri, Apr 26, 2019 at 03:40:51PM +1200, Brian E Carpenter wrote:
> 
> Specifically, I would regard that as a broken promise: not lightweight, not cheap.
> 

I don't understand this claim.

As near as I can tell, we are talking about a couple different options
for a function that, regardless, needs to be provided.  The cost of
doing this on an employee vs. a contract basis is, I'd say, quite
clearly an empirical matter that changes over time and that is
something best determined by an excecutive director in a position to
make that managerial decision.  So the "cheap" part does not seem to
be something you can assert in this way.

Similarly, we are talking about a couple different options for a
funciton that, regardless, needs to be provided, and provided through
the LLC in some way.  The way that minimizes the overhead of
provision, which is what I think "lightweight" means, seems to me to
be the sort of thing that only the relevant management can evaluate
based on (again) empirical factors before him or her.

So it seems to me that the promise can only be fulfilled by actually
permitting this flexibility.

Our experience with the old IASA design was precisely that too many
things were overspecified in the RFCs, and it seems to me that setting
things up this way so that the IASA2 function can proceed according to
sound and flexible management would be good.

What am I missing that you're seeing?

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com