Re: [Iasa20] 6635bis

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 26 April 2019 04:53 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 B4CAB120431 for <iasa20@ietfa.amsl.com>; Thu, 25 Apr 2019 21:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 Gsnkyf_fsHEX for <iasa20@ietfa.amsl.com>; Thu, 25 Apr 2019 21:53:36 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 57F9F12044C for <iasa20@ietf.org>; Thu, 25 Apr 2019 21:53:35 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id o5so907037pls.12 for <iasa20@ietf.org>; Thu, 25 Apr 2019 21:53:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=x1RaHoqgV/ShuVDUnF7+nqSbGPdkqWs/CNnwMymeW28=; b=cnayZnMM7ALBcK8q97wfsuSc31zOdjFaQVvUHmrr7BUvpt/7H+S7lQrjpeYY+Pzdms cD6lZAyM8YuQBs1L3Gmz5dZxINXhK6xptj+CcMO8D/W23De9sM9xoMvC3md7w947ePMk NpZ99j9MsCav8FfpB9jlYbXGteZ37gw7CKUNnrVRNJPLNMq6FRVEKuxfwB7yG52P/NVo vjBBZmc9vgeQEMSHKIGYXOeVz661qMQ/hvMKNkkh/NFTlTS8QkwVZMY6nmtHF/CT8U+m lrCigYCjAxV60gkCb+LOB1Rqs3OLfJJ1NFCSG5uu+xcUQjblRzpMYGxAlfuxBzC9trET mNxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x1RaHoqgV/ShuVDUnF7+nqSbGPdkqWs/CNnwMymeW28=; b=Brh92gDQjv7z1GQUlZqiAKu1l/cZzf4JsASE2Rh5ERfPq+bNczeBFAt+qdqKrJKEvb x7O12FYC8dQ6fqA6FC5hc+2ba66FkFxTqZsSVO0oNDmwjehWOK2uhsMvXGapfKDqUqOc zbYp5iU6ISayOiMtfz1bDkHShN2TXjCIlDq2G9UpbMwLBvbjWdHFSf1gtbaAA/uUGCWq O3/BC0x8xJ/o7QlYxTZeDxUIXdANYhWiRmGQqllRyl0mY9aZAC7JEJBK6sMrNxZi9rCl RlRhOxA4tAYHJ2oonKZfjpvoT4z7IaFUIG0kq48y/KhqLZfBLmaMzimkciVxgsl8GaTK wylA==
X-Gm-Message-State: APjAAAWHkeVKKUL+i0ruzpGMygruulvBvS/WQhA6oZ6Dq9sPNqxrV/bw npg84M5S+L+jau5F/Q3KugyHCl0n
X-Google-Smtp-Source: APXvYqxpCt5ieMNJ/0HnjYfVKcwsGqAr6xTLKTU9Sh/MsCSeOvcRCMfmT4BKCU10vLLWKHSTJACUuA==
X-Received: by 2002:a17:902:f24:: with SMTP id 33mr37055398ply.44.1556254413968; Thu, 25 Apr 2019 21:53:33 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id f27sm25496135pfk.111.2019.04.25.21.53.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 21:53:32 -0700 (PDT)
To: Eric Rescorla <ekr@rtfm.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Sean Turner <sean@sn3rd.com>, IASA 2 WG <iasa20@ietf.org>
References: <CCCFB260-660F-4CB9-AA4F-60F8B88465CB@sn3rd.com> <0A8ABED3-77B1-487C-BCCA-F1A4523DB9CF@gmail.com> <e1d5c5fe-42ff-91d7-ed77-7192fde27cd5@gmail.com> <CABcZeBM+KrDD5MzT531qNwPnDaHBdwTx2VNyJ_cdWdTrXSJgaQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <a29702c6-7ce0-aa80-ffdb-97f7e2393d21@gmail.com>
Date: Fri, 26 Apr 2019 16:53:27 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBM+KrDD5MzT531qNwPnDaHBdwTx2VNyJ_cdWdTrXSJgaQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/STMMtv4OvvaGr_5Gx7Lry0eHJ1w>
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 04:53:44 -0000

Hi Eric,

On 26-Apr-19 16:06, Eric Rescorla wrote:
> n Thu, Apr 25, 2019 at 8:41 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:, that is clearly stated as a "paid contractor", as is the "RFC Publisher contractor".
> 
> 
>     To me it would make no sense to have *individuals* employed by the LLC who are part of either of those teams. So it's all or nothing: the Production Center and the Publisher would have to be either 100% in-house employees or 100% contracted out. But why we'd want the LLC, which we were promised would be lightweight and cheap, to starting hiring software and operations staff and buying or renting servers, is a bit beyond me.
> 
> 
> Hi Brian,
> 
> I'd like to dig into a few of the operational concerns you raise here.
> 
> First, you say that you think that the RPC and the Publisher should be either 100% in house or 100% contracted. In my experience, both as someone on the employer and employed side, it's quite common to have a mix of employees and consultants. For instance, you might have a staff of people who do the regular work and then occasionally hire specialists to do some work that you don't need a FTE for. Another example is when you have a temporary increase in load so you hire extra contract staff to fill in the gaps during the heavy period under the assumption that you'll let them go when the load decreases. It's also not uncommon to have some FTEs who manage a contract with a company which does most of the work. Can you say more on why you think this is unworkable?

If the team is *managed* within the LLC, but brings in contractors when it needs to, sure, that can be made to work, of course. With the usual potential for misunderstandings, of course. Managerially, I'd prefer to avoid it.

> Second, you contrast the idea of hiring staff to do these jobs with a "lightewight and cheap" LLC that contracts these functions out. Lightweight is kind of subjective, but as a practical matter, it's often more expensive to contract out tasks than it is to have them done by FTEs because you pay a premium for a short term engagement and/or one which is easier to terminate. Of course, if you want that flexibility then this is advisable, but in cases where you have a relatively steady base of work, then it's often cheaper to have FTEs (and, as above, fill in gaps with contractors).

That's true enough. But again, you have the LLC managing and doing the work. 
 
> Or am I misunderstanding you?

No. It's just that an LLC that performs and manages such work itself is very different from what I thought we'd agreed to do, which I understood to be an administrative entity. Definitely creeping featurism IMHO.

    Brian