Subject: [Iasa20] 6635bis

From: Sean Turner <[email-masked]>
Date: Thu, 25 Apr 2019 14:14:30 -0400

Hi!  While I am not sending this message on behalf of the IETF Administration LLC, I have to admit that I am reading the IASA2.0 I-Ds with more interest as an LLC officer because I am somewhere nearer the front of the go-to-jail line if something goes terribly wrong ;)

With this in mind, after reading many of the the IASA2.0-related I-Ds the simple IAOC to LLC terminology swap totally makes sense.  For draft-ietf-iasa2-rfc6635bis, I am wondering whether more should be done.  Specifically, I am wondering whether the language about how the RSE services are delivered should be loosened or at least made internally consistent.  As I read it, draft-ietf-iasa2-rfc6635bis does include a reference to an “employment agreement or contracting plans, as appropriate” as it pertains to the RSOC working with the LLC concerning RSE services.  But, the rest of the draft, at least to me, reads as if the LLC will contract these services out with no wiggle room for an employee to do them.

The slant towards contracting made sense prior to forming the LLC, but now that the LLC has been formed these functions could be performed by an employee.  For any given role, the LLC might find it preferable to have the role filled by an employee versus a contractor for the purposes of being able to offer better benefits, to more easily comply with employment/tax law, or for other reasons. The original IASA model didn’t offer as much flexibility since hiring decisions were ultimately ISOC’s.  If the language in the draft was tweaked to accommodate both contractors and employees then this document would not, in mind at least, unnecessarily restrict the LLC.

Before I submit a list of potential edits to this list for draft-ietf-iasa2-rfc6635bis, I just wanted to see whether these type of changes would even be palatable?

Cheers,

spt

PS - I am sending this message right before some family-related activities so I might be slow to respond.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 25 Apr 2019 14:19:22 -0400

On Thu, Apr 25, 2019 at 2:14 PM Sean Turner <[email-masked]> wrote:

> Hi!  While I am not sending this message on behalf of the IETF
> Administration LLC, I have to admit that I am reading the IASA2.0 I-Ds with
> more interest as an LLC officer because I am somewhere nearer the front of
> the go-to-jail line if something goes terribly wrong ;)
>
> With this in mind, after reading many of the the IASA2.0-related I-Ds the
> simple IAOC to LLC terminology swap totally makes sense.  For
> draft-ietf-iasa2-rfc6635bis, I am wondering whether more should be done.
> Specifically, I am wondering whether the language about how the RSE
> services are delivered should be loosened or at least made internally
> consistent.  As I read it, draft-ietf-iasa2-rfc6635bis does include a
> reference to an “employment agreement or contracting plans, as appropriate”
> as it pertains to the RSOC working with the LLC concerning RSE services.
> But, the rest of the draft, at least to me, reads as if the LLC will
> contract these services out with no wiggle room for an employee to do them.
>
> The slant towards contracting made sense prior to forming the LLC, but now
> that the LLC has been formed these functions could be performed by an
> employee.  For any given role, the LLC might find it preferable to have the
> role filled by an employee versus a contractor for the purposes of being
> able to offer better benefits, to more easily comply with employment/tax
> law, or for other reasons. The original IASA model didn’t offer as much
> flexibility since hiring decisions were ultimately ISOC’s.  If the language
> in the draft was tweaked to accommodate both contractors and employees then
> this document would not, in mind at least, unnecessarily restrict the LLC.
>
> Before I submit a list of potential edits to this list for
> draft-ietf-iasa2-rfc6635bis, I just wanted to see whether these type of
> changes would even be palatable?

It seems important under the new model to ensure it could be a contractor
or an employee, so I'd think that's pretty palatable and wise.

best, Joe

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2019 14:22:19 -0400

Overall, this approach seems sensible to me.  The point of this document is
to describe the roles involved, and to minimize surprise with regard to how
the LLC arranges for those roles to be executed.  It should allow the LLC
flexibility where there's not a compelling need for constraint.  The
difference between employee and contractor does not seem salient in terms
of getting this work done.

--Richard

On Thu, Apr 25, 2019 at 2:14 PM Sean Turner <[email-masked]> wrote:

> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 25 Apr 2019 14:30:21 -0400

It would seem quite difficult to have the RFC Editor be an employee of 
the LLC.
What happens when the IAB / RSOC decides that it wants a different RSEs?
How would that employee respond to an RFP, since they already have an 
employment agreement with the LLC?

So while the underlying document does allow for using an employee, I 
would be very concerned about shifting the emphasis.

Also, a shift in that emphasis would seem to be a larger change than is 
in scope for this working group.

Yours,
Joel

On 4/25/19 2:22 PM, Richard Barnes wrote:
> Overall, this approach seems sensible to me.  The point of this document 
> is to describe the roles involved, and to minimize surprise with regard 
> to how the LLC arranges for those roles to be executed.  It should allow 
> the LLC flexibility where there's not a compelling need for constraint.  
> The difference between employee and contractor does not seem salient in 
> terms of getting this work done.
> 
> --Richard
> 
> On Thu, Apr 25, 2019 at 2:14 PM Sean Turner <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Administration LLC, I have to admit that I am reading the IASA2.0
>     I-Ds with more interest as an LLC officer because I am somewhere
>     nearer the front of the go-to-jail line if something goes terribly
>     wrong ;)
> 
>     With this in mind, after reading many of the the IASA2.0-related
>     I-Ds the simple IAOC to LLC terminology swap totally makes sense. 
>     For draft-ietf-iasa2-rfc6635bis, I am wondering whether more should
>     be done.  Specifically, I am wondering whether the language about
>     how the RSE services are delivered should be loosened or at least
>     made internally consistent.  As I read it,
>     draft-ietf-iasa2-rfc6635bis does include a reference to an
>     “employment agreement or contracting plans, as appropriate” as it
>     pertains to the RSOC working with the LLC concerning RSE services. 
>     contract these services out with no wiggle room for an employee to
>     do them..
> 
>     The slant towards contracting made sense prior to forming the LLC,
>     but now that the LLC has been formed these functions could be
>     performed by an employee.  For any given role, the LLC might find it
>     preferable to have the role filled by an employee versus a
>     contractor for the purposes of being able to offer better benefits,
>     to more easily comply with employment/tax law, or for other reasons.
>     The original IASA model didn’t offer as much flexibility since
>     hiring decisions were ultimately ISOC’s.  If the language in the
>     draft was tweaked to accommodate both contractors and employees then
>     draft-ietf-iasa2-rfc6635bis, I just wanted to see whether these type
>     of changes would even be palatable?
> 
>     Cheers,
> 
>     spt
> 
>     PS - I am sending this message right before some family-related
>     activities so I might be slow to respond.
>     [email-masked] <mailto:[email-masked]>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 25 Apr 2019 18:30:48 +0000

+1

From: iasa20 <[email-masked]> On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2019 11:22 AM
To: Sean Turner <[email-masked]>
Cc: IASA 2 WG <[email-masked]>
Subject: Re: [Iasa20] 6635bis

Overall, this approach seems sensible to me.  The point of this document is to describe the roles involved, and to minimize surprise with regard to how the LLC arranges for those roles to be executed.  It should allow the LLC flexibility where there's not a compelling need for constraint.  The difference between employee and contractor does not seem salient in terms of getting this work done.

--Richard

On Thu, Apr 25, 2019 at 2:14 PM Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
Hi!  While I am not sending this message on behalf of the IETF Administration LLC, I have to admit that I am reading the IASA2.0 I-Ds with more interest as an LLC officer because I am somewhere nearer the front of the go-to-jail line if something goes terribly wrong ;)

With this in mind, after reading many of the the IASA2.0-related I-Ds the simple IAOC to LLC terminology swap totally makes sense.  For draft-ietf-iasa2-rfc6635bis, I am wondering whether more should be done.  Specifically, I am wondering whether the language about how the RSE services are delivered should be loosened or at least made internally consistent.  As I read it, draft-ietf-iasa2-rfc6635bis does include a reference to an “employment agreement or contracting plans, as appropriate” as it pertains to the RSOC working with the LLC concerning RSE services.  But, the rest of the draft, at least to me, reads as if the LLC will contract these services out with no wiggle room for an employee to do them..

Cheers,

spt

PS - I am sending this message right before some family-related activities so I might be slow to respond.
_______________________________________________
iasa20 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iasa20

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Apr 2019 11:49:36 -0700

This also seems reasonable to me. Generally, I think of this section of the
document as almost like a requirements document for what the LLC ought to
be doing for the IETF, and the employee/contractor distinction doesn't seem
like a relevant requirement, as long as the LLC is properly able to respond
to the IETF's needs as managed by the IAB/RSOC.

-Ekr

On Thu, Apr 25, 2019 at 11:22 AM Richard Barnes <[email-masked]> wrote:

> is to describe the roles involved, and to minimize surprise with regard to
> how the LLC arranges for those roles to be executed.  It should allow the
> LLC flexibility where there's not a compelling need for constraint.  The
>> contract these services out with no wiggle room for an employee to do them..
>>
>> The slant towards contracting made sense prior to forming the LLC, but
>> now that the LLC has been formed these functions could be performed by an

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Apr 2019 15:00:11 -0400

A comment in-line.

On Thu, Apr 25, 2019 at 2:14 PM Sean Turner <[email-masked]> wrote:

> First, I really appreciate the LLC (or you as an individual) asking this
question of the community in this context; it's an important enough to get
community input on rather than deciding off-line.

Second, I do think that having both models be possible would be a useful
change.  I certainly don't want to remove the current model as a
possibility, but being able to have an employee relationship may make it
easier to be flexible in the future.

regards,

Ted

---

From: Bob Hinden <[email-masked]>
Date: Thu, 25 Apr 2019 15:32:55 -0700

Sean,

> On Apr 25, 2019, at 11:14 AM, Sean Turner <[email-masked]> wrote:
> 

With my editors hat on, the direction I received for doing this update was that changes like this was out of scope for the IASA 2.0 process.    

I also suspect that once the LLC has been in operation for a year or two, that there may be a range of things that the community will want to update. 

Bob

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Apr 2019 18:48:42 -0400

Like others, I don't see why we should be encoding this detail of the employment relationship in an RFC.  I recognize Joel's point about that making certain actions, like replacement, more challenging.  However, I don't see that as a concrete problem - my understanding is that the rules around termination of contract and termination of employment are equally fraught.  This does appear in many ways to be an employment relationship as it is (but that is based on no real expertise, just a reading of Publication 15-A, Section 2, so give that zero real weight).

I did a scan of the document and found a few places that mention contracts.  The mentions of contracting are either OK with respect to Sean's request in that the term "contract" is sufficiently abstract as to allow for an employment contract, or the text refers to the RPC/Publisher contracts.  Figure 2 and Section 4.4 are the only tricky parts because they seem to apply to both RSE and RPC/Publisher.

That raises a question: why only consider the RSE as employee?

The RPC (and RFC Publisher, though I see little evidence of this being a separate entity in practice) is very clearly defined as a contractor (see Section 2.1).  But the work done there could be similarly employment-like.  Would the LLC not also want the option to employ staff for an RFC Production Center and Publisher?

That is a bigger change, because the document treats the RPC as a separate entity and requires things like RFPs for the function.  But it seems to me like this is an important thing to consider here.

--Martin

On Fri, Apr 26, 2019, at 04:14, Sean Turner wrote:
> Administration LLC, I have to admit that I am reading the IASA2.0 I-Ds 
> with more interest as an LLC officer because I am somewhere nearer the 
> front of the go-to-jail line if something goes terribly wrong ;)
> 
> With this in mind, after reading many of the the IASA2.0-related I-Ds 
> the simple IAOC to LLC terminology swap totally makes sense.  For 
> draft-ietf-iasa2-rfc6635bis, I am wondering whether more should be 
> done.  Specifically, I am wondering whether the language about how the 
> RSE services are delivered should be loosened or at least made 
> internally consistent.  As I read it, draft-ietf-iasa2-rfc6635bis does 
> include a reference to an “employment agreement or contracting plans, 
> as appropriate” as it pertains to the RSOC working with the LLC 
> concerning RSE services.  But, the rest of the draft, at least to me, 
> reads as if the LLC will contract these services out with no wiggle 
> room for an employee to do them.
> 
> now that the LLC has been formed these functions could be performed by 
> an employee.  For any given role, the LLC might find it preferable to 
> have the role filled by an employee versus a contractor for the 
> purposes of being able to offer better benefits, to more easily comply 
> with employment/tax law, or for other reasons. The original IASA model 
> didn’t offer as much flexibility since hiring decisions were ultimately 
> ISOC’s.  If the language in the draft was tweaked to accommodate both 
> contractors and employees then this document would not, in mind at 
> least, unnecessarily restrict the LLC.
>

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2019 23:38:30 -0400

>employment agreement with the LLC?

You write the employment agreement with that in mind.  It's not hard to do.

I agree with Sean that it makes sense to give the LLC latitude to hire
or contract with people on whatever terms make sense.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Apr 2019 15:40:51 +1200

>> With this in mind, after reading many of the the IASA2.0-related I-Ds the simple IAOC to LLC terminology swap totally makes sense.  For draft-ietf-iasa2-rfc6635bis, I am wondering whether more sho…

I can't tell whether Sean is referring to the RFC Series Editor (a single person) or to the RFC Production Center function (a team and its hardware and software), or the RFC Publisher (also a team and its hardware and software). The three cases are separate.

Re the Editor, the draft says "The RSE is appointed by the IAB, but formally hired by the LLC." That leaves it ambiguous whether "hired" means hired as an employee or hired as a contractor, which is fine. However, since the RSE has editorial independence, my guess is that a contracting model is much more suitable than an at-will employee model. In any case, the IAB is in control of this choice.

Re the Production Center, that is clearly stated as a "paid contractor", as is the "RFC Publisher contractor".

To me it would make no sense to have *individuals* employed by the LLC who are part of either of those teams. So it's all or nothing: the Production Center and the Publisher would have to be either 100% in-house employees or 100% contracted out. But why we'd want the LLC, which we were promised would be lightweight and cheap, to starting hiring software and operations staff and buying or renting servers, is a bit beyond me.

>> The slant towards contracting made sense prior to forming the LLC, but now that the LLC has been formed these functions could be performed by an employee. 

Specifically, I would regard that as a broken promise: not lightweight, not cheap.

>> For any given role, the LLC might find it preferable to have the role filled by an employee versus a contractor for the purposes of being able to offer better benefits, to more easily comply with employment/tax law, or for other reasons. The original IASA model didn’t offer as much flexibility since hiring decisions were ultimately ISOC’s.  If the language in the draft was tweaked to accommodate both contractors and employees then this document would not, in mind at least, unnecessarily restrict the LLC.

It would open the door to a heavyweight, expensive LLC.

>> Before I submit a list of potential edits to this list for draft-ietf-iasa2-rfc6635bis, I just wanted to see whether these type of changes would even be palatable?

Not to me, if you hadn't guessed ;-)

In the charter:

>>> This working group is chartered to document the normative changes to IETF
>>> administrative structures and processes necessary to effectuate this change.

This certainly doesn't seem like a necessary change, and BTW it's the IAB that "owns" the RFC Editor arrangements, not the IETF.
 
> I also suspect that once the LLC has been in operation for a year or two, that there may be a range of things that the community will want to update. 

Very likely. But I can promise a lot of noise if people propose to move away from the lightweight cheap LLC we were promised.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Apr 2019 15:54:16 +1200

> or contract with people on whatever terms make sense.

The language already allows that for the RSE case. The language for the
Production Center and the Publisher does not; they are required to be
contracted out. As I said at length, that's consistent with the lightweight
LLC we were initially promised. I really don't see that this WG is allowed
to change it.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Apr 2019 21:06:58 -0700

n Thu, Apr 25, 2019 at 8:41 PM Brian E Carpenter <
[email-masked]> wrote:, that is clearly stated as a "paid
contractor", as is the "RFC Publisher contractor".

>
> To me it would make no sense to have *individuals* employed by the LLC who
> are part of either of those teams. So it's all or nothing: the Production
> Center and the Publisher would have to be either 100% in-house employees or
> 100% contracted out. But why we'd want the LLC, which we were promised
> would be lightweight and cheap, to starting hiring software and operations
> staff and buying or renting servers, is a bit beyond me.
>

Hi Brian,

I'd like to dig into a few of the operational concerns you raise here.

First, you say that you think that the RPC and the Publisher should be
either 100% in house or 100% contracted. In my experience, both as someone
on the employer and employed side, it's quite common to have a mix of
employees and consultants. For instance, you might have a staff of people
who do the regular work and then occasionally hire specialists to do some
work that you don't need a FTE for. Another example is when you have a
temporary increase in load so you hire extra contract staff to fill in the
gaps during the heavy period under the assumption that you'll let them go
when the load decreases. It's also not uncommon to have some FTEs who
manage a contract with a company which does most of the work. Can you say
more on why you think this is unworkable?

Second, you contrast the idea of hiring staff to do these jobs with a
"lightewight and cheap" LLC that contracts these functions out. Lightweight
is kind of subjective, but as a practical matter, it's often more expensive
to contract out tasks than it is to have them done by FTEs because you pay
a premium for a short term engagement and/or one which is easier to
terminate. Of course, if you want that flexibility then this is advisable,
but in cases where you have a relatively steady base of work, then it's
often cheaper to have FTEs (and, as above, fill in gaps with contractors).

Or am I misunderstanding you?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Apr 2019 16:53:27 +1200

Hi Eric,

On 26-Apr-19 16:06, Eric Rescorla wrote:
> n Thu, Apr 25, 2019 at 8:41 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:, that is clearly stated as a "paid contractor", as is the "RFC Publisher contractor".
> 
> 
> First, you say that you think that the RPC and the Publisher should be either 100% in house or 100% contracted. In my experience, both as someone on the employer and employed side, it's quite common to have a mix of employees and consultants. For instance, you might have a staff of people who do the regular work and then occasionally hire specialists to do some work that you don't need a FTE for. Another example is when you have a temporary increase in load so you hire extra contract staff to fill in the gaps during the heavy period under the assumption that you'll let them go when the load decreases. It's also not uncommon to have some FTEs who manage a contract with a company which does most of the work. Can you say more on why you think this is unworkable?

If the team is *managed* within the LLC, but brings in contractors when it needs to, sure, that can be made to work, of course. With the usual potential for misunderstandings, of course. Managerially, I'd prefer to avoid it.

> Second, you contrast the idea of hiring staff to do these jobs with a "lightewight and cheap" LLC that contracts these functions out. Lightweight is kind of subjective, but as a practical matter, it's often more expensive to contract out tasks than it is to have them done by FTEs because you pay a premium for a short term engagement and/or one which is easier to terminate. Of course, if you want that flexibility then this is advisable, but in cases where you have a relatively steady base of work, then it's often cheaper to have FTEs (and, as above, fill in gaps with contractors).

That's true enough. But again, you have the LLC managing and doing the work. 
 
> Or am I misunderstanding you?

No. It's just that an LLC that performs and manages such work itself is very different from what I thought we'd agreed to do, which I understood to be an administrative entity. Definitely creeping featurism IMHO.

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Apr 2019 08:55:37 +0100

Hiya,

On 25/04/2019 23:32, Bob Hinden wrote:
> With my editors hat on, the direction I received for doing this
> update was that changes like this was out of scope for the IASA 2.0
> process.
> 
> I also suspect that once the LLC has been in operation for a year or
> two, that there may be a range of things that the community will want
> to update.
That makes sense to me. We don't need to fix every bit of
old text like this.

Cheers,
S.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 26 Apr 2019 09:45:20 -0400

> On Apr 25, 2019, at 11:40 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> In the charter:
> 

I thought the plan for this doc and the other IAB stream bis documents was to discuss them here prior to the IAB running its usual call for community comment for IAB stream documents. Perhaps Ted can confirm. We had some substantive discussions about this doc on this list last year. I still think this is a fine venue for this sort of discussion prior to the IAB taking up the document.

Alissa

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 26 Apr 2019 09:53:47 -0400

> staff and buying or renting servers, is a bit beyond me.

Brian, I may be going a bit nuts or daft, but can you remind me where we
talked about a goal of this process being that the LLC is lightweight and
cheap? I think this might be confusing the goals of the LLC Board and the
LLC... we definitely wanted the overly-burdened IAOC to change to be more
strategic and nimble and less involved with operational administrative
decisions. But we always contemplated the LLC needing to grow in terms of
staff (that's been in all of the drafts as we want FTEs in roles that ISOC
filled with employees). I'm not arguing that it should be heavyweight and
expensive, just that I seem to have forgotten where we stated this and that
seems to be an important part of what you're arguing. best, Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Apr 2019 10:07:23 -0400

Hi Brian,

No hat.

> Specifically, I would regard that as a broken promise: not lightweight, not cheap.

I don't understand this claim.

As near as I can tell, we are talking about a couple different options
for a function that, regardless, needs to be provided.  The cost of
doing this on an employee vs. a contract basis is, I'd say, quite
clearly an empirical matter that changes over time and that is
something best determined by an excecutive director in a position to
make that managerial decision.  So the "cheap" part does not seem to
be something you can assert in this way.

Similarly, we are talking about a couple different options for a
funciton that, regardless, needs to be provided, and provided through
the LLC in some way.  The way that minimizes the overhead of
provision, which is what I think "lightweight" means, seems to me to
be the sort of thing that only the relevant management can evaluate
based on (again) empirical factors before him or her.

So it seems to me that the promise can only be fulfilled by actually
permitting this flexibility.

Our experience with the old IASA design was precisely that too many
things were overspecified in the RFCs, and it seems to me that setting
things up this way so that the IASA2 function can proceed according to
sound and flexible management would be good.

What am I missing that you're seeing?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 26 Apr 2019 10:31:05 -0400

I am traveling and will have to wait until next week to review the draft, but I share some of Brian's concerns. In two words, staff capture. The RSE  performs a mix of production functions and policy functions -- supervising the machinery of RFC publishing through the RFC production and publication on one hand, driving format evolution and other publication policies on the other hand.

I can debate staff versus contract decisions for the production functions, but I would have strong reservations in moving policy functions to a staff position -- this would be a first step on the path to staff capture.

-- Christian Huitema

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Apr 2019 11:40:17 -0400

> With this in mind, after reading many of the the IASA2.0-related I-Ds the simple IAOC to LLC terminology swap totally makes sense.  For draft-ietf-iasa2-rfc6635bis, I am wondering whether more shou…

Thanks for starting this discussion.

I would like to see the whole community gain a lot more confidence in the IASA 2.0 structure before a large number of people get hired by the LLC.  Clearly, the Executive Director needs to be hired very quickly, but the transition of the existing contracts from ISOC to the LLC means that most other positions are much less urgent.

Bob Hinden pointed out that the directions given to him as editor were to make the minimum changes.  I think that those were the right directions at the time.

> The slant towards contracting made sense prior to forming the LLC, but now that the LLC has been formed these functions could be performed by an employee. 

I do not know if that would be cheaper or more expensive, but I would expect the LLC board to bring such a shift to the IETF community before doing it.

> Before I submit a list of potential edits to this list for draft-ietf-iasa2-rfc6635bis, I just wanted to see whether these type of changes would even be palatable?

I do not mind the RFCs allowing it.  Flexibility is important, but that does not mean that the flexibility should be exercised without consulting the IETF community.

Russ

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 26 Apr 2019 19:41:15 +0000

>    I also suspect that once the LLC has been in operation for a year or two, that there may be a range of things that the community will want to update. 
    
[JL] For sure -- the WG specified in 4071-bis a 3-year out retrospective - https://tools.ietf.org/html/draft-ietf-iasa2-rfc4071bis-11#section-9 - so there will be a chance for revisiting things in the future based on what we learn in actual operation. That being said, it seems like if we identify small things that are obviously odd as we transition to the LLC - then we may as well try to fix them if we have consensus and get the relevant IETF/IAB reviews as well.

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 26 Apr 2019 19:55:40 +0000

Some personal observations on this topic/discussion:
- Seems like consensus is consistent with other IASA2 docs - we don't want to over-specify things and value operational flexibility for the LLC. 
- The various people performing RFC-related administrative functions could be contractors, employees, or a mix of the two. 
- It doesn't seem worthwhile to constrain/specify the categories for the people performing the functions (e.g. role X may only be a contractor).
- The LLC is administratively & legally responsible to contract/terminate/hire/fire in this area. Other groups would (obviously) provide input/advice into those decisions but I think on a strictly legal basis those actions seem to fall to the LLC.

I'm not sure how to resolve this. If the WG doesn't want to address all these issues now then perhaps a helpful compromise is to add a section at the end of 6635bis that somehow highlights this as an open issue to be resolved in the future, and that in the meantime the LLC is the responsible legal party and will need to conduct itself accordingly? Dunno...

Thanks
Jason

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Apr 2019 08:02:38 +1200

> I thought the plan for this doc and the other IAB stream bis documents was to discuss them here prior to the IAB running its usual call for community comment for IAB stream documents. Perhaps Ted c…

I fully agree, and I'm sure the IAB will note the debate here.

   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Apr 2019 08:37:34 +1200

Hi Andrew,

Replying to you, and also to Joe's message saying much the same:

> I don't understand this claim.

Before the consensus was declared to be abolishing the IAOC and
creating the LLC, you certainly recall that a number of us were
very doubtful about this, and about its complexity and overhead,
compared to making the IAOC function as originally intended. We 
were definitely led to believe that the LLC would be lightweight,
would have a minimum number of staff, and would clarify rather
than obscure who does what.

Now, that isn't explicitly stated in draft-dt-iasa20-proposal-00.
Perhaps it should have been. It was certainly always my understanding.
For example, see the model sketched by Richard Barnes at
https://mailarchive.ietf.org/arch/msg/iasa20/fRyoi3fnQNLAGtOqEi4NNp78I2M
where all operations are shown as subcontracted and what we now
call the LLC has a very simple structure. I like that picture, and
that's what I thought we were getting.

> be something you can assert in this way.

If the LLC grows to the point where it has many employees, some of whom
are working as part of an operational team with subcontractors, it will
become less and less clear whether it's a "cheap" operation or not.
Responsibilities will become unclear, exactly as they were in the
old regime. 

> sound and flexible management would be good.

Point taken, but in this specific case (the RFC Editor function) we
already have a well understood and well operating solution based
on subcontracting. Retaining this solution for this case doesn't
constrain the LLC in general.

Regards
    Brian

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2019 17:19:00 -0400

In article <[email-masked]> you write:
>>> The slant towards contracting made sense prior to forming the LLC, but now that the LLC has been formed
>these functions could be performed by an employee. 
>

Sorry, but as others have implied that's just wrong.

US employment law is complicated.  I have been an employer and an
employee, been a contractor, and hired contractors, and I would still
not claim to be an expert.  Whether someone is a contractor or an
employee has nothing to do with the length of the contract or the
terms on which it might be broken.  It has to do with stuff like who
pays for medical insurance (a big deal in the US) and pension
contributions.  It is not entirely up to the two parties -- there are
cases where someone is hired as a contractor, appeals to the labor
department, and it decides that the facts of the relationship make the
person an employee.  You cannot say whether a contractor is cheaper or
more expensive than an employee without knowing the details of that
particular job and the particular agreements.

This is the kind of business detail that we invented the LLC to take
care of.  None of us are employment law experts and it would be absurd
for us to define rules that purport to define the details of
employment relationships.

The IAB can certainly say who to hire as the RSE or whatever, what the
job entails, for how long and what would make the parties end the
agreement early.  Beyond that, it's up to the LLC.

R's,
John

---

From: Richard Barnes <[email-masked]>
Date: Fri, 26 Apr 2019 17:26:29 -0400

On Fri, Apr 26, 2019 at 5:19 PM John Levine <[email-masked]> wrote:

> now that the LLC has been formed
> person an employee.

See, e.g.,
https://www.nytimes.com/2019/03/12/technology/uber-drivers-lawsuit-settle.html

> You cannot say whether a contractor is cheaper or

💯💯💯

--RLB

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Apr 2019 17:29:05 -0400

What I fail to see is why there is any need to change the wording that 
we have on the status of the RSE.  I can imagine that the LLC will need 
to continue to exercise care in the handling of the RSE to avoid 
accidental changes of status.  As you say John, it is tricky.
But I do not see why that should result in any change to the text in the 
revision of RFC 6635.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Apr 2019 22:35:40 +0100

On 26/04/2019 15:31, Christian Huitema wrote:
>  staff capture

I agree this is a concern. ISTM that the more FTEs
the LLC has, the higher the probability that this
risk eventuates.

Changing or not changing the wording here probably
has little effect on that risk though, but I'd still
argue to leave it alone and possibly revisit this
when the LLC has been around a while.

Cheers,
S.

---

From: "John R Levine" <[email-masked]>
Date: 26 Apr 2019 18:39:16 -0400

> What I fail to see is why there is any need to change the wording that we 
> have on the status of the RSE.  I can imagine that the LLC will need to 
> continue to exercise care in the handling of the RSE to avoid accidental 
> changes of status.  As you say John, it is tricky.

Assuming we agree that the details of the agreement with the RSE are up to 
the LLC, I agree.

But RFC 6635 says "The RFC Production Center function is performed by a 
paid contractor," and " The RFC Production Center contractor is to be 
selected through an IASA Request for Proposal (RFP) process as described 
in Section 4.1." and " The RFC Publisher contractor is to be selected 
through an IASA RFP process as described in Section 4.1."

I think the current RFC people are doing a swell job but I would like us 
to give the LLC the latitude to structure things however makes sense.  At 
this point, we have a contractor which hires its staff but at some point 
it might make sense for the LLC to hire staff without an intermediary.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Apr 2019 12:04:33 +1200

Just one point:
> agreement early.  Beyond that, it's up to the LLC.

Yes, and the draft text, like RFC6635, is quite open on this.

Where it isn't open is that it intentionally specifies subcontracts
for the technical work, and I haven't seen any argument why this
WG is allowed to change that. As I understand it, since the RFC Editor
is not in the scope of the WG charter, we are simply making clerical
corrections to RFC6635, roughly equivalent to s/IAOC/LLC/. Anything
beyond that belongs elsewhere (and has implications beyond the IETF).

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Apr 2019 20:29:56 -0400

As far as I can tell, the change you propose is not necessary to get the 
LLC working.  This working group was specifically chartered NOT to 
change any policies.  The change you (and Sean if I understand properly) 
are proposing represents a change in policy.

Yes, I disagree with the change in policy.  I think it would be a mistake.

But more importantly, that change is clearly outside of the scope the 
community was told applied to this working group.

If you want to write a separate I-D, and try to find a venue for it, to 
change that policy, you clearly have the right and skills to do so.
But please do not put that substantive change into this I-D (RFC 
revision) that is specifically to make the necessary changes so the LLC 
can do the jobs it needs to do.

Yours,
Joel

On 4/26/19 6:39 PM, John R Levine wrote:
>> we have on the status of the RSE.  I can imagine that the LLC will 
>> need to continue to exercise care in the handling of the RSE to avoid 
>> But I do not see why that should result in any change to the text in 
>> the revision of RFC 6635.
> 
> Assuming we agree that the details of the agreement with the RSE are up 
> to the LLC, I agree.
> 
> to give the LLC the latitude to structure things however makes sense.  
> At this point, we have a contractor which hires its staff but at some 
> point it might make sense for the LLC to hire staff without an 
> intermediary.
> 
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 26 Apr 2019 20:34:37 -0400

> As far as I can tell, the change you propose is not necessary to get the LLC 
> working.  This working group was specifically chartered NOT to change any 
> policies.  The change you (and Sean if I understand properly) are proposing 
> represents a change in policy.
>

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.

But I don't seem to be in the majority here.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Apr 2019 21:28:14 -0400

--On Friday, 26 April, 2019 17:19 -0400 John Levine
<[email-masked]> wrote:

>>>> The slant towards contracting made sense prior to forming
>>>> the LLC, but now that the LLC has been formed
> US employment law is complicated.  I have been an employer and
> an employee, been a contractor, and hired contractors, and I
> would still not claim to be an expert.  Whether someone is a
> contractor or an employee has nothing to do with the length of
> the contract or the terms on which it might be broken.  It has
> to do with stuff like who pays for medical insurance (a big
> deal in the US) and pension contributions.  It is not entirely
> up to the two parties -- there are cases where someone is
>...

John, 

I share some of Brian's concerns although I think the part of
the problem he emphasized has probably created a distraction
from the key issue.   Certainly, in many countries, the key
difference between an employee and a contractor -- that
employees, after a relatively short period, are really hard to
fire and sometimes really hard to reassign for either
incompetence or because needs change-- does not apply in the US.
But it also isn't what I see as the issue, an issue that hinges,
not on employment law but on human and organizational behavior.  

I see two potential problems, neither of which has anything to
do with employment law and both of which many of us have seem
acted out in other organizations:

* At the point that an "administrative" function starts
acquiring significant employee staff, or staff who see
themselves as equivalent to employees or are so seen by
management, staff who are actually carrying out organizational
functions rather than providing support, incentives almost
inevitably change from depending on and serving a wider
community to preservation of the organizational structure and
the staff tail wagging the organizational dog.  We seen
variations of that happen with a number of other SDOs where
standards strategy decisions are basically made by staff and,
arguably, with some organizations in our midst such as ISOC and
ICANN.  FWIW, the larger the staff gets, the more incentive and
justification the Exec Dir has to ask for more money and, more
important, more authority on the grounds that the alternate is
the Board micromanaging.

* At the point that the staff of the organization with the
control of the money starts being responsible for technical
work, the balance of authority and power between the volunteer
participants in the SDO and the leadership/ management of that
organization starts to shift.  After all, they are full time and
can determine how to allocate resources to particular work while
the rest of us are mostly part time unless we are accountable to
some organizational entity outside the IETf that is able to call
the shots.

Is either of those scenarios inevitable?  I hope not although
history in other bodies might suggest that they are.  But,
unless we are much more confident in the ability of the LLC
Board to manage the situation effectively and to remain
transparent about its actions and decisions to the community
(and responsive to community input) than IAOC has ever been, the
risks are real and moving in the direction of more
employee-staff is part of those risks.

There is another, perhaps subtle, distinction.  As I understand
the current arrangements with the RFC Production Center (and, I
believe, the Secretariat), there are single contracts for each
between the body contracting on behalf of the IETF and another
organization.  None of the IETF, the LLC Board, or the Executive
Director get to select or manage individual staff members or
their work associated with those contracts or operations.  The
LLC Board and the Exec Dir (or the IAOC and IAD under IASA 1.0)
manage contracts, not people.  A situation in which they are
managing individuals -- whether those individuals are nominally
employees or contractors-- is very different and really does
change scope and responsibilities.

Finally, I agree with others that the proposed change to allow
employees -- presumably individual ones and essentially moving
functions requiring a team inside the LLC -- is a change that
lies well outside the scope of the WG.

   john

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Apr 2019 22:26:43 -0700

Hi Sean,
At 11:14 AM 25-04-2019, Sean Turner wrote:
>nearer the front of the go-to-jail line if something goes terribly wrong ;)

The legal document for the LLC defines how the business and affairs 
of the company will be managed.  My interpretation of that document 
is that a LLC Director would not be considered as an Officer of the LLC.

>to more easily

I have not been following those administrative discussions about the 
IETF.  I agree with Brian's comment [1] about "lightweight" as that 
is, in my opinion, in line with what is stated in the IASA2 Charter.

Regards,
S. Moonesamy

1. https://mailarchive.ietf.org/arch/msg/iasa20/Fyj8-piL_ASKKEqUPgxQ9uAXOsg

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 27 Apr 2019 20:49:42 +0000

I agree.  This is not like specifying bits on the wire. :)

---

From: Richard Barnes <[email-masked]>
Date: Sat, 27 Apr 2019 17:00:29 -0400

+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?

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.

--Richard

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Apr 2019 09:40:15 +1200

On 28-Apr-19 09:00, Richard Barnes wrote:
> 
> 
> On Sat, Apr 27, 2019 at 4:49 PM Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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

---

From: Bob Hinden <[email-masked]>
Date: Sat, 27 Apr 2019 19:43:25 -0700

Hi,

A few comments on this thread.

The RFC Editor services are broken into several parts.  There is the RFC Editor, a person doing that job with independent authority, and the Production Center where the actual editing, document production, online publication, and archiving is done.

The Production Center work is done by many people with a range of skills, full and part time editors, managers, software development, and IT support.  It’s large enough that it need staff services like HR.   People doing that job require specific training how RFCs are produced, the rules for what they look like, and the specific tools that they use to do their job.  I am probably understating this.

In my direct experience having been very involved in the hiring of two RFC Editors and the transition of this work from ISI, its very specialized.  We typically don’t get a lot of qualified bidders.   

The individual fulfilling the RFC Editor job could be a contractor or direct employee, but the kind of person who is capable of doing that job that you want to hire, will have a strong opinion which form of employment they will want.   The leverage is with the candidate, not the LLC.

Given the size and complexity of the Production Center activity, it would be a major undertaking to bring into the LLC.  The LLC would have to hire and train people capable of doing the work, provide them benefits, have managers to mange them, provide employee services for them, etc., etc.   We were very fortunate in the move from ISI that several of the key personal moved with the work.  It’s not clear that would happen again.

I think that if the LLC is seriously thinking of moving the Production Center activity inside of the IETF LLC, they don’t understand this activity.   As others have said, it would grow the amount of staff needed by the LLC significantly and turn it into a medium size company with all that entails.

Bob

---

From: "John Levine" <[email-masked]>
Date: 27 Apr 2019 23:44:06 -0400

In article <[email-masked]> you write:
>I think that if the LLC is seriously thinking of moving the Production Center activity inside of the IETF LLC,
>they don’t understand this activity.   As others have said, it would grow the amount of staff needed by the
>LLC significantly and turn it into a medium size company with all that entails.

I'm fairly sure they aren't.  

The point is that in the past the IAOC's semi-non-existence forced us
to use contractors for everything.  We don't have that issue any more
and it's not hard to forsee a situation where it could make sense for
the LLC's director or the RSE to be an employee rather than a
contractor.  Or it might make sense to have an employee who does some
aspect of the meeting management.

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.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Apr 2019 14:12:43 +0100

On 27/04/2019 22:40, Brian E Carpenter wrote:
>> 
>> 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?
>

I agree.

In addition, I think we did discuss this before - immodestly
quoting myself (urgh:-) from a thread [1] last year, this
statement did seem to get support from lots of people:

   "I do not want, and am unaware of any community demand for,
    the LLC to steer IETF strategy."

My experience of human nature is that once an organisation has
enough FTEs, those people cannot resist trying to set strategy
for what they are doing for $dayjob. If we don't want the LLC
doing that for (or rather against!) the IETF, then we need to
be extremely careful about things like this. IMO that means we
need to keep the LLC headcount minimal and likely do that in
the face of recurrent non-crazy arguments for heading in the
other direction.

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/msg/iasa20/ITpkOdfekTZE_aTpJ6hrFwOPME4

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 29 Apr 2019 10:09:38 -0400

Hi Joel,

> On Apr 26, 2019, at 8:29 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> As far as I can tell, the change you propose is not necessary to get the LLC working.  This working group was specifically chartered NOT to change any policies.  The change you (and Sean if I understand properly) are proposing represents a change in policy.
> 
> But more importantly, that change is clearly outside of the scope the community was told applied to this working group.

As noted previously, since this is an IAB stream document, this list is being used for discussion prior to the IAB processing the doc. I wouldn’t expect a WG consensus call on this document.

> 
> If you want to write a separate I-D, and try to find a venue for it, to change that policy, you clearly have the right and skills to do so.
> But please do not put that substantive change into this I-D (RFC revision) that is specifically to make the necessary changes so the LLC can do the jobs it needs to do.

It seems that such a document would also need to be an IAB stream document, in which case having a mailing list where interested people are subscribed would still be a useful thing to have as a discussion venue prior to the IAB processing. So I don’t see how shifting to a separate I-D changes anything.

Alissa

>>> What I fail to see is why there is any need to change the wording that we have on the status of the RSE.  I can imagine that the LLC will need to continue to exercise care in the handling of the RSE to avoid accidental changes of status.  As you say John, it is tricky.
>>> But I do not see why that should result in any change to the text in the revision of RFC 6635.
>> Assuming we agree that the details of the agreement with the RSE are up to the LLC, I agree.
>> But RFC 6635 says "The RFC Production Center function is performed by a paid contractor," and " The RFC Production Center contractor is to be selected through an IASA Request for Proposal (RFP) process as described in Section 4.1." and " The RFC Publisher contractor is to be selected through an IASA RFP process as described in Section 4.1."
>> I think the current RFC people are doing a swell job but I would like us to give the LLC the latitude to structure things however makes sense.  At this point, we have a contractor which hires its staff but at some point it might make sense for the LLC to hire staff without an intermediary.
>> Regards,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Apr 2019 10:16:21 -0400

Allisa, I am not following your reasoning.
Sean brought this up as a change he was asking this working group to 
consider.  It was not brought up by the IAB.  It was not brought to the 
IAB.  It was brought to this working group.  it is clearly out of scope 
for this working group.

Some folks have claimed that it is not a policy change.  If it is not a 
policy change, then it does not appear to be necessary.  If it is a 
policy change, it does not seem to be appropriate.

As a separate matter for whomever wants to consider this outside of the 
working group, there are multiple aspects of make the RSE an employee 
that would cause me concern.  For example, hiring part time employees 
who may also want to be free to engage in contract work for other people 
is doable but distinctly non-trivial.  The current approach was approved 
by the community.  And it demonstrably works.

Yours,
Joel

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 29 Apr 2019 10:17:57 -0400

+1

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 29 Apr 2019 10:30:47 -0400

Hi Joel,

> On Apr 29, 2019, at 10:16 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Allisa,

s/Allisa/Alissa/

> I am not following your reasoning.
> Sean brought this up as a change he was asking this working group to consider.  It was not brought up by the IAB.  It was not brought to the IAB.  It was brought to this working group.  it is clearly out of scope for this working group.

My point is that while there will not be a WG consensus call on this document, I think it is helpful to have this group discuss the document since the expertise is here and the document’s whole reason for being is the same as this WG’s reason for being.

As I noted in my prior mail, I thought the plan for this doc and the other IAB stream bis documents was to discuss them here prior to the IAB running its usual call for community comment for IAB stream documents. This is my understanding from talking to Ted. We have had prior threads on this document on this list, as well as threads about rfc4844bis. I found those helpful. From my perspective as an IAB member, it is useful to see these initial rounds of discussion from a focused group of people who have put a lot of thought into these documents before the IAB does a call for community comment on them. I can’t speak for the rest of the IAB.

Alissa

> 
> Some folks have claimed that it is not a policy change.  If it is not a policy change, then it does not appear to be necessary.  If it is a policy change, it does not seem to be appropriate.
> 
> As a separate matter for whomever wants to consider this outside of the working group, there are multiple aspects of make the RSE an employee that would cause me concern.  For example, hiring part time employees who may also want to be free to engage in contract work for other people is doable but distinctly non-trivial.  The current approach was approved by the community.  And it demonstrably works.
> 
> Yours,
> Joel
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Apr 2019 12:03:51 -0400

--On Saturday, April 27, 2019 23:44 -0400 John Levine
<[email-masked]> 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.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 29 Apr 2019 12:10:13 -0400

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Apr 2019 09:27:46 -0700

Howdy,

(much snipped)

On Mon, Apr 29, 2019 at 7:30 AM Alissa Cooper <[email-masked]> wrote:

>
> My point is that while there will not be a WG consensus call on this
> document, I think it is helpful to have this group discuss the document
> since the expertise is here and the document’s whole reason for being is
> the same as this WG’s reason for being.
>
> As I noted in my prior mail, I thought the plan for this doc and the other
> IAB stream bis documents was to discuss them here prior to the IAB running
> its usual call for community comment for IAB stream documents. This is my
> understanding from talking to Ted.

This is also my understanding.  Any discussion that happens here is useful
in getting community issues in focus early, so that those are clear when
the IAB does its review and interprets comments that come in during the
community review period.

As an individual, I appreciated Sean bringing the issue up here, because it
seemed useful to have the discussion in a larger setting before the IAB
review.   I believe we will not need to repeat this discussion again when
the community review occurs, as the document should reflect the results of
the discussion by the time it goes to the IAB.

regards

Ted

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Apr 2019 13:51:04 -0400

Your comment at the end about further discussion goes directly to the 
issue of scope.
People have joined this list for specific purposes.  That purp[ose does 
not include policy changes.  Much less policy changes regarding the RSE.

So no, I do not see how discussion on this list takes care of the need 
for discussion elsewhere after we know what the IAB actually wants to do.

It was specifically brought forward, and has been defended by some 
participants on this list, as being a minor procedural matter.  While 
small, it does have significant implications.  As such, it is not a 
procedural matter.

----

If this is the correct place for discussion, then I would have expected 
to see meaningful answers to the substantive concerns about this proposal.

Yours,
Joel

On 4/29/19 12:27 PM, Ted Hardie wrote:
> Howdy,
> 
> (much snipped)
> 
> On Mon, Apr 29, 2019 at 7:30 AM Alissa Cooper <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     document, I think it is helpful to have this group discuss the
>     document since the expertise is here and the document’s whole reason
>     for being is the same as this WG’s reason for being.
> 
>     As I noted in my prior mail, I thought the plan for this doc and the
>     other IAB stream bis documents was to discuss them here prior to the
>     IAB running its usual call for community comment for IAB stream
>     documents. This is my understanding from talking to Ted.
> 
> 
> This is also my understanding.  Any discussion that happens here is 
> useful in getting community issues in focus early, so that those are 
> clear when the IAB does its review and interprets comments that come in 
> during the community review period.
> 
> As an individual, I appreciated Sean bringing the issue up here, because 
> it seemed useful to have the discussion in a larger setting before the 
> IAB review.   I believe we will not need to repeat this discussion again 
> when the community review occurs, as the document should reflect the 
> results of the discussion by the time it goes to the IAB.
> 
> regards
> 
> Ted
> 
> 
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Apr 2019 13:56:51 -0400

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.

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 29 Apr 2019 14:01:22 -0400

> 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.

> 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.

--Richard

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Apr 2019 14:09:28 -0400

As far as I can tell, the argument for more flexibility in the RSE would 
also be an argument for allowing the RPC to be employees, or even 
allowing the entire secretariat to be employees.  Or hiring staff to 
produce tools (we seem to have anever-ending need).  Some standards 
bodies do that.

I do not see an argument that says there is a special need for the RSE.

if anything, the fact that the RSE is a part time position suggests that 
it is a better fit for contracting than any of the other positions.  So 
why would we want to change the agreed model.

Futher, the change from ISOC to the LLC does not seem to provide a good 
reason for this change.  If the hiring is just pro-forma, it would 
actually have been easier for ISOC (with its full HR and management 
structure) than it will be for the LLC.

Yours,
Joel

On 4/29/19 2:01 PM, Richard Barnes wrote:
> On Mon, Apr 29, 2019 at 1:56 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 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.
> 
> 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.
> 
> --Richard
> 
> 
>      > On Mon, Apr 29, 2019 at 12:04 PM John C Klensin
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> 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.
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 29 Apr 2019 14:24:41 -0400

Hi Joel,

> On Apr 29, 2019, at 1:56 PM, Joel M. Halpern <[email-masked]> 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

>> 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 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Apr 2019 14:26:20 -0400

--On Monday, April 29, 2019 12:10 -0400 Richard Barnes
<[email-masked]> wrote:

> 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).

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Apr 2019 14:28:57 -0400

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.

That seems so wrong that I presume it is not what you intended, and that 
I am misreading your text.

Yours,
Joel

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 29 Apr 2019 14:52:04 -0400

Hi Joel,

> On Apr 29, 2019, at 2:28 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> 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
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Apr 2019 15:03:48 -0400

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Apr 2019 13:53:28 -0700

Howdy,

A couple of comments in-line.

> (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

> it.

> However, my assumption is that they (and the IAB) would

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Apr 2019 17:16:04 +1200

On 30-Apr-19 06:01, Richard Barnes wrote:
> On Mon, Apr 29, 2019 at 1:56 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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. 
 
> 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

>     > On Mon, Apr 29, 2019 at 12:04 PM John C Klensin <[email-masked] <mailto:[email-masked]>
>     >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >      > poorly managed, but that seems to me to mistake the symptom for
>     >      > the problem.
>     >
>     >     of at least one example where I suggest that IASA 1..0 --and the
>     >     others have decried (I agree that is not desirable)..   But that
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Sean Turner <[email-masked]>
Date: Tue, 30 Apr 2019 12:40:32 -0400

> On Apr 29, 2019, at 15:03, Joel M. Halpern <[email-masked]> 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.

= 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.

= 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.

= 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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Apr 2019 09:46:35 -0700

On Tue, Apr 30, 2019 at 9:40 AM Sean Turner <[email-masked]> wrote:

> 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 =
>

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

> 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.

> The last sentence of the section would also need to be deleted or edited

LGTM.

> 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.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Apr 2019 14:17:55 -0400

On the SOW phrasing, I can live with removing it, although I do not see 
the value.

On the complex reporting, that was the deliberate community compromise. 
The goals was to avoid having the RSE be the line manager.  People 
management is a VEyr different skill set that what we were (and I 
believe still are) looking for in an RSE.  If you suspect there is a 
problem with the structure, one could ask the RSE and / or the RPC if 
they have a problem with it.

On making the LLC more able to make the RPC employees, that is a major 
shift in structure.  I would want to see an explicit reason for enabling 
such a change, not just "to give us more flexibility".   Flexibility in 
structuring is good if it solves / avoids a problem.  In this case, what 
does that solve / avoid?  If we develop a problem, that would seem the 
time to ask the community for permission to make such a change.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Apr 2019 14:21:10 -0400

One of the reasons the contracting arrangements for the RPC and 
Publisher are spelled out in 6635 was to make sure that the RSE had the 
intended role in the selection.  Trying to write that role without 
specifying the process would be interesting.  Presumably doable.  But 
definitely non-trivial.  Why do it in the absence of strong motivation?

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Apr 2019 19:51:42 +0100

Hiya,

On 30/04/2019 17:40, Sean Turner wrote:
> 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 believe there's a flaw in the argument that the LLC
ought have flexibility to have the RSE be an employee.

In some jurisdictions (incl. Ireland) an employee who
is on their Nth fixed term contract for the same role
is entitled to become a permanent employee. (N==3 in
Ireland.)

I think that means that were we looking for a new RSE
at some stage, and if the LLC wanted that person to be
an employee, we'd be constrained to pick someone who
does not live in a jurisdiction with such labour laws.
That, or we'd have to risk having to remove an RSE at
the end of their 2nd fixed term despite wanting to
keep them, or... we'd have to risk being "stuck" with
an RSE for an indeterminate duration.

ISTM that the fixed-term with re-appointment model for
the RSE role inherently means not filling that role by
hiring an LLC employee.

Where am I wrong in the above?

I don't believe I've seen that particular argument made
on the list so far. I have seen others make other arguments
against the idea that an employee-RSE is at all desirable.
(And I've done so myself.)

So I don't support changes to give the LLC that possibly
unwise flexibility just on the off-chance that it might
help with some unstated problem.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 May 2019 08:38:18 +1200

I agree with Joel, but once again I am strongly against a draft from
this WG making any of these changes, which are clearly outside the WG's
charter.  When we pass the draft on to the IAB, it would be perfectly
appropriate to raise these points during the IAB's period of public
comment, which of course concerns the entire community interested in
RFCs, not just the IETF.

Regards
   Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 Apr 2019 16:51:51 -0400

It seems like you're trying to use a process point to shut down discussion
here, Brian, and one that's incorrect at that.  As Alissa has already said
and Ted confirmed, "the plan for this doc and the other IAB stream bis
documents was to discuss them here prior to the IAB running its usual call
for community comment".

Nobody thinks this working group is taking any action here.  This whole
discussion is feedback to the IAB, and the IAB has asked for it in advance
of their usual comment period.

--Richard

On Tue, Apr 30, 2019 at 4:38 PM Brian E Carpenter <
[email-masked]> 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?
> >>
> >> 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.
> >>
> >> 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,
> >> If employees and contractors are both allowed, it seems like mandating
> the specific process detailed here would not work, since depending on the

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Apr 2019 22:11:02 +0100

Well, if it has to be discussed some time and somewhere, it might as well be here and now. Although I hope it will be noted that the people following this list might not have been expecting this discussion, and the people who might have comments on this issue might not be following this list.

I think it is perfectly fine that Sean raised the question because thoughtfully establishing the operational parameters of the LLC is a good thing.

In this case, however, my views follow the ones that Stephen expressed, and I think it would be a poor idea to give the LLC scope to fill the RSE role through staff employment.

The arguments against seem to many, but the biggest concern I have is that it takes away from the IAB the flexibility (and possibly the responsibility) for appointing and replacing the RSE. Yes, it is lumpy at the moment that one body appoints and another body contracts, but I think we have experience running that model.

Like Stephen, I don’t see a pressing reason to change. Maybe if/when such a reason becomes available, we can make a change: it hardly seems likely that it will be an urgent reason. Maybe I missed the reasoning why we need to make this change.

Best,

Adrian

From: iasa20 <[email-masked]> On Behalf Of Richard Barnes
Sent: 30 April 2019 21:52
To: Brian E Carpenter <[email-masked]>
Cc: IASA 2 WG <[email-masked]>
Subject: Re: [Iasa20] 6635bis

It seems like you're trying to use a process point to shut down discussion here, Brian, and one that's incorrect at that..  As Alissa has already said and Ted confirmed, "the plan for this doc and the other IAB stream bis documents was to discuss them here prior to the IAB running its usual call for community comment".

Nobody thinks this working group is taking any action here.  This whole discussion is feedback to the IAB, and the IAB has asked for it in advance of their usual comment period.

--Richard

On Tue, Apr 30, 2019 at 4:38 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]> > wrote:

Regards
   Brian

On 01-May-19 06:17, Joel M. Halpern wrote:
> On the complex reporting, that was the deliberate community compromise.. 
>>> On Apr 29, 2019, at 15:03, Joel M. Halpern <[email-masked] <mailto:[email-masked]> > wrote:
>>>
>> 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..
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 May 2019 09:43:56 +1200

On 01-May-19 08:51, Richard Barnes wrote:
> It seems like you're trying to use a process point to shut down discussion here, Brian, 

Yes. This is the club of those interested in admin reform for the IETF.
I do object strongly to it being used for another purpose.

   Brian

> and one that's incorrect at that.  As Alissa has already said and Ted confirmed, "the plan for this doc and the other IAB stream bis documents was to discuss them here prior to the IAB running its usual call for community comment".
> 
> On Tue, Apr 30, 2019 at 4:38 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     >>> On Apr 29, 2019, at 15:03, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 Apr 2019 18:36:02 -0400

> Yes. This is the club of those interested in admin reform for the IETF.

It's not a club, it's a public mailing list, just like any other one we do
business on around here.

Well, it sounds like you have an issue to take to the IAB, then, since
they're the ones who asked to have the conversation here.

In the meantime, those of us who are not challenging the IAB's guidance
here should presumably feel free to carry on the discussion.

--Richard

>
>    Brian
>
> > and one that's incorrect at that.  As Alissa has already said and Ted
> confirmed, "the plan for this doc and the other IAB stream bis documents
> was to discuss them here prior to the IAB running its usual call for
> community comment".
> >
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     >> 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.
> >     >>
> >     >> 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 =
> >     >>
> >     >> 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.
> >     >>
> >     >> = Section 2.2 =
> >     >>
> >     >> 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.
> >     >>

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2019 18:49:43 -0400

>Where am I wrong in the above?

It depends where the employee is.  

Here in the US, if you hire a person as a contractor but the the
nature of the job is more like an employee (the so called IRS 20
questions), the person can file an SS-8 form with the IRS to ask to be
reclassified as an employee.  If the IRS agrees, the employer has to
pay unemployment and social security and medicare taxes for the
employee, retroactive to when they were hired.  It can be a
significant financial risk for the employer.

This is yet another reason why it's absurd to try to micromanage this
stuff from afar.  Give the LLC board some credit for not being total
incompetents and let them have the flexibility to do their job.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 May 2019 00:01:59 +0100

Hiya,

> It depends where the employee is.  

Yes. As I explicitly said in my mail.

My point being that we don't want to constrain selection of
an RSE based on geographic variations in employment law. For
this role, that could be a significant constraint.

> significant financial risk for the employer.

Yes. But the RSE role has not been "more like an employee"
at all. And I sincerely hope that a wish for an RSE that is
more like an employee is not one that is widely held.

> incompetents and let them have the flexibility to do their job.

I wish you'd stop saying that. It is not always relevant.
Discussing whether an RSE can be a contractor/employee is
not micromanaging. Disagreeing does not constitute a claim
that any other person is incompetent.

S.

---

From: "John R Levine" <[email-masked]>
Date: 30 Apr 2019 19:22:11 -0400

> I wish you'd stop saying that. It is not always relevant. Discussing 
> whether an RSE can be a contractor/employee is not micromanaging.

It is totally micromanaging because it depends on the details of the 
employment law of wherever the employee is, in which neither you nor I nor 
anyone else here are experts.

For the American IRS rules, an indefinitely renewable agreement and a 
person who "provides services that are a key aspect of the business" make 
it more likely that the person is an employee, which sounds like the RSE 
to me.  This is something for employment lawyers to sort out, not us.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 May 2019 00:32:19 +0100

On 01/05/2019 00:22, John R Levine wrote:
> 
> It is totally micromanaging

We disagree for reasons already pointed out on this list
that I guess you don't find convincing. And yet I don't
consider you incompetent:-)

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Apr 2019 17:11:23 -0700

> this role, that could be a significant constraint.

This seems like an argument for giving the LLC *more* latitude here,
because as this discussion has shown, there are places where it's
advantageous to have people with whom you have a long-term
engagement be a contractor and others where it's advantageous
to have them be an employee.

So, I'm not sure I follow your argument here, which seems to be that
you think we ought to constrain the LLC in this respect.

> at all.

Without taking a position on the nature of the RSE, I'm not sure
that you and John mean the same thing when you say "like an
employee". See, for instance:
https://www.irs.gov/newsroom/understanding-employee-vs-contractor-designation

Note that the questions here are not largely about how *we* think of
the role but rather about the structure of the work and of the relationship.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 May 2019 01:31:24 +0100

Hiya,

> to have them be an employee.

I interpret things differently. The contractor arrangement seems
to me to fit the RSE role regardless of geography. In contrast
employee arrangements seem like a total misfit for at least
countries like Ireland (perhaps most of the EU?). And I do not
want the LLC to have fictional flexibility that really represents
a cumbersome constraint when it comes to RSE selection.

> you think we ought to constrain the LLC in this respect.

I do think we ought do that. Sorry if I've not explained it
sufficiently well.

> Without taking a position on the nature of the RSE, 

I believe the IETF has a position on that. (Not that the IETF is
the only entity who may care about the RSE role etc...)

> I'm not sure

I don't think it's that John and I have divergent opinions there,
it's that there are substantive differences in the distinction in
different places. John's claim that we, not being international
labour lawyers, don't understand the details, is correct but is
also

> the role but rather about the structure of the work and of the relationship.

I'm not at all sure I agree with you there, but figuring that out
would probably bring us too far into the weeds, and you know how
I just *hate* micromanaging:-)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 May 2019 01:34:15 +0100

(Sorry, ignore the last mail, hit send too soon.)

Hiya,

I don't think it's that John and I have divergent opinions there,
it's that there are substantive differences in the distinction in
different places. John's claim that we, not being international
labour lawyers, don't understand the details, is correct but is
also misleading - despite not knowing all the details, we are
entirely capable of recognising that the employee vs. contractor
distinction is an important and relevant one. Concluding that
there is no basis to change the current arrangement seems quite
within our ken.

Cheers,
S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Apr 2019 20:51:08 -0400

Given that Ted actually asserted that the discussion on this list was 
expected to be the primary discussion, Brian's point about this being a 
focused venue, and his further point that the relevant vanue would need 
to include a much larger audience, would seem to be very relevant.

Yours,
Joel

On 4/30/19 4:51 PM, Richard Barnes wrote:
> It seems like you're trying to use a process point to shut down 
> discussion here, Brian, and one that's incorrect at that..  As Alissa 
> has already said and Ted confirmed, "the plan for this doc and the other 
> IAB stream bis documents was to discuss them here prior to the IAB 
> running its usual call for community comment".
> 
> discussion is feedback to the IAB, and the IAB has asked for it in 
> advance of their usual comment period.
> 
> --Richard
> 
> On Tue, Apr 30, 2019 at 4:38 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     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..
>      >>
>     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.
>      >>
>     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.
>      >>
>     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.
>      >>
>      >> = Section 2.2 =
>      >>
>     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.
>      >>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Apr 2019 17:50:51 -0700

On Tue, Apr 30, 2019 at 5:34 PM Stephen Farrell <[email-masked]>
wrote:

> to me to fit the RSE role regardless of geography.

But this is precisely the point that John, Richard, and I have
been making, namely that it's actually *not* clear that the contractor
arrangement is a good fit for the RSE role in certain jurisdictions.

In contrast
> a cumbersome constraint when it comes to RSE selection.

In what way is this flexibility a constraint.

> I do think we ought do that. Sorry if I've not explained it

Yes, I get that, but it doesn't seem to follow in any way from the
arguments you are advancing.

> the only entity who may care about the RSE role etc...)

Sorry, what I mean to say is that I am not taking a position on
whether the IRS would judge that the RSE was actually an
employee.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Apr 2019 21:03:33 -0400

The ISOC, when I was on it, worked with the HR people at ISOC to make 
sure that we stayed well clear of accidentally turning the RSE into an 
employee.  While it introduced some complications, most of those were 
involved in understanding the rules.  Which are needed no matter what 
you do.

Just for clarity, the reason for the care was that none of the RSE, 
ISOC, or the RSOC (or presumably the IAB whose policy direction the RSOC 
follows) wanted the RSE to be an employee.  Which is consistent with the 
wording in the RFC approved by the community.

Yours,
Joel

On 4/30/19 8:11 PM, Eric Rescorla wrote:
...

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 May 2019 02:09:04 +0100

Hiya,

(Deleting no longer needed bits...)

> arrangement is a good fit for the RSE role in certain jurisdictions.

Sorry, I don't recall any good argument that the contractor
arrangement has problems. We seem to have O(400) or so bits
of evidence per year that the current setup works to an
extent.

In particular, the only geographic argument on this list that
I recall is the one I made to the effect that the RSE as an
employee can be problematic. If someone made a claim to the
effect that a contracting arrangement could raise geographic
or jurisdictional issues, I'll need you to send me a link to
the archive for those mails, as I do not recall seeing that
argument having been made.

> In what way is this flexibility a constraint.

Sorry, I don't see how to do better than the explanation I used
in an earlier mail. (That's the one where I asked where I was
wrong and have yet to see a specific reply setting out why I was
wrong;-)

> arguments you are advancing.

We disagree. Asserting that my argument is unfounded without
stating the basis on which you conclude that seems... unfounded,
but luckily we're both now doing that;-)

> whether the IRS would judge that the RSE was actually an

And that was not the (only) issue. The new point I raised in
this thread is all about "what if the RSE were an employee"
and has nothing at all to do with the details of employee
vs contractor distinction minutiae in any one jurisdiction.
In case it helps, the relevant legislation here is explained
at [1] and I do have some knowledge of it, having used it
to get my $dayjob employer to continue paying me when they
might otherwise have chosen to decline the fun of that :-)

Cheers,
S.

[1]
https://www.workplacerelations.ie/en/Publications_Forms/Guide_-_Protection_of_Employees_Fixed-term_Work_Act.pdf

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Apr 2019 21:09:34 -0400

I was contacted off list to indicate that I was apparently unclear about 
how my comments related to Sean's questions about section 2.1.1.

Both in the below email, and the other oen I sent about RPC contracting, 
I was trying to be clear that the "interesting" reporting relationship 
was a deliberate choice made by the community.  Further, that the RSOC 
(when i was on it) seemed to me to feel that it worked out well.  Unless 
someone has heard a complaint from the RSE, the RPC, or the ED, that the 
balance is not working right, I would be loath to change it.  Speaking 
as one of the authors, it was hard enough to find a workable balance 
given the explicit goal that the RSE was not being defined or hired as a 
line manager.

Yours,
Joel

On 4/30/19 2:17 PM, Joel M. Halpern wrote:
>> 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.
>>
>> 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.
>>
>> current contractors in current roles, but rather establishing the 
>> LLC's ability to operate successfully in the future.
>>
>>
>> = Section 2 =
>>
>> 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.
>>
>> 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.
>>
>> = Section 2.2 =
>>
>> 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 
>> 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.
>>