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.