Re: [Iasa20] 6635bis
John C Klensin <john-ietf@jck.com> Mon, 29 April 2019 16:04 UTC
Return-Path: <john-ietf@jck.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 648F61203C6 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 09:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4eTyDbr5vSc7 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 09:03:58 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BAB1203BE for <iasa20@ietf.org>; Mon, 29 Apr 2019 09:03:58 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hL8l3-000J45-7n; Mon, 29 Apr 2019 12:03:57 -0400
Date: Mon, 29 Apr 2019 12:03:51 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>
cc: iasa20@ietf.org
Message-ID: <43D5554EEDD8418CC4E0C195@PSB>
In-Reply-To: <20190428034407.4EC3B20130AC13@ary.qy>
References: <20190428034407.4EC3B20130AC13@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/tVWZHMsv_I4_Po7QZpTNGSTR6oE>
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:04:02 -0000
--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] 6635bis Sean Turner
- Re: [Iasa20] 6635bis Joseph Lorenzo Hall
- Re: [Iasa20] 6635bis Richard Barnes
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Mike Bishop
- Re: [Iasa20] 6635bis Eric Rescorla
- Re: [Iasa20] 6635bis Ted Hardie
- Re: [Iasa20] 6635bis Bob Hinden
- Re: [Iasa20] 6635bis Martin Thomson
- Re: [Iasa20] 6635bis John Levine
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Eric Rescorla
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Stephen Farrell
- Re: [Iasa20] 6635bis Alissa Cooper
- Re: [Iasa20] 6635bis Joseph Lorenzo Hall
- Re: [Iasa20] 6635bis Andrew Sullivan
- Re: [Iasa20] 6635bis Christian Huitema
- Re: [Iasa20] 6635bis Russ Housley
- Re: [Iasa20] 6635bis Livingood, Jason
- Re: [Iasa20] 6635bis Livingood, Jason
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis John Levine
- Re: [Iasa20] 6635bis Richard Barnes
- Re: [Iasa20] 6635bis Stephen Farrell
- Re: [Iasa20] 6635bis John R Levine
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis John R Levine
- Re: [Iasa20] 6635bis John C Klensin
- Re: [Iasa20] 6635bis S Moonesamy
- Re: [Iasa20] 6635bis Salz, Rich
- Re: [Iasa20] 6635bis Richard Barnes
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Bob Hinden
- Re: [Iasa20] 6635bis John Levine
- Re: [Iasa20] 6635bis Stephen Farrell
- Re: [Iasa20] 6635bis Alissa Cooper
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Joseph Lorenzo Hall
- Re: [Iasa20] 6635bis Alissa Cooper
- Re: [Iasa20] 6635bis John C Klensin
- Re: [Iasa20] 6635bis Ted Hardie
- Re: [Iasa20] 6635bis Richard Barnes
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Richard Barnes
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Alissa Cooper
- Re: [Iasa20] 6635bis John C Klensin
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Alissa Cooper
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Ted Hardie
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Sean Turner
- Re: [Iasa20] 6635bis Eric Rescorla
- Re: [Iasa20] 6635bis - RPC contracting Joel M. Halpern
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Stephen Farrell
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Richard Barnes
- Re: [Iasa20] 6635bis Adrian Farrel
- Re: [Iasa20] 6635bis Brian E Carpenter
- Re: [Iasa20] 6635bis Richard Barnes
- Re: [Iasa20] employees and contractors in 6635bis John Levine
- Re: [Iasa20] employees and contractors in 6635bis Stephen Farrell
- Re: [Iasa20] employees and contractors in 6635bis John R Levine
- Re: [Iasa20] employees and contractors in 6635bis Stephen Farrell
- Re: [Iasa20] employees and contractors in 6635bis Eric Rescorla
- Re: [Iasa20] employees and contractors in 6635bis Stephen Farrell
- Re: [Iasa20] employees and contractors in 6635bis Stephen Farrell
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] employees and contractors in 6635bis Eric Rescorla
- Re: [Iasa20] employees and contractors in 6635bis Joel M. Halpern
- Re: [Iasa20] employees and contractors in 6635bis Stephen Farrell
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] employees and contractors in 6635bis Bob Hinden
- Re: [Iasa20] employees and contractors in 6635bis John R Levine
- Re: [Iasa20] employees and contractors in 6635bis Bob Hinden
- Re: [Iasa20] employees and contractors in 6635bis Sarah B
- Re: [Iasa20] employees and contractors in 6635bis Alissa Cooper
- Re: [Iasa20] 6635bis Alissa Cooper
- Re: [Iasa20] 6635bis Joel Halpern Direct
- Re: [Iasa20] 6635bis Ted Hardie
- Re: [Iasa20] 6635bis Joel M. Halpern
- Re: [Iasa20] 6635bis Alissa Cooper