Re: [Iasa20] 6635bis

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 26 April 2019 21:29 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 D185A12023D for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 14:29:09 -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 NYaKekLCBizk for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 14:29:07 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 98D9312061A for <iasa20@ietf.org>; Fri, 26 Apr 2019 14:29:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 44rRyC25ZQzb3WG; Fri, 26 Apr 2019 14:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1556314147; bh=JWx6+3Huuz/xCBSQ+tuDm56TUBosj1OEKBKXp5NqV1E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jmm79V/R/W7QDlwbvJvfLFqBemT/4eBuYMu9ojB6LeCCkCpjmGaeJdun7dDlFtFVi RJk5Gj+Uwc9j7fR0FHvSRrwJN0fO1S18WuRHAs81W2ciW3IBN/NlBMT1unzbOFdKZP /ReMRWhe3XOGOtG3yR26Su7Fw9Iui8bCe6MhXYP4=
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 44rRyB4nsjzb3WC; Fri, 26 Apr 2019 14:29:06 -0700 (PDT)
To: John Levine <johnl@taugh.com>, iasa20@ietf.org
References: <20190426211900.555852012FE081@ary.qy>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <22f00e3c-faa1-2eb3-ad38-97f6fb743aac@joelhalpern.com>
Date: Fri, 26 Apr 2019 17:29:05 -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: <20190426211900.555852012FE081@ary.qy>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/ntGmZwkYhYh8anONPgUlGbnkB3s>
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: Fri, 26 Apr 2019 21:29:22 -0000

What I fail to see is why there is any need to change the wording that 
we have on the status of the RSE.  I can imagine that the LLC will need 
to continue to exercise care in the handling of the RSE to avoid 
accidental changes of status.  As you say John, it is tricky.
But I do not see why that should result in any change to the text in the 
revision of RFC 6635.

Yours,
Joel

On 4/26/19 5:19 PM, John Levine 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 hired as a contractor, appeals to the labor
> department, and it decides that the facts of the relationship make the
> person an employee.  You cannot say whether a contractor is cheaper or
> more expensive than an employee without knowing the details of that
> particular job and the particular agreements.
> 
> This is the kind of business detail that we invented the LLC to take
> care of.  None of us are employment law experts and it would be absurd
> for us to define rules that purport to define the details of
> employment relationships.
> 
> The IAB can certainly say who to hire as the RSE or whatever, what the
> job entails, for how long and what would make the parties end the
> agreement early.  Beyond that, it's up to the LLC.
> 
> R's,
> John
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>