Re: [Iasa20] 6635bis

John C Klensin <john-ietf@jck.com> Sat, 27 April 2019 01:28 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 13E47120033 for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 18:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no 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 mVwlukVFyGOz for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 18:28:26 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8937C12002F for <iasa20@ietf.org>; Fri, 26 Apr 2019 18:28:26 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hKC8Z-000B30-Ud; Fri, 26 Apr 2019 21:28:19 -0400
Date: Fri, 26 Apr 2019 21:28:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>
cc: iasa20@ietf.org
Message-ID: <5E2DCE069A4A0F6FB99A007B@JcK-HP5.jck.com>
In-Reply-To: <20190426211900.555852012FE081@ary.qy>
References: <20190426211900.555852012FE081@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
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/-Rp3pasbarFRdiqL19Hx0SHZ3xU>
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: Sat, 27 Apr 2019 01:28:28 -0000


--On Friday, 26 April, 2019 17:19 -0400 John Levine
<johnl@taugh.com> wrote:

> In article <e1d5c5fe-42ff-91d7-ed77-7192fde27cd5@gmail.com>
> you write:
>>>> The slant towards contracting made sense prior to forming
>>>> the LLC, but now that the LLC has been formed
>> these functions could be performed by an employee. 
>> 
>> Specifically, I would regard that as a broken promise: not
>> lightweight, not cheap.
> 
> Sorry, but as others have implied that's just wrong.
> 
> US employment law is complicated.  I have been an employer and
> an employee, been a contractor, and hired contractors, and I
> would still not claim to be an expert.  Whether someone is a
> contractor or an employee has nothing to do with the length of
> the contract or the terms on which it might be broken.  It has
> to do with stuff like who pays for medical insurance (a big
> deal in the US) and pension contributions.  It is not entirely
> up to the two parties -- there are cases where someone is
>...

John, 

I share some of Brian's concerns although I think the part of
the problem he emphasized has probably created a distraction
from the key issue.   Certainly, in many countries, the key
difference between an employee and a contractor -- that
employees, after a relatively short period, are really hard to
fire and sometimes really hard to reassign for either
incompetence or because needs change-- does not apply in the US.
But it also isn't what I see as the issue, an issue that hinges,
not on employment law but on human and organizational behavior.  

I see two potential problems, neither of which has anything to
do with employment law and both of which many of us have seem
acted out in other organizations:

* At the point that an "administrative" function starts
acquiring significant employee staff, or staff who see
themselves as equivalent to employees or are so seen by
management, staff who are actually carrying out organizational
functions rather than providing support, incentives almost
inevitably change from depending on and serving a wider
community to preservation of the organizational structure and
the staff tail wagging the organizational dog.  We seen
variations of that happen with a number of other SDOs where
standards strategy decisions are basically made by staff and,
arguably, with some organizations in our midst such as ISOC and
ICANN.  FWIW, the larger the staff gets, the more incentive and
justification the Exec Dir has to ask for more money and, more
important, more authority on the grounds that the alternate is
the Board micromanaging.

* At the point that the staff of the organization with the
control of the money starts being responsible for technical
work, the balance of authority and power between the volunteer
participants in the SDO and the leadership/ management of that
organization starts to shift.  After all, they are full time and
can determine how to allocate resources to particular work while
the rest of us are mostly part time unless we are accountable to
some organizational entity outside the IETf that is able to call
the shots.

Is either of those scenarios inevitable?  I hope not although
history in other bodies might suggest that they are.  But,
unless we are much more confident in the ability of the LLC
Board to manage the situation effectively and to remain
transparent about its actions and decisions to the community
(and responsive to community input) than IAOC has ever been, the
risks are real and moving in the direction of more
employee-staff is part of those risks.

There is another, perhaps subtle, distinction.  As I understand
the current arrangements with the RFC Production Center (and, I
believe, the Secretariat), there are single contracts for each
between the body contracting on behalf of the IETF and another
organization.  None of the IETF, the LLC Board, or the Executive
Director get to select or manage individual staff members or
their work associated with those contracts or operations.  The
LLC Board and the Exec Dir (or the IAOC and IAD under IASA 1.0)
manage contracts, not people.  A situation in which they are
managing individuals -- whether those individuals are nominally
employees or contractors-- is very different and really does
change scope and responsibilities.

Finally, I agree with others that the proposed change to allow
employees -- presumably individual ones and essentially moving
functions requiring a team inside the LLC -- is a change that
lies well outside the scope of the WG.

   john