Welcome to the IETF

Introduction This document is aimed at somebody who has not yet engaged with the IETF, or is early in their IETF journey. Welcome! By the time you have finished reading this, you should have a clear idea of whether the IETF is the right place for you, and whether you are likely to add value to the IETF's mission. This is a simplified, high level overview. There are many other resources to read to understand more detail, but this will get you started.

Who even is the IETF? The IETF -- the Internet Engineering Task Force -- is the open, international organisation that develops the voluntary technical standards the Internet is built on. It works by the consensus of the people who turn up to do the work, and everything it produces is freely available for anyone to read and implement. The IETF's output is documents called RFCs (Request for Comments). There have been over 10,000 of them already. These documents describe how the Internet works, and also how the IETF itself works. RFCs have value because they are good, well written, technically sound documents. They are good because of the hard work of people like you. The IETF's mission is defined in as "to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better". Famously, we're not the Internet police. Our documents have so much influence by persuasion and demonstrated value. People trust that if they implement a protocol defined in an RFC, it will work reliably and be secure. Because others trust that too, they implement the same RFC, and their systems can then interoperate with each other. The IETF is also people. Quite a lot of people. We meet in person 3 times per year, about 1000 of us, and there are many more who attend remotely or engage with the IETF via email on our mailing lists. Almost all of these people are volunteers, giving their own time or sponsored by their employers, and applying their judgement and energy towards making the Internet better. It isn't run entirely by volunteers, though. The IETF is also supported by paid staff and consultants who run the tooling and machinery, including professional editors who keep the quality of the documents high. Most of the IETF's work happens in working groups. Each one is chartered to tackle a specific problem area -- things like routing, email, or security -- and in practice a working group is really just a mailing list with a couple of chairs to keep it focused and moving. When you engage with the IETF, most of the time you're engaging with a working group. Crucially, there's no membership. No fees to join, no application to fill in, and no gatekeeper who decides whether you belong. You participate by participating. Almost all of the work happens in the open on public mailing lists, and the archives are there for anyone to read. If you're reading this, you're already as entitled to take part as anyone else.

Why would you come to the IETF? Everybody has their own reasons, but frequently you come because you have a problem and you want to change something about how the Internet works to solve that problem. Further, you probably need others to make changes to how they do things as well, so you can interoperate with them! Most people come to the IETF with a goal. Those who are most successful come with a compelling problem that needs solving. Maybe you also have a sketch of a possible solution, but the real value of the IETF is the people, and what they bring to your problem: insight, hard-won experience, and good taste. A lot of that experience is about making good tradeoffs, and the hardest tradeoff is almost always compatibility. The installed base of software that already implements the existing specs is large, messy, and buggy, and it won't upgrade on your schedule. Making a change that solves your problem without breaking all of that is a genuine skill, and it's one the IETF has in depth. The solution the IETF settles on may look very different from your initial idea.

Why wouldn't you come to the IETF? It costs quite a lot of many people's time to generate an RFC. Take the publicly available figures for what it costs to run the IETF and the time participants put in, divide by the number of RFCs produced in a year, and you land somewhere around USD $100,000 for an average one. Large, complex documents easily cost into the millions. For that level of investment, it wants to be something with a wide applicability, that will positively affect the lives of many people, and stands a chance of being implemented. If you come to the IETF with an idea, one of the first questions is going to be "who would use this, and are they interested in it?". If your presentation looks like a marketing blitz and is about why your idea is going to be good for you, that won't go over well. If you describe why your idea is good for the Internet, and how it fits in without disrupting everything else, that will do better.

Quality takes time Collaboration is slower than you might expect, and you're relying on other people's time. Everybody already has plenty of their own ideas about what would make the Internet better, so you need to show them that you care about their priorities too -- and that you have sound technical judgement. If you are generous with your time, reviewing and assisting others, they will repay you in kind. The average RFC takes over 3 years from beginning to end. Drafts whose proponent disappears before they are finished are a lot less likely to complete the journey. Somebody has to care about the problem enough to keep it moving, and if you brought the idea to the IETF in the first place, that somebody is probably you. The oldest RFC is more than 50 years old now. These documents are the foundation of the Internet. Foundations take a long time to build, but they also last a long time.

Most of the work is not glamorous It's great to get your name on an RFC. Having a published RFC is very valuable to people's careers. Not every RFC is a headline protocol with its own name and press release. Most are the careful, slow, painstaking work of defining the edge cases and error handling that make everything reliable in a chaotic world. But many people are addicted to this organisation! The IETF is full of people who really care about doing good work. If you bring that energy, you will be very much welcomed. Many people change jobs, and continue coming to the IETF. As they become more senior, participation at the IETF becomes a non-optional part of their contract negotiations. You'll get to work with smart, like-minded people and make lifelong friends -- relationships that last even longer than it takes to realise the mistakes you made in your first RFC and go back and replace it with a newer one.

How decisions get made The IETF doesn't vote. Participants speak for themselves as individuals, not on behalf of their employers, so counting hands would be close to meaningless -- it would just reward whoever dragged the most colleagues along to the room. The way the IETF describes itself is "rough consensus and running code". Both halves matter. Rough consensus is how we decide. A chair listens to the discussion and judges where the group has landed. A proposal moves ahead once the objections have been heard, understood, and either dealt with or shown to be wrong. An objection with real technical merit behind it has to be engaged with; you can't paper over it by being more numerous. In a meeting you'll sometimes hear a chair ask the room to hum. It's a deliberately fuzzy way to gauge the mood, and it works well enough. Running code is the other half. We have a deep respect for things that actually work. Show two independent implementations talking to each other and you've made an argument that's very hard to beat with words alone. That's a big part of why we run a Hackathon at every meeting. So the currency here is persuasion and demonstration. Nobody gets to pull rank.

The IETF has a culture This organisation has existed for decades. It produces a ton of highly influential documents. It's not perfect, but it is very successful. It does have a reputation of being hard to get started in, some of which is legitimately earned and some of which is people wanting it to be something it isn't. To be involved in the IETF, you need to fit in with the culture that makes it work. Take the time to observe and understand, see what works and what doesn't. Some people at the IETF you will admire and be impressed at their ideas and behaviours. Some you will observe and think "I wouldn't take that approach". Be unafraid to help improve things, while humble enough to realise there might be value you have not yet understood in how things are currently done.

Everything here is on the record The flip side of all that openness is that everything you say is public and kept forever. Posts to the mailing lists, comments at the microphone, the drafts you submit -- all of it is archived and searchable, and it isn't going away. Write accordingly. Two things are worth knowing before you contribute. The first is the "Note Well": by taking part you agree that your contributions can be published and freely used, and you take on an obligation to disclose patents you know about that would be needed to implement what's being discussed. That's a simplified summary -- the actual Note Well text, and the policies it points to, are what bind you. You'll see it referenced at the start of every meeting and on every mailing list. Read it once so it doesn't surprise you later. The second is that the IETF has a code of conduct and an anti-harassment policy, and they're taken seriously. Argue hard about the technical questions -- that's the whole point of being here -- while treating the people on the other side of the argument well. Attack the argument and leave the person alone. Behave well and you'll never need to become intimately familiar with the penalties in the code of conduct, the Ombudsteam, or the list moderators.

A note on agents It has never been easier to produce a plausible-looking draft. An LLM will happily generate a hundred pages of correctly-formatted protocol text overnight, full of confident RFC 2119 keywords. Writing the text was never the hard part. The hard part is caring about a problem for three years, showing up to defend the work, reading other people's drafts as carefully as you'd want yours read, getting two implementations to actually interoperate, and persuading a room full of sceptical experts that your idea earns its place in the Internet. Those are the things that turn an idea into a standard, and a tool can't do them for you. Use whatever helps you think and write more clearly. But remember that every draft costs other people their time to read. If you send text that no human has read, understood, and is willing to stand behind, you're spending expensive volunteer attention to do the work you skipped -- and people here can tell. Own what you submit. The norms around all this are still being worked out, but some guidance already exists. The IRTF's code of conduct () says a generative tool must not be listed as an author of a document, and that significant amounts of AI-generated content must be disclosed. Whichever tools you use, the accountability stays with you.

Still here? Good! Bring problems, then help iterate towards solutions. If this sounds like something you want to do, then the IETF wants you. Once your idea has been adopted by the IETF, it becomes the IETF's idea. You have as much say, and also as little say, as everybody else in the eventual outcome. Your influence will be proportional to the quality of your ideas, and your ability to persuade. Persuasion happens both in person, and online - so hone your ability to communicate well in both settings, and build relationships such that when you need something from some other volunteer, they will be inclined to make the effort. Clear writing is a big part of this. The easier your ideas are to read, and the more carefully you choose your terminology, the more persuasive you'll be -- and the less of everyone's time you'll spend untangling what you actually meant.

Where to begin If you've read this far and you're keen, the on-ramp is smaller than the IETF's reputation suggests. Find the working group whose problem space is closest to yours, subscribe to its mailing list, and read for a while to get a feel for how the group talks and what it cares about. Read the drafts it's working on. Come to a meeting, in person or online, and introduce yourself. Introduce yourself to the working group chairs, or the area directors responsible for the area you care about, and ask them how you can help. Offering to review a document or take on a small piece of work is one of the fastest ways to become known and trusted -- the kind of generosity that gets repaid later. You don't have to do this alone. The IETF runs sessions for new participants at every meeting, and there's a mentoring programme that will pair you with someone experienced. Plenty of people are happy to be asked a "dumb" question; most of us were new once, and someone helped us. The official guides at https://www.ietf.org/about/ go into the practical detail this document deliberately skips.