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 >
- [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