Re: [Iasa20] 6635bis

["Joel M. Halpern" <[e-mail]>]

So I went to look at Sean's original email, and at the text in RFC 6635.

Regarding the RSE, there is one place that implies that the RSE is a 
contractor, namely the figure on administrative implementation.  The 
emphasis in that diagram is on who is responsible for overseeing the 
RSE.  While we could wordsmith that, there seems to be little point.

The text that is explicit about contracting is relative to the RPC and 
the RFC Publisher.

The discussion has focused on the RSE.  There is already more 
flexibility in the RFC than I personally like in that regard.  But it is 
what we agreed as a community and I do not propose changing it.
So why would we need to make any changes to the document?

If the question is the RPC and / or the publisher, the issues of scale 
become very important.

Maybe the correct answer is for us all to stop arguing for any position 
until there is a proposed change that can be discussed?

Yours,
Joel

On 4/29/19 2:52 PM, Alissa Cooper wrote:
> Hi Joel,
> 
>> On Apr 29, 2019, at 2:28 PM, Joel M. Halpern <[e-mail]> wrote:
>>
>> I presume I am misreading part of the text below.
>> It seems to say that your understanding is that the ED could decide that the RSE needs to be an employee, and place that restriction on selecting candidates, without consulting the community.
>> Or that the ED could decide that the LLC should be staffing the RPC function directly without consultation with the community.
> 
> No, my point was that none of the other functions (secretariat, accounting, legal, tools, remote participation, communications, executive director, etc.) have RFCs written that constrain how the functions can be staffed. Historically, the IAD used his or her best judgment about how to staff them. For example, my understanding is that people resources to support accounting used to be essentially donated by other ISOC staff (or at least donated in the sense that they didn’t appear in the IETF budget), and within the last two years that became a contracted function. Tools project management used to be a volunteer activity, and now it’s provided by a paid contractor. And so on. The only roles that have RFC text restricting their employment type seem to be the RPC and, arguably, the RSE (6635 mentions an SOW for the RSE, which seems to imply contractor).
> 
> Also to clarify, I think the question Sean posed is “should the RFC allow for either situation” as opposed to “should the LLC staff role X with an employee.” The question is about the broad lines the RFC draws about how much leeway the LLC will have in the future, not about which employment type is best now or will be best later.
> 
> Does that clarify?
> 
> Thanks,
> Alissa
> 
>>
>> That seems so wrong that I presume it is not what you intended, and that I am misreading your text.
>>
>> Yours,
>> Joel
>>
>> On 4/29/19 2:24 PM, Alissa Cooper wrote:
>>> Hi Joel,
>>>> On Apr 29, 2019, at 1:56 PM, Joel M. Halpern <[e-mail]> 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 HR implications of more employees are also different than the HR implications with of an organization with one or two employees.
>>>>
>>>> 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.
>>> I disagree. Sections 5(c) and 5(d) and the LLC Agreement and Section 5.2 of rfc4071bis are clear about this. The Board hires and manages the ED and provides strategic direction. Whether the community wants to constrain the ED from having the flexibility to fill any particular role with employees or contractors does not bear on the workload of the 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.
>>> I don’t see anyone asking the question about whether to hire people as employees for the above functions. Indeed, this is the sort of decision the IAD historically made without community consultation, albeit the set of choices realistically available were different under ISOC. As far as I know we do not have RFCs written down that constrain whether any of the other roles are employees or contractors (including the ED role itself, which could be either). I think Sean's question is about whether to allow that flexibility in the future for the RSE role, and others have raised the same question about allowing the flexibility for the RPC functions in the future.
>>> Somewhat related to this is Section 5.5 of draft-haberman-iasa20dt-recs.
>>> Alissa
>>>>
>>>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>     --On Saturday, April 27, 2019 23:44 -0400 John Levine
>>>>>     <[e-mail] <mailto:[e-mail]>> 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
>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>     https://www.ietf.org/mailman/listinfo/iasa20
>>>>> _______________________________________________
>>>>> iasa20 mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/iasa20
>>>>
>>>> _______________________________________________
>>>> iasa20 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/iasa20
>