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

> On 23/06/2021, at 1:43 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Wed, Jun 23, 2021, at 11:14, Jay Daley wrote:
>> ## RFC Production Center
>> 
>> The RFC Production Center (RPC) shall develop and maintain a work 
>> 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...
> 
> This should be item 1:
> 
>> All matters of budget, timetable and impact on its performance 
>> targets, are between the RPC and IETF LLC.
> 
> Item 2:
> 
>> 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. 
> 
> Item 3:
> 
>> 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.
> 
> Item 4:
> 
> 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.
> 
> 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".

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

> 
> -- 
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
> 

-- 
Jay Daley
IETF Executive Director
jay@ietf.org