You may have heard one referenced during a meeting or maybe you’re an expert who’s been relying on them to move work forward. Whatever the case may be, RFCs are here to stay and there are a number of advantages to adopting an RFC process.
What is an RFC?
The acronym ‘RFC’ stands for Request for Comments. RFCs have quite the history, dating back to the late 1960s in the age of ARPANET, which was a wide-area experimental network connecting hosts and terminal servers together.
As noted by Flavio Copes, “traditionally what we mean with RFC on the Internet is a publication that’s written by engineers and computer scientists, aimed at other professionals that work in the Internet sphere.”
Said another way, an RFC is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet. Sounds a tad complicated, right?
The thing is, this is where the Internet started—with RFCs becoming the starting point of a discussion. As David Stahl notes in his paper, What’s an RFC and what can they do for me?, through the organization known as the Internet Society, designers, engineers, and computer scientists can publish papers or discourses in the form of an RFC, either for peer review or simply to share new concepts, information, or (occasionally) engineering humor.
Why is peer review needed? Just like with a research project at school, it’s always important to get a second opinion. Peer review opens the door to feedback from others on your work, research, or personal ideas, and in this case, by others who are considered to be experts in the same field. The IETF will then go on to adopt some of the proposals published as RFCs as “Internet Standards.”
And as RFCs grew from actual requests for comments via typewriters shared with ARPA researchers to documentation shared via the Internet, they provided a convenient way for distribution of the research, and ended up becoming the “official record of the Internet’s design decisions, architecture, and technical standards.”
To sum it all up? Think of RFCs as official Internet documents of record, which often include very detailed technical information.
Writing a good RFC
Now that we’ve covered the history of RFCs, you may be wondering what it will take to kick one off. And as teams look to reach consensus on topics quickly and efficiently, referring to an RFC outline can help to improve the process.
Inspired by Phil Calçado’s Structured RFC Process, writing a good RFC should be entirely voluntary, though it’s encouraged to write an RFC for any major change. A major change might be:
An addition of any major new feature or subsystem
Change that impacts existing, public APIs. This includes Java APIs, but also things like GFSH commands and externally exposed protocols.
To get started, we suggest drawing inspiration from this template from Calçado’s post. In summary, it’s important to cover the following:
Header: Authors, Review Date, Revisit Date, State
Need (Problem): What is this proposal solving? Why does the problem matter? How does the problem affect the user?
Anti-Goals: What is outside of the scope of what the proposal is trying to accomplish?
Approach (Solution): How will your solution solve the problem? (this is likely the largest section of your proposal)
Competition: What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?
FAQs: Are there any questions you can answer prior to the peer review/feedback loop?
Learning from others
Long gone are the days of typewriters and snail-mail that we mentioned earlier. We’ve gathered a few of the more famous and foundational RFC documents to help you
Stay tuned for Part II in our The History & Applications of RFCs series next week, where we’ll dive into how to build a culture of RFCs at your company, why collaboration is a vital part of the RFC process, and how an asynchronous platform like Threads can set your RFC culture up for success.