Re: [Iasa20] 6635bis

Richard Barnes <rlb@ipv.sx> Mon, 29 April 2019 16:10 UTC

Return-Path: <rlb@ipv.sx>
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 3CDA412034E for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 09:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 pHridLbjPEoz for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 09:10:41 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 81FFB120168 for <iasa20@ietf.org>; Mon, 29 Apr 2019 09:10:41 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id u15so9095244otq.10 for <iasa20@ietf.org>; Mon, 29 Apr 2019 09:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NRS33FEoeA8bwjyc2SAcg+fqUJ8Ovi8cYygEwZ2Y5s0=; b=QZcm1GTVccMpTeWPi3ioxIVrudEXiuvqcQCvXPlejeiO/IMCtDirY46j2VjbhQoXH1 4184IDqSnknp2zI7+AT1lKVJmd0gB9/0rn+TuEmqeHPr1t1JOffGtHK4ZOBVJ8J+8TqR fsy6rBImr/p2LblJ6gSGWNv9jQ60f3I5kdwCNwupr/sA8zcCvO0EedhydYKg5QduIbRg OVbAqIUvb1LyW1Do/Ixvjnjz0/geixnH++GVvu28+9gHE+z7nJ2fEU5XAuSWNPkN72OJ 1Rh/kgO2EJbn9KDs8eOwZERQUBRGcFMQrDxenL39rcYmzwXaxGsBTu0lXJfhrqVEPIrJ 4uhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NRS33FEoeA8bwjyc2SAcg+fqUJ8Ovi8cYygEwZ2Y5s0=; b=jtyBCYwLc8C05bWEetCEp2TvbtZEXoIpm0QkVNo0Qd0hSy2JJ+r7GOijfYKg5MUhTD ELiaa2jAh/M8NaOIxviM2XrOkDmEbRTKahJwgP4l7bYtvUMkLkMk/F8y1X9mmLs8E7jH f3NHngPWv1yI7sG3fV1HAhaPNKBe8Wb1usq9jr1waK1PuzCo7Njn0mXxKeoeaYSTRi1A yAyFHyluV0a43UJcaxLMiNtBLfUOw8n5DFpBYXzS9AaLlJp/yXLEvj30aLDh1SyN/Heg AgZEIkYUAVtmzx6aNdHLpU7SfcABPbU60TRz8ahGJJC/t5k6YT+sSEJ38IsyxGTz9zfr ne6w==
X-Gm-Message-State: APjAAAUUQpgortuQWFFAbfw/zDvk39SPY9gr3fJDb6SXsJFI8Cv95nqo 0cxbboMAJ0jdbNM82U9r4xvWW8XkGLinMB52RVKsUx/qPXM=
X-Google-Smtp-Source: APXvYqxtDza6/+aST0pcn04jxKtOnXtxO1BIxIpzVeZtHa0ps/fnA7DCFQtS2Qd7XX4TcL2Cnsn2xwh7gyTNMpub+KM=
X-Received: by 2002:a9d:5787:: with SMTP id q7mr7972692oth.162.1556554240461; Mon, 29 Apr 2019 09:10:40 -0700 (PDT)
MIME-Version: 1.0
References: <20190428034407.4EC3B20130AC13@ary.qy> <43D5554EEDD8418CC4E0C195@PSB>
In-Reply-To: <43D5554EEDD8418CC4E0C195@PSB>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 29 Apr 2019 12:10:13 -0400
Message-ID: <CAL02cgSnpP1pA=mStxkEahG8rmqEFL0CkAVkgq1b3mp_Kif9Sg@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: John Levine <johnl@taugh.com>, IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000093a1070587ad8643"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/jxJ_wxOKHDWO9xjHL7iJ_2_-30E>
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: Mon, 29 Apr 2019 16:10:44 -0000

John: I'm confused by this "lean and mean" point.  How is an organization
with a collection of contractors (RSE, RPC, etc.) leaner and meaner than an
organization with an equivalent number of employees?

--Richard

On Mon, Apr 29, 2019 at 12:04 PM John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Saturday, April 27, 2019 23:44 -0400 John Levine
> <johnl@taugh.com> wrote:
>
> > As it stands the LLC can always fudge it by turning an
> > employee into a nominal contractor by running him or her
> > through a body shop but that seems silly.  The arguments
> > against having employees all seem to be of the form that
> > organzation X or situation Y had or has employees who are
> > poorly managed, but that seems to me to mistake the symptom for
> > the problem.
>
> John, just to stress something I think is important --and
> important whether this is the WG's decision or the WG is
> supplying input to the IAB, within the WG's responsibility, or
> something else [1] -- I don't believe your statement about the
> arguments is correct.  As he pointed out, Stephen has raised the
> argument before and I don't believe his position is covered by
> your description.  In different ways, Brian, Bob, Joel, myself,
> and others have addressed variants on the issue.  Each of us
> have had slightly different perspectives or expressed our
> concerns in different ways, but I don't believe any of those
> comments have been dependent on "employees who were poorly
> managed" even if some have included examples of that type.
>
> Even if that were the only issue, the IETF LLC is sooner or
> later almost certainly going to face tradeoffs in selecting
> permanent Executive Directors.  Those tradeoffs may be with
> costs or benefits (assuming the budget is not unlimited) or
> skill set, types of experience, management skills versus
> financial skills versus understanding of the work the IETF
> actually does, etc.  While I assume the LLC Board will do its
> best, finding the perfect person may not always be possible and,
> partially as a result, I don't think any of us can guarantee in
> advance that the person chosen will always be a superb manager
> of people as well as a superb manager of contracts [2].
>
> However, I believe that one of the community's assumptions about
> the IAOC and IASA 1.0 had little or nothing to do with the
> corporate entity concern.   That assumption was the desire to
> keep the organization and structure as "lean and mean" as
> possible, with few employees (or contracted semi-permanent staff
> [2]) as possible.   I see that assumption as having been carried
> forward into IASA 2.0.   If the assumption has been changed,
> that is almost certainly a matter for this WG to discuss.  If
> the assumption is at all controversial, then I think the WG has
> an obligation --one that falls well within its charter -- to
> spell it out in some appropriate document.  More broadly, if the
> LLC decided it wants to start bringing a significant number of
> functions in-house and hiring significant staff (same
> qualification, see [2]) to carry them out, I think it would be
> entirely appropriate and quite desirable for its Board to have
> to come back to the IETF, discuss the reasoning, and ask
> permission [3].
>
> I think that what I mean by "lean and mean" is similar to what I
> believe Brian intended by "lightweight and cheap".   It isn't
> about whether an individual whom the LLC needs to retain is
> retained as an employee or as a contractor.   It is very much
> about whether the number of people who end up being treated as
> staff  (or people reporting to people treated as staff) by the
> Executive Director become large enough to form a club, large
> enough to require the Exec Dir or LLC Board to start thinking
> about HR or employee relations programs or staff, or other
> evolutionary changes that increase the probability of personnel
> employed by (or contracted by) the IETF LLC beginning to set or
> manipulate policy on their own.  That risk exists even when the
> number of employees (or direct contractors) is only one (I know
> of at least one example where I suggest that IASA 1.0 --and the
> IETF-- suffered from that problem) but a great deal of
> experience elsewhere with organizational behavior (with or
> without bad management) suggests the risk rises much more
> quickly that linearly with organization size.   If you believe
> that the IETF LLC will, because of some inherent virtue, be
> exempt from those pattern or organizational development and
> evolution but it seems to me that, like a plan to improve
> networking by having traffic exceed the speed of light by a bit,
> those suggesting that we will be ok because it hasn't happened
> here (yet, or very often) have the obligation to demonstrate why
> those fundamentals will not express themselves in this case.
>
> best,
>     john
>
>
> [1] I'm also a little troubled by the "this is an IAB document"
> discussion, but not for the reasons Alissa and others have
> cited.  At least for the purposes of this discussion I'm fine
> with the IAB getting community input and then making decisions
> about hiring and most strategy for the RFC Editor.  However, if
> a decision the IAB might make, or is considering making, would
> change or expand the functions or authority of the IETF LLC or
> its leadership, it seems to me that would lie squarely within
> the the scope and responsibility of this WG and IETF consensus
> more broadly.  If such a change were made using the IAB's
> authority, especially if it were supported by the assertion that
> the IAB is not a consensus body or responsible to IETF
> consensus, it seems to me that would violate assumptions and
> provisions that go directly back to POISED and the Kobe affair.
>
> [2] As we have discussed separately, I think we are in agreement
> that the difference between an employee and a contractor on an
> individual contract who is treated as one is almost
> non-existent, but I don't see that as the key issue here despite
> several postings about it.
>
> [3] I think trying to define how many hires (or consultants on
> individual contracts treated as employees) are permitted would
> quickly deteriorate into the kind of overspecification you and
> others have decried (I agree that is not desirable).   But that
> is different from establishing clear guidance that, if the LLC
> decides to start hiring multiple people, its Board is obligated
> to come back to the community for discussion and before doing so.
>
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>