Subject: Re: [Iasa20] 6635bis

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 May 2019 22:27:18 -0400

Hi Joel, all,

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

Sure, but I think the question that Sean asked remains unanswered, and I’m interested in the answer as well. Under RFC 6635, if the performance of the RPC does not meet the standards in the RPC contract, are the RSOC/IAB expected to hold the RSE accountable for that? Is the fact that the RPC contract is silent about this performance accountability to the RSE deliberate, or an oversight, or something else?

Thanks,
Alissa

> 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:
>> 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
>> On 4/30/19 12:40 PM, Sean Turner wrote:
>>> 
>>>> 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
>>> _______________________________________________
>>> iasa20 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/iasa20
>>> 
>> _______________________________________________
>> iasa20 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/iasa20
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 1 May 2019 23:12:40 -0400

My understanding was that if the RPC was not meeting standards, it was 
first and foremost the RSE's job to
1) notice this
2) figure out why
3) propose ways to remedy the problem

For example, if the RSE had not alerted the RSOC and the IAB to the 
expected SLA slippages during tools changeover, that would have been a 
shortcoming on her part.  She did notify everyone involved of the 
expectation.  There was even discussion of whether we needed to hire 
more staff to address the issue (and whether it was even practical to do 
so.)

In the strange case where the RPC problems were due to non-performance 
by the RPC staff, that would be taken to the IAB, and then to the IAD / 
ED for action.  The assumption was that if the IAB said to the ED "we 
have a problem with the contract deliverables" due to misbhaior, 
appropriate steps would be taken.  I have never heard of anything 
anywhere near close to this.

IN terms of who the IAB should talk to if they see an apparent problem 
with the RPC activity, it is indeed the RSE.  That is what the 
responsibility text means.

All of the above is admittedly my understanding.  But I did the pen 
holding for the writing, and served on the RSOC for several years (I am 
not currently on the RSOC.)

One note is that none of this should be the LLC's problem in any regard.

Yours,
Joel

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 May 2019 07:25:41 -0700

Hi Joel,

A comment in-line.

> One note is that none of this should be the LLC's problem in any regard.
If the IAB takes a matter to the Executive Director saying that there is a
problem with contract deliverables, they seem to be placing it in the LLC
hands at that point.  In the terms of my previous comment, that's the
equivalent of the task requester telling the contracting officer there is a
problem. From that point on, it is in the ED's hands to resolve, returning
to the RSOC/IAB only with any changes that require their approval (e.g.
modifying the tasks).

Does that match your understanding?

regards,

Ted

> >> 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.
> >
> > Sure, but I think the question that Sean asked remains unanswered, and
> I’m interested in the answer as well. Under RFC 6635, if the performance of
> the RPC does not meet the standards in the RPC contract, are the RSOC/IAB
> expected to hold the RSE accountable for that? Is the fact that the RPC
> contract is silent about this performance accountability to the RSE
> deliberate, or an oversight, or something else?
> >
> > Thanks,
> > Alissa
> >
> >> 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 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
> >>>>> Maybe the correct answer is for us all to stop arguing for any
> position until there is a proposed change that can be discussed?
> >>>>
> >>>> 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 =
> >>>>
> >>>> 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 =
> >>>>
> >>>> 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: Thu, 2 May 2019 10:32:14 -0400

Trimmed for readability.

Comments after yours.

On 5/2/19 10:25 AM, Ted Hardie wrote:
...
> If the IAB takes a matter to the Executive Director saying that there is 
> a problem with contract deliverables, they seem to be placing it in the 
> LLC hands at that point.  In the terms of my previous comment, that's 
> the equivalent of the task requester telling the contracting officer 
> there is a problem. From that point on, it is in the ED's hands to 
> resolve, returning to the RSOC/IAB only with any changes that require 
> their approval (e.g. modifying the tasks).
> 
...

I would be cautious about following the government contracting officer 
model too far.  We as a community do not have rules creating such strict 
separation, nor do we have the level of problems that cause the 
government to require those rules.

My understanding is that in general, yes, if the problems rose to the 
level that ED efforts to remediate are needed, one would expect the ED 
to have point on that.
The IAB can be as general or as specific as they deem necessary in what 
they ask the ED to do.
And the ED can use good judgment in when to ask for more input from the 
IAB and if appropriate the RSE.
And of course the actions of the IAB and the RSE have to be grounded 
somehow in the community (although the exact means of grounding is not 
specified, nor in my opinion should it be.)  And such grounding can be 
tricky, as if it is individual staff misbehavior taking that to the 
community would border on disastrous for myriad reasons.

Yours,
Joel

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 2 May 2019 15:28:05 -0400

Hi Joel,

> On May 1, 2019, at 11:12 PM, Joel Halpern Direct <[email-masked]> wrote:
> 
> My understanding was that if the RPC was not meeting standards, it was first and foremost the RSE's job to
> 1) notice this
> 2) figure out why
> For example, if the RSE had not alerted the RSOC and the IAB to the expected SLA slippages during tools changeover, that would have been a shortcoming on her part.  She did notify everyone involved of the expectation.  There was even discussion of whether we needed to hire more staff to address the issue (and whether it was even practical to do so.)
> 
> In the strange case where the RPC problems were due to non-performance by the RPC staff, that would be taken to the IAB, and then to the IAD / ED for action.  The assumption was that if the IAB said to the ED "we have a problem with the contract deliverables" due to misbhaior, appropriate steps would be taken.  I have never heard of anything anywhere near close to this.
> 
> IN terms of who the IAB should talk to if they see an apparent problem with the RPC activity, it is indeed the RSE.  That is what the responsibility text means.
> 
> All of the above is admittedly my understanding.  But I did the pen holding for the writing, and served on the RSOC for several years (I am not currently on the RSOC.)

Thanks, that is helpful.

> One note is that none of this should be the LLC's problem in any regard.

In addition to the aspect that Ted raised, it seems that the contracts that the LLC is signing should align with the expectations of all the relevant parties about how the accountability works. If there are discrepancies (as there appear to be at the moment), those would be the responsibility of the LLC and the contractors to resolve.

Alissa