Re: [Iasa20] 6635bis

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 30 April 2019 05:16 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 BA8111200B5 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 22:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 IdxNHWVLGHS0 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 22:16:08 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 6530B120103 for <iasa20@ietf.org>; Mon, 29 Apr 2019 22:16:08 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id w25so6468993pfi.9 for <iasa20@ietf.org>; Mon, 29 Apr 2019 22:16:08 -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=D/T7rfoYv1Og/z0EOEXCSlUEPoVAcOjS1nFbfJSQmDA=; b=D+fJ9HyPYa6+AicJi5gcRSG9N3+gDpa3m/oQ8wUmJzfIhzG+nJ1jCUbSB6djIwPu7d HTV64S/pVbXy+YiwhzyihwhtrYwsWv0H2AEMHeN7SvjA/ksbrnMYIj2SAqIhMi75+V8/ Myt8zFjQm5Io/QT/P6awqxi7vPu/OC56OEcjItTHqqYn06SGjhd9Ck5d4nQ4DSTVmJsY DFAavu1MItiQ2zEHvmIUp+oKHaGrw+T78kEyu0wDzcVg7HfcxF29GpIEu+DJF7dUXB7q m3WkRTSKY3vHiWGLyFdMEeU4PK9859ACVUuBb1p3eMf/1ObGFQElQb5pT6zrtnYzO6P3 f7Lg==
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=D/T7rfoYv1Og/z0EOEXCSlUEPoVAcOjS1nFbfJSQmDA=; b=K/UcyqnggrjfziBFbOxBagWoVFWXJCrfLyxKjU8iXxsSx5NHAQbERW+D1HwfMD+K6I m7pLoLm0kr9viJNYGzbUNQZpjS9Al2O+RB7Z+OJamRVCRyHReX2rTydE8KgBslS+9daP 13+ai/Z8hnDzveM6c8kGqhSkFN2YmXxEnewyO2sfVnRtGRnMX9C6Tb5hXNnyrxGkkqTZ JPS+vhHSBMH90scxlnLFT9ymPZU9BmVl/1Uc/HZaahCZEUy55BZLu1ooLi0TsviIscYF PlU5CSX2i85q4ssYN9LXp/aO0UllGMpCHleCXXsgafjee/4+QW/g8JfXt9JPBcgvcDi7 b6xw==
X-Gm-Message-State: APjAAAW02DSrCbnVyMPmRevQ8+cjr9/LHEBYWQG1f67YtJwWb+QB09EP y4chDuVM30SFKir7lIhPK9FLcwN7
X-Google-Smtp-Source: APXvYqw0DFWwko0vYLu+6gGogypMVMB2aRBrsP2V83y6OaR1+SwNs9id9YIww6wXnEhula2g8fHnKQ==
X-Received: by 2002:a63:4a5a:: with SMTP id j26mr61095607pgl.361.1556601367546; Mon, 29 Apr 2019 22:16:07 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id p2sm99887264pfi.73.2019.04.29.22.16.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 22:16:06 -0700 (PDT)
To: Richard Barnes <rlb@ipv.sx>, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: IASA 2 WG <iasa20@ietf.org>
References: <20190428034407.4EC3B20130AC13@ary.qy> <43D5554EEDD8418CC4E0C195@PSB> <CAL02cgSnpP1pA=mStxkEahG8rmqEFL0CkAVkgq1b3mp_Kif9Sg@mail.gmail.com> <58df809e-44dc-88b8-ff11-1c7ef1ccb8f6@joelhalpern.com> <CAL02cgTCqPhcHTMn7+nEpH7mtEg0f_YzqxdjBWz7QvsKekGvow@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <e4c38273-5462-91a0-d84a-3ccc7e240a8a@gmail.com>
Date: Tue, 30 Apr 2019 17:16:04 +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: <CAL02cgTCqPhcHTMn7+nEpH7mtEg0f_YzqxdjBWz7QvsKekGvow@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/PdPElWPGbYYKc9HLN5esdwfLL_4>
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 05:16:11 -0000

On 30-Apr-19 06:01, Richard Barnes wrote:
> On Mon, Apr 29, 2019 at 1:56 PM Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
> 
>     The most obvious difference is that if the RSE is an employee, the LLC
>     has to supervisor that person.  If the RSE is a contractor, primary
>     supervision falls to the IAB and the RSOC.
> 
> 
> The LLC would be negligent if it didn't have someone monitoring the performance of the contract.  Since, after all, the contract is between the LLC and the RSE.  Maybe there's a difference here, but it's slight.

Indeed, the LLC clearly has to monitor both the financial and technical performance of all its contractors (and staff). But for each function, the expertise for judging the technical performance is elsewhere - in the IAB and RSOC for the RFC Editor contracts (plural), and in the IESG (and IETF) for the secretariat, tools, etc., contracts. 
 
>     The HR implications of more employees are also different than the HR
>     implications with of an organization with one or two employees.
> 
> 
> In my experience, the difference tends to kick in at the order of several dozen.  That's not what we're talking about here.  What we are talking about is giving the LLC board and management the leeway to deal with those things.

Our experiences obviously differ. I've seen "staff capture" in much smaller businesses than that. Anyway, it doesn't change the fact that quite a lot of us definitely expected a lean-and-mean LLC.

All of which is rather beside the point for this particular draft, unless somebody is trying to use it as a stalking horse. This particular draft was supposed to be updated clerically to deal with s/IAOC/LLC/. It doesn't constrain the LLC for the general case, and it doesn't prevent the form of the RFC Editor services being debated in an appropriate forum. As we discussed a few months ago, that forum is much wider than just the IETF.

   Brian

> 
> --Richard
> 
>  
> 
> 
>     The very implication that this is a question that the LLC board cares
>     about indicates that it likely increases the work load on the LLC board.
> 
>     Structurally, we were told this was a small organization with very
>     specific responsibilities, and a board concerned with those specific
>     responsibilities.  If the IETF LLC hires people for meeting planning,
>     RFC production, RSE, tools production, etc. then it is, but simply, a
>     VERY different organization from what was described to the IETF during
>     the BoFs.
> 
>     Yours,
>     Joel
> 
>     On 4/29/19 12:10 PM, Richard Barnes wrote:
>     > John: I'm confused by this "lean and mean" point.  How is an
>     > organization with a collection of contractors (RSE, RPC, etc.) leaner
>     > and meaner than an organization with an equivalent number of employees?
>     >
>     > --Richard
>     >
>     > On Mon, Apr 29, 2019 at 12:04 PM John C Klensin <john-ietf@jck.com <mailto:john-ietf@jck.com>
>     > <mailto:john-ietf@jck.com <mailto:john-ietf@jck.com>>> wrote:
>     >
>     >
>     >
>     >     --On Saturday, April 27, 2019 23:44 -0400 John Levine
>     >     <johnl@taugh.com <mailto:johnl@taugh.com> <mailto:johnl@taugh.com <mailto:johnl@taugh.com>>> wrote:
>     >
>     >      > As it stands the LLC can always fudge it by turning an
>     >      > employee into a nominal contractor by running him or her
>     >      > through a body shop but that seems silly.  The arguments
>     >      > against having employees all seem to be of the form that
>     >      > organzation X or situation Y had or has employees who are
>     >      > poorly managed, but that seems to me to mistake the symptom for
>     >      > the problem.
>     >
>     >     John, just to stress something I think is important --and
>     >     important whether this is the WG's decision or the WG is
>     >     supplying input to the IAB, within the WG's responsibility, or
>     >     something else [1] -- I don't believe your statement about the
>     >     arguments is correct.  As he pointed out, Stephen has raised the
>     >     argument before and I don't believe his position is covered by
>     >     your description.  In different ways, Brian, Bob, Joel, myself,
>     >     and others have addressed variants on the issue.  Each of us
>     >     have had slightly different perspectives or expressed our
>     >     concerns in different ways, but I don't believe any of those
>     >     comments have been dependent on "employees who were poorly
>     >     managed" even if some have included examples of that type.
>     >
>     >     Even if that were the only issue, the IETF LLC is sooner or
>     >     later almost certainly going to face tradeoffs in selecting
>     >     permanent Executive Directors.  Those tradeoffs may be with
>     >     costs or benefits (assuming the budget is not unlimited) or
>     >     skill set, types of experience, management skills versus
>     >     financial skills versus understanding of the work the IETF
>     >     actually does, etc.  While I assume the LLC Board will do its
>     >     best, finding the perfect person may not always be possible and,
>     >     partially as a result, I don't think any of us can guarantee in
>     >     advance that the person chosen will always be a superb manager
>     >     of people as well as a superb manager of contracts [2].
>     >
>     >     However, I believe that one of the community's assumptions about
>     >     the IAOC and IASA 1.0 had little or nothing to do with the
>     >     corporate entity concern.   That assumption was the desire to
>     >     keep the organization and structure as "lean and mean" as
>     >     possible, with few employees (or contracted semi-permanent staff
>     >     [2]) as possible.   I see that assumption as having been carried
>     >     forward into IASA 2.0.   If the assumption has been changed,
>     >     that is almost certainly a matter for this WG to discuss.  If
>     >     the assumption is at all controversial, then I think the WG has
>     >     an obligation --one that falls well within its charter -- to
>     >     spell it out in some appropriate document.  More broadly, if the
>     >     LLC decided it wants to start bringing a significant number of
>     >     functions in-house and hiring significant staff (same
>     >     qualification, see [2]) to carry them out, I think it would be
>     >     entirely appropriate and quite desirable for its Board to have
>     >     to come back to the IETF, discuss the reasoning, and ask
>     >     permission [3].
>     >
>     >     I think that what I mean by "lean and mean" is similar to what I
>     >     believe Brian intended by "lightweight and cheap".   It isn't
>     >     about whether an individual whom the LLC needs to retain is
>     >     retained as an employee or as a contractor.   It is very much
>     >     about whether the number of people who end up being treated as
>     >     staff  (or people reporting to people treated as staff) by the
>     >     Executive Director become large enough to form a club, large
>     >     enough to require the Exec Dir or LLC Board to start thinking
>     >     about HR or employee relations programs or staff, or other
>     >     evolutionary changes that increase the probability of personnel
>     >     employed by (or contracted by) the IETF LLC beginning to set or
>     >     manipulate policy on their own.  That risk exists even when the
>     >     number of employees (or direct contractors) is only one (I know
>     >     of at least one example where I suggest that IASA 1..0 --and the
>     >     IETF-- suffered from that problem) but a great deal of
>     >     experience elsewhere with organizational behavior (with or
>     >     without bad management) suggests the risk rises much more
>     >     quickly that linearly with organization size.   If you believe
>     >     that the IETF LLC will, because of some inherent virtue, be
>     >     exempt from those pattern or organizational development and
>     >     evolution but it seems to me that, like a plan to improve
>     >     networking by having traffic exceed the speed of light by a bit,
>     >     those suggesting that we will be ok because it hasn't happened
>     >     here (yet, or very often) have the obligation to demonstrate why
>     >     those fundamentals will not express themselves in this case.
>     >
>     >     best,
>     >          john
>     >
>     >
>     >     [1] I'm also a little troubled by the "this is an IAB document"
>     >     discussion, but not for the reasons Alissa and others have
>     >     cited.  At least for the purposes of this discussion I'm fine
>     >     with the IAB getting community input and then making decisions
>     >     about hiring and most strategy for the RFC Editor.  However, if
>     >     a decision the IAB might make, or is considering making, would
>     >     change or expand the functions or authority of the IETF LLC or
>     >     its leadership, it seems to me that would lie squarely within
>     >     the the scope and responsibility of this WG and IETF consensus
>     >     more broadly.  If such a change were made using the IAB's
>     >     authority, especially if it were supported by the assertion that
>     >     the IAB is not a consensus body or responsible to IETF
>     >     consensus, it seems to me that would violate assumptions and
>     >     provisions that go directly back to POISED and the Kobe affair.
>     >
>     >     [2] As we have discussed separately, I think we are in agreement
>     >     that the difference between an employee and a contractor on an
>     >     individual contract who is treated as one is almost
>     >     non-existent, but I don't see that as the key issue here despite
>     >     several postings about it.
>     >
>     >     [3] I think trying to define how many hires (or consultants on
>     >     individual contracts treated as employees) are permitted would
>     >     quickly deteriorate into the kind of overspecification you and
>     >     others have decried (I agree that is not desirable)..   But that
>     >     is different from establishing clear guidance that, if the LLC
>     >     decides to start hiring multiple people, its Board is obligated
>     >     to come back to the community for discussion and before doing so.
>     >
>     >     _______________________________________________
>     >     iasa20 mailing list
>     >     iasa20@ietf.org <mailto:iasa20@ietf.org> <mailto:iasa20@ietf.org <mailto:iasa20@ietf.org>>
>     >     https://www.ietf.org/mailman/listinfo/iasa20
>     >
>     >
>     > _______________________________________________
>     > iasa20 mailing list
>     > iasa20@ietf.org <mailto:iasa20@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/iasa20
>     >
> 
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>