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

From: Martin J. Dürst <[email-masked]>
Date: Mon, 16 Aug 2021 14:35:09 +0900

Hello Jay, others,

I'm very sorry it took me over two weeks for an answer,

On 2021-07-29 04:52, Jay Daley wrote:
> Mrtin
> 
>> On 28/07/2021, at 8:51 PM, Martin J. Dürst <[email-masked]> wrote:
>>
>> Hello Jay, others,
>>
>> On 2021-07-28 07:48, Jay Daley 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 <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.
>>
>> Sorry, but please avoid using colors for such distinctions. I usually view all my mail as plain text, and I think there are quite a few others on this list who do so, too. I switched to HTML view just for this mail, but I'd prefer to avoid this.
>>
>>> 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.
>>> 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.
>>> * 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.
>>> 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.
>>
>> I have difficulties to see how "work program" and "performance targets" are related. The above description lets them look quite independent, but if that's the case, things won't work out very well. The work program may look very nice, but because it's not part of the performance targets, it may get ignored. If the work program is just a matter between RSAB/RSWG and RPC, without involving the LLC, it may be dead on arrival.
> 
> By definition, the role of the RPC is to follow the RFCs that define the role of the RPC and so if there is an RFC that says they must have a work program and consult on it then that is part of their role.  The LLC is responsible for ensuring that the RPC follows its defined role and so, again by definition, the LLC will ensure that the RPC has a work program and follows it.  I don’t think we need to say anything about this explicitly but I would not object to in principle to any text that makes that explicit.

I think it would be helpful to have something like a definition of "work 
program" that makes clear that it's subsidiary to the RFCs, the contract 
with the LLC, and the performance targets. So what about:

The work program lays out in some detail how and in what timeframe the 
RPC plans to execute its work to implement applicable RFCs, execute the 
contract with the LLC, and achieve its performance targets.

An alternative text (taking into account the discussion below) would be:

The work program lays out in some detail how and in what timeframe the 
RPC plans to execute its work to implement new work defined in 
applicable RFCs, separate from the RPC's day-to-day publishing activity 
to meet its performance targets.

>>
>> Also, the terms "work program" and "performance targets" suggest different stuff. Under "work program", I could imagine stuff similar to past items such as introducing DOIs and ISSNs; under "performance targets", I'd imagine "number of RFCs published", "number of RFC pages published", "average delay between some defined states in the editing pipeline", and so on.
> 
> That’s spot on.

It's good if I got that right. But I'd prefer not having to read between 
the lines, and I guess some others also have the same preference.

> The RPC needs to balance what resources it puts into the work program and what it puts into day-to-day work to ensure that its performance targets are met.  As per the text, that balance and the key factors that affect it - budget, timetable and impact on performance - are between the RPC and LLC.
> 
>>
>> Also, all this "work program" stuff seems to somehow be at odds with the process that we are currently working on. To take a past example, let's say the RSWG creates a document that says that RFCs should have DOIs. That document is approved by the RSWG (and published as an RFC), and thus supposed to represent community consensus. But if we follow the above points, it looks like everything might have to be rehashed or regurgitated for the "work program".
> 
> In that scenario the document simply becomes an action on the work plan and the only decision for the RPC is how to prioritise it.  There’s no text that gives the RPC any leeway to rehash or regurgitate.  Again I don’t see a need to say anything about this explicitly but I would not object to in principle to any text that makes that explicit.

My two proposed text variants are attempts to make the relationship 
between the relevant RFCs, the work program, and the performance targets 
more explicit. I'm sure they can be improved, but something like one of 
these would be very helpful to have in the document.

Regards,   Martin.

> Jay
> 
>>
>> So I think we need to clarify the relationship between RSWG consensus documents, LLC performance targets, and RPC work program.
>>
>> Regards,   Martin.
>>
>>
>>> ### 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.
>>
>>
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 16 Aug 2021 14:14:36 +0200

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 <[email-masked]> wrote:
> 
> 	https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab-rfcefdp-rfced-model.md#roles-and-processes
> 

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

> * 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? 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Aug 2021 08:52:38 +1200

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

Regards
   Brian

On 17-Aug-21 00:14, Mirja Kuehlewind wrote:
> 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.
>> 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.

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 17 Aug 2021 09:07:36 +0900

Hello everybody,

> move it to the actual contract between the LLC and the contractor.

I would be fine with that. In that case, it's those people's 
responsibility to make clear how the various parts are related. I think 
my concern was created because the work program and the RFCs were in the 
same document.

Regards,   Martin.

---

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

> On 17/08/2021, at 8:52 AM, Brian E Carpenter <[email-masked]> wrote:
> 

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Aug 2021 17:02:18 +1200

On 17-Aug-21 16:31, Jay Daley wrote:
> 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.
> - no constraints on how the RPC communicates with the community or vice-versa

Yes. I think in general we should be asserting general principles like that
(and perhaps we need a critical pass over the next version of the draft,
looking for any cases where we are micro-managing by RFC.)

Rgds
   Brian

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 17 Aug 2021 09:58:09 +0200

That sounds good to me.

> On 17. Aug 2021, at 06:31, Jay Daley <[email-masked]> wrote:
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Aug 2021 14:14:12 +0200

Ok.

I think where we are on this issue is that some would like to see LESS 
detail about how the work programme is managed.  Jay has made the point 
below about stating the high level principles to be adhered.  Can I ask 
Mirja and Brian perhaps to work together to come up with whatever 
substitute text they think the right level should be?

We can then discuss and perhaps wordsmith this at the interim next week.

Eliot

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 24 Aug 2021 11:20:20 +0200

Brian and I have been working on some text proposal. This text is mainly based on the current text in the draft and Jay’s proposal for requirements but avoids the term work program. Here it is:

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

The RPC shall proactively implement the policies specified by the RSWG/RSAB process reflecting the priorities of the community. 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. 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.

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.

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

> On 19. Aug 2021, at 14:14, Eliot Lear <[email-masked]> wrote:
> 
> Ok.
> 
> I think where we are on this issue is that some would like to see LESS detail about how the work programme is managed.  Jay has made the point below about stating the high level principles to be adhered.  Can I ask Mirja and Brian perhaps to work together to come up with whatever substitute text they think the right level should be?
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Aug 2021 12:01:11 +0200

Mirja and Brian,

Thanks very much for this.  Could people comment?  We'll also talk about 
this at our interim.

Eliot

---

From: Lars Eggert <[email-masked]>
Date: Tue, 24 Aug 2021 13:54:35 +0300

Hi,

some initial reactions based on a first read.

> 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 implemen…

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?

> 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)?

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

> be raised with the IETF LLC. The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter.

Thanks,
Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 24 Aug 2021 13:08:51 +0200

Some quick comments below.

> On 24. Aug 2021, at 12:54, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 

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.

> 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 proce…

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”?

> 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 comm…

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?

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Aug 2021 12:11:44 +0100

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

Yeah, heaven forfend we should involve the community in any discussions :-Z

Example 1: What is the correct expansion of an abbreviation? Surely the
authors or experts in the community are best placed to give advice to the
RPC.

Example 2: What did you intend this paragraph to say? Surely the authors
would answer this.

Note: The text does not say that policies will be set by the authors and
community, but that, "Publication of RFCs shall continue [...] based on
advice from direct discussions with the [...] authors and other community
members..."
I agree that the punctuation of the sentence could give rise to ambiguity.

Cheers,
Adrian

---

From: Jay Daley <[email-masked]>
Date: Tue, 24 Aug 2021 23:52:12 +1200

(Resending from the correct address)

> On 24/08/2021, at 11:09 PM, Mirja Kuehlewind <[email-masked]> wrote:
> 

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

> 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 processe…

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 24 Aug 2021 14:03:49 +0200

See inline.

> On 24. Aug 2021, at 13:52, Jay Daley <[email-masked]> wrote:
> 

Yes, you are right. I combined these sentences and this got scrambled.

> 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 o…

I wouldn’t call this a requirement though. As long as this idea doesn’t violate any policy or would require a new policy, I don’t see a reason why the RPC cannot just improve their processes (independent of the fact where the idea came from). Not sure we need to say anything about that in this document though.

>> 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 th…

This is the part that I tried to remove because it talks about a “work program” without defining what that is intended to imply. 

Mirja

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Aug 2021 14:29:26 +0200

Ok.

<no hats>

I have, perhaps poorly, attempted to piece together what I think is 
roughly what we're all talking about.  I may have entirely gotten this 
wrong, and so please nitpick.  There is one sentence in brackets that I 
think is redundant.  I have not really touched the relationship text.

Eliot

# Roles and Processes

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.  [[The RPC shall implement 
the policies specified by the RSWG/RSAB process reflecting the 
priorities of the community.]] They shall report regularly to and 
consult with the RSAB, RSWG, and broader community regarding status of 
work undertaken and plans for work to be done, including timeline for 
implementation as well as any key risks they identify.  In doing so, the 
RPC will observe the principle of transparency. The RPC shall consult 
with the RSAB for advice on how to resolve any conflicts that arise from 
community input.

All matters of budget, timetable and impact on its performance targets, 
are between the RPC and 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.

--------

---

From: Lars Eggert <[email-masked]>
Date: Tue, 24 Aug 2021 15:33:37 +0300

Hi,

On 2021-8-24, at 15:29, Eliot Lear <[email-masked]> wrote:
> I have, perhaps poorly, attempted to piece together what I think is roughly what we're all talking about.  I may have entirely gotten this wrong, and so please nitpick.  There is one sentence in brackets that I think is redundant.  I have not really touched the relationship text.
> 
> Eliot
> 
> # Roles and Processes

<snip>

this would work for me, with or without the sentence in brackets.

Thanks,
Lars

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Aug 2021 11:25:56 -0400

I think that the bracketed sentence should e deleted.

It seems to require that once the RSWG / RSAB have approved a policy, 
the RPC must implement it.  Even if it costs money and the LLC has not 
yet allocated the funds.  That would seem to put them in a very 
difficult position.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Aug 2021 11:33:20 -0400

Joel,

While the phrasing may be wrong for the reason you identify, the
sentence is probably a useful statement of intent.

This is a question because I'm not sure, but I wonder if, rather
than removing the sentence, it would be useful to add a few
qualifying words such as "resources permitting", "in
coordination with the LLC about resources", or something like
that.

best,
   john

--On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> It seems to require that once the RSWG / RSAB have approved a
> policy, the RPC must implement it.  Even if it costs money and
> the LLC has not yet allocated the funds.  That would seem to
> put them in a very difficult position.
> 
> Yours,
> Joel
> 
>> I have, perhaps poorly, attempted to piece together what I
>> think is  roughly what we're all talking about.  I may have
>> entirely gotten this  wrong, and so please nitpick.  There
>> is one sentence in brackets that I  think is redundant.  I
>> have not really touched the relationship text.
>> 
>> Eliot
>> 
>> # Roles and Processes
>> 
>> 
>> 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.  [[The RPC shall implement  the policies
>> specified by the RSWG/RSAB process reflecting the  priorities
>> of the community.]] They shall report regularly to and 
>> consult with the RSAB, RSWG, and broader community regarding
>> status of  work undertaken and plans for work to be done,
>> including timeline for  implementation as well as any key
>> risks they identify.  In doing so, the  RPC will observe the
>> principle of transparency. The RPC shall consult  with the
>> RSAB for advice on how to resolve any conflicts that arise
>> from  community input.
>> 
>> 
>> All matters of budget, timetable and impact on its
>> performance targets,  are between the RPC and 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.
>> 
>> --------
>> 
>> 
>> 
>> 
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Aug 2021 11:49:45 -0400

I could live with "in coordination with the LLC about resources".

Part of my thought on removing it is that we already have text that says 
that the RSWG / RSAB sets strategic policy.  Not sure what this adds.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Aug 2021 12:14:00 -0400

--On Tuesday, August 24, 2021 11:49 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> Part of my thought on removing it is that we already have text
> that says that the RSWG / RSAB sets strategic policy.  Not
> sure what this adds.

it depends on how much we feel is required to be specified.  My
general bias is that we are specifying far too many details.
Instead, we should be laying out general roles and principles,
trusting people to Do the Right Thing, and being sure there is
effective accountability if, for whatever reason (certainly
including ones whose specifics we can't anticipate) they do not.
On that basis, I think we would be better off dropping this
sentence (and many more).  

However, I am clearly in the rough about that approach and even
trying to express some of its implications has gotten me into
trouble.  Within the context of the current approach and
document, some words about the RPC's obligations to implement
strategic policy set by the other bodies seems perfectly
reasonable.

best,
   john

---

From: Michael StJohns <[email-masked]>
Date: Tue, 24 Aug 2021 13:32:58 -0400

Hi -

Unfortunately I can't live with the paragraph in general, even with the 
various changes.   Basically, this section still reads as if there is a 
oversight, monitoring, or directive relationship between the 
RSWG/RSAB/community and the RPC.  It also does a poor job of describing 
the relationship between the RPC and the RSAB and RSCE for the advisory 
purposes.

So instead:

Publication of RFCs shall continue to be handled by the RFC Production  
Center (RPC) function in accordance with policies described in the 
Editorial series of RFCs, and consistent with the engagement 
agreement(s) between the RPC and the LLC.

  * The LLC is requested to negotiate a deliverable with the RPC that
    results in regular updates to the community regarding status of work
    undertaken, planned work,  implementation timelines, and any
    identified risks to those timelines.

  * The LLC is requested to negotiate a task with the RPC that permits
    and requires the RPC to collaborate in at least an advisory capacity
    in the content creation of the Editorial series RFCs as they affect
    the RPC and that collaboration is expected to be the main path for
    community input into the RPC processes.

The RPC shall consult  with the RSAB generally and the RSCE specifically 
for advice on how to resolve any conflicts that arise between the RSWG 
proposed documents, the Editorial series,  the RPC's existing engagement 
agreement's scope, and any technical or cost limitations for 
implementing the Editorial series policies, and if necessary, shall 
refer any issues unresolved after such consultation to the LLC or the 
IED for final resolution.

## Relationship between the RPC and the RSAB or RSWG

Neither the RSAB nor the RSWG has any oversight, monitoring, or 
directive relationship with respect to the RPC.  The RSAB and RSCE have 
an advisory relationship with the RPC as described above.

-30-

Mike

On 8/24/2021 11:49 AM, Joel M. Halpern wrote:
> Part of my thought on removing it is that we already have text that 
> says that the RSWG / RSAB sets strategic policy.  Not sure what this 
> adds.
>
> Yours,
> Joel
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Aug 2021 11:13:18 -0700

On Tue, Aug 24, 2021 at 10:33 AM Michael StJohns <[email-masked]>
wrote:

> RSWG/RSAB/community and the RPC.  It also does a poor job of describing the
> relationship between the RPC and the RSAB and RSCE for the advisory
> purposes.
>
> So instead:
>
> Editorial series of RFCs, and consistent with the engagement agreement(s)
> between the RPC and the LLC.
>
>    - The LLC is requested to negotiate a deliverable with the RPC that
>    undertaken, planned work,  implementation timelines, and any identified
>    risks to those timelines.
>
>
>    - The LLC is requested to negotiate a task with the RPC that permits
>    and requires the RPC to collaborate in at least an advisory capacity in the
>    content creation of the Editorial series RFCs as they affect the RPC and
>    that collaboration is expected to be the main path for community input into
>    the RPC processes.
>
>
> agreement's scope, and any technical or cost limitations for implementing
> the Editorial series policies, and if necessary,  shall refer any issues
> unresolved after such consultation to the LLC or the IED for final
> resolution.
>
> Neither the RSAB nor the RSWG has any oversight, monitoring, or directive
> relationship with respect to the RPC.  The RSAB and RSCE have an advisory
> relationship with the RPC as described above.
>

This seems incorrect to me just as a matter of fact. When the RSWG and RSAB
publish an RFC describing how the RPC ought to behave, then this is in fact
directive.

-Ekr

> <[email-masked]> <[email-masked]> wrote:
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 24 Aug 2021 14:34:27 -0400

On 8/24/2021 2:13 PM, Eric Rescorla wrote:
>     directive relationship with respect to the RPC.  The RSAB and RSCE
>     have an advisory relationship with the RPC as described above.
>
>
> This seems incorrect to me just as a matter of fact. When the RSWG and 
> RSAB publish an RFC describing how the RPC ought to behave, then this 
> is in fact directive.
>
> -Ekr
>
I believe you're missing the difference between the noun "directive" 
(e.g. the RFC is a policy directive which describes the operation of the 
RPC) which has the meaning:

"an official or authoritative instruction".

And the adjective "directive" (e.g. the RSWG has no directive 
relationship with the RPC) which has the meaning:

"involving the management or guidance of operations" -

To put it another way, your state executive or legislature may issue a 
directive (or a law) with respect to the wearing of masks, but the state 
does not have a directive relationship with you unless you actually work 
for the state.   I am personally subject to 1000s of directives of 
various forms, but since I work for myself, I am not the subject of a 
directive relationship in the meaning above.

I believe we've agreed that the RSAB and RSWG don't get to directly tell 
the RPC or the RSCE what to do - e.g. they may NOT direct either of 
those entities to perform specific work - all they can do is publish the 
RFCs and then ask the LLC to craft a contract or engagement agreement 
reflecting those RFCs.

Later, Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Aug 2021 11:38:38 -0700

On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns <[email-masked]>
wrote:

> RSAB publish an RFC describing how the RPC ought to behave, then this is in
> fact directive.
>
> -Ekr
>
> I believe you're missing the difference between the noun "directive" (e.g.
> the RFC is a policy directive which describes the operation of the RPC)
> which has the meaning:
>
> And the adjective "directive" (e.g. the RSWG has no directive relationship
> with the RPC) which has the meaning:
>
> for the state.   I am personally subject to 1000s of directives of various
> forms, but since I work for myself, I am not the subject of a directive
> relationship in the meaning above.
>

It seems to me that if we are having to refer to this kind of
dictionary-based interpretation, then a rewrite is in order.

> the RPC or the RSCE what to do - e.g. they may NOT direct either of those
> entities to perform specific work - all they can do is publish the RFCs and
> then ask the LLC to craft a contract or engagement agreement reflecting
> those RFCs.
>
I think you're drawing too sharp a distinction.

Suppose that the RSAWG were to publish an RFC saying that heretoforth
authors should be listed in alphabetical order. I would expect the RPC to
comply with that without some new contractual term from the LLC. Do you
disagree?

-Ekr

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 24 Aug 2021 15:32:59 -0400

On 8/24/2021 2:38 PM, Eric Rescorla wrote:
>
>
> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>         Neither the RSAB nor the RSWG has any oversight, monitoring,
>>         or directive relationship with respect to the RPC.  The RSAB
>>         and RSCE have an advisory relationship with the RPC as
>>         described above.
>>
>>
>>     This seems incorrect to me just as a matter of fact. When the
>>     RSWG and RSAB publish an RFC describing how the RPC ought to
>>     behave, then this is in fact directive.
>>
>>     -Ekr
>>
>     I believe you're missing the difference between the noun
>     "directive" (e.g. the RFC is a policy directive which describes
>     the operation of the RPC) which has the meaning:
>
>     To put it another way, your state executive or legislature may
>     issue a directive (or a law) with respect to the wearing of masks,
>     but the state does not have a directive relationship with you
>     unless you actually work for the state.   I am personally subject
>     to 1000s of directives of various forms, but since I work for
>     myself, I am not the subject of a directive relationship in the
>     meaning above.
>
>

I referred to a dictionary only for your convenience.  But "directive" 
in conjunction with "relationship"  is the appropriate term here.  I 
guess you could use governing, or  control as replacements with some 
work, but those aren't as clear.

>
>     I believe we've agreed that the RSAB and RSWG don't get to
>     directly tell the RPC or the RSCE what to do - e.g. they may NOT
>     direct either of those entities to perform specific work - all
>     they can do is publish the RFCs and then ask the LLC to craft a
>     contract or engagement agreement reflecting those RFCs.
>
> authors should be listed in alphabetical order. I would expect the RPC 
> to comply with that without some new contractual term from the LLC. Do 
> you disagree?

The other section has this:

> Production  Center (RPC) function in accordance with policies 
> described in the Editorial series of RFCs, and consistent with the 
> engagement agreement(s) between the RPC and the LLC.

Assuming that the change in the RFC's does not require a change in the 
costs, or impose more work and where the change is consistent with the 
agreement between the RPC and the LLC, then there is no requirement to 
change the contract.   And actually, if this requires a tooling change 
(not saying it will, but who knows), it might require LLC approval to 
spend the money so... it may not be a contract change, but it may 
require LLC (or IED) buy in.  That seems something that a) the RPC would 
hopefully bring up during the RFC creation, b) the LLC would analyze 
before RFC approval, and c) the LLC would be proactive in working with 
the RPC to implement the new RFC policies.   Or d) the LLC would say - 
we're not payinf for this.

The counter example is that you write a new RFC that says that the RPC 
shall maintain a GIT instance tracking all of the changes made between 
submission and publication of an RFC candidate and that wasn't part of 
the contract, then yes it requires a change.

So the general answer to the more general question: "Will Editorial 
stream RFCs published by RSAB/RSWG require contract changes to the RPC?" 
is "It depends" which I think you probably already knew.

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2021 15:02:50 +1200

> coordination with the LLC about resources", or something like

Yes. The concern behind the sentence (with or without "proactively")
was to ensure that an agreed policy does get transformed into action.
But definitely, that might require resources that the LLC has to
provide.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2021 15:15:26 +1200

Front posting for cause:

I think Mike's concern about Eliot's text derives from the way it starts.
So I'd suggest:

OLD:
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.  [[The RPC shall implement the policies specified by the RSWG/RSAB process reflecting the priorities of the community.]]

NEW:
Publication of RFCs shall continue to be handled by the RFC Production Center (RPC) function under direction from the IETF LLC, in accordance with 
high-level policies that have been specified through the RSWG/RSAB process, and subject to the IETF LLC providing the necessary resources.

I wouldn't want to lose the text that discusses the RPC consulting directly with and reporting directly to the community.

Regards
   Brian Carpenter

On 25-Aug-21 07:32, Michael StJohns wrote:
>> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.  The RSAB and RSCE have an advisory relationship with the RPC as described above.
>>>
>>>
>>>     This seems incorrect to me just as a matter of fact. When the RSWG and RSAB publish an RFC describing how the RPC ought to behave, then this is in fact directive.
>>>
>>>     -Ekr
>>>
>>     I believe you're missing the difference between the noun "directive" (e.g. the RFC is a policy directive which describes the operation of the RPC) which has the meaning:
>>
>>     And the adjective "directive" (e.g. the RSWG has no directive relationship with the RPC) which has the meaning:
>>
>>     To put it another way, your state executive or legislature may issue a directive (or a law) with respect to the wearing of masks, but the state does not have a directive relationship with you unless you actually work for the state.   I am personally subject to 1000s of directives of various forms, but since I work for myself, I am not the subject 
of a directive relationship in the meaning above.
>>
>>
>> It seems to me that if we are having to refer to this kind of dictionary-based interpretation, then a rewrite is in order.
> 
> I referred to a dictionary only for your convenience.  But "directive" in conjunction with "relationship"  is the appropriate term here.  I guess you could use governing, or  control as replacements with some work, but those aren't as clear.
> 
>>
>>     I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish the RFCs and then ask the LLC to craft a contract or engagement agreement reflecting those RFCs.
>>
>> Suppose that the RSAWG were to publish an RFC saying that heretoforth authors should be listed in alphabetical order. I would expect the RPC to 
comply with that without some new contractual term from the LLC. Do you disagree?
>> Publication of RFCs shall continue to be handled by the RFC Production  Center (RPC) function in accordance with policies described in the 
> 
> Assuming that the change in the RFC's does not require a change in the costs, or impose more work and where the change is consistent with the agreement between the RPC and the LLC, then there is no requirement to change the contract.   And actually, if this requires a tooling change (not saying it will, but who knows), it might require LLC approval to 
spend the money so... it may not be a contract change, but it may require 
LLC (or IED) buy in.  That seems something that a) the RPC would hopefully bring up during the RFC creation, b) the LLC would analyze before RFC approval, and c) the LLC would be proactive in working with the RPC to implement the new RFC policies.   Or d) the LLC would say - we're not payinf for this.
> 
> The counter example is that you write a new RFC that says that the RPC shall maintain a GIT instance tracking all of the changes made between submission and publication of an RFC candidate and that wasn't part of the contract, then yes it requires a change.
> 
> So the general answer to the more general question: "Will Editorial stream RFCs published by RSAB/RSWG require contract changes to the RPC?" is "It depends" which I think you probably already knew.
> 
> Later, Mike
> 
> 
> 
>>
>> -Ekr
>>
>>     Later, Mike
>>
>>
>>
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Aug 2021 06:46:42 +0200

Just one point below:

> I wouldn't want to lose the text that discusses the RPC consulting directly with and reporting directly to the community.

We say that slightly differently- instead of reporting to the community, 
providing reports to the community.

Eliot

> (

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2021 17:28:48 +1200

>> Publication of RFCs shall continue to be handled by the RFC Production 
Center (RPC) function in accordance with high-level policies that have been
>> Publication of RFCs shall continue to be handled by the RFC Production 
Center (RPC) function under direction from the IETF LLC, in accordance with
> providing reports to the community.

Indeed. I momentarily forgot the distortion of meaning of the phrase
"report to" to mean "grovel and obey" in HR land.

    Brian

>>>>      I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish 
the RFCs and then ask the LLC to craft a contract or engagement agreement 
reflecting those RFCs.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 25 Aug 2021 16:38:03 -0400

> I think Mike's concern about Eliot's text derives from the way it starts.

Hi Brian -

If I thought that was the problem I would have provided changes to your 
text rather than new text.  I'm too lazy to write if I don't have to.

WRT to your text, I really need it to not link the RPC with the 
RSWG/RSAB and instead link it to the documents.  While this group has 
finally gotten the point that the RPC does not "report to" those groups, 
nor can those groups command the RPC, what I'm afraid of is 3-5 years 
down the road where someone uses the text to justify the RSWG giving 
operational directions to the RPC.

I also want to get the point made that the RPC works with the RSWG as it 
tries to form strategic policy and that the RSWG is the primary place 
for the RPC interaction rather than - as your text seems to imply - the 
RPC is responsible for interacting with all comer directly on matters of 
strategy.

None of the above is meant to imply that the RPC doesn't work with 
authors on their documents - but that's not the thrust of the text you 
and Mirja crafted and I think is handled elsewhere?  If not, a simple 
line that indicates that set of interactions would be useful.

The RPC has both a role in the strategic process (e.g. sanity checks on 
whether things will work, or the costs of doing new things as specified 
by the Editorial series - e.g. with the RSWG), and the tactical process 
(publishing documents while adhering to the aforesaid Editorial series 
documents - with the RSCE and RSAB I would expect).  Those need to be 
teased apart and specified separately and the RPC interaction with the 
community on strategy ideally given a single specified place to happen.  
That will help both the LLC and RPC scope the tasking required to 
support the strategic process.

By the way - I'm not sure how you would have come to the conclusion you 
came given the text I wrote.  Could you explain how you got there?

Thanks, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Aug 2021 10:33:54 +1200

> came given the text I wrote.  Could you explain how you got there?

Simply because the thrust of your text was to say that the line of
command was policy --> IETF LLC --> RPC and Eliot's text seemed
to dilute that. Whereas yours seemed to emphasise that and dilute
the RPC's ability to interact widely with the community as well as
with authors. (I don't dispute that RSWG is the *primary* place
for such interaction.)

   Brian

---

From: Michael StJohns <[email-masked]>
Date: Wed, 25 Aug 2021 19:10:28 -0400

> with authors. (I don't dispute that RSWG is the *primary* place

Actually, the line of authority is more generally:

Community -> RSWG -> RSAB ->  Editorial Series -> RPC and LLC -> RPC.   
Both of the "->" indicators pointing to the RPC are constrained by the 
terms of the engagement agreement.   There's also   RSAB - advise when 
requested -> RPC.

I phrased it as I did because there's a large difference between an 
ability and a requirement.   The following has "They shall report ... to 
and consult with ... the broader community regarding...".   Which 
implies a requirement that RPC engages with the community on the 
strategic stuff outside of the RSWG.   Maybe I'm parsing this too 
tightly, but the RSWG (and the RSWG mailing list for sure) is the place 
where the community gets to engage this process and specifying them as 
separate entities in this instance (not generally), muddies the water 
for this specific partner.

I guess I don't understand what RPC ability you think I removed?   Maybe 
you could describe a scenario which is prohibited by my text?

> They shall report regularly to and
> risks they identify.

Then there is this clause:

> The LLC is requested to negotiate a task with the RPC that permits and 
> requires the RPC to collaborate in at least an advisory capacity in 
> the content creation of the Editorial series RFCs as they affect the 
> RPC and that collaboration is expected to be the main path for 

Which enhances the *ability* of the RPC to participate in the RFC series 
process discussions as a partner rather than as a supplicant or 
afterthought.

Thanks for the response! Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Aug 2021 11:21:29 +1200

Front posting to say that I could in fact live either with Mike's text
or with Eliot's as amended. I think that we are really trying to say
the same thing and it's a question of which is clearest.

Regards
   Brian

---

From: IETF Executive Director <[email-masked]>
Date: Thu, 26 Aug 2021 12:13:43 +1200

From my reading of all of this, we are trying to encode the following separate things but each set of suggested text so far only identifies a subset of these:

# externalities that affect the RPC

- the RPC is *instructed by* RFCs (not the RSAB/RSWG)

- the RPC is *advised by* the RSAB and has a duty to ask for that advice under specific circumstances

- the RPC is *contractually overseen by* the LLC to ensure that it delivers

# RPC behaviours

- the RPC *participates* in the creation of new RFCs, at least in an advisory capacity

- the RPC *reports* to the community on its performance and plans

- the RPC *consults* with the community on its plans

- the RPC *negotiates* its resources with the LLC

Perhaps if we could agree this list we could then turn it into text?

Jay

> On 26/08/2021, at 11:21 AM, Brian E Carpenter <[email-masked]> wrote:
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Aug 2021 15:24:13 +1200

Good analysis. 

Regards
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Aug 2021 06:34:18 +0200

Thanks, Jay.  I'll add that I have no particular allegiance to the text 
that Brian called "Eliot's text."

What I do think is important is that we level the text correctly.  That 
means addressing sufficient detail so that everyone is clear on roles 
and general responsibilities, but stopping at the point where the detail 
does not add normative value or overly constrains the role.

There is, I think, some art to that; which is why we may be struggling a 
bit on which wording we like.  On the call, it may be useful to start 
with Jay's text below to see if the principles are agreeable, and then 
see how we proceed on text.  We can live edit a bit, but only if we can 
reasonably agree on a starting point to see how we cover those principles.

Eliot

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 26 Aug 2021 16:26:24 +0900

Hello Mirja, others,

Sorry to be late with my comments. Some may already be obsolete in case 
we move to new text, but some text pieces have been kept in other 
proposals, so comments on these may still be relevant.

> Brian and I have been working on some text proposal. This text is mainly based on the current text in the draft and Jay’s proposal for requirements but avoids the term work program. Here it is:

It's fine to avoid the term "work program". I can't complain now, 
because I was the one who complained about "work program".

But actually, I wasn't complaining about the term itself, but because it 
was unclear from the text what the relation ship between (strategy) RFCs 
and the "work program" was. The text below is fine in this regards, but 
would be fine with the word "work program", too. So if somebody is 
attached to that work, I'm not opposed to go back to it.

> 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 implemen…

"Publication of RFCs shall continue to be handled": This looks great for 
now, but remember that we are trying to create an RFC that reads good 
even in a few years. So I would change this to "Publication of RFCs is 
handled". That way, the text will be good as long as it's in force.

"RFC Production Center (RPC) function": The text below sometimes has 
"RPC", and sometimes "RPC function". Is there a distinction? If yes, 
what's the difference?

> The RPC shall proactively implement the policies specified by the RSWG/RSAB process reflecting the priorities of the community. 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.

These two sentences make it very clear that the policies are at the top, 
and the 'plan' is for implementing these policies, i.e. subordinate.

Regards,   Martin.