Re: [Iasa20] 6635bis

Ted Hardie <ted.ietf@gmail.com> Mon, 29 April 2019 20:54 UTC

Return-Path: <ted.ietf@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 51CB41207AA for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 13:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 aPSGFP4bX4-L for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 13:54:01 -0700 (PDT)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0: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 3C46A1207AB for <iasa20@ietf.org>; Mon, 29 Apr 2019 13:53:57 -0700 (PDT)
Received: by mail-it1-x130.google.com with SMTP id v143so1310613itc.1 for <iasa20@ietf.org>; Mon, 29 Apr 2019 13:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GqwHJluVMGYmg9c+2SI0GtnPYVQ/R+RV07KG2Ax+aAk=; b=l9Pt8NaiRF/rhWS6Qr5Fm55HYIM0CYsmLL/bjDs22I8jXaaP6OV1S1zmydlP5SLL2n rV76iwn/uJoKBSvwiQ2+rZGyo/jeqZt1bIRyK+Rkr/luxLL4dhn3WUqFapksarbOAklP igUrG0Wqr59RzzXwtKDv0aTxzGYf3y0vI2gxZPijcSlOKvorjjI55B7FGpBD51Fl+ckh Qp59RI6cN2chZrLpHP2qwEaV0errDMw7/FjMXcA874yhfobqvZENBdvNNo+KwL0JRMc7 cutWQk046a32A3SkOe91mJ25TMoawWymRu/vSp6hcJ/vIcLCBVl2k2Hy9bnZk3pLJH4O sJfA==
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=GqwHJluVMGYmg9c+2SI0GtnPYVQ/R+RV07KG2Ax+aAk=; b=ZYBhizqU287wsVwiGxGqQ0nG2EN7j3kyElpm4IY9xgr8IwA9GgtrN0ER7nnkykKcSw iuZZZL4oKCfebx3dgb4rbQxPEZr7HfdAFppZ4bQApHrhAHMQ8gSEVuSPpsm4NiBdvAYL iFX+csPWDa9D5TqPpWBa5ql9dVlbTlBgO8BJuxHAGalrWOhrI3IyTAwvwjv2qbQ/D3+2 HYSnEslqBtwbs35xWAwAe/eWB65Hn7FSdz2bNx+CKjfnOJf2DmkdKHnBvtM2a3J8Of/7 8sfEIci5w0l5VTIpqlN6kIjAb/8ZWYjJVOaPHBXSt2CSa2YVQzL1Cshtm85kiqyZ0mgI U+GA==
X-Gm-Message-State: APjAAAW9CxT23s6klQXkVaJVZ079ZbBeOrtShQaEypZjOj8j44mwe9vn YYx+sZ949OxNbr9TSqiDnMePYdmcNFO1TOtSjY4=
X-Google-Smtp-Source: APXvYqyP2Cez4W7NDEz+fG6Rd95cf4UcooCi64OjbfsVzwf/3fsE6HQ090FBIzJIEQbk44Bpz8Mwsd0R4U1Uz5GW1Bk=
X-Received: by 2002:a24:4f13:: with SMTP id c19mr945719itb.96.1556571236176; Mon, 29 Apr 2019 13:53:56 -0700 (PDT)
MIME-Version: 1.0
References: <20190428034407.4EC3B20130AC13@ary.qy> <43D5554EEDD8418CC4E0C195@PSB> <CAL02cgSnpP1pA=mStxkEahG8rmqEFL0CkAVkgq1b3mp_Kif9Sg@mail.gmail.com> <5A9A7451775BD1B632CB7140@PSB>
In-Reply-To: <5A9A7451775BD1B632CB7140@PSB>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 29 Apr 2019 13:53:28 -0700
Message-ID: <CA+9kkMChNEv1K6uA0OkCv=kDWd-DUxso88G-H1Y0g0fAKW5DWQ@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Richard Barnes <rlb@ipv.sx>, IASA 2 WG <iasa20@ietf.org>, John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="000000000000999a660587b17bcc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/wNkyvN4GEuieC0-Ukhgm0YEGsYU>
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: Mon, 29 Apr 2019 20:54:05 -0000

Howdy,

A couple of comments in-line.

On Mon, Apr 29, 2019 at 11:26 AM John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Monday, April 29, 2019 12:10 -0400 Richard Barnes
> <rlb@ipv.sx> 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?
>
> I may still not have the right tag line. There may not be one.
>
> However, to try again, I'm more concerned about the management
> and between-staff relationships than I am about the
> employee-contractor distinctions.  I think the latter are of
> little interest as long as the individual is full time but, as
> others have pointed out, can get a tad more complicated if they
> are not.  Specific cases may differ (see below).   Let's take
> the RSE and RPC as examples, with the understanding that other
> examples may differ.
>
> RSE: As long as the contracts are written carefully and any
> chosen LLC Executive Director's sense of boundaries exceeds that
> person's power and control influences, I don't see any
> difference between contractor and employee status.   However,
> note the qualifications there and the added burdens they may
> impose on the LLC Board to exert active oversight and maintain
> transparency about boundaries and authority (I don't believe we
> did very well about that sort of oversight and transparency with
> the IAOC and, while I see encouraging signs, I don't yet see
> either structural mechanisms that would better constrain the LLC
> Board; YMMD).   So, for example, many of us worked at
> universities at one time or another and had both staff/employee
> positions with the university and permission to do outside
> consulting.  The core relationships were clear: employment was
> with the university, primary loyalty was to the university, and
> the university had the right (subject to interminable arguments
> about academic freedom) to dictate what jobs could or could not
> be taken.   The RSE role is different: it is explicitly not
> full-time and the RSE appointees are presumably (and I assume
> contractually) free to do whatever they like with the rest of
> their time, subject only to (I assume) avoidance of significant
> conflicts of interest.  Could an employee agreement be designed
> to create that same situation?  I'm quite confident that it
> could and I'd have no problems with going that way if the LLC
> Board and Executive Director decided that was the right thing to
> do, subject to the comments below.  I do suggest it would be a
> bit harder, if only because such an employee agreement that
> doesn't put the employer into a position of being somehow
> primary is almost certainly not as common as contractor ones.
> I'd also be concerned with another issue that is hinted at
> above.  At present, the RSE reports to the IAB (or, as
> delegated, the RSOC).  The SOW belongs to the IAB, constrained
> for a particular RSE by whatever is covered in the contract (if
> that is not consistent with the SOW, the IAB has a problem, but
> one that I expect would quickly be sorted out among the parties
> involved).  That is unambiguous and, from the standpoint of what
> is normally meant by "reporting", I assume the contract is about
> how the RSE gets paid rather than about how the RSE is managed.
> However, if the RSE is an employee of the LLC, my understanding
> of the description of the Executive Director's role in the IETF
> Administration LLC agreement is that the RSE then "reports to"
> the Exec Dir.  Having two masters (on a day-to-day basis rather
> than general oversight of a contract) is rarely a good idea
> although I assume that boundaries could be sorted out as long as
> everyone involved behaved like an adults with the same goals
> (something else I believe can reasonably be assumed).
>
>
Having spent a lot of time in previous lives on government contracts, my
thinking on this has roughly been that the current model has the IAB as the
"task requester" (in NASA parlance) that sets out the work to be done
(that's delegated to the RSOC in our current system, but rooted at the
IAB).  The LLC and ISOC before it are the equivalent of contracting
officers, who have the authority to actually make the contracts and pay the
money.   It's common in such systems for an individual on a contract to
have two bosses (one being someone at the company holding the contract and
one being the task requester),  but commonly neither of them is the
contracting officer.

My take on Sean's question is whether the LLC itself could provide the
service, rather than contracting it out.   I don't think that requires a
change in who the task requester is; that would remain the IAB/RSOC.
Evaluating the performance against the tasks still happens there.  Having
that remain stable is why I think it is worth having the language be
flexible on this; the key piece of evaluating what should and has been done
does not change.

Just my own opinion and mental model,

Ted


I don't consider any of the above to be an important issue for
> an odd reason: I don't believe anyone who would have the skills
> and experience to be qualified to be RSE would accept an
> employment agreement that did not spell all of the details out
> in great care (or would accept such an agreement at all).   If
> the Exec Director and LLC Board decided it was worth the trouble
> to work out such agreements with a particular candidate, so be
> it.



> However, my assumption is that they (and the IAB) would
> discover that it severely constrained candidate choices.  And,
> of course, if someone were chosen for the RSE role without the
> right skills and experience, the problems that would cause would
> probably make details of employment or contractor relationship
> seem trivial by comparison.
>
> So now let's look at the RPC.  As I understand the current
> arrangement, there is a single contract with AMS to perform that
> function and the Exec Dir manages that contract while the RSE
> has oversight responsibility (and, I assume, high-level task
> assignment responsibility) for the specific work being done.  I
> assume the IETF LLC does not control (independent of any
> informal conversations that might occur) the particular people
> who are hired by AMS, their terms of employment, etc.  So,
> informal arrangements and discussions aside, neither the RSE nor
> the LLC Exec Dir are managing the staff of the RPC on a day to
> day basis.  Now, assume things are shifted so that the RPC
> function is brought in-house.  First of all, even if the Exec
> Dir appoints an RPC manager and delegates as much as possible to
> him or her, the Exec Dir is suddenly managing staff, perhaps a
> lot of staff.  There is more potential for conflicts between the
> Exec Director's role wrt that staff and the RSE's role,
> conflicts that are different (not necessarily better one way or
> the other) depending on which the RSE is also an LLC employee
> nominally reporting to the Exec Dir or a contractor with
> performance responsibilities only to the IAB.  There may (or may
> not) be an issue with the difference between that role for the
> Exec Dir and the role and skills for which the Exec Dir was
> chosen.
>
> And, as other people have suggested, I have another
> (not-quite-separate) concern should the number of employees of
> the LLC exceed some threshold that makes the shape and
> responsibilities of the organization a matter that requires
> separate consideration.  John Levine wrote in a separate note
> "I'd see no more than two employees in the forseeable future,
> the exec dir and maybe the RSE".   The threshold at which my
> experience suggests that one should become really worried about
> what I think Christian referred to as staff capture probably
> occurs when the number of employees gets close to or passes the
> size of the oversight body, so, modulo the concern above about
> the reporting chain for the RSE, that particular two-employee
> arrangement wouldn't, by itself, cause me to lose any sleep.
>
> However, I've also seen a lot of organization mission and
> staffing size creep in my time and, as suggested above, I don't
> believe the IAOC and IAD set positive records for openness and
> transparency and, indeed, sometimes did not live up to the
> expectations many or most of us had when the IASA 1.0 model was
> adopted.  I don't yet see enough of a positive track record for
> the LLC Board and Executive Director to dispel whatever concerns
> that history suggests, especially for decisions that enough
> personnel matters that the Exec Dir and LLC Board would be
> justified in making decisions in secret, negotiating and
> executing contracts or employment agreements, and then
> announcing the results, even then not providing the community
> without any details.   That risk existed with IASA 1.0 and the
> IAOC/IAD, but, as the discussion of appeals against Exec Dir or
> LLC Board actions made clear, the new arrangements, in practice,
> give the community no mechanism for directing the LLC Board if
> there is a different of opinion about strategy or holding Board
> members accountable except via waiting a long time for a
> sufficient set of Nomcom appointments role around or trying to
> use an ineffectual recall procedure.
>
> So, if the real issue here is "it should be ok for the Exec Dir
> and/or RSE to be employees", let's discuss that and, if there is
> rough consensus, write it into an appropriate document.  I
> personally see no problem with the first and have outlined some
> of the tradeoffs I see (including why I don't expect it to be an
> issue) with the second above.   But let's not use phrasing broad
> enough to allow the LLC to, e.g., pull the RPC or Secretariat
> in-house without coming back to the community and having a
> serious discussion.  Maybe we would actually want to do that but
> let's not spend a lot of time on it --or open the door to its
> being done on a creeping basis and in secret-- until we have a
> real example of why it would be good for the community in front
> of us.
>
> best,
>    john
>
>
>
>
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>