Re: [Iasa20] 6635bis

Russ Housley <housley@vigilsec.com> Fri, 26 April 2019 15:40 UTC

Return-Path: <housley@vigilsec.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 C0246120192 for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 08:40:32 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 vAtXZyTRZ16q for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 08:40:30 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6201200DE for <iasa20@ietf.org>; Fri, 26 Apr 2019 08:40:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1288A3004E8 for <iasa20@ietf.org>; Fri, 26 Apr 2019 11:22:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jfmG4BtqwyjR for <iasa20@ietf.org>; Fri, 26 Apr 2019 11:22:00 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 1CE8E300580; Fri, 26 Apr 2019 11:22:00 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <0A8ABED3-77B1-487C-BCCA-F1A4523DB9CF@gmail.com>
Date: Fri, 26 Apr 2019 11:40:17 -0400
Cc: iasa20@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6CBE88F-CA59-41D3-B62C-46330ED8FAB4@vigilsec.com>
References: <CCCFB260-660F-4CB9-AA4F-60F8B88465CB@sn3rd.com> <0A8ABED3-77B1-487C-BCCA-F1A4523DB9CF@gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>, Sean Turner <sean@sn3rd.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/JNS2oDLRtu6huGKM6UU94C3Liqk>
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 15:40:33 -0000

Sean:

> 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.

Thanks for starting this discussion.

I would like to see the whole community gain a lot more confidence in the IASA 2.0 structure before a large number of people get hired by the LLC.  Clearly, the Executive Director needs to be hired very quickly, but the transition of the existing contracts from ISOC to the LLC means that most other positions are much less urgent.

Bob Hinden pointed out that the directions given to him as editor were to make the minimum changes.  I think that those were the right directions at the time.

> 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. 

I do not know if that would be cheaper or more expensive, but I would expect the LLC board to bring such a shift to the IETF community before doing it.

> 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?

I do not mind the RFCs allowing it.  Flexibility is important, but that does not mean that the flexibility should be exercised without consulting the IETF community.

Russ