[What Is] A Request for Comments (RFC)?

By June 2026, the RFC series crossed number 10,000. 

Number 9971, Multiple Loss Ratio Search, was published in August 2026, and it carries the name of a PANTHEON.tech engineer.

Today we want to talk about what an RFC is, what it does for people involved in networking and how our talented developers landed on the author line of seven of them.

What an RFC actually is

An RFC is a published, permanently archived document with a number. It defines a standard, information or best practice in networking, which has been commented, discussed and revised several times by the IETF.

Steve Crocker wrote RFC 1, Host Software, in April 1969. Crocker had no authority to tell anyone how to build anything, so he went with requesting comments.

The IETF itself started later. Its first meeting ran in January 1986 with 21 attendees. There wasn’t and is no membership. You do not join the IETF, and your employer cannot buy a seat. You subscribe to a mailing list, you argue, and if your argument survives, you get a document.

Before it publishes, a working group, an area director, the IESG and a public last call have all read it 

Who writes RFCs?

RFCs come out of working groups. Each has a charter, mailing list, two chairs and an area director. Groups sit in areas: routing, internet, transport, security, operations and management, applications.

Not every RFC is a standard. The series carries several categories:

• Standards documents define protocols you are expected to come in contact with.
• Informational documents describe methodology, terminology, or practice without commanding anything. Our RFC 9971 sits here.
• Best Current Practice documents established processes and operational conventions. Think MUST, SHOULD and MAY in capital letters.
• Experimental and Historic covers ideas under test, and ideas the community walked away from.

Nobody enforces any of these. The IETF has no inspecting body and issues no certificates. In 2021 the community published RFC 8962, “Establishing the Protocol Police”, purely to state that the protocol police do not exist and never will. 

Their authority comes from the sheer technical background and rounds of approval from the community. RFCs often define technologies that shape the internet, are universally testable and replicable, or set a kind of benchmark for operations. 

There is no average number on how long until a RFC is published. One RFC tried to - RFC 8963 found that an “average RFC in the 2018 sample was produced in 3 years and 4 months”.

25 years of standards work and how PANTHEON.tech got there

At PANTHEON.tech, we are big fans of standards - they make vendor lock-in a thing of the past and make the freedom of choice in networking possible. We are not only contributing to the IETF. Our work in OpenDaylight made its  model-driven architecture, based on IETF standards like YANG models or the RESTCONF protocol.

Building PCEP support in OpenDaylight meant implementing stateful PCE extensions while the extensions were still drafts. Robert Varga, Pantheon Fellow, is a co-author of RFC 8231 and RFC 8232 (2017), RFC 8281 (2017) and RFC 8408 (2018). Modelling network topologies for controllers produced RFC 8345 and RFC 8346 in March 2018. 

Six RFCs on one author page, all of them cited by other RFCs: RFC 8231 alone is referenced by 49 of them.

RFC 9971 came from a different corner: performance testing in FD.io CSIT, where Vratko Polák of PANTHEON.tech worked alongside Cisco's Maciek Konstantynowicz as co-editor. 

The pattern behind all seven documents is the same. Someone wrote code, saw a difference between what the specification said and what the hardware did. Then they’ve spent years arguing the fix into a document that outlives the contract it was written under. 

RFCs worth reading

Let’s start off with some classics. IPv4 in RFC 791. BGP-4 in RFC 4271. TLS 1.3 in RFC 8446. QUIC in RFC 9000. Private address space in RFC 1918, which quietly shaped how every enterprise network on earth is numbered.

For data centers, RFC 7432 for the control plane and RFC 8365 for running it over VXLAN. If you build or operate automation, RFC 6241 (NETCONF) and RFC 7950 (YANG 1.1) are the two you will read more than once. 

After you are done with the serious ones, look up a few April Fools RFCs

RFC 1149, IP over Avian Carriers, appeared on 1 April 1990. It specifies IP datagrams printed on paper and carried by homing pigeon. The joke has a point. A methodology written with enough precision can be implemented by anyone, including people using birds.

RFC 2324, the Hyper Text Coffee Pot Control Protocol, came out in April 1998 and gave the world HTTP status 418, "I'm a teapot", which real libraries still ship.

Why RFCs matter today

If you are building a product on top of a moving target, the question worth asking is whether the draft is stable enough to ship against, and who you talk to when it changes. EVPN gives you a 2015 specification with a decade of running code behind it. A working-group draft at version 03 gives you neither.

This is why standardization matters. Open networking starts with open standards, which give you the freedom to choose, switch or combine vendor solutions. All of this to avoid being locked to one forever.

RFCs offer a place for technical, constructive, albeit time-consuming discourse, which documents and shapes technologies for years ahead. They are the encyclopedia of the way the internet works, or is expected to work.

And PANTHEON.tech is glad to be part of it.

You can contact us at https://pantheon.tech/contact/

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.