The Wayback Machine - https://web.archive.org/web/20100819082141/http://www.ietf.org:80/newcomers.html

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. If you are simply curious about where RFCs come from, look here.

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 a engineering point of view. We try to avoid policy and business questions, as much as possible. If you're interested in these general aspects, consider joining the Internet Society. Most participants in the IETF are engineers with knowledge of networking protocols and software. Many of them know a lot about networking hardware too.

Contents

Structure

The IETF often appears very informal or even chaotic to newcomers, because the style of communication is usually quite casual. But there is a system: the work is organized around more than 100 separate Working Groups (WGs). Every WG has a written charter, defining what it is supposed to do and when each work item is due. Each WG has a Chair, or more often two co-Chairs, who manage the work. The WGs are grouped in various technical areas, and each Area has two Area Directors (ADs) who coordinate things. The ADs sit together, along with the general Chair of the IETF, as the Internet Engineering Steering Group (IESG).

There are some more committees, but that's enough for a short introduction.

Participation

The IETF is completely open to newcomers. There is no formal membership, no membership fee, and nothing to sign. By participating, you do automatically accept the IETF's rules, including the rules about intellectual property (patents, copyrights and trademarks). If you work for a company and the IETF will be part of your job, you must obviously clear this with your manager. However, the IETF will always view you as an individual, and never as a company representative.

How to Start

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 WG 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.)

Working Group Mail Lists

A good technique for newcomers is to decide on one or two (not more!) WGs whose topics are interesting or relevant, and join their mailing lists. Beware: if the 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.

Attending a Meeting

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 available. This isn't free; apart from travel and hotel costs, there is a meeting fee. Be sure to arrive in time for the Newcomers Tutorial, always held early on the Sunday afternoon before the meeting starts. It will give you a lot more information than this brief introduction. Also on Sunday afternoons, typically between 1600-1700 local time, is the Newcomer's Meet & Greet, which is a hosted reception where first-time attendees and WG Chairs mingle informally for an hour. Try to stay at the meeting for the entire week, so that you can sample other WGs as well as the ones you have been following in detail. And make a point of speaking to people around you, during the breaks and mealtimes. There are usually at least 1000 interesting people at each IETF meeting.

IETF Official Documents

The IETF's official products are documents, published free of charge as RFCs. "RFC" stands 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

The Tao of the IETF

Here's a must read document: The Tao of IETF. If you read nothing else, read this. It's a much more thorough introduction to the IETF than this short web page.

Other Resources

All the other resources you need are on the IETF web site. On most pages, you will see a sidebar at the left. Initially, make sure it's set to "Extended" mode using the "Customize View" menu at the bottom left. Below, we list a small selection of pages that could be especially useful to newcomers.

  • The EDU (education) team site (especially, look for the most recent version of the Newcomers Tutorial).
  • The Glossary explains a number of the acronyms and terms that you may see and hear.
  • The list of current Working Groups 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.
  • The photo directory of WG Chairs is very helpful if you want to find a particular chair to ask questions or discuss an issue.
  • Join the IETF-Announce mailing list to get important announcements for all participants.
  • Other general mailing lists.
  • The main page for Internet-Drafts, the IETF's working drafts.
  • The tracker allows you to track the progress of a particular draft. (Drafts normally expire after 6 months unless they are being actively considered for publication.)
  • An informal list of the IETF's rules, which do get updated from time to time, so this list is not definitive.
  • The official Note Well statement, which makes it clear that the rules apply to you personally.
  • The Daily Dose, which lists recent messages to the IETF-Announce email list; new, revived, and updated internet-drafts; drafts recently sent to the IESG; drafts recently sent to the RFC Editor; and more.

Appendix: Where do RFCs come from?

  • 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 four 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 (DS). The second official stage, when interoperable implementations have been convincingly demonstrated.
    • Standard (STD). The final stage, when the standard is shown to be very widely deployed. However, a new Proposed Standard may well obsolete a Draft Standard or Standard.
    • Best Current Practice (BCP). This is a single stage alternative to the above for more 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 IETF search box at the top left of this page.