Re: [Iasa20] 6635bis

Mike Bishop <mbishop@evequefou.be> Thu, 25 April 2019 18:30 UTC

Return-Path: <mbishop@evequefou.be>
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 64DC71200EA for <iasa20@ietfa.amsl.com>; Thu, 25 Apr 2019 11:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 hOhUlMvLND60 for <iasa20@ietfa.amsl.com>; Thu, 25 Apr 2019 11:30:56 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730129.outbound.protection.outlook.com [40.107.73.129]) (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 42468120337 for <iasa20@ietf.org>; Thu, 25 Apr 2019 11:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2eUrTuvabpoveL/oSYEm3UF7pXQBtTWwG4Gua5/xC4w=; b=GtHE9Dl4NKiOZWs5pi3jwcaPfL6BJKHBOHWeT1yiamdk4/GYRtxlHQwtvjSnPyRbpV78F7t7P6b4n3mXEVc0tzVlP2JtWLMcHbvlW3zWeCUwj/PaEmcDeC32f6S7y8ZD+KfCMJtalhBpkHw+WcXhWdc5HABaBGCL1BjXNa+HcS8=
Received: from MWHPR22MB0991.namprd22.prod.outlook.com (10.171.145.21) by MWHPR22MB0813.namprd22.prod.outlook.com (10.171.150.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Thu, 25 Apr 2019 18:30:48 +0000
Received: from MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::780e:9855:aecc:6c9a]) by MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::780e:9855:aecc:6c9a%5]) with mapi id 15.20.1813.017; Thu, 25 Apr 2019 18:30:48 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Richard Barnes <rlb@ipv.sx>, Sean Turner <sean@sn3rd.com>
CC: IASA 2 WG <iasa20@ietf.org>
Thread-Topic: [Iasa20] 6635bis
Thread-Index: AQHU+5LGY4uFw1VFxUmeW46robBOwaZNMHyAgAACWNA=
Date: Thu, 25 Apr 2019 18:30:48 +0000
Message-ID: <MWHPR22MB099151B37B35BCDC9EC92349DA3D0@MWHPR22MB0991.namprd22.prod.outlook.com>
References: <CCCFB260-660F-4CB9-AA4F-60F8B88465CB@sn3rd.com> <CAL02cgS-QzkfDrYyLRD_T8beNZ2Zg_c1F4jnZDCSk=Wf67qnSA@mail.gmail.com>
In-Reply-To: <CAL02cgS-QzkfDrYyLRD_T8beNZ2Zg_c1F4jnZDCSk=Wf67qnSA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [2601:600:8080:701:7508:dd94:720e:f22a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9968fc38-46c8-4c71-4454-08d6c9ac2384
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MWHPR22MB0813;
x-ms-traffictypediagnostic: MWHPR22MB0813:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MWHPR22MB081331400553FE37DCA6347EDA3D0@MWHPR22MB0813.namprd22.prod.outlook.com>
x-forefront-prvs: 0018A2705B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(396003)(39830400003)(366004)(346002)(189003)(199004)(8676002)(102836004)(73956011)(86362001)(46003)(97736004)(71200400001)(5660300002)(7736002)(71190400001)(966005)(68736007)(99286004)(14454004)(52536014)(74316002)(33656002)(53936002)(508600001)(6116002)(790700001)(446003)(9686003)(476003)(53546011)(186003)(81156014)(81166006)(236005)(486006)(11346002)(66556008)(55016002)(66446008)(2906002)(66946007)(76116006)(66476007)(316002)(6306002)(54896002)(110136005)(76176011)(7696005)(25786009)(256004)(74482002)(6436002)(229853002)(4326008)(606006)(8936002)(6246003)(64756008)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR22MB0813; H:MWHPR22MB0991.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: kO4CQI0S8lNNh9FXAQ8VOg8LQfiRUCMoAEXIBD1iBiKCs5RWn4yLRvaT/QQ1mavsbZGGF96PnWuSYSXifWYmvCaLTUN61rsom61PNV8iNd2trVBEAx1KmnifEA1PQlKBR/3BWDVcqYNKJe70gBmoOMPfwKtf7NZ9lnV+pO7N8Y4HShDZulL8pLOVYAjXdkli18M6RAddoe0X5CdCO/iMhy7Tmi2X/nYPx63lONX5uiYUlWvnigLPEdPqcV8GkZsTP+/q9pxZu1bhJVtZ1ExhpZlsxr3fiJBcErF8dJcN4tVpnWe9jX7/AEQ4NH3Sx7bpFb8kfo0pQyftwDc04EyNSS19mPrT0WThaN5ey4X7Igmn9bllxiebWtktOzuRSuoVk1Gi0s4z/9ZAJB5/NxkhF4+6RW2fLuQMEUJ9vBC9ia0=
Content-Type: multipart/alternative; boundary="_000_MWHPR22MB099151B37B35BCDC9EC92349DA3D0MWHPR22MB0991namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 9968fc38-46c8-4c71-4454-08d6c9ac2384
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 18:30:48.4180 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0813
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/SYMmN6d63wugzbnQlmQUfgJNShU>
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: Thu, 25 Apr 2019 18:31:00 -0000

+1

From: iasa20 <iasa20-bounces@ietf.org> On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2019 11:22 AM
To: Sean Turner <sean@sn3rd.com>
Cc: IASA 2 WG <iasa20@ietf.org>
Subject: Re: [Iasa20] 6635bis

Overall, this approach seems sensible to me.  The point of this document is to describe the roles involved, and to minimize surprise with regard to how the LLC arranges for those roles to be executed.  It should allow the LLC flexibility where there's not a compelling need for constraint.  The difference between employee and contractor does not seem salient in terms of getting this work done.

--Richard

On Thu, Apr 25, 2019 at 2:14 PM Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>> wrote:
Hi!  While I am not sending this message on behalf of the IETF Administration LLC, I have to admit that I am reading the IASA2.0 I-Ds with more interest as an LLC officer because I am somewhere nearer the front of the go-to-jail line if something goes terribly wrong ;)

With this in mind, after reading many of the the IASA2.0-related I-Ds the simple IAOC to LLC terminology swap totally makes sense.  For draft-ietf-iasa2-rfc6635bis, I am wondering whether more should be done.  Specifically, I am wondering whether the language about how the RSE services are delivered should be loosened or at least made internally consistent.  As I read it, draft-ietf-iasa2-rfc6635bis does include a reference to an “employment agreement or contracting plans, as appropriate” as it pertains to the RSOC working with the LLC concerning RSE services.  But, the rest of the draft, at least to me, reads as if the LLC will contract these services out with no wiggle room for an employee to do them..

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.  For any given role, the LLC might find it preferable to have the role filled by an employee versus a contractor for the purposes of being able to offer better benefits, to more easily comply with employment/tax law, or for other reasons. The original IASA model didn’t offer as much flexibility since hiring decisions were ultimately ISOC’s.  If the language in the draft was tweaked to accommodate both contractors and employees then this document would not, in mind at least, unnecessarily restrict the LLC.

Before I submit a list of potential edits to this list for draft-ietf-iasa2-rfc6635bis, I just wanted to see whether these type of changes would even be palatable?

Cheers,

spt

PS - I am sending this message right before some family-related activities so I might be slow to respond.
_______________________________________________
iasa20 mailing list
iasa20@ietf.org<mailto:iasa20@ietf.org>
https://www.ietf.org/mailman/listinfo/iasa20