Subject: [Rfced-future] Suggested text for issues #56, #57, #61, #62

From: Jay Daley <[email-masked]>
Date: Wed, 23 Jun 2021 13:14:12 +1200

Here is my proposed text to address the following issues

#56 - Process for RPC work not requiring consensus
#57 - How are RPC priorities set?
#61 - Replacing the previous RSE role in gathering requirements for the RPC
#62 - Communicating decisions about RPC projects/priorities to the community

The RPC have not had a chance to comment on this text, but I am hoping they will on list in due course.

—— 
## RFC Production Center

The RFC Production Center (RPC) shall develop and maintain a work 
program for the implementation of community requirements. In 
developing this work program, the RPC should consult with the RSAB so 
that the RSAB may:

* Inform the RPC of any community requirements that it should consider
  in addition to policy proposals emanating from the RSWG.
* Advise the RPC on what degree of community consultation and 
  engagement is required for any proposed or planned work item.
* Advise the RPC on the relative priorities of proposed and planned 
  work items.

All matters of budget, timetable and impact on its performance 
targets, are between the RPC and IETF LLC.

In the event that the RPC is required to make a decision without 
consultation that would normally deserve consultation, or makes a 
decision against the advice of the RSAB then it must notify the 
RSAB.

The RPC shall report regularly to the RSAB, RSWG and broader 
community, on the contents and progress of its work program and any 
key risks or issues affecting it. 
—— 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Jun 2021 11:43:38 +1000

On Wed, Jun 23, 2021, at 11:14, Jay Daley wrote:
> program for the implementation of community requirements. 

Thanks Jay,

This is a good start, though I would move the first chunk down to reduce the emphasis on it.  Reasoning below...

> decision against the advice of the RSAB then it must notify the 

Item 4:

The RPC will develop this program using the strategic direction set by the community as input.  The RPC can consult with the RSAB directly, rather than relying on public consultation.  As stream managers, the RSAB can provide input on stream-specific policies or requirements.  The RSAB should be able to advise on whether a decision might need to be made by the RSWG and what items are currently under discussion in the RSWG.  The RSAB might be able to provide input on how work items on the program are prioritized.

However, I'm concerned that this last item gives considerable power to the RSAB.  Setting priority is a very good proxy for setting policy.  As stream managers, that is probably fine (hence my suggested tweak), as a body, that risks undermining the RSWG process: "the WG decided this, but it's silly, so deprioritize its implementation".

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Jun 2021 21:58:28 -0400

Jay I like your text a lot.  It provides a needed bright line in 
(martin's renumber 1) between contractual direction and non-contractual 
discussion and work plan directions.

Martin - I think the reordering is fine.  But see comments on the last 
chunk you wrote.

On 6/22/2021 9:43 PM, Martin Thomson wrote:
> SAB.
Ultimately, legally and effectively, the timing and priority of any work 
by the RPC is an LLC/RPC decision.  Ditto for any hired/contracted for 
RSA/E (mutual agreement consistent with the contract/employment 
agreement).  So yes - the RSAB may say "deprioritize" vs RSWG 
"emphasize" at which point if there's disagreement, that's going to be 
an interesting contractual discussion between the LLC contract manager 
and the RPC based on input from both the RSAB and the RSWG.  That's just 
reality and I don't really thing we need to spend a lot of time on 
trying to change how those levers of power are manipulated.  If there's 
a massive failure later, AND someone has a better idea, AND it can be 
implemented through contractual language, THEN we can readdress this point.

Which also has me asking a question:  Should the LLC provide a liaison 
to the RSAB as mandatory requirement?

(Jay - sorry if any of this makes your life harder... )

Mike

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Jun 2021 12:19:33 +1000

> implemented through contractual language, THEN we can readdress this point.

I wasn't suggesting that we needed to change the substance here, just to change the emphasis on the text.  You'll note that I just reworded Jay's text, not changed the bullet points.
 
> to the RSAB as mandatory requirement?

Not mandatory, and I don't think we need formal encouragement for everyone to be proactively consultative.  I'd rather stay silent (for reasons similar to those you outline above).

---

From: Jay Daley <[email-masked]>
Date: Wed, 23 Jun 2021 14:30:23 +1200

> On 23/06/2021, at 2:19 PM, Martin Thomson <[email-masked]> wrote:
> 

I think there should be an LLC liaison as a non-voting member.  That’s what we have with RSOC and what I think is necessary for the LLC in it’s role of setting the performance targets for the RPC and negotiating the work plan budget/timetables.

Jay

> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Wed, 23 Jun 2021 14:50:17 +1200

> On 23/06/2021, at 1:43 PM, Martin Thomson <[email-masked]> wrote:
> 
> The RPC will develop this program using the strategic direction set by the community as input.  

I don’t think we should give the RPC a wide-ranging community engagement role by default because that will inevitably create a parallel mechanism for changes outside of the RSWG/RSAB process, and all the tensions that come with that.  A narrower constraint, whereby changes are normally funnelled through the RSWG/RSAB, while leaving the door open for an extraordinary widespread consultation seems more appropriate.

> The RPC can consult with the RSAB directly, rather than relying on public consultation.  

Similarly, my proposed text had the RSAB as the first stop for the RPC for advice on how/where to consult, rather than the RPC making that decision and choosing or not choosing the RSAB.  This was following a principle that the community manages/decides/advises on how it is consulted rather than any support function to the community. 

> As stream managers, the RSAB can provide input on stream-specific policies or requirements.  The RSAB should be able to advise on whether a decision might need to be made by the RSWG and what items are currently under discussion in the RSWG.  The RSAB might be able to provide input on how work items on the program are prioritized.
> 

My proposal was only for the RSAB to be able to advise the RPC on priorities not instruct them.  And don’t forget we expect that to be public.  Rather than seeing this as a risk, I would say that as the RSAB is basically the four stream managers plus the RSE/A, this kind of advisory power is a useful check and balance to the RSWG.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jun 2021 15:06:29 +1200

> #61 - Replacing the previous RSE role in gathering requirements for the 
RPC

I understand why that becomes an RSWG and RSAB function, but I think we need it to be clear elsewhere in the document that we expect the RSEA to have a major role in this work (and very likely be the de facto communications channel from the RSWG and RSAB to the RPC).

I may have missed it, but I don't there's a github issue for finalizing the role and title of the RSEA. That's where I would like to hang this comment.

    Brian C

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Jun 2021 14:16:45 +1000

On Wed, Jun 23, 2021, at 12:50, Jay Daley wrote:
> My proposal was only for the RSAB to be able to advise the RPC on 
> priorities not instruct them.  And don’t forget we expect that to be 
> public.  Rather than seeing this as a risk, I would say that as the 
> RSAB is basically the four stream managers plus the RSE/A, this kind of 
> advisory power is a useful check and balance to the RSWG.

In terms of checks and balances, I'm far more worried about the RSAB than the open processes of the RSWG.  The RSWG is far less likely to do something the RSAB doesn't like because the RSAB forms the core of the RSWG anyway.

Yes, we've done a lot to improve transparency through this process, but I have seen that dynamic.  The meeting will be at 3am, the decision might be questionable, but the minutes won't capture sufficient nuance and the RSAB will close ranks in defense of the decision, not wanting to re-litigate it.

This is already a problematic dynamic in the IETF where editor teams and design teams form, one that I've seen from both sides.  It is in fact one of the major shortcomings of us moving to GitHub and it happens even though there is a marked improvement in transparency and accountability.  The clique makes decisions that are hard to overturn.

This is part of why it is important - at least in my opinion - that the board is able to approve only.  For permanent outcomes, they approve decisions from the RSWG; for temporary decisions with time constraints, they approve decisions the RPC makes (in consultation with the well-informed and affected).

As I noted in response to Mike, I don't think that the substance of what you have is wrong, just the emphasis.  This sort of consultation is perfectly fine and might not even need to be formally recognized, because in formal recognition we establish an expectation and that expectation can be exploited to exert power.

I would prefer that the sort of text here be left out now.  The RPC formulates its work plan and can consult with the nominated representatives of its customers (i.e., stream managers) rather than the amorphous mass that is the community to inform its decisions.  That this also happens to be the RSAB is convenient, but it isn't a formal responsibility of that body.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jun 2021 09:51:08 +0200

> I may have missed it, but I don't there's a github issue for finalizing the role and title of the RSEA. That's where I would like to hang this comment.

There are several, one of which we just are in the process of closing.  
The title one I have deferred discussing for the moment.  We also have 
the agreed text from Issue 12:

> This person will be a senior professional with deep knowledge of 
> technical publishing.
>
> The RSE will operate by providing expert advice to the RSAWG, and if 
> requested, to the RPC, on any relevant matters. The value this 
> individual provides is an understanding of the process of technical 
> publishing. They expected to learn how the process is applied in the 
> RFC series. They will be asked to produce regular reviews of the 
> process and identify problems and opportunities for improvement. There 
> are also opportunities to spontaneously learn of these problems, 
> likely the result of interactions with day-to-day operations. The 
> person may be requested to draft documents
>
> For example, the RSE might be consulted about proposed changes to the 
> style guide, RFC formatting in general, web presence, copyright 
> matters, or archiving policy, or might of their own initiative suggest 
> such changes to the RSAWG.
>
> The RSE is expected to attend all RSAWG meetings, and to have an 
> ongoing working relationship with the RPC and tooling team.
>
https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md

This text needs to make its way into the draft.  That is not to say this 
text can't improve, but this was what we agreed.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jun 2021 09:30:08 +1200

> the agreed text from Issue 12:

Fair enough (but see below) but in my defence, the title of that issue didn't seem like it covered the role definition.

>> requested, to the RPC, on any relevant matters. 

Yes, we agreed on that, but I think we missed the question of who will be 
tasked with communicating RSWG and/or RSAB decisions and advice to the RPC. So there's an open issue either here in #12 or in Jay's proposed texts. I'd be inclined to fill it here, something like:

The RSEA will communicate relevant RSWG and RSAB decisions and advice to the RPC.

(The alternative would be to task the RSWG and RSAB chairs with this, but 
if we're hiring an expert, that would seem like the normal person to do it.)

   Brian

>> The value this

---

From: Jay Daley <[email-masked]>
Date: Thu, 24 Jun 2021 13:11:29 +1200

> On 24/06/2021, at 9:30 AM, Brian E Carpenter <[email-masked]> wrote:
> 

For me this is a backward step.  We appear to have agreed in principle that the RPC is stepping up and engaging much more directly with the community (though we’re still discussing if that’s primarily through the RSAB/RSWG or more directly) and we appear to have agreed that the RSEA is not the manager of the RPC.  Under those conditions, breaking the direct connection between the RSAB/RSWG and the RPC by inserting the RSEA into the chain seems retrograde and reopens multiple questions about the nature of the relationship between the RSEA and the RPC that are otherwise moot.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jun 2021 17:06:44 +1200

On 24-Jun-21 13:11, Jay Daley wrote:
> 
> 
>> On 24/06/2021, at 9:30 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Fair enough (but see below) but in my defence, the title of that issue 
didn't seem like it covered the role definition.
>> tasked with communicating RSWG and/or RSAB decisions and advice to the 
RPC. So there's an open issue either here in #12 or in Jay's proposed texts. I'd be inclined to fill it here, something like:
> For me this is a backward step.  We appear to have agreed in principle that the RPC is stepping up and engaging much more directly with the 
community (though we’re still discussing if that’s primarily through the RSAB/RSWG or more directly) and we appear to have agreed that the RSEA is not the manager of the RPC.  Under those conditions, breaking the direct connection between the RSAB/RSWG and the RPC by inserting the RSEA into the chain seems retrograde and reopens multiple questions about the nature of the relationship between the RSEA and the RPC that are otherwise moot.

I probably phrased it wrongly. Yes, in the normal case the RPC will be fully aware of what's going on and will hopefully be fully aware of RSWG/RSAB outcomes. But the RSEA is supposedly a subject matter expert and if we're paying for that, the RSEA is surely a resource we want to use. For sure, the RSEA is not giving orders to the RPC.

"The RSEA's expertise will be available to the RPC when implementing RSWG 
and RSAB decisions and advice."

Better?

   Brian
>>> https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md <https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md>
>>>
> [email-masked] <mailto:[email-masked]>
>

---

From: Jay Daley <[email-masked]>
Date: Thu, 24 Jun 2021 19:19:37 +1200

> On 24/06/2021, at 5:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Yes thanks. There’s already some relevant text along these lines in the bullet points off section 4 in the draft. 

Jay

(sent from my phone)

-- 
Jay Daley
IETF Executive Director
+64 21 678840

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Jun 2021 08:35:35 +0200

Jay, Martin,

Let's go through where we seem to agree first:

I am not hearing any argument about the reordering that Martin proposed, 

> decision against the advice of the RSAB then it must notify the

Then there is the question of a non-voting liaison from the RPC. If 
there is to be such a person, how does that person get appointed and by 
whom?  The easiest answer is by the IETF Executive Director.  Is that 
correct?  At some point we need to back up to how we relate all of this 
to the tooling team.  Is it represented by the same liaison?  Is it 
governed in a similar fashion?

> However, I'm concerned that this last item gives considerable power to the RSAB.  Setting priority is a very good proxy for setting policy.  As stream managers, that is probably fine (hence my sugg…

This raises questions:

 1. Should there be a frequency by which the RPC reports?  If they're
    frequent enough, then there is no need to make massive shifts
    without consultation, and we are talking about a pretty focused
    function (i.e., not like an entire government ministry or
    department).   The only real question is whether the RPC should seek
    approval/endorsement of its plan.  "Here's what we did, here's how
    it went, here's what we plan to do over the next XX months/year(s)".
 2. Are we are using the RSAB for regular consultations between stream
    managers and the RPC?  In this case, is the RSAB acting as a group
    or merely being gathered as stream managers?  If the latter, then
    the RSAB has no formal role.  The RPC is always free to consult who
    they want to consult in order to get the job done or to identify
    issues.  Right?

Eliot

---

From: Jay Daley <[email-masked]>
Date: Tue, 29 Jun 2021 22:16:31 +1200

> On 29/06/2021, at 6:36 PM, Eliot Lear <[email-masked]> wrote:
> 
> 
> Jay, Martin,
> 
> I am not hearing any argument about the reordering that Martin proposed, and so I think we stand as follows:
> 
> Then there is the question of a non-voting liaison from the RPC.  If there is to be such a person, how does that person get appointed and by whom?  The easiest answer is by the IETF Executive Director.  Is that correct? 
> 
To me there are two separate needs here. The IETF Executive Director is a liaison to coordinate the overall operational response and ensure that performance targets and priorities are met - that includes RPC, tools, comms etc. 

The question of whether the RPC has a liaison depends on the nature of the RPC role that we are still discussing below so I’ll pick that up there.  
> At some point we need to back up to how we relate all of this to the tooling team.  Is it represented by the same liaison?  Is it governed in a similar fashion?
> 
There’s no need for a specific tools liaison.  The RPC have tools requirements that are discussed direct with the IETF Executive Director (funding/contracting) and Tools Team PM (internal/community implementation).  The authors discuss their tools requirements directly on list. 
> Should there be a frequency by which the RPC reports?  If they're frequent enough, then there is no need to make massive shifts without consultation, and we are talking about a pretty focused function (i.e., not like an entire government ministry or department).   The only real question is whether the RPC should seek approval/endorsement of its plan.  "Here's what we did, here's how it went, here's what we plan to do over the next XX months/year(s)".
> Are we are using the RSAB for regular consultations between stream managers and the RPC?  In this case, is the RSAB acting as a group or merely being gathered as stream managers?  If the latter, then the RSAB has no formal role.  The RPC is always free to consult who they want to consult in order to get the job done or to identify issues.  Right?
So this is where I think Martin and I have two very different visions of the RPC and the answer to all of the above revolves around which vision we move forward with. 

The current structure has an RSE that collects community requirements, engages with the community as needed, interprets those requirements and delivers a prioritised list to the RPC.  The RSE also reports to the community. The RPC certainly picks up plenty of requirements from its engagement with authors but those are fed into the RPC for them to work into their plans.  The checks and balances to this process are multiple - there is the RSOC overseeing the RSE, the RSE overseeing the RPC and the LLC monitoring both contracts.  The key check here is that the RSE cannot unilaterally decide who they consult and what they consult on. 

If we switch to a structure where the RPC is responsible to the full community then two things happen. First, they take on all of the role of the RSE above, which I am concerned is far too much of a change for the RPC.  Second, the only check and balance becomes the LLC, which now monitors the contract, manages performance, agrees the work program with the RPC, takes on the community role of ensuring that the RPC consults with the right people and consults on the right things and the role of ensuring the reporting to the community is adequate. I am concerned that is too large a role for the LLC and oversteps the community line. (Of course there is an alternative that nobody does some parts of this, but that is significantly worse). 

The structure I am suggesting inserts the RSAB into the mixture and by doing so both softens the changes to the RPC and spreads the checks and balances. The RSAB takes on the role of advising the RPC on community requirements, priorities, what needs consulting on and who should be consulted. While the RPC still makes the final call, we now have some separation of roles. The requirement for the RPC to inform the RSAB where it goes against its advice ensures transparency and adds another check to the process.  The RSWG/RSAB also take on the role of receiving the reports and are implicitly responsible for addressing the suitability of the reports. The role of the LLC is reduced to contract monitoring and performance management. The LLC doesn’t take on any community role but acts as an escalation point for the RSAB/RWSG. 

Each of these structures envisions a very different RPC.  If can agree which vision of the RPC we prefer then the answers all fall out from that. 

Jay

-- 
Jay Daley
IETF Executive Director

---

From: Michael StJohns <[email-masked]>
Date: Tue, 29 Jun 2021 16:20:51 -0400

On 6/29/2021 2:35 AM, Eliot Lear wrote:
> there is to be such a person, how does that person get appointed and 
> by whom?  The easiest answer is by the IETF Executive Director.  Is 
> that correct? 

If there is a liaison (and I think there probably should be regardless 
of the model), then the appropriate person/entity to select the RPC 
representative is the manager on the RPC side, not the ED.   This goes 
back to the general (US at least) rules for contracts vs employment.  
The ED can tell the RPC what to do (within the bounds of what's written 
in the contract), but mostly not how to do it.  That usually means also 
not directing who does it with exceptions existing such as "key man" 
clauses.  The RPC manager is going to have the best view of who of the 
set of RPC employees should represent the interests of the RPC to the RSAB.

Or to put it a slightly different way, the ED manages the contract not 
the RPC. (And yes we can quibble about what manage means here).

This isn't going to be an appointment, it's going to be an assignment, 
and the RPC management IMHO will/should make that assignment.

Mike

ps - some food for thought on Jay's comment:   The RSE is a selected 
individual with specific qualifications; the RPC is a contracted service 
with a defined SLA.  These are not fungible entities.  That needs to be 
taken into account when attempting to assign duties currently the 
purview of the RSE to the RPC.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2021 11:28:46 +1200

Jay,

> The structure I am suggesting inserts the RSAB into the mixture and by doing so both softens the changes to the RPC and spreads the checks and balances. The RSAB takes on the role of advising the RPC on community requirements, priorities, what needs consulting on and who should be consulted

I think this is reasonable as a high level statement. However, I remain worried that a committee as a whole can't advise an operational unit as a whole. That's a small version of a football crowd advising another football crowd.

So I continue to see a role here for the RSEA as a communicator.

Regards
   Brian Carpenter

On 29-Jun-21 22:16, Jay Daley wrote:
>> Then there is the question of a non-voting liaison from the RPC.  
If there is to be such a person, how does that person get appointed and by whom?  The easiest answer is by the IETF Executive Director.  
Is that correct? 
>>
> To me there are two separate needs here. The IETF Executive Director is 
a liaison to coordinate the overall operational response and ensure that performance targets and priorities are met - that includes RPC, tools, comms etc. 
>>> However, I'm concerned that this last item gives considerable power to the RSAB.  Setting priority is a very good proxy for setting policy.  As stream managers, that is probably fine (hence my suggested tweak), as a 
body, that risks undermining the RSWG process: "the WG decided this, but it's silly, so deprioritize its implementation".
>>
>> This raises questions:
>>
>>  1. Should there be a frequency by which the RPC reports?  If they're frequent enough, then there is no need to make massive shifts without consultation, and we are talking about a pretty focused function (i.e., 
not like an entire government ministry or department).   The only real question is whether the RPC should seek approval/endorsement of its plan.  "Here's what we did, here's how it went, here's what we plan to do over the next XX months/year(s)".
>>  2. Are we are using the RSAB for regular consultations between stream 
managers and the RPC?  In this case, is the RSAB acting as a group or merely being gathered as stream managers?  If the latter, then the 
RSAB has no formal role.  The RPC is always free to consult who they 
want to consult in order to get the job done or to identify issues.  
Right?
> The current structure has an RSE that collects community requirements, engages with the community as needed, interprets those requirements and delivers a prioritised list to the RPC.  The RSE also reports to the community. The RPC certainly picks up plenty of requirements from its engagement with authors but those are fed into the RPC for them to work into 
their plans.  The checks and balances to this process are multiple - 
there is the RSOC overseeing the RSE, the RSE overseeing the RPC and the LLC monitoring both contracts.  The key check here is that the RSE cannot unilaterally decide who they consult and what they consult on. 
>> 2.

---

From: Jay Daley <[email-masked]>
Date: Wed, 30 Jun 2021 11:34:41 +1200

> On 30/06/2021, at 11:28 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Jay,
> 

I was not expecting all 11 members of the RPC to be present for this exchange, just the manager and possibly her deputy.

> So I continue to see a role here for the RSEA as a communicator.

That replaces 

	RSAB -> RPC Manager   with   RSAB -> RSEA -> RPC Manager

I don’t see how that helps anything.  Don’t forget the RSAB includes the RSAB so it is actually  RSAB/RSEA -> RPC Manager.

Jay

> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Tue, 29 Jun 2021 20:19:11 -0400

On 6/29/2021 7:34 PM, Jay Daley wrote:
> I don’t see how that helps anything.  Don’t forget the RSAB includes 
> the RSAB so it is actually  RSAB/RSEA -> RPC Manager.
>
> Jay

Hi Jay -

I think you're missing the point that the RSEA will be "on" much more 
than the RSAB.   The RSAB operates when convened, but, with the 
exception of the RSEA, consists of people stuck with "other duties as 
assigned" - e.g. additional duties mostly not related to their day job 
and probably not going to want to spend a lot of time doing things they 
may not be paid for.

Having the RSEA (*sigh* can we pick one name please?)  be the point 
person for day to day things and bring those things back to the RSAB 
when it convenes to have a discussion seems to me to make a lot more 
sense than direct and persistent management by committee.   I expect the 
RSAB to interpret the strategic direction model as proposed by the RSWG, 
but I would be very surprised if that gives rise to the RSAB meeting 
with the RPC or its representatives as frequently as might be needed by 
the RPC to resolve tactical issues.

Just my $.02. Mike

---

From: Jay Daley <[email-masked]>
Date: Wed, 30 Jun 2021 12:35:45 +1200

> On 30/06/2021, at 12:19 PM, Michael StJohns <[email-masked]> wrote:
> 
> I think you're missing the point that the RSEA will be "on" much more than the RSAB.   The RSAB operates when convened, but, with the exception of the RSEA, consists of people stuck with "other duties as assigned" - e.g. additional duties mostly not related to their day job and probably not going to want to spend a lot of time doing things they may not be paid for.  
> 
> Having the RSEA (*sigh* can we pick one name please?)  be the point person for day to day things and bring those things back to the RSAB when it convenes to have a discussion seems to me to make a lot more sense than direct and persistent management by committee.   I expect the RSAB to interpret the strategic direction model as proposed by the RSWG, but I would be very surprised if that gives rise to the RSAB meeting with the RPC or its representatives as frequently as might be needed by the RPC to resolve tactical issues.
> 
> Just my $.02. Mike
> 
Point taken.  That seems to me to be a good reason to make the RSEA -> RPC Manager another required source of advice etc in addition to other sources (RSAB -> RPC Manager and RSWG -> RPC Manager) but not to replace them as proposed.  Your earlier point about the fungibility of roles however, does lead to a structure more like RSWG -> RSAB -> RSEA - RPC, which we should explore properly.

Whatever we choose, we have to be careful that whatever role we create for the RSEA doesn’t have a distant centre of gravity such that the role is under pressure to change right from the outset.  Some of these proposed changes concern me that is how we are setting it up.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Tue, 29 Jun 2021 21:38:32 -0400

Hi Jay -

On 6/29/2021 8:35 PM, Jay Daley wrote:
> Point taken.  That seems to me to be a good reason to make the RSEA -> 
> RPC Manager another required source of advice etc in addition to other 
> sources (RSAB -> RPC Manager and RSWG -> RPC Manager) but not to 
> replace them as proposed.  Your earlier point about the fungibility of 
> roles however, does lead to a structure more like RSWG -> RSAB -> RSEA 
> - RPC, which we should explore properly.
>
> Whatever we choose, we have to be careful that whatever role we create 
> for the RSEA doesn’t have a distant centre of gravity such that the 
> role is under pressure to change right from the outset.  Some of these 
> proposed changes concern me that is how we are setting it up.

Actually there shouldn't be  RSWG -> RSAB nor RSWG -> RPC.   The RSWG is 
solely a strategic body writing documents that describe the policy of 
the RFC series.  The RSWG's sole and only form of interaction with the 
RPC here should be at the document level.    The interaction with the 
RSAB is more nuanced: the arrow above implies some level of oversight or 
direction that isn't in the model - there's interaction between the two, 
but no directive actions from one to the other:

RSWG --- Doc submission --- > RSAB --- Doc approval  ---> RFC Editorial 
Series Document

RFC Editorial Series --- Policy ---- > RSAB   <--> RPC
                             ^            ^          ^
                             |_____> |_> RSEA <_|

There are both  RSAB -> RPC and RSEA -> RPC relationships, but their 
forms of interaction will be a bit different.  Month to month or quarter 
to quarter vs day to day would be one way to scope it.

If the documents don't answer the policy questions, the RSAB may ask for 
input from the RSWG in forming its advice to the RPC, or could suggest 
the RSWG write a new document, but having the RSWG with a direct path to 
the RPC seems a likely failure mode.

With respect to the RSAB/RSEA and their roles vis a vis the RPC, I'd 
take a look at https://ballotpedia.org/Council-manager_government as I 
think it sort of describes the model I'm thinking of.  It's not exact 
since the RSEA is a full member of the RSAB, but the division of labor 
seems to be more correct than not.

Mike

---

From: Jay Daley <[email-masked]>
Date: Wed, 30 Jun 2021 14:27:41 +1200

Thanks Mike

> On 30/06/2021, at 1:38 PM, Michael StJohns <[email-masked]> wrote:
> 
> Hi Jay -
> 
> Actually there shouldn't be  RSWG -> RSAB nor RSWG -> RPC.   The RSWG is solely a strategic body writing documents that describe the policy of the RFC series.  The RSWG's sole and only form of interaction with the RPC here should be at the document level.    The interaction with the RSAB is more nuanced: the arrow above implies some level of oversight or direction that isn't in the model - there's interaction between the two, but no directive actions from one to the other:

My arrows were only meant to show the flow of requirements and priorities (and advice on those) that the RPC builds its workplan from, not any form of oversight or direction.  

> 
> RSWG --- Doc submission --- > RSAB --- Doc approval  ---> RFC Editorial Series Document
> 
>                             |____________+_> RSEA <_|
> 
> There are both  RSAB -> RPC and RSEA -> RPC relationships, but their forms of interaction will be a bit different.  Month to month or quarter to quarter vs day to day would be one way to scope it.

I concur.

> 
> If the documents don't answer the policy questions, the RSAB may ask for input from the RSWG in forming its advice to the RPC, or could suggest the RSWG write a new document, but having the RSWG with a direct path to the RPC seems a likely failure mode.

Fine by me.  I am very comfortable with your second diagram above (which I’ve fixed up slightly).

> With respect to the RSAB/RSEA and their roles vis a vis the RPC, I'd take a look at https://ballotpedia.org/Council-manager_government as I think it sort of describes the model I'm thinking of.  It's not exact since the RSEA is a full member of the RSAB, but the division of labor seems to be more correct than not.

That seems to me to describe the current IAB/RSOC/RSE/RPC model rather than the new one being proposed.  

My mental image of the new RSEA as defined so far is a floating, independent publishing expert who gets involved in everything related to RFC series policy and policy implementation, reads the lists, talks to people, researches the issues, provides advice widely, produces drafts to stimulate thinking and potentially initiate policy discussions, and communicates what they see/hear/think to the RSWG, RSAB and RPC alike.  This fits closely with your diagram and with the title of RSA.

Crucially though, in the structure proposed so far they have no responsibility.  If they are to be given responsibility, such as a stream manager role or the main communication point for the RPC, then we need to make sure they have the authority to deliver that and there is appropriate accountability in place.  The proposals I’ve seen so far do neither.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Jun 2021 08:18:18 +0200

Sooo....

On 30.06.21 04:27, Jay Daley wrote:
>> forms of interaction will be a bit different.  Month to month or 
>> quarter to quarter vs day to day would be one way to scope it.
>
> I concur.

I *think* this is where we're at:

  * The RSWG establishes policy, with input from the community, the
    RSAB, and the RSEA.
  * The RSAB approves that policy.
  * The RPC periodically reports to the RSAB on how it is implementing
    that policy.
  * The RSEA provides expertise to the RPC and RSAB on how to implement
    the policy on an ongoing and operational basis, perhaps raising
    issues along the way for both the RSAB and community to consider.

If issues arise with particular policies, the RPC still brings them to 
the RSAB who interprets the policy, and provides interim guidance to the 
RPC, informing the RSWG of those interpretations. This is roughly in 
line with what we said re Issue 60 (Resolution of disputes between the 
RPC and authors with cross-stream implications).

This provides the RPC expert advise on an ongoing basis, and direct 
communications to the RSAB.  It does not provide direct commuications 
between the RPC and the RSWG, but reports to the RSAB would be public.

Is this what people want?

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jun 2021 12:15:25 -0400

On 6/30/2021 2:18 AM, Eliot Lear wrote:
> The RSWG establishes policy, with input from the community, the RSAB, 
> and the RSEA.

s/establishes/proposes/ please.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jun 2021 12:19:54 -0400

> s/establishes/proposes/ please.
Or maybe even:

The RSWG drafts policy documentation, with input from the community, the 
RSAB and the RSEA.

The RSAB considers and decides whether to approve such documentation for 
publication in the editorial series.

This makes it clear that the RSAB is not a rubber stamp for the RSWGs 
proposals.

Mike

---

From: Jay Daley <[email-masked]>
Date: Thu, 1 Jul 2021 06:51:43 +1200

wfm

> On 1/07/2021, at 4:19 AM, Michael StJohns <[email-masked]> wrote:
> 
>>> The RSWG establishes policy, with input from the community, the RSAB, and the RSEA.
>> 
> The RSWG drafts policy documentation, with input from the community, the RSAB and the RSEA.
> 
> The RSAB considers and decides whether to approve such documentation for publication in the editorial series.
> 
> 
> This makes it clear that the RSAB is not a rubber stamp for the RSWGs proposals.
> 
> Mike
> 
> 
> -- 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Jun 2021 21:40:06 +0200

Here's the model, slightly tweaked, but the goal is not to wordsmith 
this model, but rather to explain the relationships with the RPC in 
particular (e.g., the first two bullets are really just there for 
completeness; we've covered that ground).  I don't think this text goes 
into the draft.  We need something that is a bit more elaborated.  But 
if people are comfortable with the general approach, then we have a good 
starting point to develop appropriate text.

>   * The RSAB considers those proposals and approves or returns as
>     appropriate.
>   * The RSEA provides expertise to the RPC and RSAB on how to
>     implement the policy on an ongoing and operational basis, perhaps
>     raising issues along the way for both the RSAB and community to
>     consider.
>
> the RSAB who interprets the policy, and provides interim guidance to 
> the RPC, informing the RSWG of those interpretations.
>
Are there people who are generally uncomfortable with the overall 
approach?  Please discuss.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jul 2021 08:57:22 +1200

On 01-Jul-21 07:40, Eliot Lear wrote:
> 
> Here's the model, slightly tweaked, but the goal is not to wordsmith this model, but rather to explain the relationships with the RPC in particular (e.g., the first two bullets are really just there for completeness; we've covered that ground).  I don't think this text goes into the draft.  We need something that is a bit more elaborated.  But if 
people are comfortable with the general approach, then we have a good starting point to develop appropriate text.
> 
>>   * The RSWG establishes policy, with input from the community, the RSAB, and the RSEA.
>>   * The RSAB considers those proposals and approves or returns as appropriate.
that policy.
>>   * The RSEA provides expertise to the RPC and RSAB on how to implement the policy on an ongoing and operational basis, perhaps raising issues along the way for both the RSAB and community to consider.

Yes, I think that position's the RSEA's role nicely (and to my mind, fixes the name as RSA because the RSEA is clearly *not* in authority).

   Brian

>> If issues arise with particular policies, the RPC still brings them to 
the RSAB who interprets the policy, and provides interim guidance to the RPC, informing the RSWG of those interpretations. 
>>
> Are there people who are generally uncomfortable with the overall approach?  Please discuss.
> 
> Eliot
> 
>