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

[Jay Daley <[e-mail]>]

(Resending from the correct address)

> On 24/08/2021, at 11:09 PM, Mirja Kuehlewind <[e-mail]> wrote:
> 
> Some quick comments below.
> 
>> On 24. Aug 2021, at 12:54, Lars Eggert <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> some initial reactions based on a first read.
>> 
>>> On 2021-8-24, at 12:20, Mirja Kuehlewind <[e-mail]> wrote:
>>> # Roles and Processes
>>> 
>>> ## RFC Production Center (RPC)
>>> 
>>> Publication of RFCs shall continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies that have been
>>> specified through the RSWG/RSAB process as well as based on advice from direct discussions with the RSEA, stream managers, IETF LLC, authors and other community memberss in cases where the implementation of a policy is not clear or not sufficient.
>> 
>> Why include "authors and other community members" here? I can understand why the RPC would consult with the other bodies/roles listed, since they have defined roles in terms of setting policy and may hence be able to offer additional guidance. But acting based on advice from authors and/or otherwise unidentified community members seems unmotivated?
> 
> I took this from the original proposed text from Jay. I agree that listing "RSEA, stream managers, IETF LLC” here should be sufficient. However, I let Jay reply if he had more specific cases in mind.

This text has merged text I didn’t write with text I did write and now has quite a different meaning from what I intended. 

My text mentioned “ direct discussions with the RSEA, stream managers, IETF LLC, authors and other community members” in the context of the requirements for the work program not the  policies. In other words - the RPC should be open to saying “we had this great suggestion from X to improve Y that we plan to implement”. 

The phrase “high level policies” originally appeared in a different context:

> 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.


This was followed by my text below, which I think is still the best way to explain this, it’s the detail following that needs changing not this text. 

> 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.


Jay
-- 
Jay Daley
IETF Executive Director

> 
>> 
>>> The RPC shall proactively implement the policies specified by the RSWG/RSAB process reflecting the priorities of the community.
>> 
>> Is "proactively" a no-op filler word, in which case it could just be removed, or is it supposed to convey some meaning, e.g., that the RPC shall implement policies while they are still in the process of being defined (or some other meaning)?
> 
> Maybe. The intention was to make it clear that this sentence does say something else/more than the previous sentence, in that the RPC in that the RPC should not only follow set policy but also actively plan for implementation of procedural changed based on new policies. I guess “proactively” is not really the right word. Maybe just “actively” or “plan to implement”?
> 
>> 
>>> The RPC shall report regularly to the RSAB, RSWG, and broader community regarding their plan and time line for implementation as well as any key risks or issues affecting it.
>> 
>> No issues with a report to the community, obviously.
>> 
>>> The RPC is expected to revise their plan based on community input if concern regarding the  implementation plan or priorities of work are raised. In case of conflicting requirements from the community, the RPC shall consult with the RSAB.
>> 
>> But this sentence turns the reporting into a discussion, and the RPC is asked to somehow judge community consensus on its operation, and then act on that. Part of the problem here is that "the community" is pretty undefined. I could maybe see this working if the RPC was asked to take input from the RSWG that the chairs have declared consensus on into account. That would also allow for managing input that overlaps with areas the LLC is responsible for. I find the open model defined above too unclear.
> 
> I don’t think that what this text says. My understanding of the desired process is that the RPC should provide a plan, ask for feedback, and then might provide a revised plan. So the RPC keeps the authority about the plan and it’s probably more the LLC that will finally accept the plan or not. So if at all it’s the LLC board that has to consider consensus.
> 
> This text on purpose only describes expectations and not requirements because it’s on the LLC how to handle it in details. However, my impression of the feedback from the group was that people find it important to note that there is an expectation that the community is consulted.
> 
> Is there anything we can or should say to clarify this text?
> 
> 
>> 
>>> This document does not constrain how the RPC and the community communicate with each other. 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.
>>> 
>>> If individuals or groups within the community have concerns about the performance of the RPC, they 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.
>> 
>> Thanks,
>> Lars
>> 
>> 
>> 
>> 
>> -- 
>> Rfced-future mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/rfced-future