Re: [Iasa20] 6635bis

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 27 April 2019 21:40 UTC

Return-Path: <brian.e.carpenter@gmail.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 4BCFE12025D for <iasa20@ietfa.amsl.com>; Sat, 27 Apr 2019 14:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 Nra2BZgdMN_B for <iasa20@ietfa.amsl.com>; Sat, 27 Apr 2019 14:40:21 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 851C312004B for <iasa20@ietf.org>; Sat, 27 Apr 2019 14:40:21 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id z8so3206193pln.4 for <iasa20@ietf.org>; Sat, 27 Apr 2019 14:40:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sFa+bohyDDGA6lmTZ4cKFau0uRo2BNNCp8LU23/3qA4=; b=qTt0r5fCY0eaY+VsFlPL6CUvYT7XVftOUO8V26AOrEDK0LRIOpNr1Sw5VAZklOHrQ7 ktIGxvwRescG0IVAsK00sjSLnAdqgRw4TPryVukAo2Kcg1yft28/WwyzOYIut1cBwDY0 SfBxY0TAB90SRmpELw8fRLq17OSwAHuxerfQJbQpSvydAZ+lOf/QiGTRDfoLJ/mOzmZz IXQTjzy/cV/LbL4RhR01Be65xWJdie9DFi9edLIFBqhAl9XRQQK9PXMYnF+YG5icmuOS zHGfAQDPwVvIyc4sDGwGD86ZBG+fGPkuiJh4N0RALz++1fi6/FnA4zempGG9vXOMrMZi sWbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sFa+bohyDDGA6lmTZ4cKFau0uRo2BNNCp8LU23/3qA4=; b=d6Qx6Ndi1Zncott6BR+kj+I/QVkNnt/By1dXPecWZsl5NTKW4SLfQmVQxpcXqSRbeb Pe3svarM0IM2eEViQC+Zi056Lbyv9OOdEyuYY9p7F0H4Bm/hwK2oc2Ae7+C8P1Y9HnpS CGAr95tbLzy/OaE6YRIrkycOLFpowS3NMCKpXTpjCKDSxBsuB3XWdHH8wV2arhjHQU0N SYHoie+cMj9OiWo1pwuK8EilMyW5dJWYUXthtKQ/8GrhLF6QJ3Qs0+DjQP/qc57ouPw2 wEhr5ZcPCUXDLDM/TdFJEwB5xofyx2+NcQ7vLhE/LJAQwpZJmw8Ufc28GP6GqUZkj28B 4Cng==
X-Gm-Message-State: APjAAAVOat6Urh2aKjVSHE+kawuw5q4yoM0J/ftC+u7g0qmGKu9WFmKq v+LyyM6GrburVqXWQPyMGwcOOSCn
X-Google-Smtp-Source: APXvYqz1FECFTkIDzrBTzdE21Jy88sTciULqXI/U17dygcXflqHnQcaKf1W3rtkzOeNOZ7/3ppOexg==
X-Received: by 2002:a17:902:a5cb:: with SMTP id t11mr24610064plq.268.1556401220830; Sat, 27 Apr 2019 14:40:20 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id n18sm26320552pfi.48.2019.04.27.14.40.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Apr 2019 14:40:20 -0700 (PDT)
To: Richard Barnes <rlb@ipv.sx>, "Salz, Rich" <rsalz@akamai.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, John R Levine <johnl@taugh.com>, "iasa20@ietf.org" <iasa20@ietf.org>
References: <20190426211900.555852012FE081@ary.qy> <22f00e3c-faa1-2eb3-ad38-97f6fb743aac@joelhalpern.com> <alpine.OSX.2.21.1904261835490.29589@ary.qy> <c2a25515-b5cc-13f9-cdf9-058170194d1f@joelhalpern.com> <alpine.OSX.2.21.1904262033390.29815@ary.qy> <2F643707-45C2-4088-8D0F-A1F0F1238D86@akamai.com> <CAL02cgQFXPXgeFiayehWmpCDND1gS0LmAzRo8COKLvspNNPh7A@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <40d9048e-f744-a6cf-de56-a444f2787fef@gmail.com>
Date: Sun, 28 Apr 2019 09:40:15 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAL02cgQFXPXgeFiayehWmpCDND1gS0LmAzRo8COKLvspNNPh7A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/c9U0a-vu7Zv_0CIn0h7BKyntJsE>
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: Sat, 27 Apr 2019 21:40:23 -0000

On 28-Apr-19 09:00, Richard Barnes wrote:
> 
> 
> On Sat, Apr 27, 2019 at 4:49 PM Salz, Rich <rsalz@akamai.com <mailto:rsalz@akamai.com>> wrote:
> 
>     >    I don't think it's a change in policy and I think we're making a classic
>         IETF overspecification mistake not to let the LLC run its own business.
> 
>     I agree.  This is not like specifying bits on the wire. :)
> 
> 
> +1
> 
> As I said before, I don't think the distinction between contractor and employee is substantive to the IETF.   Perhaps those that think this distinction is substantive could elaborate on their reasons why?

Asked and answered already.
 
> AFAICT the only reason that has been given for this distinction being meaningful is "staff capture".  But the proper control on that is good oversight by the community, which is what the board is there for.  And if the board is not exercising proper oversight of the organization, then we will have much worse problems than whether the RFC staff are contractors.

Staff capture is only part of it; the general inefficiency of mixing up directly employed staff with contractors is also a factor. But you're correct, it is something that's subject to Board oversight.

However, that isn't the point for the present document, which is about one specific service to the wider community (not just the IETF) that currently runs well and that this WG is not chartered to interfere with. What we specify here for the RFC Editor service doesn't constrain the LLC for other services.

    Brian