Getting started in the IETF

Welcome! If you are a new participant in the IETF, this page is meant for you. It gives a short introduction, some general advice to new participants, and a guide to sources of further information.

Introduction

The IETF's mission is "to make the Internet work better," but it is the Internet Engineering Task Force, so this means: make the Internet work better from an engineering point of view. We try to avoid policy and business questions, as much as possible. Most participants in the IETF are engineers with knowledge of networking protocols and software. Many of them know a lot about networking hardware too.

The IETF's standards development work is organized into several Areas. Each Area has one or more Area Directors (ADs), which together comprise the Internet Engineering Steering Group (IESG). The IESG is responsible for technical management of IETF activities, the Internet standards process, and for the actions associated with entry into and movement along the Internet "standards track," including final approval of specifications as Internet Standards and publication as an RFC.

Within each Area there are multiple Working Groups (WG). Each WG has one or more chairs who manage the work, and a written charter defining what the work is and when it is due. There are more than 100 WGs. The WGs produce Internet Drafts (I-Ds) which often lead to the publication of an Internet standard as an RFC. The IETF Datatracker has the charters, chairs and other information for all the current WGs.

People interested in particular technical issues join the mailing list of a WG (also available via the IETF Datatracker) and occasionally participate in IETF meetings.

How to Start

A good technique for newcomers is to decide on one or two (not more!) Working Goups (WGs) whose topics are interesting or relevant, and join their mailing lists.

You can find the list of currently active WGs on the IETF Datatracker. Clicking on a group acronym (e.g., "tcpm") gets you to that group's list of documents. You will want to click on the "About" tab on that page to see the group description. From there, in the "mailing list" section in the table at the top, there is a link "to subscribe" to that groups email list. Follow the instructions there to sign up to the mailing list and you have effectively joined the working group.

A working group's About tab might also have pointers to other sources of WG information, such as a wiki page or a Github repository.

If a WG is in an active phase of discussion, you may well receive tens of message a day from each list. You need to be using a mail program with a good method of automatically sorting incoming mail into multiple inboxes.

Once you have that working, simply read the mail threads daily, and read any draft documents that they refer to. (See the next section for hints on how to find particular drafts.) It's advisable to wait several weeks before starting to contribute to the mailing list. But when you feel comfortable that you have something new to say, go for it!

The IETF is normally very welcoming to newcomers, and tolerance is the rule. The technical level is quite high, so if you write something that turns out to be wrong, you may get some quite frank replies. Or sometimes you will get a reply from someone whose first language is not English, and they can be rude without intending it. (If someone is seriously offensive, the WG Chairs are supposed to deal with it.) Don't be discouraged; everybody started as a newcomer.

Guides Program

If you are just getting started in the IETF, you may be interested in the IETF Guide Program. This program matches experienced IETF participants with newcomers in order to aid their integration into the IETF community through advice, help, and collected wisdom. The guidance provided by the mentors should speed up the time it takes for newcomers to become active, contributing members of the IETF.

Participating in Meetings

Some good news for your travel budget: it's possible to participate in the IETF without ever attending a meeting. If you really want to get results, you probably need to attend some meetings, but it's certainly not required to get started. The IETF carries out most of its detailed technical work online, with the primary method being email.

Every IETF Working Group has a dedicated mailing list, and that's where proposals are made and discussed, where issues are raised, and where consensus is established. (Since the IETF has no formal membership, decisions cannot be taken by voting; the method is to establish rough consensus on the mailing list.)

After participating by email for a while, it may be time to attend your first meeting. Details are linked off the IETF home page as soon as they are available. This isn't free. There are meeting registration fees and for meetings with in-person participation, there are travel and hotel costs.

Be sure to plan to participate in Newcomers webinars ahead of the meeting. These are usually held Sunday afternoon before the meeting starts. It will give you a lot more information than this brief introduction. 

A number of newcomer-oriented activities are organized for each IETF meeting throughout the meeting week. These vary from meeting to meeting and details are linked from the main meeting webpage. Be sure to sample other WGs as well as the ones you have been following in detail. And make a point of connecting with and speaking to people around outside of meeting sessions. There are usually at least 1000 interesting people at each IETF meeting.

Remember: Every experienced IETF attendee was once a newcomer.

Here is a series of video testimonials from other attendees talking about their first meeting.

IETF Official Documents

The IETF's official products are documents, published free of charge as RFCs. "RFC" originally stood for Request for Comments, and this name (used since 1969, before the IETF existed) expresses something important: the Internet is a constantly changing technical system, and any document that we write today may need to be updated tomorrow. One way to look at the IETF is as the group of people who work together to improve the technology of the Internet on a daily basis. 

As well as producing RFCs, the IETF is a forum where network operators, hardware and software implementers, and researchers talk to each other to ensure that future protocols, standards and products will be even better. This is not the only technical forum for the Internet, of course. But it is the forum where the basic technical standards for Internet protocols are set and maintained. 

The IETF does not standardize transmission hardware (we leave that to organizations like the IEEE and the ITU) and does not standardize specialized application layer protocols. For example, we leave HTML and XML standards to the World-Wide Web Consortium. But the IETF does standardize all the protocol layers in between, from IP itself up to general applications like email and HTTP.

Resources

Here are some other resources to help you get started in the IETF.

The Tao of the IETF

The Tao of the IETF is a must read document. If you read nothing else, read this. It's a very thorough introduction to the IETF.

IETF New Participant Overview Videos

These provide overviews of the the IETF structure and meetings, as well as other resources available.

The list of Working Groups

This includes links to their charters. In each charter, there are links to all drafts currently discussed by the WG and to all RFCs that the WG has produced. Also, there are instructions on how to join each WG mailing list.

Photo directory of Working Group chairs 

This is very helpful if you want to find a particular chair to ask questions or discuss an issue.

The official Note Well

This statement makes it clear that the rules apply to you personally, as an IETF participant.

How to Read an RFC

This blog post by Mark Nottingham provides a practical approach to reading RFCs, the document format in which specifications developed in the IETF are published.

Appendix: Where do RFCs come from?

An abridged list of information about RFCs and Internet-Drafts.

  • Internet-Drafts can be written and shared by anyone. Only some Internet-Drafts (I-Ds) are formally adopted for consideration by a group in the IETF and an even smaller fraction become RFCs.
  • Not all RFCs are standards. Only RFCs that open with words like "This document specifies an Internet standards track protocol" or "This memo documents an Internet Best Current Practice" are normative documents approved by the IETF. (Most recently, they will also have a header stating "Category: Standards Track" or "Category: Best Current Practice".) Any other RFC is informational in nature, even if it reads like a technical specification and even if a marketing person asserts that it's a standard. (Some such RFCs carry the label "Experimental" or "Historic" rather than "Informational".)
  • Even standards track RFCs may be obsolete. Often a more recent RFC has obsoleted an older one. You can't find this out from looking at the old one.
  • Not all RFCs come from the IETF.Some RFCs come from the IAB, the IRTF, or are independent submissions. None of these are standards.
  • Always check the status of an RFC. There are various ways to do this; the most fundamental source is the RFC Editor site.
  • Formally standardized RFCs come in several flavors:
    • Proposed Standard (PS). The first official stage, but many standards never progress beyond this level (probably because IETFers don't like bureaucracy). 
    • Draft Standard. An intermediate stage that is no longer used for new standards. 
    • Internet Standard. The final stage, when the standard is shown to be interoperable and widely deployed. However, a new Proposed Standard may well obsolete an older Internet Standard. 
    • Best Current Practice (BCP). This is a single stage alternative to the above for operational specifications. 
  • The text of an RFC never changes. When an RFC is updated, it gets a new number. IETF RFCs, including standards track RFCs, can be updated by an IETF Working Group or by individual authors working within the IETF process. If you think an IETF RFC needs updating, you will need to either participate in the IETF yourself and do the work, or persuade someone else to do so. RFC authors are usually glad to hear from people using their work who have constructive suggestions.
  • Some RFCs have errata. As people read and re-read RFCs, they often find mistakes. When those people are kind enough to report those mistakes to the RFC Editor, the errata can become associated with the RFC. You can see the errata in the search results from the RFC Editor site. Errata include technical mistakes as well as editorial errors that were not found in the RFC before it was published; therefore, reviewing the errata for an RFC is always a good idea.
  • Finding RFCs for a particular topic is an art. To find RFCs on a given topic, a good option is to consult the indexes at the RFC Editor site. Another option is the search feature of the IETF Datatracker.