Re: [Iasa20] 6635bis

Eric Rescorla <ekr@rtfm.com> Thu, 25 April 2019 18:50 UTC

Return-Path: <ekr@rtfm.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 61359120227 for <iasa20@ietfa.amsl.com>; Thu, 25 Apr 2019 11:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 9SXWb7Wn4WbE for <iasa20@ietfa.amsl.com>; Thu, 25 Apr 2019 11:50:15 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E76120134 for <iasa20@ietf.org>; Thu, 25 Apr 2019 11:50:15 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id h18so417594lfj.11 for <iasa20@ietf.org>; Thu, 25 Apr 2019 11:50:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H/2KbLF7WHbddPU1ZoyssaJhe5aXitEp7cIrQwbmFSE=; b=vFDU4aLOWLcFY3owOxtFHFo1RP5JkHJlEhfvs7cQQ74XdMMj9YzDq3FTz9qg6APGxp Qz8/NEIi/z56IqTqQR6DarxeKh9tIKXkXuYw0DSbseUvcuTmAIeVNPM2gMUA12Uk49hF /NUCO9eHJfQz88kX+e4wXGjXbeJ7aZSUvfo6Ei47DuQ2yI1x0W+G81Ok84AXxCTf7j2C VKIpEwaNgyeVdbGp+cfziqXD7OCoOeyDOl8sFtbKuErWIlDTrG6+aiIknn/Gi8Nus1k0 H43+V87npINF77+dQnwZ/JNjcXPaOwuAb75H+VPXNeojL3YLpqVN9bf2RgGngTHGRI1i CHoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H/2KbLF7WHbddPU1ZoyssaJhe5aXitEp7cIrQwbmFSE=; b=jikG4lAXr4ehYBRZ4cI7jsfvGI/GlPowXE8JZKiaBL1HidNE+IihH8aveDbc3Qpwn5 1W37RPu7S1jWA8IGVzCR50EagbKHg2V3cZm7/Ig/wpOeX383qEz0kQ8+o9tBVbzWQbQp AGwKW18V+7YatkFdxRkYsWBfDCEWBraT0CAPC3gs/2bjQyVVmvnReyWAzLCB57lPkVgt kSm1f+7aP+sQnZ7hm3FUMKvdeSdYwhyVL3eTNPOraNLId7D+hexCYwpKv1AcxtVfGTl2 vpmHhNhMxzBgbWX1My8i9mPffyRd1Rx8WD67B/9zasnDF4pO0A5DR+WwW+IZFFyrXdlM dKjQ==
X-Gm-Message-State: APjAAAU3G53C9X2TmQdh3Vzpo7zMpeJs+2LOtTkKhNBq7QbTsjUWn/T+ 7Ycf6j5q/D36JVlQt6UKg5gEOqVGf5LaD9m8Yvcclg==
X-Google-Smtp-Source: APXvYqx3BFnstDCPI0Qekq5osSCVPaOVvbViTBt+lrB2aBM/p/yx4Y10Dg7Eo1i621JK4y21cSG1L6a67sFJpNx4SIM=
X-Received: by 2002:a19:ae0b:: with SMTP id f11mr19816338lfc.106.1556218213194; Thu, 25 Apr 2019 11:50:13 -0700 (PDT)
MIME-Version: 1.0
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 25 Apr 2019 11:49:36 -0700
Message-ID: <CABcZeBNyB_-W0-ar31s=XkzM5LgVS4gqhwkmgAUMK3127YmxMQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Sean Turner <sean@sn3rd.com>, IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ca731305875f491c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/sEfGNBd68CZ3pmYL4hZjbXw3adk>
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:50:19 -0000

This also seems reasonable to me. Generally, I think of this section of the
document as almost like a requirements document for what the LLC ought to
be doing for the IETF, and the employee/contractor distinction doesn't seem
like a relevant requirement, as long as the LLC is properly able to respond
to the IETF's needs as managed by the IAB/RSOC.

-Ekr


On Thu, Apr 25, 2019 at 11:22 AM Richard Barnes <rlb@ipv.sx> wrote:

> 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> 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
>> https://www.ietf.org/mailman/listinfo/iasa20
>>
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>