Re: [hrpc] The relevance of RFCs // was: Possible options for a HRPC research publication

[Paul Wouters <[e-mail]>]

On Mon, 13 Apr 2020, Niels ten Oever wrote:

> In discussions here and on other mailinglists, some have criticized the format of I-D and RFCs, the workings of the datatracker, the slightly archaic nature of mailinglists and other tools that we use. I, however, would like to shortly note how important I-D's, RFC's, mailinglists, and the datatracker have been in my research, my involvement in this field, and how extraordinary it is that it is possible to find documents, notes, and presentations going back to 1969. While there is indeed a learning curve, the reward for traveling that curve is access to a huge wealth of highly consistent information in a very structured archive.

Indeed! It is a very useful thing to have, although it would be nice to
get an easier overview or browing capability per WG. Navigating through
a few years of meetings link for a WG can be tedious.

> In many different kinds of organizations it is hardly possible to find documents from just a few years back, let alone finding them in the same format and context. This is true for NGOs, universities, private corporations, governance bodies, and sadly also governments.

I'm glad to see IETF is doing well compared to others here.

> Furthermore, RFC's for me embody a relational understanding of infrastructure that combines hardware, software, and wetware, or in the vernacular of another field: technological materiality, institutional ordering, economic drivers, and epistemic communities. For me, this is an important argument to keep on using RFCs and I-Ds (and by extension also mailinglists and the datatrackers), to keep this practice alive, by testing and expanding it with new, and sometimes relevant, contributions.

I ran into this myself when evaluating WireGuard. There is basically
an ever changing implementation with no history, no static reference,
a "whitepaper" that is not a specification, and an ever changing
implementation that is the only reference on how parts of the protocol
are supposed to work. It is the antithesis of protocol development.

Paul