Subject: Re: [rfc-i] New proposal/New SOW comment period

From: Eliot Lear <[email-masked]>
Date: Mon, 2 Sep 2019 08:10:02 +0200

Hi Sarah and Adrian,

Just to make sure that the last call isn’t lost in the other kerfuffle, I agree with Adrian’s comments, and with your response to Mike.

Best wishes to you (and to us all!) on a successful RFQ/hiring process.

Eliot

> On 31 Aug 2019, at 12:32, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Sarah,
> 
> [Deliberately continuing the discussion cross-posted despite the Sergeant At Arms’ entreaties]
> 
> Thanks for coordinating the construction of this draft and for putting it out for comment.
> 
> In the ensuing discussions…
> 
>>> 1) Is this a full time position?  If not, then describe the expected
>>> workload.   From the description, it's a level of effort contract
>>> somewhat less than full time.  State that level.
>> 
>> SB// The RSOC in years past has specifically stayed out of the "how
>> long does it take to do the job" and the "this is a 32-hour-a-week"
>> job. I'd defer this to the LLC; if the person they're hiring is a contractor
>> I'm not sure this matters, since they're bidding on the total amount of
>> work (that's been the thought) versus the employee who clearly needs
>> to understand if this is a part time or full time job.
> 
> When people bid fixed-pay fixed-deliverables on a contract, they usually have a pretty detailed description of the work, that way they can work out how much time they think it will take them, and bid accordingly. If such detail is not available, a wise contractor will make an estimate and add a lot of contingency. That puts up the price paid by the customer, potentially unnecessarily. OTOH, an unwise or "keen" contractor may under-bid risking that a poor job will be delivered. Frankly, the more detail supplied, the more accurate the bid and the better the work.
> 
> Alternatively, the customer may give better guidance as to the expected amount of work. The draft says that RFC 6635 section 2.15 is not applicable, and (of course) that is true because this SoW does not cover all of the job described in the RFC. But at the same time, it should be clear to everyone that if 6635 considered that the job was 20 hours per week and nearly full time during IETF week, then the work covered by this SoW is bounded by that as an upper limit.
> 
> Anyway, I don't think the current draft has enough detail of what the job is to enable a meaningful bid. Maybe this is fixed by simply adding something to say that during the process of preparing bids and on request, the RSOC will make available to bidders additional information to help them scope and understand the nature of the tasks.
> 
> 
> Further to the tactical/strategic discussions on the list, I don't think it is helpful to show your thought processes in the SoW. I would suggest:
> - Strike "The RSE’s job functions can be logically split into 2 functional areas: strategic and tactical."
> - Replace "is being created to fill the tactical functions of the RSE role" with "is being created to fill certain functions of the RSE role as listed below"
> - Strike "These “tactical” responsibilities of the RSE are not defined explicitly in RFC6635; the expected nature of the work is explained below."
> Doing this would allow you to make the list of tasks you want done, without getting into discussion of whether they are 73% tactical and 27% strategic.
> 
> 
> I struggle with the following paragraph:
>   Some of the functions described below may not be possible within that timeframe
>  (for example, chairing the search committee when the RPC contract goes out to bid
>  again). It is expected that this position and the person filling it will work with the
>  RSOC to identify new or changing work items as they arise.
> 
> To me this reads as though you want the contractor to be very flexible on deliverables. Firstly you are giving permission for the contractor to not deliver some things: I guess that's OK, no one will object to being paid for not delivering 😊 Second, you might be saying that new/changed deliverables may arise, but you are not making it clear whether you expect them to be delivered under the contract or not. The usual way to handle both of these points is "variations by mutual agreement in writing."
> 
> 
> Why "Scope of work - primary"? Is there a secondary scope of work somewhere?
> 
> 
> I would expect to see a termination clause.
> 
> 
> The line "This relationship is subject to later reorganization" should be business as usual in a contract like this, but the history suggests that it might be better to be a bit clearer. Just as a point of note, the previous paragraph names the RSOC as the body with whom scope changes might be identified, but (presumably) if the reporting changed, that wouldn't be true.
> 
> 
> Finally (you'll be glad to hear), what is the purpose of item 3 on the Affidavit? Is the intention here that you propose that only entities registered in the US for tax purposes may win this contract?
> 
> Good luck!
> Adrian
> 

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Michael StJohns <[email-masked]>
Date: Mon, 2 Sep 2019 15:24:34 -0400

On 8/30/2019 3:39 PM, Sarah Banks wrote:
> Hi Mike,
> Some thoughts, inline. Speaking for myself. SB//

Not really.  Seriously - you're the author of the SOW with the RSOC so 
this is direct commentary on your work product.

>
>> On Aug 30, 2019, at 10:30 AM, Michael StJohns <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Five immediate large items:
>>
>>
>> 0) The requirements for this position are pretty much 
>> indistinguishable from that of the RSE as stated in previous versions 
>> of the SOW.   I don't think that makes sense.  If this is simply a 
>> "we want to hire some short time to do the RSE position", then state 
>> that rather than using the figleaf of strategic and tactical.  I'm 
>> not saying you'll get community buy-in for that, but at least it 
>> would be less obfuscated.
>
> SB// The thought here was as intended; specifically on tactical, and 
> nothing more. It IS focused on what the current RSE does tactically - 
> I'm not sure how we change that until the community has a conversation 
> about the role. I'm all ears and open to suggestions, though!

I don't think you've actually thought through the tactical items well 
enough for the community to give you a thumbs up or down.

So some additional questions:

     a) Does this contract end with the RSE contract is let?

     b) Does the RSE regain most of the tactical stuff?

     c) If so, there's an end product that needs to be requested - the 
hand-over documentation.

     d) Does acting as the tactical person prevent you from bidding on 
the RSE?  If not, why not?   [E.g. insider knowledge vs fairness of the 
bid process]

     e) Can you think of any of these items to eliminate as "can wait 
for an RSE"?  If not, then see my original question (0).

>> workload.   From the description, its a level of effort contract 
> job. I'd defer this to the LLC; if the person they're hiring is a 
> contractor I'm not sure this matters, since they're bidding on the 
> total amount of work (that's been the thought) versus the employee who 
> clearly needs to understand if this is a part time or full time job.

I can't see how this could be let as a firm fixed price contract or even 
a piece work or deliverable task contract.  I think this is an LOE 
contract with meta deliverables.  You're going to want some of this 
persons time to be committed, and you're going to want to tell them up 
front what that time commitment is.   I think figuring out what that LOE 
is is squarely in the wheelhouse of the SOW authors.

>
>> 2) The style manual (last bullet) is a strategic item, not a tactical 
>> item. Delete it.
>
> SB// I could live with this, thanks.
>
>> 3)  Matrix management - seriously?   That's how we got to this 
>> situation in the first place.
>
> SB// We understand that's a concern, and it should probably be one of 
> the items we discuss as a community. We're not looking to force the 
> process though, and to that end, using the process we have (this 
> language came from the previous SOW we used, in fact) seemed prudent. 
> Given that they're focused on the RPC and the new format work and 
> reporting to the RSOC, how else would you propose we address your concern?
>
>> 4) Term - for a tactical contract, this is pretty long - 1.5 years 
>> with the possibility of a year extension.
>
> SB// As I previously explained, we as a community don't tend to have 
> short conversations. The process will take time. If we conclude in 
> less than 1.5 years then fantastic, we'll have some overlap with 
> whatever outcome we get from that discussion and the current/temporary 
> RFC Series Project Manager. That seems like an acceptable thing to me.
>
>>
>> Small items:
>> 1) Drop the "Experience as an RFC editor" bullet in favor of 
>> "Familiarity with the RFC series is desired but not required".
>> 2) The "culture and process" bullet is also strategic and not 
>> tactical.   Drop this to just the RFC process.
>> 3) Travel internationally - state if this is in addition to the IETF 
>> meetings.
>>
>
> SB// These seem reasonable.
>
>> Overall comment:
>>
>> This has the feel to me of a push towards a more "managed" RFC Editor 
>> vs the independent model we've had over the lifetime of the series - 
>> and doing it by small nibbles and by delay.  The RFC++ bof indicated 
>> community displeasure with that direction, and I'm not sure this SOW 
>> is representative of community desires. I'd be happier with this if 
>> the sole and only contract reporting link is from this contractor to 
>> the LLC.  The LLC MAY appoint the RSOC for day to day things, but any 
>> contractual discussions OF ANY KIND should be with the actual 
>> organization that holds the contract.   From a community point of 
>> view, we have oversight and a direct line of responsibility from the 
>> LLC to the community (with the concomitant ability of the community 
>> to recall or otherwise fail to reappoint LLC board members) . That is 
>> not the case with the RSOC.
>>
>> With respect to the evolution of the RFC Series - I haven't seen any 
>> clear statement from anyone of the changes they believe need to be 
>> made.  So, prior to putting us in the penalty box for a year and a 
>> half, perhaps we could actually get a statement of interests which 
>> would indicate that we need such a delay in the RFC SE selection 
>> process.    E.g. a full formal ID/RFC not random musings in email 
>> with enough initial support that we have the possibility of getting 
>> to some sort of consensus for change if we invest the time.
>>
>
> SB// The goal is to have the conversation as a group, and figure out 
> what to do. if we don't want a managed RFC Editor, but the independent 
> model that folks believe we should have, then as a community we should 
> say that, and figure out how to instrument what we want. Personally, I 
> like the spirit of what was described to me starting with Postel, and 
> having some independence from being told what to do blindly with the 
> ability to push back doesn't seem to be a bad thing. But that's my 
> personal thought, and as an RSOC it's not our current purview to tell 
> the community what to do.

I agree, however, the RSOC seems to have taken it as a purview to 
diminish the independence of the RSE from previous levels.  If the RSOC 
(and for that matter) would take a look at what it was fall of 2016 vs 
how its been behaving vis a vis the RSE since that point in time, I'd be 
much happier with your statement that you don't tell the community what 
to do.

> We're trying to strike a balance between the process we have, which 
> keeps our contractors moving and documents flowing, and allowing the 
> community to do its thing. This position "reporting" to the LLC makes 
> little sense to me - 1. that's not the current process we have (and if 
> you don't like it, speak up and change it, Ted's outlined how we might 
> proceed to doing that) and 2. The LLC really isn't equipped to handle 
> it either.

See my note to Stephen.  Basically, I think it may be OK to have the 
RSOC operate as a COTR under the purview of the LLC with no ability to 
tell the RSE what to do, but instead acts as an advisor to the LLC for 
contract issues.  That gives whoever gets hired one and only one point 
of control to deal with.   I'd also suggest that the RSOC no longer do 
the "we're talking about contracts in executive session" stuff and 
instead call for community input every couple of years or so and write a 
public report detailing pros and cons based on that input (and 
specifically no anonymous input) as the basis for the LLC to make its 
decisions.  6635 is not controlling on the LLC as they are the 
fiduciaries - but the community might not like that interpretation.  
They could adopt 6635 as an operating instruction by vote of the board, 
but I don't see that as having taken place.

> The RSOC seems to be the reasonable choice given the situation we find 
> ourselves in, and again, this is a 1.5 year contract with clearly 
> described goals.

"clearly described goals" is overstating it I would say.  Sorry.

Mike

> We'll have the conversation to change (or not) - in the grand scheme 
> of things, this doesn't seem to be an issue to me. The alternatives 
> concern me more - do we just not have an RSE-like function at all, in 
> any capacity, being executed, while we chat as a group? No documents 
> are published? We're paying for the RPC function by contract now; I'd 
> like to see our money well spent, personally. I'm not sure I 
> understand the analogy to a penalty box, but if you mean we're in a 
> holding pattern until we figure out what we want then yes, I totally 
> agree, we are, and I don't see a better alternative. I'm happy to 
> discuss any alternatives you might have.
>
> /S
>
>
>> Later, Mike
>>
>>
>>
>> On 8/30/2019 12:38 PM, Sarah Banks wrote:
>>> (Cross-post with [email-masked] <mailto:[email-masked]>)
>>>
>>> Hello,
>>> The RSOC has received a lot of feedback regarding the current SOW, 
>>> in addition to the feedback received generally around the RSE role, 
>>> both on and off list, and at the microphone at the plenary session 
>>> in Montreal. We've listened, discussed, and come up with a proposal 
>>> that you'll find attached here.
>>> Broadly speaking, the RSE role contains 2  functions, a strategic 
>>> function and a tactical function. We believe that we, as a 
>>> community, still want RFCs published while we discuss the RSE role 
>>> evolution. We also have a contract in place with the RPC (both 
>>> Production Center and Publisher), both of whom are accustomed to a 
>>> day to day contact to lean on for assistance (the current RSE).
>>> With that in mind, we are proposing a temporary position that 
>>> focuses on the tactical components of the current RSE role, with 2 
>>> large work items in mind.
>>>
>>> First, this temporary position (called the Temporary RFC Series 
>>> Project Manager) would serve as the day to day contact for the RPC, 
>>> assisting with tactical items.
>>>
>>> Second, this role would focus on the v3 format work, assisting with 
>>> the delivery of the new tools for the format work, and bringing the 
>>> new format work to a close.
>>>
>>> Details are included within the SOW, attached with this email.
>>>
>>> The IAB plans on sharing a follow up email shortly, that covers 
>>> possible next steps for the strategic portions of the RSE role and 
>>> the evolution discussion.
>>>
>>> We'd like to open a 2 week comment period on the SOW, starting on 
>>> August 30, 2019, closing ons on September 14, 2019. Please send your 
>>> comments and feedback to the RSOC ([email-masked] <mailto:[email-masked]>).
>>>
>>> Kind regards,
>>> Sarah Banks
>>> For the RSOC
>>>
>>>
>>
>
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Sep 2019 17:31:22 -0500

> this is direct commentary on your work product.

I suspect that what she means (since I've made similar disclaimers in 
the past and have seen many others do so as well) is that she's speaking 
without yet consulting with the RSOC or IAB on the related topics, so as 
to avoid confusion between her perspective and the consensus position of 
either of those bodies. If you have a proposal for a better way to 
phrase that kind of thing, I would love for you to offer it up.

/a

---

From: Michael StJohns <[email-masked]>
Date: Mon, 2 Sep 2019 23:17:46 -0400

On 9/2/2019 6:31 PM, Adam Roach wrote:
>> Not really.  Seriously - you're the author of the SOW with the RSOC 
>> so this is direct commentary on your work product.
>>
>
> the past and have seen many others do so as well) is that she's 
> speaking without yet consulting with the RSOC or IAB on the related 
> topics, so as to avoid confusion between her perspective and the 
> consensus position of either of those bodies. If you have a proposal 
> for a better way to phrase that kind of thing, I would love for you to 
> offer it up.
>
> /a
>
Fair point, and I can see that's probably what was meant.

The problem is that doing that is somewhat an abdication of the 
responsibility for the SOW.  I would have said something more like:  
"Here's my opinion - I'll ask the rest of the RSOC to chime in as well", 
rather than the "speaking for myself" construct. Or "I'll make sure the 
RSOC considers these, but I think I agree with XXXX and disagree with 
YYY and here's why".

Someone has to be willing to take and manage the commentary - if not 
Sarah, then who?    (I don't really care who - I just want to know who 
gets to decide what goes into the next version and how I affect that 
decision).

"Success has many fathers, failure is an orphan".  I'd really like this 
not to be an orphan.

Later, Mike

Later, Mike

"

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Sep 2019 23:06:21 -0500

> gets to decide what goes into the next version and how I affect that 

The RSOC -- each and every one of us -- are carefully reading everything 
sent to [email-masked], and all comments sent there will be given 
significant consideration when revising the SOW. I presume that most or 
all of us are also reading the input on both [email-masked] and 
[email-masked], although I can't actually speak for the 
other members. In any case, the input you're providing right now is 
exactly how you affect that decision. I really appreciate the specific 
and concrete suggestions you've made so far, as that kind of feedback is 
much easier to incorporate than more generalized objections.

To be clear, the SOW under consideration incorporates significant text 
from the SOW used during the previous several bid processes, and has so 
far been edited by three of us as part of trying to get it into 
reasonable shape for this upcoming bid. So it's fair to say that we are 
likely to jointly manage the commentary.

/a

---

From: Sarah Banks <[email-masked]>
Date: Tue, 3 Sep 2019 20:26:08 -0700

Hi Mike,
	Please see inline.

> On Sep 2, 2019, at 12:24 PM, Michael StJohns <[email-masked]> wrote:
> 
> Not really.  Seriously - you're the author of the SOW with the RSOC so this is direct commentary on your work product.  
> 
>> 

SB// I'm honestly perplexed by this response. I am speaking for myself and my comments are not representing RSOC consensus, which I would relay with the RSOC chair hat on. I also believe it's perfectly permissible for me to have a voice without my chair hat on. I honestly expect you to know this, which makes me think there's something else at play here, and we have a disconnect; am I missing something? 

>>> On Aug 30, 2019, at 10:30 AM, Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 0) The requirements for this position are pretty much indistinguishable from that of the RSE as stated in previous versions of the SOW.   I don't think that makes sense.  If this is simply a "we want to hire some short time to do the RSE position", then state that rather than using the figleaf of strategic and tactical.  I'm not saying you'll get community buy-in for that, but at least it would be less obfuscated.
>> 
>> SB// The thought here was as intended; specifically on tactical, and nothing more. It IS focused on what the current RSE does tactically - I'm not sure how we change that until the community has a conversation about the role. I'm all ears and open to suggestions, though!
> I don't think you've actually thought through the tactical items well enough for the community to give you a thumbs up or down.
> 

The SOW clearly calls for a firm initial term. I believe I've also followed up since stating there might be overlap. Help me understand where the confusion is here? Have I overlooked something?
>     b) Does the RSE regain most of the tactical stuff?

Your question assumes outcome of the community process. I have no idea what that outcome is. This is a TEMPORARY role. There's nothing to "take" away from the next RSE, should we the community choose to continue to have one. I'm being somewhat obtuse on purpose - the SOW is NOT a comment on what happens with the next RSE or the process or any of that - the SOW covers the specific work items laid out, with the ability to adjust them by mutual consent should something arise, and allow RFCs to continue flowing while we, the community, figure out what we want to do.

>     c) If so, there's an end product that needs to be requested - the hand-over documentation.
> 
> 

This might be a reasonable addition to add to the SOW. Let's see what others think.

>     d) Does acting as the tactical person prevent you from bidding on the RSE?  If not, why not?   [E.g. insider knowledge vs fairness of the bid process]
> 
The SOW doesn't take a position on this, and IMHO, that's a good thing. We want the best person for the job. Any incumbent would have "insider knowledge", in that they know how the process works, and are already sitting in the job. I don't think this is our biggest problem to solve, or a huge problem in and of itself. That's my opinion. If the rest of the community feels differently they can say so and we'll discuss. 

>     e) Can you think of any of these items to eliminate as "can wait for an RSE"?  If not, then see my original question (0).
> 

I don't understand what the "items to eliminate" are? The SOW is specific in it's 2 goals, which I've already stated again in this email. They cannot wait, hence the SOW. 

>> 
>>> 1) Is this a full time position?  If not, then describe the expected workload.   From the description, its a level of effort contract somewhat less than full time.  State that level.
>> 
>> SB// The RSOC in years past has specifically stayed out of the "how long does it take to do the job" and the "this is a 32-hour-a-week" job. I'd defer this to the LLC; if the person they're hiring is a contractor I'm not sure this matters, since they're bidding on the total amount of work (that's been the thought) versus the employee who clearly needs to understand if this is a part time or full time job. 
> 
> I can't see how this could be let as a firm fixed price contract or even a piece work or deliverable task contract.  I think this is an LOE contract with meta deliverables.  You're going to want some of this persons time to be committed, and you're going to want to tell them up front what that time commitment is.   I think figuring out what that LOE is is squarely in the wheelhouse of the SOW authors.
> 
> 
> 
Your opinion is noted, thank you.

<snip>
>> 
>> SB// The goal is to have the conversation as a group, and figure out what to do. if we don't want a managed RFC Editor, but the independent model that folks believe we should have, then as a community we should say that, and figure out how to instrument what we want. Personally, I like the spirit of what was described to me starting with Postel, and having some independence from being told what to do blindly with the ability to push back doesn't seem to be a bad thing. But that's my personal thought, and as an RSOC it's not our current purview to tell the community what to do.
> I agree, however, the RSOC seems to have taken it as a purview to diminish the independence of the RSE from previous levels.  If the RSOC (and for that matter) would take a look at what it was fall of 2016 vs how its been behaving vis a vis the RSE since that point in time, I'd be much happier with your statement that you don't tell the community what to do.
> 
> 
> 
Mike, what exactly do you want? Honestly, what is it? I believe the RSOC made a mistake. We publicly and very specifically said that we made the mistake, owned it, and apologized. I am incapable of undoing that mistake, it is what it is. That said, I believe the RSOC has been very thoughtful in it's actions since, starting with the feedback we've received, drafting a new SOW, and IMO clearly stating that the SOW is specifically a temporary position that allows us to keep RFC's flowing while the community figures out "what's next". I'm at a loss to understand how we're telling the community what to do. 

This is starting to feel a little more personal, and while I'm happy to have this conversation with you, I'm no longer willing to do it on a public list. I believe it would be more productive to do 1 on 1, and I'm happy to meet and talk whenever is convenient for you. I want your opinion and your feedback. You've been here a very long time, and have a perspective that's steeped in an experience that I'm not sure everyone else understands. I value that, and I'm not trying to stifle that, but I am trying to keep it productive for both of us. 

>> We're trying to strike a balance between the process we have, which keeps our contractors moving and documents flowing, and allowing the community to do its thing. This position "reporting" to the LLC makes little sense to me - 1. that's not the current process we have (and if you don't like it, speak up and change it, Ted's outlined how we might proceed to doing that) and 2. The LLC really isn't equipped to handle it either.
> See my note to Stephen.  Basically, I think it may be OK to have the RSOC operate as a COTR under the purview of the LLC with no ability to tell the RSE what to do, but instead acts as an advisor to the LLC for contract issues.  That gives whoever gets hired one and only one point of control to deal with.   I'd also suggest that the RSOC no longer do the "we're talking about contracts in executive session" stuff and instead call for community input every couple of years or so and write a public report detailing pros and cons based on that input (and specifically no anonymous input) as the basis for the LLC to make its decisions.  6635 is not controlling on the LLC as they are the fiduciaries - but the community might not like that interpretation.  They could adopt 6635 as an operating instruction by vote of the board, but I don't see that as having taken place.
> 
> 
> 

That's your point of view, *a* point of view, and I think it's reasonable for this to be a part of the conversation that we have as a community to decide how we want things to change. If we agree as a community on it then I suppose bigger changes are coming. But I'll point out that it's outside the purview of this SOW.

>> The RSOC seems to be the reasonable choice given the situation we find ourselves in, and again, this is a 1.5 year contract with clearly described goals.
There's a saying I have on my team - don't come to me with problems, come with solutions. It's perfectly acceptable to not agree with what I said, If you feel it's not "clearly described goals" then please, propose text for the rest of us to review and agree upon that leaves you comfortable with the goals being clearly stated. I'm happy to help review.

Thanks,
Sarah

> 
>> We'll have the conversation to change (or not) - in the grand scheme of things, this doesn't seem to be an issue to me. The alternatives concern me more - do we just not have an RSE-like function at all, in any capacity, being executed, while we chat as a group? No documents are published? We're paying for the RPC function by contract now; I'd like to see our money well spent, personally. I'm not sure I understand the analogy to a penalty box, but if you mean we're in a holding pattern until we figure out what we want then yes, I totally agree, we are, and I               don't see a better alternative. I'm happy to discuss any alternatives you might have.
>> 
>> /S
>> 
>> 
>>> Later, Mike
>>> 
>>> 
>>> 
>>>> 	The RSOC has received a lot of feedback regarding the current SOW, in addition to the feedback received generally around the RSE role, both on and off list, and at the microphone at the plenary session in Montreal. We've listened, discussed, and come up with a proposal that you'll find attached here.
>>>> 	
>>>> 	Broadly speaking, the RSE role contains 2  functions, a strategic function and a tactical function. We believe that we, as a community, still want RFCs published while we discuss the RSE role evolution. We also have a contract in place with the RPC (both Production Center and Publisher), both of whom are accustomed to a day to day contact to lean on for assistance (the current RSE). 
>>>> 	
>>>> 	With that in mind, we are proposing a temporary position that focuses on the tactical components of the current RSE role, with 2 large work items in mind. 
>>>> 
>>>> 	First, this temporary position (called the Temporary RFC Series Project Manager) would serve as the day to day contact for the RPC, assisting with tactical items.
>>>> 
>>>> 	Second, this role would focus on the v3 format work, assisting with the delivery of the new tools for the format work, and bringing the new format work to a close.
>>>> 
>>>> 	The IAB plans on sharing a follow up email shortly, that covers possible next steps for the strategic portions of the RSE role and the evolution discussion. 
>>>> 
>>>> 	We'd like to open a 2 week comment period on the SOW, starting on August 30, 2019, closing ons on September 14, 2019. Please send your comments and feedback to the RSOC ([email-masked] <mailto:[email-masked]>).
>>>> 
>>>> Kind regards,
>>>> Sarah Banks
>>>> For the RSOC
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>
>

---

From: Sarah Banks <[email-masked]>
Date: Tue, 3 Sep 2019 20:35:02 -0700

Hi,
	<snip>

>> 
>> I suspect that what she means (since I've made similar disclaimers in the past and have seen many others do so as well) is that she's speaking without yet consulting with the RSOC or IAB on the related topics, so as to avoid confusion between her perspective and the consensus position of either of those bodies. If you have a proposal for a better way to phrase that kind of thing, I would love for you to offer it up.
>> 
>> /a
>> 
> The problem is that doing that is somewhat an abdication of the responsibility for the SOW.  I would have said something more like:  "Here's my opinion - I'll ask the rest of the RSOC to chime in as well", rather than the "speaking for myself" construct.     Or "I'll make sure the RSOC considers these, but I think I agree with XXXX and disagree with YYY and here's why".
> 

I take the chair role incredibly seriously. I was taught to chair by consensus, and if need be, rough consensus. I am a product manager by day. It's in my DNA to broker consensus. :) So when I send an email speaking for the RSOC, it really is that; it's an email that represents the consensus of the RSOC, whatever it may be, however rough it may be, regardless of my personal opinion on the matter. That said, I am also a community member, and while I agree that sometimes it might be hard to separate "chair of such and such" from "community member", I believe it's totally fair to share my own personal thoughts, without having first vetted them with the RSOC, when they are not damaging to the RSOC or the process. My opinions are just that, and the rest of the RSOC doesn't have to chime in if they don't want to. I appreciate your POV, but this is really a long winded way of me saying that my opinions are my opinions; i'll continue to share them when they're appropriate, and I'll continue to share those opinions in the best way I know how.
> Someone has to be willing to take and manage the commentary - if not Sarah, then who?    (I don't really care who - I just want to know who gets to decide what goes into the next version and how I affect that decision).  
> 

How did we get from "my personal opinion" to "Sarah abdicating responsibility of the SOW?" I don't see the leap, but let me state the obvious. The RSOC opened the comment period, and asked for the feedback to be sent to us. The IAB and SAA asked for it to go to RFCs-interest@. We're adults, we'll read the feedback on both lists and distill it. You are a voice in the community, and your feedback will be weighed along with everyone else's. 

Thanks,
Sarah
> "Success has many fathers, failure is an orphan".  I'd really like this not to be an orphan.
> 
> Later, Mike
> 
> 
>

---

From: Sarah Banks <[email-masked]>
Date: Tue, 3 Sep 2019 20:43:42 -0700

Hi Adrian,
	Please see inline.

> On Aug 31, 2019, at 3:32 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Sarah,
> 

I think what I'm hearing you say is that providing some sort of time bound would help here. Point taken, thank you.

> Doing this would allow you to make the list of tasks you want done, without getting into discussion of whether they are 73% tactical and 27% strategic.

Thank you for your feedback, we will discuss. I realize that sounds canned, but it's so true. :)

> To me this reads as though you want the contractor to be very flexible on deliverables. Firstly you are giving permission for the contractor to not deliver some things: I guess that's OK, no one wi…

Yup, that's exactly what we're saying. Some of what we know we want we've clearly stated; some of the rest we don't know, so we're giving a heads up. Any changes to deliverables would happen the same way we do it today with Heather; we discuss as a team, and agree or disagree as a team. We cannot simply add something to the list without the contractors buy in; that's crazy talk. We would mutually adjust, if need be. We can certainly discuss the language you've proposed, thank you for providing an alternative.

> Why "Scope of work - primary"? Is there a secondary scope of work somewhere?

You know, I can't really answer that, other than to say "this is the SOW we've used for 2 bidding processes, and to minimize churn, my thought was specifically to keep things as status quo as we could." If the major concern here is calling it "scope of work - primary" we can certainly refine this :)

> I would expect to see a termination clause.

The SOW is NOT the contract. I would expect the termination clause there for all the regular HR-ish reasons that lawyers put in there. I'll defer this to the LLC and confirm that's there; if not, then I agree, we'll have to agree on where to put it and if it's the SOW, then so be it, and draft the language. 

> The line "This relationship is subject to later reorganization" should be business as usual in a contract like this, but the history suggests that it might be better to be a bit clearer. Just as a…

Feel free to suggest text that might make it clearer. I'm not sure I can do better than this. We don't know what we don't know and to your point, they might not report to the RSOC (although I expect this interim contractor probably would, and the new RSE would be where the change starts, but that's for us to all discuss). Even if it did though, I'd argue that "the relationship is subject to later reorg" covers this. If not, what do you propose to say instead?

> Finally (you'll be glad to hear), what is the purpose of item 3 on the Affidavit? Is the intention here that you propose that only entities registered in the US for tax purposes may win this contra…

Nope, that's never been the case before, I'd expect it to not be now, either. We'll review.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 4 Sep 2019 10:44:11 +0100

Thanks for your reply, Sarah, and I appreciate you can't commit to any changes without first chatting with the rest of the RSOC.

>> When people bid fixed-pay fixed-deliverables on a contract, they usually
>> have a pretty detailed description of the work, that way they can work
>> out how much time they think it will take them, and bid accordingly. If
>> such detail is not available, a wise contractor will make an estimate and
>> add a lot of contingency. That puts up the price paid by the customer,
>> potentially unnecessarily. OTOH, an unwise or "keen" contractor may
>> under-bid risking that a poor job will be delivered. Frankly, the more
>> detail supplied, the more accurate the bid and the better the work.
>> 
>> Alternatively, the customer may give better guidance as to the expected
>> amount of work. The draft says that RFC 6635 section 2.15 is not applicable,
>> and (of course) that is true because this SoW does not cover all of the job
>> described in the RFC. But at the same time, it should be clear to everyone
>> that if 6635 considered that the job was 20 hours per week and nearly full
>> time during IETF week, then the work covered by this SoW is bounded by
>> that as an upper limit.
>> 
>> Anyway, I don't think the current draft has enough detail of what the job is
>> to enable a meaningful bid. Maybe this is fixed by simply adding something
>> to say that during the process of preparing bids and on request, the RSOC
>> will make available to bidders additional information to help them scope
>> and understand the nature of the tasks.
>

I believe that would be very helpful, yes.  Even if it as vague as:
The RSOC imagines that this job will average at around xx hours per week between IETF meetings, and be nearly full time during IETF meetings. We expect, however, that the contractor will be flexible in their use of time to handle peeks and troughs in the work load.

However, I do also think that some assistance in describing the tasks is needed. Either you must give more detail in the SoW or you must offer to provide more details on request. Recall that people bidding for this work may not have immediate and in-depth knowledge of the day-to-day work of the RSE.

>> Further to the tactical/strategic discussions on the list, I don't think it is helpful
>> to show your thought processes in the SoW. I would suggest:
>> - Replace "is being created to fill the tactical functions of the RSE role" with
>>   "is being created to fill certain functions of the RSE role as listed below"
>> - Strike "These “tactical” responsibilities of the RSE are not defined explicitly
>>    in RFC6635; the expected nature of the work is explained below."
>> Doing this would allow you to make the list of tasks you want done, without
>> getting into discussion of whether they are 73% tactical and 27% strategic.
>

No, I understand that at the moment the best you can say is "added to the list of things RSOC needs to discuss."

You (collective, RSOC) may still want to highlight that the objective is to fill the tactical not strategic parts of the total RSE roll, and I understand that. But be clear that not everyone has the same view of tactics and strategy, and that could result in confusion or even conflict down the road. Better just to set out what tasks you want done and (by omission) what tasks you don't want done.

>> To me this reads as though you want the contractor to be very flexible on
>> deliverables. Firstly you are giving permission for the contractor to not deliver
>> some things: I guess that's OK, no one will object to being paid for not 
>> delivering 😊 Second, you might be saying that new/changed deliverables may 
>> arise, but you are not making it clear whether you expect them to be delivered
>> under the contract or not. The usual way to handle both of these points is
>> "variations by mutual agreement in writing."
> 
> Yup, that's exactly what we're saying. Some of what we know we want we've
> clearly stated; some of the rest we don't know, so we're giving a heads up. Any
> changes to deliverables would happen the same way we do it today with Heather;
> we discuss as a team, and agree or disagree as a team. We cannot simply add
> something to the list without the contractors buy in; that's crazy talk.

😊 But SoWs lead to contracts. I have seen a few in my time, and it is interesting what customers expect.

> We would mutually adjust, if need be. We can certainly discuss the language you've
> proposed, thank you for providing an alternative.

You're welcome. Words are cheap.

> You know, I can't really answer that, other than to say "this is the SOW we've used
> for 2 bidding processes, and to minimize churn, my thought was specifically to keep
> things as status quo as we could." If the major concern here is calling it "scope of work
> - primary" we can certainly refine this :)

OK

> The SOW is NOT the contract. I would expect the termination clause there for all the
> regular HR-ish reasons that lawyers put in there. I'll defer this to the LLC and confirm
> that's there; if not, then I agree, we'll have to agree on where to put it and if it's the
>  SOW, then so be it, and draft the language. 

Sure, details of termination go in the contract.
But if surely changes how a contractor quotes if they know it is for a guaranteed block of 18 months, or that it can be terminated, without cause, on 30 day notice.
So something should be written unless you want to attract higher and more cautious bids.

>> The line "This relationship is subject to later reorganization" should be business
>> as usual in a contract like this, but the history suggests that it might be better to
>> be a bit clearer. Just as a point of note, the previous paragraph names the RSOC
>> as the body with whom scope changes might be identified, but (presumably) if
>> the reporting changed, that wouldn't be true.
> 
> Feel free to suggest text that might make it clearer. I'm not sure I can do better
> than this. We don't know what we don't know and to your point, they might not
> report to the RSOC (although I expect this interim contractor probably would, and
> the new RSE would be where the change starts, but that's for us to all discuss).
> Even if it did though, I'd argue that "the relationship is subject to later reorg" 
> covers this. If not, what do you propose to say instead?

I understand the motivation, but am concerned about the impact of a transfer of management relationship since the manager and point of contact has a significant impact on the work that has to be done and the working environment. It's a relatively short term contract, so perhaps that is not too bad. But viewed from the other side, there are some concerns expressed in the community that having the RSE (or part of the function) report to different parts of the IETF would be problematic.

I think you can do one of two things depending on how likely you think such a change is.
- If you think it is likely to change, replace "RSOC" in the SoW with some term such as
  "Work Manager", and state that the initial Work Manager will be RSOC, but that the 
  LLC reserves the right to change this. But I would probably expect "mutual agreement"
  in this case.
- If you think it is not very likely to change, just don't even talk about it in the SoW because it
  falls into the usual contract "special cases" clauses.

>> Finally (you'll be glad to hear), what is the purpose of item 3 on the Affidavit? Is the
>> intention here that you propose that only entities registered in the US for tax purposes
>> may win this contract?
>

OK. Will be interesting to see how that pans out.

Best,
Adrian

---

From: Michael StJohns <[email-masked]>
Date: Thu, 5 Sep 2019 10:59:42 -0400

Pruning

On 9/3/2019 11:26 PM, Sarah Banks wrote:
> Hi Mike,
> Please see inline.
>
>> On Sep 2, 2019, at 12:24 PM, Michael StJohns <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>

>>>> indistinguishable from that of the RSE as stated in previous 
>>>> versions of the SOW.   I don't think that makes sense.  If this is 
>>>> simply a "we want to hire some short time to do the RSE position", 
>>>> then state that rather than using the figleaf of strategic and 
>>>> tactical.  I'm not saying you'll get community buy-in for that, but 
>>>> at least it would be less obfuscated.
>>>
>>> nothing more. It IS focused on what the current RSE does tactically 
>>> - I'm not sure how we change that until the community has a 
>>> conversation about the role. I'm all ears and open to suggestions, 
>>> though!
>>
> The SOW clearly calls for a firm initial term. I believe I've also 
> followed up since stating there might be overlap. Help me understand 
> where the confusion is here? Have I overlooked something?

If this contract runs concurrently with the RSE, and they are separate 
awards, then either there's duplication of effort, or the RSE role is 
greatly reduced.   If the overlap is only in the form of handover, 
that's useful guidance.

> Your question assumes outcome of the community process. I have no idea 
> what that outcome is. This is a TEMPORARY role. There's nothing to 
> "take" away from the next RSE, should we the community choose to 
> continue to have one. I'm being somewhat obtuse on purpose - the SOW 
> is NOT a comment on what happens with the next RSE or the process or 
> any of that - the SOW covers the specific work items laid out, with 
> the ability to adjust them by mutual consent should something arise, 
> and allow RFCs to continue flowing while we, the community, figure out 
> what we want to do.

Fair enough.   But I would hope that the RSOC at least have some idea - 
as the current group of responsible people - as to what outcome makes 
sense for the RSE.  The issues I (and I think others) have had is not so 
much with what the RSE has been doing/is going to be doing, but in the 
management regime to come.   Mostly that won't be reflected in the SOW 
except as side effects for the process changes that happen if a 
temporary position is created (and possibly maintained).

>> the RSE?  If not, why not?   [E.g. insider knowledge vs fairness of 
>> the bid process]
>>
> The SOW doesn't take a position on this, and IMHO, that's a good 
> thing. We want the best person for the job. Any incumbent would have 
> "insider knowledge", in that they know how the process works, and are 
> already sitting in the job. I don't think this is our biggest problem 
> to solve, or a huge problem in and of itself. That's my opinion. If 
> the rest of the community feels differently they can say so and we'll 
> discuss.
>
> I don't understand what the "items to eliminate" are? The SOW is 
> specific in it's 2 goals, which I've already stated again in this 
> email. They cannot wait, hence the SOW.

Take a look at the deliverables for the RSE SOW that hired Heather, 
compare them to the SOW deliverables in this document. Besides items 
already removed if any, are there any that could absolutely wait for an 
RSE and don't need to provided for before we get a "real" RSE post this 
contract?

>
>>>
>>>> 1) Is this a full time position?  If not, then describe the 
>>>> expected workload.   From the description, its a level of effort 
>>>> contract somewhat less than full time. State that level.
>>>
>>> total amount of work (that's been the thought) versus the employee 
>>> who clearly needs to understand if this is a part time or full time 
>>> job.
>>
>>
>> I can't see how this could be let as a firm fixed price contract or 
>> even a piece work or deliverable task contract.  I think this is an 
>> LOE contract with meta deliverables.  You're going to want some of 
>> this persons time to be committed, and you're going to want to tell 
>> them up front what that time commitment is.   I think figuring out 
>> what that LOE is is squarely in the wheelhouse of the SOW authors.
>>
>>

That unfortunately isn't really a useful response.  But let me try this:

You have basically three classes of deliverables:   One-time (or 
one-time with phases - finish the V3 transition for example); recurring 
(e.g. quarterly project reports), and continuous (technical expertise as 
needed, RPC oversight etc).  Only the first two allow for a reasonable 
fixed price bid.  The last one is going to need something like "For 
approx 10 hours a week, plus full time 3 weeks out of each year commit 
to provide technical expertise in the following areas to the extent 
possible for the allotted hours; increases or reductions in negotiated 
time commitments may be made by mutual written consent".

>>> what to do. if we don't want a managed RFC Editor, but the 
>>> independent model that folks believe we should have, then as a 
>>> community we should say that, and figure out how to instrument what 
>>> we want. Personally, I like the spirit of what was described to me 
>>> starting with Postel, and having some independence from being told 
>>> what to do blindly with the ability to push back doesn't seem to be 
>>> a bad thing. But that's my personal thought, and as an RSOC it's not 
>>> our current purview to tell the community what to do.
>>
>> diminish the independence of the RSE from previous levels.  If the 
>> RSOC (and for that matter) would take a look at what it was fall of 
>> 2016 vs how its been behaving vis a vis the RSE since that point in 
>> time, I'd be much happier with your statement that you don't tell the 
>> community what to do.
>>
>>
> Mike, what exactly do you want? Honestly, what is it? I believe the 
> RSOC made a mistake. We publicly and very specifically said that we 
> made the mistake, owned it, and apologized. I am incapable of undoing 
> that mistake, it is what it is. That said, I believe the RSOC has been 
> very thoughtful in it's actions since, starting with the feedback 
> we've received, drafting a new SOW, and IMO clearly stating that the 
> SOW is specifically a temporary position that allows us to keep RFC's 
> flowing while the community figures out "what's next". I'm at a loss 
> to understand how we're telling the community what to do.
>
>
What I'm trying to get to is fixing or at least placing a temporary 
patch on the issues with the current oversight model without having to 
wait 2.5 or so years.  I'm mostly ok with the discussions about what the 
RSE is going to be doing, but I'm less sanguine about what the RSOC and 
IAB will be allowed to do without some proposed changes in that 
model.    I don't want to be back here in a year or so with the 
possibility of having the same things go wrong again.   That maybe hard 
for the RSOC to hear, but it is what it is.  What's hard for me to hear 
is the lack of thought about how to mend the current oversight model.

>>> community to do its thing. This position "reporting" to the LLC 
>>> makes little sense to me - 1. that's not the current process we have 
>>> (and if you don't like it, speak up and change it, Ted's outlined 
>>> how we might proceed to doing that) and 2. The LLC really isn't 
>>> equipped to handle it either.
>>
>> RSOC operate as a COTR under the purview of the LLC with no ability 
>> to tell the RSE what to do, but instead acts as an advisor to the LLC 
>> for contract issues.  That gives whoever gets hired one and only one 
>> point of control to deal with.   I'd also suggest that the RSOC no 
>> longer do the "we're talking about contracts in executive session" 
>> stuff and instead call for community input every couple of years or 
>> so and write a public report detailing pros and cons based on that 
>> input (and specifically no anonymous input) as the basis for the LLC 
>> to make its decisions.  6635 is not controlling on the LLC as they 
>> are the fiduciaries - but the community might not like that 
>> interpretation.  They could adopt 6635 as an operating instruction by 
>> vote of the board, but I don't see that as having taken place.
>>
>>
>
> That's your point of view, *a* point of view, and I think it's 
> reasonable for this to be a part of the conversation that we have as a 
> community to decide how we want things to change. If we agree as a 
> community on it then I suppose bigger changes are coming. But I'll 
> point out that it's outside the purview of this SOW.

And a large part of the problem I'm concerned about.

>
>>> The RSOC seems to be the reasonable choice given the situation we 
>>> find ourselves in, and again, this is a 1.5 year contract with 
>>> clearly described goals.
>>
> There's a saying I have on my team - don't come to me with problems, 
> come with solutions. It's perfectly acceptable to not agree with what 
> I said, If you feel it's not "clearly described goals" then please, 
> propose text for the rest of us to review and agree upon that leaves 
> you comfortable with the goals being clearly stated. I'm happy to help 
> review.

I actually have proposed an approach to fix the oversight problem.  The 
rest of this - well - the SOW is only part of what you need here, the 
other is the plan and contingencies.  I think we're getting some of 
those edges discussed, but the SOW shouldn't be what drives the plan, 
but the plan being what drives the SOW. I think the current SOW has too 
much in it for the stated purpose of "temporary and tactical" and I 
alluded to that above.  It's difficult to provide text if I don't 
understand the hard edges of what you want to accomplish - hence the 
various questions above.

Later, Mike

>>> concern me more - do we just not have an RSE-like function at all, 
>>> in any capacity, being executed, while we chat as a group? No 
>>> documents are published? We're paying for the RPC function by 
>>> contract now; I'd like to see our money well spent, personally. I'm 
>>> not sure I understand the analogy to a penalty box, but if you mean 
>>> we're in a holding pattern until we figure out what we want then 
>>> yes, I totally agree, we are, and I don't see a better alternative. 
>>> I'm happy to discuss any alternatives you might have.
>>>
>>> /S
>>>
>>>
>>>> Later, Mike
>>>>
>>>>
>>>>
>>>>> in addition to the feedback received generally around the RSE 
>>>>> role, both on and off list, and at the microphone at the plenary 
>>>>> session in Montreal. We've listened, discussed, and come up with a 
>>>>> proposal that you'll find attached here.
>>>>> Project Manager) would serve as the day to day contact for the 
>>>>> RPC, assisting with tactical items.
>>>>>
>>>>> Second, this role would focus on the v3 format work, assisting 
>>>>> with the delivery of the new tools for the format work, and 
>>>>> bringing the new format work to a close.
>>>>>
>>>>> August 30, 2019, closing ons on September 14, 2019. Please send 
>>>>> your comments and feedback to the RSOC ([email-masked] 
>>>>> <mailto:[email-masked]>).
>>>>>
>>>>> Kind regards,
>>>>> Sarah Banks
>>>>> For the RSOC
>>>>>
>>>>>
>>>>
>>>
>>>

---

From: Sarah Banks <[email-masked]>
Date: Thu, 5 Sep 2019 08:38:05 -0700

Hi Mike,
	Please see inline. I'll <snip> more judiciously :)

/S

> If this contract runs concurrently with the RSE, and they are separate awards, then either there's duplication of effort, or the RSE role is greatly reduced.   If the overlap is only in the form of handover, that's useful guidance.
> 
> 
> 

SB// We'll have to address that when we get there. There's a balance between giving the person bidding some semblance of how long the initial contract would run, and balancing that against how long it'll take the community to complete its discussion. The text reflects that balance and is of course, subject to input, feedback, and comments.

> Fair enough.   But I would hope that the RSOC at least have some idea - as the current group of responsible people - as to what outcome makes sense for the RSE.  The issues I (and I think others) have had is not so much with what the RSE has been doing/is going to be doing, but in the management regime to come.   Mostly that won't be reflected in the SOW except as side effects for the process changes that happen if a temporary position is created (and possibly maintained).
> 
> 
> 

SB// On one hand, of course we do.. but on the other, I'd say you can't have it both ways. You can't say/accuse the RSOC of steering the process, and then wonder why we aren't sharing those thoughts as an RSOC, because I think if we did we'd be subject to the "but you're steering the process" feedback. Personally, I feel I wear 2 hats; one as a member of the RSOC, and one as the member of the community. When we get to the actual community comment/process that Heather is kicking off leading up to and in Singapore, I'll share my thoughts with my community hat on. I understand you're concerned about the management regime to come, but I'll point out that if we want to change that, then the meetings that are coming are the places where we all get to voice what we want changed. The SOW shouldn't reflect that now because there is no consensus. Restricting the SOW to tactical items that have 1. clearly defined deliverables and 2. a process by which we can mutually amend the deliverables (presumably add something if the need arises) is the best way I can think of to restrict any "danger", or unwanted items, until the community has its say. 

I want to touch on your last 3 words here; it is again the intent that this position be a temp position. If the community chooses otherwise then it'll be what it'll be, but the RSOC is NOT proposing a temp position with the notion of baiting and switching down the line; it really is what I think I've said 15+ times at this point - something that helps us keep documents flowing, and our other contractor happy, while the community discusses what we want. If another body were to come in and attempt to make it permanent without community consensus I'd be the first one in line to jump up and down. The community has been extremely clear; we will all have our say.

<snip>
> Take a look at the deliverables for the RSE SOW that hired Heather, compare them to the SOW deliverables in this document.   Besides items already removed if any, are there any that could absolutely wait for an RSE and don't need to provided for before we get a "real" RSE post this contract?
> 
> 
> 

If you want to propose something change, the onus is on you to propose the list :) If there is something in the current document that you think can wait please propose it here.

<snip>
> You have basically three classes of deliverables:   One-time (or one-time with phases - finish the V3 transition for example); recurring (e.g. quarterly project reports), and continuous (technical expertise as needed, RPC oversight etc).  Only the first two allow for a reasonable fixed price bid.  The last one is going to need something like "For approx 10 hours a week, plus full time 3 weeks out of each year commit to provide technical expertise in the following areas to the extent possible for the allotted hours; increases or reductions in negotiated time commitments may be made by mutual written consent".
> 
> 
> 
I wasn't trying to be facetious, simply acknowledging that you've stated your opinion. We'll review all the comments that come in, and thank you for sharing it. I'm not sure how else to put it, but I also acknowledge that it sounds cheeky, even though that's not at all how I mean it to be.

<snip>
> What I'm trying to get to is fixing or at least placing a temporary patch on the issues with the current oversight model without having to wait 2.5 or so years.  I'm mostly ok with the discussions about what the RSE is going to be doing, but I'm less sanguine about what the RSOC and IAB will be allowed to do without some proposed changes in that model.    I don't want to be back here in a year or so with the possibility of having the same things go wrong again.   That maybe hard for the RSOC to hear, but it is what it is.  What's hard for me to hear is the lack of thought about how to mend the current oversight model.
> 
> 
> 
I manage expectations for a living, so when I read your first sentence above, I have a LOT of sympathy for it. I do. It's very hard to put your arms around something that's undefined, and I think the worry might be that the conversation could take a long time is a potential possibility.  On the other hand, I think we seem to be very invested in getting to "something" that makes the majority of us comfortable with where we're going. Ted and Heather have taken that first step, and Heather's been incredibly gracious setting up the meetings and running them. I suppose it's entirely possible things could go wrong again - I don't see any way to guarantee that that couldn't ever happen again - and I apologize if that's hard to hear. 

My perception of what you've been sharing is that there are nuggets of information we should seriously discuss, mixed with a lot of anger. I think it's totally your right to be angry about things. But anger isn't going to change the situation we're in. With all due respect, saying that there's a "lack of thought about how to mend the current oversight model" is rude at best. I've spent an inordinate amount of time thinking about this; thinking about it leading up to the decision the RSOC made, when we made it, and everything that's happened since. Heather is walking away. That weighs incredibly heavy on me. I've not been shy in my praise and support of Heather, that I think the RSOC is here to support her, and that I've not seen the community unhappy with her/want her out/anything else super bad you could write here. I'm on the RSOC Mike but I still chair a WG and participate in others, and write drafts like everyone else. It matters to me deeply that we have someone who is focused on the RFC Series. So while I suspect we somewhat differ on our opinions of the specifics on what went wrong here, it's not helpful to make comments like that last sentence, on a comment thread for the current SOW. This isn't, and wasn't ever supposed to be, where you'd heard anyone's thoughts on how to mend the current oversight model. I look forward to the community discussion that Heather is preparing for shortly.

<snip>
> I actually have proposed an approach to fix the oversight problem.  The rest of this - well - the SOW is only part of what you need here, the other is the plan and contingencies.  I think we're getting some of those edges discussed, but the SOW shouldn't be what drives the plan, but the plan being what drives the SOW.  I think the current SOW has too much in it for the stated purpose of "temporary and tactical" and I alluded to that above.  It's difficult to provide text if I don't understand the hard edges of what you want to accomplish - hence the various questions above.
> 
> 

Perhaps this is the point in the communication process where I say perhaps email isn't working. I feel I've written any number of times what we're trying to accomplish, and Ted has specifically spelled out the approach. So if it's that you don't agree with the current approach, that's one thing; if it's that you really don't understand what we want to accomplish, then I'm not sure how to say it any differently. I'd suggest again that perhaps we sync up one on one on a call. 

Thanks,
Sarah

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 6 Sep 2019 09:17:14 -0500

For what it's worth ...

On Thu, Sep 5, 2019 at 10:39 AM Sarah Banks <[email-masked]> wrote:

> [deleted down to]

> You have basically three classes of deliverables:   One-time (or one-time
> with phases - finish the V3 transition for example); recurring (e.g.
> quarterly project reports), and continuous (technical expertise as needed,
> RPC oversight etc).  Only the first two allow for a reasonable fixed price
> bid.  The last one is going to need something like "For approx 10 hours a
> week, plus full time 3 weeks out of each year commit to provide technical
> expertise in the following areas to the extent possible for the allotted
> hours; increases or reductions in negotiated time commitments may be made
> by mutual written consent".
>
>
> I wasn't trying to be facetious, simply acknowledging that you've stated
> your opinion. We'll review all the comments that come in, and thank you for
> sharing it. I'm not sure how else to put it, but I also acknowledge that it
> sounds cheeky, even though that's not at all how I mean it to be.
>

I'm not a likely candidate to bid on the temporary position, but I have
been a consultant working under contracts since 2016, and I've been looking
at this thread and trying to imagine what likely candidates must be
thinking about whether, and how, to provide bids.

Mike's three-way split seems very helpful to me (and I'm not surprised,
because he has much more experience bidding on contracts than I do).

And I recognize that "do the right thing" is better as guidance than as a
contract deliverable.

Thanks,

Spencer