Subject: [Rfced-future] What do we need/want?

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 Apr 2020 15:40:25 +1100

I appreciate Brian's attempt to avoid blame in trying to look for problems.

I think that we also need to ask what this community needs and wants from this function.  Maybe that's a little out of scope, but I think that it matters a great deal.

https://iaoc.ietf.org/documents/RSE-descr-2016-r6-Clean.pdf contains a recent statement of work.  RFC 8728 defines what the RFC editor *is*.  Plus the other stuff Eliot shared.  But in terms of the structure in which the function sits, what is truly important?

In terms of over-arching goals, I have heard "good enough to support the series for another 50 years if the content is up to snuff", paraphrasing Stephen (hopefully accurately), which might be good as an abstract mission statement, even if it is a bit of a mouthful.  That last clause about the quality of content does a lot more work than I'd like there as well.  This does imply some unspecified strategic decisions; you don't have a hope of operating on that timescale without a lot of forethought.

Worrying about a legacy over very long periods is not worth the effort that might be expended on it.  You could examine the system we have - one that clearly exhibits survivor bias - with the hope that you might learn something relevant, but we could instead concentrate on doing the best we can over periods that are more relevant.  5 years is a solid length of time to plan for, if not 10-15.

The other meta-goal I routinely hear "keep the RFCs coming".  That might lead to ignoring or downplaying the challenges we might need to anticipate.  I happen to think that this is highly relevant, if not the totality of the overall goal.  The format change has not been good in that regard.  I had a simple, standalone document that was relatively time-sensitive sit in queue for almost 4 months after approval.  At the other extreme, I also have another document that is still being processed after almost 4 years in queue.  My understanding is that the RSE is responsible for anticipating and working to avoid systemic or structural problems of that nature.  To use the words the RSOC used: that's an important, but tactical function.

To me, the series exists to serve a community of people who benefit from creating a record of their agreements (and disagreements if you like).  That we use a bespoke and user-hostile format is not a feature, but a bug.  That we depend on extensive and expensive copy-editing is more bug than feature, as much as I appreciate the improved quality of the result.  That we insist on these artifacts being immutable is a bug.  And many other things that I'm sure will elicit much disagreement.  However, those are not important characteristics of the series; the content - and often the agreements that the content codifies - is what matters.  And besides that, those questions aren't in scope for this effort.

Our goal is to work out how we might designate responsibility for leadership on those - and other matters - to a role that fits within our organizational structure.  Again, I'm tempted to ignore that scope and ask why we need that leadership to be so delegated, but I will try to keep on target.

We have, for the longest time, had a single figurehead to shepherd those aspects of the series that matter least. I don't see any editorial control being exercised over content, with the exception of the Independent Submissions Stream, where ISE discretion is the entire purpose of the stream.  What has been achieved there in to my knowledge has been largely tactical.  Yes, it matters that we have DOIs on documents and that we can use real names, those are changes with long-term value.  Archival agreements and rescuing data from old bits of paper is similarly good, but not really strategic. Assigning responsibility to anticipate and address problems like that is important, but it does not require someone with the stature of previous RSEs.

Meanwhile, valuable content continues to be published in RFCs.  And other SDOs produce work with far less pomp and circumstance.  So while we have created a role to which great gravitas has accrued, maybe we don't need that and a little more employee and less venerated elder is in order.  For the leadership part, maybe we should look to the community.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Apr 2020 10:00:10 +0200

Hi Martin

Thanks for your well thought-out message.  Two points below.

> On 2 Apr 2020, at 06:40, Martin Thomson <[email-masked]> wrote:
> 
> https://iaoc.ietf.org/documents/RSE-descr-2016-r6-Clean.pdf contains a recent statement of work.

I have added this to the suggested reading list.  It’s good to read because it make it quite concrete as to what was being asked of the RFC Editor at that point in time.  People can use it to think about which items in the SoW should be under the purview of the RSE, which are missing, which should be under someone else’s remit, and which takes shouldn’t be performed at all.

As to the rest of your message, it outlines your vision and your concerns, and that in turn drives a point of view as to how the role needs to be structured.  And so I don’t find the message to be at all out of scope for this group but rather well worth the read, even if one disagrees with your point of view.

Eliot