Re: [Iasa20] employees and contractors in 6635bis

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 01 May 2019 01:09 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 34F6312042B for <iasa20@ietfa.amsl.com>; Tue, 30 Apr 2019 18:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 MDqcR3QV6N43 for <iasa20@ietfa.amsl.com>; Tue, 30 Apr 2019 18:09:13 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00F3120448 for <iasa20@ietf.org>; Tue, 30 Apr 2019 18:09:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E47D5BE6F; Wed, 1 May 2019 02:09:07 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFUayaWisetX; Wed, 1 May 2019 02:09:06 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B525ABE50; Wed, 1 May 2019 02:09:05 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1556672945; bh=g5zKMjXBR8CUl7Z6lmQk/llDQrvS1vBz6JuUiWKFcy8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=ME+cU8TZNWbgwEOYbjd4yju1RwdE3HHaj3Cnqg6D+Neh7BVuWx3JNjcp++XUXBUWi ezI1BjDP+ba0YFerEl50PwqE78c1F2uu2wMtuq7ocON4tgdQXFLoORVA9wf7tid8vf ky2O5w6Jr3fWFkfhjWJL4x13ft7IOlC5fuXmuoeQ=
To: Eric Rescorla <ekr@rtfm.com>
Cc: IASA 2 WG <iasa20@ietf.org>, John Levine <johnl@taugh.com>
References: <20190430224943.D666020132688F@ary.qy> <7d6c9ac4-d4b5-8e94-b555-29facb771d6e@cs.tcd.ie> <CABcZeBOdgy1R54W20XdXgLjeoCsEvrOaoMMG+S3HhOw9D-w_fg@mail.gmail.com> <4c8b07c5-41ae-34a5-38c0-6175cf2506c2@cs.tcd.ie> <CABcZeBPh6dnXGMrnR1ZdHU9Te6uC=39mYPxPaw7N0HV-6sAjOQ@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <760211b1-95ee-93ec-5a33-11f05bd9d493@cs.tcd.ie>
Date: Wed, 01 May 2019 02:09:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBPh6dnXGMrnR1ZdHU9Te6uC=39mYPxPaw7N0HV-6sAjOQ@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="fnDJ5hPcU9W36TYf1QUSJt5EGNPHtmIIc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/sxRT9-AicJniPxkKm9NUIvk_OmE>
Subject: Re: [Iasa20] employees and contractors in 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: Wed, 01 May 2019 01:09:21 -0000

Hiya,

(Deleting no longer needed bits...)

On 01/05/2019 01:50, Eric Rescorla wrote:
> On Tue, Apr 30, 2019 at 5:34 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>>
>> On 01/05/2019 01:11, Eric Rescorla wrote:
>>> On Tue, Apr 30, 2019 at 4:02 PM Stephen Farrell <
>> stephen.farrell@cs.tcd.ie>
>>> wrote:
>>>
>>> This seems like an argument for giving the LLC *more* latitude here,
>>> because as this discussion has shown, there are places where it's
>>> advantageous to have people with whom you have a long-term
>>> engagement be a contractor and others where it's advantageous
>>> to have them be an employee.
>>
>> I interpret things differently. The contractor arrangement seems
>> to me to fit the RSE role regardless of geography.
> 
> 
> But this is precisely the point that John, Richard, and I have
> been making, namely that it's actually *not* clear that the contractor
> arrangement is a good fit for the RSE role in certain jurisdictions.

Sorry, I don't recall any good argument that the contractor
arrangement has problems. We seem to have O(400) or so bits
of evidence per year that the current setup works to an
extent.

In particular, the only geographic argument on this list that
I recall is the one I made to the effect that the RSE as an
employee can be problematic. If someone made a claim to the
effect that a contracting arrangement could raise geographic
or jurisdictional issues, I'll need you to send me a link to
the archive for those mails, as I do not recall seeing that
argument having been made.

> 
> 
> In contrast
>> employee arrangements seem like a total misfit for at least
>> countries like Ireland (perhaps most of the EU?). And I do not
>> want the LLC to have fictional flexibility that really represents
>> a cumbersome constraint when it comes to RSE selection.
>>
> 
> In what way is this flexibility a constraint.

Sorry, I don't see how to do better than the explanation I used
in an earlier mail. (That's the one where I asked where I was
wrong and have yet to see a specific reply setting out why I was
wrong;-)

> 
>> So, I'm not sure I follow your argument here, which seems to be that
>>> you think we ought to constrain the LLC in this respect.
>>
>> I do think we ought do that. Sorry if I've not explained it
>> sufficiently well.
> 
> Yes, I get that, but it doesn't seem to follow in any way from the
> arguments you are advancing.

We disagree. Asserting that my argument is unfounded without
stating the basis on which you conclude that seems... unfounded,
but luckily we're both now doing that;-)

> 
> 
>>> Here in the US, if you hire a person as a contractor but the the
>>>>> nature of the job is more like an employee (the so called IRS 20
>>>>> questions), the person can file an SS-8 form with the IRS to ask to be
>>>>> reclassified as an employee.  If the IRS agrees, the employer has to
>>>>> pay unemployment and social security and medicare taxes for the
>>>>> employee, retroactive to when they were hired.  It can be a
>>>>> significant financial risk for the employer.
>>>>
>>>> Yes. But the RSE role has not been "more like an employee"
>>>> at all.
>>>>
>>>
>>> Without taking a position on the nature of the RSE,
>>
>> I believe the IETF has a position on that. (Not that the IETF is
>> the only entity who may care about the RSE role etc...)
>>
> 
> Sorry, what I mean to say is that I am not taking a position on
> whether the IRS would judge that the RSE was actually an
> employee.

And that was not the (only) issue. The new point I raised in
this thread is all about "what if the RSE were an employee"
and has nothing at all to do with the details of employee
vs contractor distinction minutiae in any one jurisdiction.
In case it helps, the relevant legislation here is explained
at [1] and I do have some knowledge of it, having used it
to get my $dayjob employer to continue paying me when they
might otherwise have chosen to decline the fun of that :-)

Cheers,
S.

[1]
https://www.workplacerelations.ie/en/Publications_Forms/Guide_-_Protection_of_Employees_Fixed-term_Work_Act.pdf

> 
> -Ekr
>