Re: [Iasa20] 6635bis

Eric Rescorla <ekr@rtfm.com> Tue, 30 April 2019 16:47 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 024151202F3 for <iasa20@ietfa.amsl.com>; Tue, 30 Apr 2019 09:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] 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 MVtxMR4pnw76 for <iasa20@ietfa.amsl.com>; Tue, 30 Apr 2019 09:47:23 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 89ECE120309 for <iasa20@ietf.org>; Tue, 30 Apr 2019 09:47:14 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id h126so11406994lfh.4 for <iasa20@ietf.org>; Tue, 30 Apr 2019 09:47: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=7TrQ7vl+cLtUWiOnzDxTPrppbo/Jq0CQxgZkB14ExEY=; b=E8lbe0jRfKBxJpHsaYiiUzRPGZOrVQKvB37fBSog0EmU52SyAJMd3TNauTnsjtPhY7 MOKybcMRe4fiUPzZZnzJShoOcsmr+wpAQq2BbMGZ56mSGzzvSbfuWyAxphqVBn3jHEp3 p/k/32KlsEpqNqoEEXsUCz0aXi+FT7Q8eqZ1Y8yAetu+JbsgO6m5b6ESYzh5083H/hwh WV7i2x6jton/9NBwUteQdj5Yq1fYpZRq0ttlGcQqzN42PDb5EhawkU8Q1L+zn9sjIJKi 3TtWbay1R/IlkM9TQFjVDH3HH6GT9l/dui+eqdl089ddLpG6SOXHLU7AQQuAdv83Lv1v HlhQ==
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=7TrQ7vl+cLtUWiOnzDxTPrppbo/Jq0CQxgZkB14ExEY=; b=kPNffEv40T+B9ptlxKpkBDmypB3Mi5lIBUasSvwC4b/XvmzrbQJSOTEHukPboY3mAf 9y6yo0v3+Gz++Tpsn9v4qbqsOTYE7D7F+QlPQx0v0M6ZZ3Xs7s/t1XkG9X+VDQdEqZYT 4qL1DRAmQ5CBaH0x1ns8dlHTovVyvgP0L2t20PRdvb2DmqPeD25/WBWhZmjekNPRfhNl ecPQp64hcHupug0g5sBlO2RRKGzle4fp1WU9HBxu5X7dicj/wO0XOLBuoQAelMze1m+I N9S2Ntc2VCmSo3zQVlhyXT8aFOlLlXaGZZCB/IvaybOr+q0Hoqx3eliriea3k7SfLBv7 MIxA==
X-Gm-Message-State: APjAAAVrzow2aYuWDLMxvADg63lOrhMgmM6z95nZqWOUUzespXdtxnvR +80D5BMrHRdyznsyw1F8c7fReUmRUczocoARwZogjQ==
X-Google-Smtp-Source: APXvYqxFfCPJsY145Jl4idnJRE9CPPz3D7ZqYZGpJ4Wd+P1WeNlk2CnayVJBCqy8iCKBmXKcm91LmpZPEnia6Lzw9Do=
X-Received: by 2002:ac2:59d9:: with SMTP id x25mr1947086lfn.123.1556642832385; Tue, 30 Apr 2019 09:47:12 -0700 (PDT)
MIME-Version: 1.0
References: <20190428034407.4EC3B20130AC13@ary.qy> <43D5554EEDD8418CC4E0C195@PSB> <CAL02cgSnpP1pA=mStxkEahG8rmqEFL0CkAVkgq1b3mp_Kif9Sg@mail.gmail.com> <58df809e-44dc-88b8-ff11-1c7ef1ccb8f6@joelhalpern.com> <02C8F2A9-D8E5-4E3B-A185-B8C9C9AC410D@cooperw.in> <37d6031a-b0c6-c082-d4e7-008a67ba02b4@joelhalpern.com> <AFC2A44B-2F42-4BD6-BF16-3A4F9895B9B7@cooperw.in> <f6bf4fea-64d0-4616-17d9-25c3b1e961d3@joelhalpern.com> <82D23000-AADA-4534-89A8-DF43861CB468@sn3rd.com>
In-Reply-To: <82D23000-AADA-4534-89A8-DF43861CB468@sn3rd.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 30 Apr 2019 09:46:35 -0700
Message-ID: <CABcZeBPqxX+HrxGc=ffRHOAaVYDwX9iM2+pz1yC9GWSgErt_1A@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011204b0587c2273c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/ulqevWSoZQdOTNLHxlfRGOj3C68>
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: Tue, 30 Apr 2019 16:47:27 -0000

On Tue, Apr 30, 2019 at 9:40 AM Sean Turner <sean@sn3rd.com> wrote:

>
> > On Apr 29, 2019, at 15:03, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> >
> > Maybe the correct answer is for us all to stop arguing for any position
> until there is a proposed change that can be discussed?
>
> Hi! Again sorry for going into radio silence right after starting this
> thread.
>
> Since Joel asked, I have included review comments below. These deal
> directly with the question about more flexibility for the RSE and RPC to be
> either contractors or employees, and the text suggestions assume that the
> desired result is flexibility for the LLC to choose the type of employment
> relationship. I have some other comments/questions based on reviewing the
> doc but I will hold those for now so we can focus on this particular issue.
>
> I realize people wanted to just s/IAOC/LLC/ here as in the other documents
> (and that the editors dutifully followed this direction), but this draft is
> prescriptive about what the LLC can do in a way that the other documents
> are not. As a result, changing the label seems to have other implications
> that it is worth the community considering. If IAOC == LLC then we would
> not have gone to the trouble to create the LLC.
>
> Also, in case it was not clear, none of this relates to performance of
> current contractors in current roles, but rather establishing the LLC's
> ability to operate successfully in the future.
>
>
> = Section 2 =
>
> The use of the term "SOW" could be read to imply contractor status.
> Suggestion:
>
> OLD
>   These responsibilities are defined below, although the specific work
>   items under them are a matter for the actual employment contract and
>   its Statement of Work (SOW).
>
> NEW
>   These responsibilities are defined below.
>

This seems like a larger change than necessary. Why not just strike "and
its Statement of Work (SOW)"



> = Section 2.1.1 =
>
> "The RSE is responsible for the performance of the RFC Production Center
> and Publisher."
>
> It is not clear what this is meant to imply from a management perspective.
> Also relevant here is Figure 2 and this text from 2.2: "All these
> activities will be done under the general direction, but not day-to-day
> management, of the RSE." Under RFC 6635, does this mean that if the
> performance of the RPC does not meet the standards in the RPC contract,
> that the RSOC/IAB are to hold the RSE accountable for that? Section 2.1.1
> also says the RSE performs annual reviews for the RPC and the Publisher
> function. But this performance responsibility/accountability relationship
> is not specified in the RPC contract as far as I can tell. That is,
> accountability to the RSE for performance of the contract does not appear.
> Accountability to ISOC (now assigned to the LLC) does appear.
>
> If both employees and contractors are allowed for these functions, it
> seems like there are multiple different management structures that could
> all be workable here (e.g., RPC employees reporting to an RSE employee who
> is their manager, or all of them as employees reporting to another manager
> within the LLC, or two contractors whose contracts are both managed by the
> same LLC employee). So if there is flexibility allowed in the employment
> types, it would probably make more sense for this section to just specify
> who is expected to be accountable to whom for their performance, and leave
> out the bits about SOWs and vendor selection. But it's hard to suggest a
> specific edit since the intent of RFC 6635 is not clear, or not clearly
> reflected in the contracts.
>

This does seem like a problem, which I hope the IAB will do something to
fix. Ultimately, the RSE can't be responsible for the performance of the
RPC unless it has actual authority (hiring/firing, etc.). Is that what
people's expectation was? As you note, that's not part of the current
contracts.



> = Section 2.2 =
>
> Same comment as Section 2, regarding "paid contractor.”
>
> OLD
>   The RFC Production Center function is performed by a paid contractor,
>   and the contractor's responsibilities include the following:
>
> NEW
>   The RFC Production Center's responsibilities include the following:
>
> The last sentence of the section would also need to be deleted or edited
> based on edits to 4.1.
>

LGTM.



> = Section 2.3 =
>
> The last sentence of the section would need to be deleted or edited based
> on edits to 4.1.
>
> = Section 4.1 =
>
> If employees and contractors are both allowed, it seems like mandating the
> specific process detailed here would not work, since depending on the
> circumstances this might be a vendor selection process or an employee
> hiring process or a mix of both. It seems like specifying who must be
> involved in whatever process is used is important, since that allows the
> community to know that the people who are the appointed experts (on RSOC or
> selected by RSOC) will be involved. But eliding the rest of the details and
> the language about vendors and SOWs and RFPs would be needed to provide the
> flexibility.
>
> What to suggest here specifically is dependent on the intent of 2.1.1, per
> my comments above.
>
> spt
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>