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

[Jay Daley <[e-mail]>]

> On 17/08/2021, at 8:52 AM, Brian E Carpenter <[e-mail]> wrote:
> 
>> I’m still slightly concerned that we are over-specifying this in the RFC.
> 
> I'm more than slightly concerned. Obviously there should be a work plan,
> and if there isn't, the contract manager (i.e. the LLC) should complain.
> Management 101, so why should we bikeshed the details in an RFC?
> 
> Personally I'd remove most of the detailed text quoted below, or rather,
> move it to the actual contract between the LLC and the contractor.

I think that’s inconsistent with the level of specification in the rest of this RFC but consistent with others that cover the LLC.  If the group chooses to go that way, then I would suggest that there are some general requirements set in this document to ensure that someone in the future doesn’t do away with things the community feels is important.

Some examples:

- the RPC/LLC is expected to implement any and all RFCs that come from the RSWG
- the priorities of the RPC must reflect those of the community
- the RPC priorities and plans are public and consulted on
- no constraints on how the RPC communicates with the community or vice-versa

Jay

> 
> Regards
>   Brian
> 
> On 17-Aug-21 00:14, Mirja Kuehlewind wrote:
>> Hi Jay, hi all,
>> 
>> Replying to this original mail. The additional text is helpful to better explain what is meant by work program.
>> 
>> I’m still slightly concerned that we are over-specifying this in the RFC. I think the process as described is fine, but writing it down in an RFC means we can't easily change anything in future if we see room or need for optimisation.
>> 
>> However, if other people feel it’s important to have it in this 
> level of details in this RFC, the text looks fine for me.
>> 
>> Three small comments/questions below.
>> 
>> 
>>> On 28. Jul 2021, at 00:48, Jay Daley <[e-mail]> wrote:
>>> 
>>> Eliot asked me to propose some additional text to close off issues #56, #57, #61, #62 which I’ve done below.  It doesn’t have the elegance of Peter’s prose so may require some work to align with that.
>>> 
>>> Much of this is already covered in the latest draft at:
>>> 
>>> 	https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab-rfcefdp-rfced-model.md#roles-and-processes
>>> 
>>> My suggested additions are in red and my suggested text moves are in blue.  
>>> 
>>> Jay
>>> 
>>> —— 
>>> 
>>> ## Role of the RPC
>>> 
>>> Publication of RFCs shall be continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies currently in force or yet to be defined following the processes specified in the foregoing sections of this document.
>>> 
>>> ### RPC work program
>>> 
>>> The RPC follows a work program based on requirements it has gathered from a variety of sources, including policies that have been through the RSWG/RSAB process, and from direct discussions with the RSEA, stream managers, IETF LLC, authors and other IETF participants.  In developing this work program, the RPC makes some key decisions which impact the IETF community:
>>> 
>>> 1.  For each requirement that is gathered, can it be directly incorporated into the work program or must it first be subject to community consultation.
>>> 
>>> 2.  Setting the relative priorities for the various requirements within the work program.
>>> 
>>> 3.  Determining if all the important requirements have been gathered.
>>> 
>>> It is likely that the RPC will require advice during the drafting of its work program, which it should seek from at least the RSAB and if required, the chairs of the RSWG.
>> 
>> Why are the chairs or the RSWG mentioned here? I guess the RPC is free to ask anybody for advise they want but the main contact point for me would be the RSAB (given it includes the stream managers).
>> 
>>> 
>>> In order to ensure community oversight of the RPC work program:
>>> 
>>> * The RPC must present a draft work program for community feedback at least annually and then publish a final work program incorporating any agreed feedback.
>> 
>> How and with whom is the feedback agreed?
>> 
>>> 
>>> * The RPC shall report regularly to the RSAB, RSWG, and broader community regarding the contents and progress of its work program and any key risks or issues affecting it.
>> 
>> How does the RPC report to the broader community. Isn’t it enough to report to RSWG? 
>> 
>>> 
>>> 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.
>>> 
>>> All matters of budget, timetable and impact on its performance targets, are between the RPC and IETF LLC.
>>> 
>>> ### Relationship between the RPC and the IETF LLC
>>> 
>>> This document does not specify the exact relationship between the IETF 
> LLC and the RPC function; for example, the RPC function could be provided 
> by a separate corporate entity under contract to the IETF LLC, it could be performed by employees of the IETF LLC, or the IETF LLC could work with 
> independent contractors for some or all aspects of the RPC function. The exact relationship is a matter for the IETF LLC and the IETF Executive Director to determine.
>>> 
>>> The IETF LLC has authority over negotiating performance targets for the RPC and also has responsibility for ensuring that those targets are adhered to. The IETF LLC is empowered to appoint a manager or to convene a committee to complete these activities.
>>> 
>>> Community members who have concerns about the performance of the RPC can request that the IETF LLC look into the matter. Even if the IETF LLC opts to delegate this activity, concerns should be raised with the IETF LLC. The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter.
>>> 
>>> —— 
>>> 
>>> -- 
>>> Jay Daley
>>> IETF Executive Director
>>> [e-mail]
>>> 
>>> -- 
>>> Rfced-future mailing list
>>> [e-mail]
>>> https://www.iab.org/mailman/listinfo/rfced-future
>> 
> 

-- 
Jay Daley
IETF Executive Director
[e-mail]