An RFC Document As Part Of Software Development

Hiraq Citra M
lifefunk
Published in
3 min readMay 25, 2023
Source: https://www.ietf.org/proceedings/63/slides/newcomer-0/sld34.htm

Table of Contents

What is RFC (Request for Comments)?
History of RFC
Some examples of RFC document structures
RFC Statuses
Outro

What is RFC (Request for Comments)?

I’ve found now that some startup tech companies have implemented a RFC(Request for Comments) or a Design Docor just a Proposalas a part of their software development processes.

An RFC actually is a document with clearly defined structures, used to describe some technical plans or an architecture or an engineering standard.

The document is normally used to write down the technical plans (for software engineering) and gather all feedback, once it’s approved by defined approvers, it means, all approvers agreed to implement the solution proposed from the document.

An RFC document sometimes will be useful for writing down a plan for complexity issues, non-trivial problems that need to be solved, or discussing some engineering standards.

This is a good example of implementation:

Although I’m not a Rust programmer, I think it is a good example of RFC implementation.

History of RFC

Taken from Wikipedia

The inception of the RFC format occurred in 1969 as part of the seminal ARPANET project. Today, it is the official publication channel for the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB), and — to some extent — the global community of computer network researchers in general.

The authors of the first RFCs typewrote their work and circulated hard copies among the ARPA researchers. Unlike the modern RFCs, many of the early RFCs were actual Requests for Comments and were titled as such to avoid sounding too declarative and to encourage discussion.

The RFC leaves questions open and is written in a less formal style. This less formal style is now typical of Internet Draft documents, the precursor step before being approved as an RFC.

In December 1969, researchers began distributing new RFCs via the newly operational ARPANET. RFC 1, titled “Host Software”, was written by Steve Crocker of the University of California, Los Angeles (UCLA), and published on April 7, 1969.

Although written by Steve Crocker, the RFC emerged from an early working group discussion between Steve Crocker, Steve Carr, and Jeff Rulifson.

Famous RFC Examples

Some examples of RFC document structures

Google

  • Context and scope
  • Goals and non-goals
  • The actual design
  • System-context diagram
  • APIs
  • Data storage
  • Code and pseudo-code
  • Degree of constraint
  • Alternatives considered
  • Cross-cutting concerns

Uber

  • List of approvers
  • Abstract (what is the project about?)
  • Architecture changes
  • Service SLAs
  • Service dependencies
  • Load & performance testing
  • Multi data-center concerns
  • Security considerations
  • Testing & rollout
  • Metrics & monitoring
  • Customer support considerations

RFC Statuses

It’s common to have statuses for each RFC document to give its readers, and other people the progress of it.

Common statuses

  • WIP: As it’s named, the document is still in progress, maybe the author still finding some references or may still building the diagram, etc
  • Ready (or Ready to Review or Ready for Comments): It means the document was finished and ready to gather feedback
  • Implemented: It means currently proposed approaches from the current RFC document have been implemented somewhere
  • Closed: Current RFC document was no longer active
  • Abandoned / Cancelled: As it’s named, the current RFC document has been canceled due to some reason

Outro

RFC will not be useful for discussing some trivial issues or something that can be done by anyone with some sort of time.

But if you need to solve some non-trivial issue, you need to draw a diagram first, and need to gather feedback, and discuss it, then RFC will be really useful and worth it to implement.

--

--