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

From: "Martin Thomson" <[email-masked]>
Date: Mon, 05 Jul 2021 12:24:18 +1000

On Thu, Jul 1, 2021, at 02:15, Michael StJohns wrote:
> 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.

I respectfully disagree.  The goal of this process is to seat the authority in the community, which means RSWG establishes policy.  The purpose of the RSAB being only to ensure that the outcome is not unreasonable.

I find the "with input from the community" a bit odd in Eliot's phrasing.  The goal is to - to the extent possible - have RSWG == community, with the usual caveat that it is more like RSWG \self-selected-subset-of community.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 5 Jul 2021 13:31:04 +0900

On 2021-07-01 05:57, Brian E Carpenter wrote:
> 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.
>>>    * 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.
> 
> 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).

I'm somewhat worried here. While I agree with Martin Thomson (see 
separate mail) that it's the RSWG that establishes policy, I think it's 
important to mention that the RS[EA...] not only provides expertise on 
how to implement policy, but also on potential new policies, including 
proposing new policies by themselves. "perhaps raising issues" may have 
been written to include that, but in my view, it's quite weak.

Regards,   Martin.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Jul 2021 16:52:05 +1200

On 05-Jul-21 16:31, Martin J. Dürst 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

> been written to include that, but in my view, it's quite weak.

That text isn't the primary part of the RSEA's job description, though.
I thought it was OK in the context of this part of the draft.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 5 Jul 2021 11:37:29 +0200

> I respectfully disagree.  The goal of this process is to seat the authority in the community, which means RSWG establishes policy.  The purpose of the RSAB being only to ensure that the outcome is…

Again, we're not relitigating the roles here.  This is just a matter of 
establishing the relationships relating to RPC.  Don't worry about word 
smithing at this point.  I didn't intend that text to go into the draft 
verbatim, but to be the basis of our understanding of those 
relationships so that text could be written.

> I find the "with input from the community" a bit odd in Eliot's phrasing.  The goal is to - to the extent possible - have RSWG == community, with the usual caveat that it is more like RSWG \self-se…

Actually so did I, in retrospect, for the precise reasons you state.

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 9 Jul 2021 15:21:48 -0600

> I thought it was OK in the context of this part of the draft.

Additionally, anyone (including the RSEA) can propose policy changes in
the RSWG. But for the avoidance of doubt we could say:

* The RSEA provides expert advice to the RPC and RSAB on how to
  implement established policies on an ongoing and operational basis,
  which can include raising issues or initiating proposed policy changes
  within the RSWG.

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jul 2021 16:43:04 +1200

wfm

Regards
   Brian Carpenter

On 10-Jul-21 09:21, Peter Saint-Andre wrote:
>>>> 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).

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 12 Jul 2021 13:08:30 +0900

Looks good to me, too.   Regards,   Martin.

---

From: Jay Daley <[email-masked]>
Date: Wed, 28 Jul 2021 10:48:08 +1200

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.  

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.

### 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
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Wed, 28 Jul 2021 10:50:25 +1200

The heading ### Relationship between the RPC and the IETF LLC is also an addition.

> On 28/07/2021, at 10:48 AM, Jay Daley <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 28 Jul 2021 17:51:19 +0900

Hello Jay, others,

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

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

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.

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

So I think we need to clarify the relationship between RSWG consensus 
documents, LLC performance targets, and RPC work program.

Regards,   Martin.

---

From: Jay Daley <[email-masked]>
Date: Thu, 29 Jul 2021 07:52:22 +1200

Mrtin

> On 28/07/2021, at 8:51 PM, Martin J. Dürst <[email-masked]> wrote:
> 
> Hello Jay, others,
> 
> 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
> 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.

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

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.

Jay

> 
> So I think we need to clarify the relationship between RSWG consensus documents, LLC performance targets, and RPC work program.
> 
> Regards,   Martin.
> 
> 

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2021 14:56:45 -0600

[ no hats ]

Overall this looks good. One question below.

On 7/27/21 4:48 PM, 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.
> 
> 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>
> 
> 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.
> 
> 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.
> 
> * 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.

One could envision challenges here along several dimensions:

1. Timeline. When does the RPC publish its proposed work program? How
long is the comment period? How long does the RPC take to consider the
feedback and publish a final work program?

2. Feedback. Does the RPC need to merely take feedback under advisement
or are they under any obligation to address it? What is "agreed
feedback"? If a community member feels that they're being ignored, would
they raise concerns with the LLC?

Peter