Re: [Iasa20] 6635bis

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 29 April 2019 18:09 UTC

Return-Path: <jmh@joelhalpern.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 C64BF1205F5 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 11:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=joelhalpern.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 YANjRy6WI3r0 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 11:09:32 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0F01205D3 for <iasa20@ietf.org>; Mon, 29 Apr 2019 11:09:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 44tCNX0NH3zyfr6; Mon, 29 Apr 2019 11:09:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1556561372; bh=mv+GxFT71J9o+fUwpUa2g4dVxPUiERA/In0ky62z0IY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EQ4Np+i/uu8khK7GAuIgpe21IMRqH4jX8oIXl6NHxycwzlqW7UF7NzJv7gRj1cIIB 8PK4l/vVZFYqBvCR5eAiFwkXeUFJuOM0qlji+hTUXaaervRWv67IrP/rdFlipiYwlC vkrlplImc7CGWY3BQ7eNBdnl/vRYKxV/gd7p0fdQ=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 44tCNT41kszyfr4; Mon, 29 Apr 2019 11:09:29 -0700 (PDT)
To: Richard Barnes <rlb@ipv.sx>
Cc: IASA 2 WG <iasa20@ietf.org>
References: <20190428034407.4EC3B20130AC13@ary.qy> <43D5554EEDD8418CC4E0C195@PSB> <CAL02cgSnpP1pA=mStxkEahG8rmqEFL0CkAVkgq1b3mp_Kif9Sg@mail.gmail.com> <58df809e-44dc-88b8-ff11-1c7ef1ccb8f6@joelhalpern.com> <CAL02cgTCqPhcHTMn7+nEpH7mtEg0f_YzqxdjBWz7QvsKekGvow@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <47df6dff-9faf-05e8-d964-443991aff81e@joelhalpern.com>
Date: Mon, 29 Apr 2019 14:09:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAL02cgTCqPhcHTMn7+nEpH7mtEg0f_YzqxdjBWz7QvsKekGvow@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/40W7mHTZw4MlO9TcPJ-Mba-U2ZY>
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 18:09:35 -0000

As far as I can tell, the argument for more flexibility in the RSE would 
also be an argument for allowing the RPC to be employees, or even 
allowing the entire secretariat to be employees.  Or hiring staff to 
produce tools (we seem to have anever-ending need).  Some standards 
bodies do that.

I do not see an argument that says there is a special need for the RSE.

if anything, the fact that the RSE is a part time position suggests that 
it is a better fit for contracting than any of the other positions.  So 
why would we want to change the agreed model.

Futher, the change from ISOC to the LLC does not seem to provide a good 
reason for this change.  If the hiring is just pro-forma, it would 
actually have been easier for ISOC (with its full HR and management 
structure) than it will be for the LLC.

Yours,
Joel

On 4/29/19 2:01 PM, Richard Barnes wrote:
> On Mon, Apr 29, 2019 at 1:56 PM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     The most obvious difference is that if the RSE is an employee, the LLC
>     has to supervisor that person.  If the RSE is a contractor, primary
>     supervision falls to the IAB and the RSOC.
> 
> 
> The LLC would be negligent if it didn't have someone monitoring the 
> performance of the contract.  Since, after all, the contract is between 
> the LLC and the RSE.  Maybe there's a difference here, but it's slight.
> 
>     The HR implications of more employees are also different than the HR
>     implications with of an organization with one or two employees.
> 
> 
> In my experience, the difference tends to kick in at the order of 
> several dozen.  That's not what we're talking about here.  What we are 
> talking about is giving the LLC board and management the leeway to deal 
> with those things.
> 
> --Richard
> 
> 
>     The very implication that this is a question that the LLC board cares
>     about indicates that it likely increases the work load on the LLC board.
> 
>     Structurally, we were told this was a small organization with very
>     specific responsibilities, and a board concerned with those specific
>     responsibilities.  If the IETF LLC hires people for meeting planning,
>     RFC production, RSE, tools production, etc. then it is, but simply, a
>     VERY different organization from what was described to the IETF during
>     the BoFs.
> 
>     Yours,
>     Joel
> 
>     On 4/29/19 12:10 PM, Richard Barnes wrote:
>      > 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 <mailto:john-ietf@jck.com>
>      > <mailto:john-ietf@jck.com <mailto:john-ietf@jck.com>>> wrote:
>      >
>      >
>      >
>      >     --On Saturday, April 27, 2019 23:44 -0400 John Levine
>      >     <johnl@taugh.com <mailto:johnl@taugh.com>
>     <mailto:johnl@taugh.com <mailto: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 <mailto:iasa20@ietf.org> <mailto:iasa20@ietf.org
>     <mailto:iasa20@ietf.org>>
>      > https://www.ietf.org/mailman/listinfo/iasa20
>      >
>      >
>      > _______________________________________________
>      > iasa20 mailing list
>      > iasa20@ietf.org <mailto:iasa20@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/iasa20
>      >
>