Re: [Iasa20] 6635bis

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

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:
> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/iasa20
>>
> 
> _______________________________________________
> iasa20 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iasa20