What Is an RFC? How Internet Standards Get Written

What is an RFC, and who decides what goes into one? I asked myself that the first time I stood at a microphone in an IETF meeting room, sure I’d get something wrong. I’d read Request for Comments documents for years by then. I had implemented parts of a few, cursed at the ambiguity in others, and quoted section numbers in vendor disputes. But reading a standard and helping write one are different jobs. A quiet room of a hundred and fifty engineers waiting to hear your argument teaches you that fast.

Years later, after serving as a working group chair, I still hear that same question more than any other from clients, procurement teams, and new engineers. Is an RFC a law? A suggestion? A product spec? Why do vendors brag about being “RFC compliant” when nobody seems to agree on what that means?

This article is my answer. It comes from inside the process, and I’ve tried to stay honest about how messy, slow, and surprisingly human the whole thing is.

What Is an RFC, in Plain Terms

An RFC is a numbered document in an archival series that records the technical and organizational work of the Internet’s engineering community. Most people meet RFCs as protocol specifications. RFCs define TCP, DNS, HTTP, TLS, email, and IPv6. TechTarget sums it up well: an RFC is a formal IETF document that holds specifications and organizational notes on Internet and networking topics.

That covers the definition. The more useful answer is that an RFC is a snapshot of agreement. Each one captures the point where a group of people, often from competing companies, settled on how something should work and agreed to write it down permanently.

And “permanently” matters. Once the RFC Editor publishes an RFC, nobody touches its text again. Not a comma. If someone finds a mistake, they file an erratum. If the protocol needs real revision, the community writes a new RFC that either “updates” or “obsoletes” the old one. TCP shows how this works. The original specification, RFC 793, served for four decades until RFC 9293 replaced it in 2022. The RFC Editor’s info page for RFC 9293 lists its status as Internet Standard and shows which older RFCs it obsoletes and updates.

So when someone tells me a product “supports RFC such and such,” I first check whether that RFC still stands or whether something newer has replaced it. You’d be surprised how often it has.

Why Is It Called a “Request for Comments”?

The name is a historical accident that stuck. The series began in 1969, during the early ARPANET work. Steve Crocker wrote RFC 1, titled “Host Software,” and dated it April 7, 1969. The graduate students and researchers involved worried about sounding like they were issuing orders. So they framed their notes as requests for comments.

The early documents really did ask open questions. Their authors chose that title on purpose to sound less declarative and to invite discussion.

The tone changed as the network grew, but the name didn’t. Today a standards track RFC has survived years of review, several rounds of formal approval, and careful editorial polish. It isn’t asking for your comments anymore. The name is a bit of humility the community never let go of, and I’m glad. It reminds every author that a document is only as good as the scrutiny it survived.

Jon Postel shaped much of that early culture. He served as RFC Editor for nearly three decades. When he died in 1998, the community published his obituary as RFC 2468. That tells you how engineers see the series: as their own record of themselves, people included.

Who Actually Writes RFCs?

Most outsiders get the IETF wrong right here. The IETF has no membership. You pay no dues, join no voting bloc, and your company holds no reserved seat. You participate as an individual, and you participate by showing up on mailing lists, reading drafts, and sending comments.

The IETF’s own newcomer guide, the Tao of IETF, describes the organization as a loosely self organized group of people who contribute to the engineering and evolution of Internet technologies.

In practice, standards come from engineers at network operators, cloud providers, browser makers, hardware vendors, universities, and a scattering of independent consultants. Your employer may pay for your travel. But when you stand at the mic, the community expects you to speak for yourself and your technical judgment, not for your company’s marketing department. People notice quickly when someone forgets this, and that person loses credibility that takes a long time to rebuild.

Working Groups, Areas, and the IESG

The IETF organizes its work into working groups. Each one has a charter that spells out what it may and may not work on, plus one or more chairs. Working groups sit inside larger areas such as Security, Routing (home of protocols like BGP), Transport, or Applications and Real Time. Area Directors oversee each area, and together they form the Internet Engineering Steering Group, the IESG.

As a chair, I didn’t write the documents. I ran the process fairly, kept the discussion moving, judged consensus, and protected the group from the loudest voice in the room. Sometimes that loudest voice was technically right. Often it wasn’t. Telling the difference was most of the work.

How Internet Standards Get Written: The Real Lifecycle

Here’s the path a specification takes, from someone’s idea to a published RFC. I’ll describe it the way I’ve lived it, not just the way the process documents describe it.

Step 1: Someone Writes an Internet Draft

Everything starts as an Internet Draft. Anyone can submit one. Nobody guards the gate at this stage, so the drafts repository holds brilliant work right next to ideas that will never go anywhere.

Internet Drafts are temporary on purpose. A draft expires after 185 days unless its authors post a revision. That expiry date creates a quiet pressure. I’ve watched promising drafts lapse because their authors changed jobs or lost interest. I’ve also watched authors post a new revision every five months for years, keeping an idea alive until the industry caught up with it.

Every newcomer should learn one rule early: an Internet Draft is a work in progress. It isn’t a standard, and vendor datasheets make a classic mistake when they cite one as if it were. If a product claims to “implement the standard” and the linked document is a draft, read that claim very carefully.

Step 2: The Working Group Considers Adoption

If a draft fits a working group’s charter, the authors can ask the group to adopt it. Adoption means the working group takes ownership. From that point on, the group’s consensus drives changes to the document, not the authors’ preferences. The authors become editors.

This is often the first real fight. People argue about whether the problem deserves solving, whether this draft makes the right starting point, and whether a competing draft should go first. RFC 7221 states the rule plainly: adopting a draft and making substantive changes to it both require working group rough consensus.

When I ran adoption calls, I asked a simple question on the mailing list: Should the group solve this problem, and does this draft give us a reasonable place to start? I always asked people to explain their answer. A string of “+1” replies tells a chair very little. A short paragraph explaining why someone would implement it tells you a lot.

Step 3: Iteration, Argument, and Running Code

This phase lasts the longest by far, and it’s where the real engineering happens. Editors revise the draft, sometimes dozens of times. Participants file issues and debate them on the mailing list, and increasingly in GitHub repositories. Chairs schedule interim meetings. People build prototypes and bring the results to interoperability events, which the IETF calls hackathons.

You’ll hear the phrase “rough consensus and running code” constantly. It isn’t a slogan for posters. It means that a document backed by two independent implementations that actually talk to each other carries far more weight than a beautifully argued position paper with no code behind it.

Some of my favorite moments as a chair came from this phase. Once, a heated three week thread about an encoding choice ended almost instantly when someone posted interop results showing that one option broke on real hardware. Nobody had to win the argument. The data settled it.

Step 4: Judging Rough Consensus

People misunderstand IETF consensus more than any other part of the process. It isn’t voting. It isn’t unanimity either. It’s the chair’s judgment that the group has considered every serious objection, and that the group either addressed the remaining objections or decided they don’t justify blocking progress.

Pete Resnick’s RFC 7282 offers the best explanation I know. He argues that a chair can declare rough consensus once the group has truly considered an objector’s technical issue and made an informed decision about it. He also makes a point I’ve repeated to every new chair I’ve mentored: a lack of disagreement matters more than agreement.

Humming, Mailing Lists, and Hard Calls

That distinction changes how you run a room. You don’t count hands. You ask whether anyone holds an objection the group hasn’t heard. Sometimes you hum, which sounds silly until you’ve done it. A hum lets a room show the strength of its feeling without singling anyone out. A loud hum for option A and a few scattered hums for option B gives you useful information. Then you take it back to the mailing list, because a decision made only in a meeting room excludes everyone who couldn’t travel.

The hardest consensus calls I ever made involved a respected expert objecting while the room went the other way. You have to take the objection seriously, write down why the group moved past it, and stand ready to defend that call if someone appeals it. And yes, people do appeal. Appeals help keep the system honest.

Step 5: Working Group Last Call

When the editors and chairs think a document is ready, the chairs issue a Working Group Last Call. This formal window, usually around two weeks, gives the group a final chance to raise issues. Many of the most important reviews happen here, because people who ignored the draft for two years suddenly realize it’s about to ship.

After the group resolves its Last Call issues, a document shepherd, often one of the chairs, writes a report for the IESG. It covers the document’s history, how strong the consensus was, whether anyone has implemented it, whether anyone filed intellectual property disclosures, and whether anything controversial is lurking. Writing that report forces honesty. If you can’t explain clearly why the group agrees, the group probably doesn’t.

Step 6: Area Director Review and IETF Last Call

The responsible Area Director reviews the document next. Sometimes they send it back with a long list of comments. Once satisfied, they request an IETF Last Call, which opens the document to the entire IETF community, not just the working group. Reviewers from directorates in security, operations, internationalization, and other specialties weigh in at this point.

This step catches problems a focused working group can miss. Routing experts designing a transport protocol might overlook a congestion control issue. Application developers designing a data format might miss its privacy implications. Every RFC must include a Security Considerations section, and IETF Last Call exposes the weak ones.

Step 7: IESG Evaluation

The full IESG then ballots on the document. Each Area Director can enter a position, and the one that gets everyone’s attention is DISCUSS. A DISCUSS blocks the document and says, in effect, “we need to talk about this before it goes out.” The editors and the Area Director holding the DISCUSS work it out, sometimes in a day, sometimes over months.

I’ve watched documents sail through IESG review and I’ve watched others sit there so long they needed a new revision for unrelated reasons. Neither outcome says much about the quality of the work. It says a lot about how well the group anticipated concerns from other areas.

Step 8: The RFC Editor Queue and AUTH48

Once the IESG approves a document, it moves to the RFC Production Center. Editors there copyedit the text, check references, coordinate registry actions with IANA, and format everything. Near the end comes AUTH48, the authors’ final review. Every author has to sign off on the final text, and this is the last chance to fix anything before the words freeze forever.

Take AUTH48 seriously. I learned this the hard way when I spotted a confusing sentence in a document I had helped edit, only after it went out. It’s still there. It will always be there. Errata exist for real technical errors, not for wishing you had written something more clearly.

Then the RFC Editor assigns a number and publishes the RFC. At that moment the draft name disappears and the number becomes the thing everyone cites.

Not Every RFC Is a Standard

This point trips up procurement teams constantly. An RFC number does not mean “Internet standard.” The series includes several kinds of documents, and the status label at the top tells you which one you’re reading.

The Two Levels of the Standards Track

The standards track itself has two levels. RFC 6410, published in 2011, simplified the old three step ladder down to two steps: Proposed Standard and Internet Standard. It folded away the old middle level, Draft Standard, partly because people kept confusing it with Internet Drafts.

RFC 6410 also admitted something most insiders already knew: the vast majority of standards track documents stay at Proposed Standard and never advance. So don’t dismiss a Proposed Standard as unfinished. A huge share of the protocols your business depends on every day sit at that level and always will.

Other Document Types and Streams

Outside the standards track you’ll find several other categories.

• Best Current Practice (BCP): Operational guidance and the IETF’s own process rules. RFC 2026, which describes the standards process itself, forms part of BCP 9.
• Informational: Useful documentation that isn’t a standard. This can include descriptions of proprietary protocols, architecture overviews, or explanations of how something works.
• Experimental: Ideas worth trying in the real world but not yet ready to standardize.
• Historic: Documents the community has retired.

RFCs also come from different streams. The series has five: IETF, IRTF, IAB, Independent Submission, and Editorial. Only the IETF stream produces standards and BCPs. An Independent Submission can contain excellent work, but it doesn’t carry IETF consensus, and its boilerplate says so.

And then there are the April Fools’ RFCs. RFC 2324, the Hyper Text Coffee Pot Control Protocol, gave the world the famous status code 418, “I’m a teapot.” Engineers have a sense of humor. Just don’t put one of those in a contract.

How to Read an RFC Without Losing Your Mind

Most RFCs feel dense, but they follow a predictable structure. Here’s how I read one when a client asks me to review a vendor claim.

Start with the header. Check the status, the stream, and the date. Then look for “Obsoletes” and “Updates” lines, and visit the RFC’s info page to see whether a newer RFC has replaced it. Read the abstract and introduction, then jump to the Terminology section.

Watch the Capitalized Keywords

Pay close attention to capitalized words like MUST, SHOULD, and MAY. BCP 14, made up of RFC 2119 and RFC 8174, gives them precise meanings. RFC 8174 settled a point that caused years of arguments: those words carry their special meaning only when they appear in capitals. A lowercase “must” is plain English. A capitalized MUST sets a requirement an implementation has to meet before it can claim conformance.

Check Security, IANA, and Errata

Next, read the Security Considerations and IANA Considerations sections. The first tells you what the authors worried about. The second tells you which registries the protocol uses, which matters if you build or buy something that has to interoperate.

Finally, check the errata. A verified erratum can change how you should read a sentence, and vendors don’t always keep up.

How the RFC Series Itself Is Changing

Individual RFCs never change, but the series does. Two shifts in recent years deserve your attention.

First, the format. For most of its history, an RFC meant plain ASCII text with fixed page breaks. That started changing in 2019, when XML became the canonical source format and the RFC Editor began producing HTML and PDF versions too. RFC 9720, published in January 2025, now governs RFC formats and versions. Reading a modern RFC in a browser feels far more pleasant than it used to, with working links and real section anchors.

Second, governance. RFC 9280 overhauled how the community manages the series in 2022. It created the RFC Series Working Group and the RFC Series Approval Board to set policy. The community has already refined that model. RFC 9920, published in February 2026, records lessons learned from running the new structure and obsoletes RFC 9280.

Notice what happened there. The community revised the rules for managing the RFC series by publishing a new RFC that obsoletes the old one. The process uses itself on itself, which feels either elegant or a little dizzying, depending on how much coffee you’ve had.

Why This Matters for Businesses and Professional Services Firms

If you work in consulting, IT services, managed networking, or procurement, RFCs shape your work whether or not you ever attend a meeting. Even everyday infrastructure choices, like weighing SD-WAN vs MPLS, lean on protocols the IETF wrote down.

When a client’s RFP demands “compliance with relevant RFCs,” that phrase means almost nothing until someone names the specific documents and status levels. I’ve seen contract disputes hinge on whether a vendor implemented an obsoleted version of a protocol. Reading the header of an RFC and explaining what changed is a real billable skill.

The Payoff From Participation

Participation pays off too. Firms whose engineers join working groups see changes coming years before they hit the market. Those engineers understand why the group made a design choice, which makes them better troubleshooters and better advisors. And because anyone can join the mailing lists for free, the barrier to entry is time and attention, not money.

One caution if you send staff to participate. The IETF sets clear rules on disclosing patents and other intellectual property related to work under discussion, and the “Note Well” statement at every session summarizes them. Make sure your legal team understands those obligations before your engineers start contributing text.

What I Wish Someone Had Told Me Earlier

If you’re thinking about getting involved, here’s the advice I give every newcomer.

Read before you post. Spend a few weeks on a working group’s mailing list just watching how people argue.

Review drafts. Careful reviews are the most valuable thing a newcomer can contribute, and chairs remember the people who send them.

Bring data. An interop result or a packet capture from your network monitoring tools moves a discussion further than any amount of eloquence.

Be patient. A good specification often takes two to four years from first draft to published RFC. That isn’t failure. It’s what happens when dozens of independent implementations need to work together across the entire Internet.

And keep your sense of humor. You’ll need it the third time someone reopens an issue the group closed eighteen months ago.

So, what is an RFC? It’s the closest thing the Internet has to a shared memory. Every number marks a moment when people who often disagreed found enough common ground to write something down for good. Once you’ve helped get one across the line, you never read the series quite the same way again.

Frequently Asked Questions

What does RFC stand for?

RFC stands for Request for Comments. The name dates to 1969, when Steve Crocker wrote the first document in the series. You can read that original note, RFC 1: Host Software, on the RFC Editor site.

Is every RFC an Internet standard?

No. Only IETF standards track documents labeled Proposed Standard or Internet Standard count as standards. Others carry Informational, Experimental, Best Current Practice, or Historic status. RFC 6410 defines the two level standards track.

Can anyone change an RFC after publication?

No. Nobody edits a published RFC. People record corrections as errata, and real changes arrive through a new RFC that updates or obsoletes the old one. You can check any document’s status and errata through the RFC Editor search page.

What is the difference between an Internet Draft and an RFC?

An Internet Draft is a temporary work in progress that expires after 185 days unless its authors revise it. An RFC is the permanent result that comes out after review and approval. The IETF Datatracker tracks current drafts.

How long does it take to write an RFC?

It varies widely. Simple documents can move in under a year, while major protocols often take several years. RFC 2026, The Internet Standards Process lays out the formal steps.

Who can participate in writing RFCs?

Anyone. The IETF has no membership, and you can join working group mailing lists for free. The IETF’s Tao of IETF newcomer guide offers the best starting point.

What does “rough consensus” mean?

It means the working group chair has judged that the group considered every serious objection and either addressed it or decided it doesn’t justify blocking progress. It isn’t a vote. RFC 7282, On Consensus and Humming in the IETF explains it best.

What do MUST and SHOULD mean in an RFC?

They are requirement keywords from BCP 14. They carry special meaning only in capital letters, a point RFC 8174 clarifies.

References

• RFC 2026: The Internet Standards Process, Revision 3
• RFC 6410: Reducing the Standards Track to Two Maturity Levels
• RFC 7282: On Consensus and Humming in the IETF
• RFC 7221: Handling of Internet Drafts by IETF Working Groups
• RFC 2418: IETF Working Group Guidelines and Procedures
• RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
• RFC 9920: RFC Editor Model (Version 3)
• RFC 9293: Transmission Control Protocol (TCP)
• RFC 2468: I Remember IANA
• The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force
• TechTarget: What Is a Request for Comments (RFC)?
• Wikipedia: Request for Comments

About the Author

Sarah Whitmore

Administrator

Technology writer for Foretec.com, covering IT infrastructure, networking, cybersecurity, and practical technology solutions for modern businesses.

View All Posts