Subject: [Rfced-future] A few thoughts on problem definition

From: Alissa Cooper <[email-masked]>
Date: Wed, 22 Apr 2020 15:36:46 -0400

Hi Eliot, all,

I have a few thoughts to offer below about problems to be solved. In general I do not plan to engage much in this program but figured I would throw these out there during the problem definition phase in case they resonate with anyone else who does plan to engage more.

There has been mention of the absence of both a strategy for the RFC series and a process to create one. Together with that, but worthy of its own emphasis I think, is the absence of a process for determining how well the series is meeting its objectives and serving the wide variety of audiences it is intended to serve. There are so many different communities that make use of RFCs — implementers, operators, architects, researchers, students, product managers, procurement officers, regulators, other SDOs, etc. As far as I’m aware there is no body of knowledge about how these audiences use RFCs and no established and rigorous method for understanding the role of RFCs in the world. This makes it difficult to make informed decisions about the future of the series and to measure the impact of changes to it. Having a wholistic picture isn’t impossible but we don’t have it now.

Given that lack of information, my next point is admittedly based on intuition: it seems like it should be much easier to understand the contours of the series as a reader than it is today. For example, the 3D matrix of streams, maturity levels, and routes to publication yields numerous combinations where the subleties matter but are likely lost on anyone who hasn’t been an active IETF participant for a very long time. The fact that RFCs are (quasi-)officially hosted in at least three places on the web and the path for someone to discover the document they’re looking for could land them in any of these places (without any data collection on the RSE/IETF side to really know) means that different readers of the same document have different user experiences and access to different representations of document metadata. There is no coherent, consistent, and readily available experience to help readers understand the context and process that produced a given RFC they may be reading.

The series also lacks a sound technology change management process. We are into the seventh year of the transition from format v2 to v3, I believe. Some of that time was spent on IETF-style consensus processes, and we all know those are not time-bound, and some of that time was spent on other things. For decisions that are essentially choices about what technology RFC readers and writers will use, though, using a change process that is unbounded in time doesn’t make a lot of sense, because the pace of technological change is rapid. Technology choices made three or five or seven years ago could be out-of-date before they even get implemented. Somehow, there needs to be a way to be able to manage change in the underlying technologies that are used to produce and consume RFCs that combines solicitation of input from interested parties with the ability to evolve in time frames consistent with technological change.

These three problems come to mind in part because they speak to some competencies that would be good to have at hand if attempts were to be made at solving them: market research, communications, data analysis, user experience/design, program management. They also demonstrate the extent to which the management of the RFC series straddles basically every function that already exists to support the IETF itself: community consensus processes, tools, IT, admin, communications, finance. It creates a challenging situation to have a function that is operationally deeply intertwined with all of these other functions, but conceptually meant to exist basically independent from them.  

Alissa

---

From: Larry Masinter <[email-masked]>
Date: Wed, 22 Apr 2020 15:42:57 -0700

> ...                            There are so many different communities that make
> use of RFCs — implementers, operators, architects, researchers, students,
> product managers, procurement officers, regulators, other SDOs, etc. As far
> as I’m aware there is no body of knowledge about how these audiences use
> RFCs and no established and rigorous method for understanding the role of
> RFCs in the world. 

But there IS a body of knowledge about standards in general and
technical specifications and their quality and utility. There are
courses on it. Books about it. Courses on standards in engineering
curricula. Papers about it*

While there might be some reasons why IETF processes are different
from those of other SDOs, the RFC series has to exist in the context
of an evolving non-RFC environment.
--
* https://docs.google.com/document/d/1aEaOvS3rKret7IwyYeawL8rCby8b7erNEZTYXclDBbU/edit?usp=sharing 
https://LarryMasinter.net  https://going-remote.info

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Apr 2020 09:49:05 +0200

Alissa,

Thank you for these comments.  I have adjusted the summary I am keeping on GitHub at https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md accordingly.

Eliot

> On 22 Apr 2020, at 21:36, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Eliot, all,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2020 11:36:58 +1200

Thanks for the summary record, Eliot. It's useful. I do want to comment on one item:

> Focus on the role; Don't focus on what we want the series to be - a great many people

Certainly the RSE role is the immediate problem. But as I said earlier, the lack of an agreed high level charter/mission/strategy for the RFC series actively hampers us in defining the role. It's as if the job ad said "Wanted: a senior, experienced person to run an operation whose mission is to do the right thing." I exaggerate to make my point, but there is a real gap here (and not a new one).

Regards
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Apr 2020 08:04:55 +0200

Good evening, Brian.

> On 24 Apr 2020, at 01:36, Brian E Carpenter <[email-masked]> wrote:
> 

Two points:

To be clear, these were points others made and I captured.  I may have overstated them slightly in my summary (the hazards of summaries).
I believe we have enough discussion points that it may be time to go through each of them in a bit more detail.  I’ll write more about that in a follow-up message.

Eliot