IMC membership | Features chart | Newsletter | Internet Mail standards
MailConnect | Definitions | Reports | Internationalization
HIPAA | Upcoming events | Spam | vCard/vCalendar
S/MIME and PGP/MIME | Other organizations | IMC home
Please note that this document was last updated February 2002; it is now quite out of date.
Please see The Tao of the IETF instead.
This document describes many aspects of the IETF (the Internet Engineering Task Force). It is a work in progress, not a final report, because the IETF continues to change. This is by no means a "definitive" or "authoritative" document, but simply a collection of my observations and pointers designed to help novices deal with the IETF. The motivation for writing this document is the fact that many people often ask long-time (or not-so-long-time) IETF participants questions such as "how do I write an Internet Draft?", "what should I do in a Working Group meeting?", and "who runs this organization, anyhow?".
Readers should be aware that there are many authoritative documents on the IETF process, and I reference those throughout this document. Those documents were created over a long period of time by hundreds of participants in the IETF process. However, those documents don't always reflect the reality of how things are done today, although they are certainly paid attention to by most IETF participants. Note that some of the authoritative documents are in the process of revision in order to better reflect what is actually happening, or what should be happening now that there is lots more experience with the IETF process.
Jargon note: most parts of the IETF are referred to by their acronym, not by their name. For instance, you almost never hear anyone saying "Internet Engineering Task Force": it's almost always just "IETF". In this document, both the name and the acronyms are used, but be aware that the acronyms are often used much more extensively on the mailing lists and in verbal discussion. That's just the way dweebs are.
One of the facts about the IETF that bothers many newcomers is that the IETF doesn't exist. Well, it does exist as a collection of happenings and people, but it doesn't legally exist. There's no corporation, no board of directors, no members, and no dues. It is really just a bunch of people who agree that it exists and are willing to work to be sure that it exists well. Pretty nifty trick, eh?
Of course, no organization can be as successful as the IETF is without having some sort of structure. In the IETF's case, that structure is provided by other organizations, as described in BCP 11, "The Organizations Involved in the IETF Standards Process". If you participate in the IETF and only read one BCP, this is the one you should read.
A well-known guide to the IETF is "The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force". The document is an overview of the IETF, including everything from how to participate in Working Groups to what to do at face-to-face meetings.
Essentially all work in the IETF is done by volunteers. The people who write documents, the chairs and the participants of the Working Groups, the IESG, and the IAB are all doing their work for free. Everyone has a different reason for volunteering, but the large majority of people do so because they want the Internet to operate better and the working in the IETF is an excellent way to achieve that goal. Most participants have day jobs, and many have to cajole their employers to let them participate as much as they do on company time.
You should note that many folks call themselves "members" of the IETF. There is no formal membership in the IETF, but there are no other good words in English to describe people who actively participate and support a group like the IETF. The positive side of this is that makes anyone who brags about their IETF membership look all the more silly.
The Internet Society is the international non-profit organization that fosters the expansion of the Internet. One of the ways that ISOC does this is through financial and legal support of the other "I" groups described here, particularly the IETF. ISOC's oversight of the IETF is remarkably hands-off, so many IETF members don't even know about it. ISOC accepts the IETF-defined standards process, they provide insurance coverage for many of the people in the IETF process, and they give a public relations channel for the times that one of the "I" groups wants to say something to the press. The ISOC is one of the major unsung (and underfunded) heroes of the Internet.
The vast majority IETF's work is done in many "Working Groups"; at the time of this writing, there are about 115 different WGs. (The term "Working Group" is often seen capitalized, but probably not for a very good reason.) BCP 25, "IETF Working Group Guidelines and Procedures", is an excellent resource for anyone participating in WG discussions.
A WG is really just a mailing list with a bit of adult supervision. You "join" the WG by subscribing to the mailing list; all mailing lists are open to anyone. Some IETF WG mailing lists only let subscribers to the mailing list post to the mailing list, while others let anyone post. Each WG has one or two chairpeople.
More importantly, each WG has a charter that the WG is supposed to follow. The charter states what the scope of the discussion for the WG is, as well as what are the goals of the WG. The WG's mailing list and face-to-face meetings are supposed to focus on just what is in the charter, and not to wander off on other "interesting" topics. Of course, looking a bit outside the scope of the WG is occasionally useful, but the large majority of the discussion should be on the topics listed in the charter. In fact, some WG charters actually specify what the WG will not do, particularly if there were some attractive but nebulous topics brought up during the drafting of the charter. The list of all WG charters makes interesting reading for folks who want to know what the different WGs are supposed to be doing.
The role of the WG chairs is described in both BCP11 and BCP 25. Basically, their job is to keep the discussion moving forwards towards the milestones in the WG charter, which is usually publication of one or more RFCs. They are not meant to be taskmasters, but are responsible for assuring positive forward motion and preventing random wandering.
As you can imagine, some WG chairs are much better at their jobs than others. When a WG has fulfilled its charter, it is supposed to cease operations. (Most WG mailing lists continue on after a WG is closed, still discussing the same topics as the WG did.) In the IETF, it is a mark of success that the WG closes up because it fulfilled its charter. This is one of the aspects of the IETF that newcomers who have experience with other standards bodies have a hard time understanding. However, some WG chairs never manage to get their WG to finish, or keep adding new tasks to the charter so that the WG drags on for many years. The output of these aging WGs is often not nearly as useful as the earlier products, and the messy results are sometimes called "degenerative Working Group syndrome".
One important role of the chair is to decide which Internet Drafts get published as "official" Working Group drafts, and which don't. In practice, there is actually not much procedural difference between WG drafts and independent drafts; for example, many WG mailing lists also discuss independent drafts (at the discretion of the WG chair). Procedures for Internet Drafts are covered in much more detail later in this document.
WG chairs are strongly advised to go to the new chairs' training lunch the first day of the IETF meeting. If you're interested in what they hear there, you may find the slides of the WG chairs training to be useful.
One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often due to someone who could not attend the meeting pointing out a serious flaw in the logic used to come to the decision.
Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The exact method of determining rough consensus varies from WG to WG. The lack of voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that anyone can join and it is impossible to count the participants?)
The IESG is pretty much the leadership of the IETF. However, they don't do much direct leadership, such as the kind you will find in many other standards organizations. The basic purposes of the IESG are to ratify or correct the output from the IETF's Working Groups, to get WGs started and finished, and to make sure that non-WG drafts that are about to become RFCs are correct.
The IESG consists of the Area Directors ("ADs"), who are selected by the Nominations Committee (which is usually called "Nomcom") and are appointed for two years. The process for choosing the members of the IESG is detailed in BCP 10, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees". Basically, Nomcom is a randomly selected voluntary committee with the task of suggesting people to fill open slots on the IESG. Open slots usually occur when a serving AD's term expires. (Nomcom does the same thing for the IAB.)
The current areas are:
Because the IESG has a great deal of influence in the decision to help or to prevent Internet Drafts from becoming RFCs, many people look at the ADs as somewhat godlike creatures. IETF participants sometimes reverently ask an Area Director for their opinion on a particular subject. However, most ADs are nearly indistinguishable from mere mortals and rarely speak from mountaintops.
The ADs for a particular area are expected to know more about the WGs in that area than anyone else. On the other hand, the entire IESG votes on each Internet Draft that is becoming an RFC, and it only takes two IESG members to block a draft from moving forwards. The purpose of this is to make sure that an AD's "pet project" doesn't make it onto standards track if it will have a negative effect on the rest of the IETF protocols.
This is not to say that the IESG never wields power. When the IESG see a Working Group veering from its charter, or when a WG asks the IESG to make the WG's badly-designed protocol a standard, the IESG will act. In fact, because of their high work load, the IESG usually moves in a reactive fashion. They approve most WG requests for Internet Drafts to become RFCs, and usually only step in when something has gone very wrong. Another way to think about this is that the ADs are hired to think, not to just run the process. The quality of the IETF standards comes both from the review they get in the Working Groups and the review that the WG review gets from the ADs.
The IETF is run by rough consensus, and it is the IESG that decides if a WG has come up with a result that is a real consensus. Because of this, one of the main reasons that the IESG might block something that was produced in a WG is that the result is not really consensus in the IETF as a whole, that is, among all of the WGs in all areas. For instance, the result of one WG might clash with a technology developed in a different WG. An important job of the IESG to watch over the output of all the WGs to help prevent IETF protocols that are at odds with each other. This is why ADs are supposed to review the drafts coming out of areas other than their own.
The IAB is responsible for looking at the "big picture" of the Internet. They are the ISOC's technical advisory group, and they often contribute to the IETF's process by focusing on topics that span many WGs and many areas.
Like the IESG, the IAB is selected for multi-year positions by Nomcom, as described in BCP 10. In an interesting twist on normal rules of hierarchy, the IAB is actually the body that seats the IESG. That is, Nomcom gives its nominations to the IAB, who then decides whether or not to accept the nominations. There has never been a case where the IAB didn't support the Nomcom's nominations.
Probably the most important job done by the IAB is to act as liaison with groups outside the IETF that affect the IETF standards process. These groups include the RFC Editor and the IANA, whose contracts are both with the IAB. The IAB also has liaisons with other standards bodies, such as the ITU (International Telecommunication Union).
The IAB is also in the unenviable position of being the court of appeal when someone complains that the IETF process has failed. This means that someone who feels that the IESG or Nomcom has done something wrong takes their complaint to the IAB. The appeals process is mentioned later in this document.
The core registrar for the IETF's activities is the IANA. Many Internet protocols require that someone keep track of protocol items that were added after the protocol came out. Typical examples of the kinds of registries needed are for TCP port numbers and MIME types. IANA is chartered by the IAB and these days is paid for by the ISOC.
Five years ago, no one would have expected to ever see the IANA mentioned on the front page of a newspaper. IANA's role had always been very low key. The fact that IANA was also the keeper of the root of the domain name system forced it to become a much more public entity, one which was badly maligned by a variety of people who never looked at what its role was. The domain name and IP address assignment functions are no longer part of the IETF's IANA.
Even though being a registrar may not sound interesting, many IETF participants will testify to how important IANA has been for the Internet. Having a stable, long-term repository run by careful and conservative operators makes it much easier for people to experiment without worrying about messing things up. IANA's founder, Jon Postel, was heavily relied upon to keep things in order while the Internet kept growing in leaps and bounds, and he did a fine job of it.
At last, a group that doesn't have an acronym starting with "I"! The main role of the RFC Editor is to decide which Internet Drafts become RFCs. An important secondary role is to format the RFCs in a consistent fashion, and to be sure that there is at least one definitive repository for all RFCs. The RFC editor does essentially no editing on documents, including not doing any spelling correction. (Getting an RFC published is described later in this document.)
One of the most popular misconceptions in the IETF community is that the role of the RFC Editor is performed by IANA. In fact, the RFC Editor is a separate job, although both the RFC Editor and IANA have always been the same people. Both are contracted by the IAB, and both are paid for by ISOC. The RFC Editor can be contacted by email at email@example.com.
There are, in fact, a few people who are paid to maintain the IETF. The IETF Secretariat does day-to-day logistical support, which mainly means coordinating the face-to-face meetings and running the IETF-specific mailing lists (not the WG mailing lists). The Secretariat is also responsible for keeping the official Internet Drafts directory up to date and orderly, and for helping the IESG do its work. The IETF Secretariat is financially supported by the fees of the face-to-face meetings.
The computer industry is rife with conferences, seminars, expositions, and all manner of other kinds of meetings. IETF face-to-face meetings are nothing like these. The meetings, held three times a year, are week-long dweebfests whose primary goal is to reinvigorate the WGs to get their tasks done, and whose secondary goal is to get a fair amount of mixing between the WGs and the areas. The cost of the meetings is paid by the people attending the meetings and by the corporate host for each meeting, although ISOC kicks in additional funds for things like the MBONE simulcast of the meetings.
For many people, IETF meetings are a breath of fresh air when compared to the standard computer industry conferences. There is no exposition hall, no tutorials, and no big-name industry pundits. Instead, there is lots of work, as well as a fair amount of time for socializing. IETF meetings are of little interest to sales and marketing folks, but of high interest to engineers and developers.
Most IETF meetings are held in North America, because that's where most of the participants are from; however, meetings are held on other continents about once every year or two. The past few meetings have had about 2000 attendees. There have been over 45 IETF meetings so far, and future meeting sites are usually announced at least three months in advance.
Newcomers to IETF face-to-face meetings are often in a bit of shock. They expect them to be like other standards bodies, or like computer conferences. Fortunately, the shock wears off after a day or two, and many new attendees get quite animated about how much fun they are having. One particularly jarring feature of recent IETF meetings is the use of wireless Internet connections throughout the meeting space. It is common to see half the people in a WG meeting reading email and reading the web pages during presentations they find uninteresting.
The most important thing that everyone (newcomers and seasoned experts) should do before coming to a face-to-face meeting is to read the Internet Drafts and RFCs before the meeting. WG meetings are explicitly not for education: they are for developing the group's documents. Even if you do not plan to say anything in the meeting, you should read the group's documents before attending so that you can understand what is being said.
It is up to the WG chair to set the agenda for the meeting, usually a few weeks in advance of the meeting. If you want something discussed at the meeting, be sure to let the chair know about it. The agendas for all the WG meetings are available in advance, but many WG chairs are lax (if not totally negligent) about turning them in.
The WG meetings are scheduled only a few weeks in advance, and the schedule often changes as little as a week before the first day. If you are only coming for one WG meeting, you may have a hard time booking your flight with such little notice, particularly if the WG's meeting changes schedule. You should keep track of the current agenda so you can schedule flights and hotels. But, you should probably not be coming for just one WG meeting. It's likely that your knowledge could be valuable in a few WGs, assuming that you've read the drafts and RFCs for those WGs.
If you are giving a presentation at a face-to-face meeting, you should probably come with a few slides prepared. Until recently, almost all presentations were done on transparencies; recent meetings have had projectors for laptop-based presentations. The IETF Secretariat has said that there will be projectors at all future meetings. You should definitely avoid a practice that is common outside the IETF, which is putting your company's logo on every slide. The IETF frowns on this kind of corporate advertising, and most presenters don't even put their logo on their opening slide. The IETF is about technical content, not company boosterism.
In order to form a Working Group, you need a charter and someone who is able to be chair. In order to get those things, you need to get people interested so that they can help focus the charter and convince an Area Director that the project is worthwhile. A face-to-face meeting is useful for this. In fact, very few WGs get started by an Area Director; most start after a face-to-face BOF due to individuals interested in the topic.
A BOF meeting must be approved by the Area Director in the relevant area before it can be scheduled. If you think you really need a new WG, you should first approach an AD informally with your proposal. If he or she thinks it's good (or at least reasonable), they will let you know. You should then request a meeting slot at the next face-to-face meeting. You do not need to wait for that meeting before getting work done, such as setting up a mailing list and start discussing a charter.
BOF meetings have a very different tone than WG meetings. The purpose of a BOF is to make sure that a good charter with good milestones can be created, and that there are enough people willing to do the work needed in order to create standards. Some BOFs have Internet Drafts already in process, while others start from scratch. An advantage of having a draft before the BOF is to help focus the discussion; on the other hand, having a draft might tend to limit what the other folks in the BOF want to do in the charter. It is important to remember that most BOFs happen in order to get support for an eventual Working Group, not to get support for a particular document.
Many BOFs do not turn into WGs for a variety of reasons. A common problem is that not enough people can agree on a focus for the work. Another typical reason is that the work would not end up being a standard, such as if the document authors do not really want to relinquish change control to a WG. Only two BOFs on a particular subject can take place; either a WG has to form, or the topic should be dropped.
There is a second kind of BOF that happens as often, if not more often, than the ones described above. A "bar BOF" is a very unofficial gathering of some people to talk about some topic for some period of time. The number of people, the breadth of the topic, and the expected length of time usually expand as the meeting happens. Bar BOFs often happen in many different places around an IETF meeting, such as restaurants, coffee shops, and (if we are so lucky) pools.
The dress code is definitely casual or, more precisely, comfortable. Tiedye t-shirts are often more common than ties. T-shirts that were sold at previous IETF meetings are often considered cool, and other t-shirts with geek humor (particularly Internet geek humor) abound.
Checking name tags is very common because many of the people have not met in person but know each other well from the WG mailing lists. You should wear your name tag where strangers can look at it easily, and you shouldn't be frightened about looking at other people's name tags.
Instead of the tacky ribbons that most conferences use to identify special people, the IETF uses colored dots. The color code is blue for WG and BOF chairs, yellow for IESG members, and red for IAB members. Some folks add their own dots of different colors just to keep you on your toes.
The meetings run from Monday to Friday, with a newcomer's orientation and a large opening social the Sunday preceding the first day. All newcomers should attend the orientation, if for no other reason to see the large number of other newcomers so you don't feel so out of place. There is also a social on Tuesday night, usually away from the meeting hotel, that is often quite popular (although it is often quite loud and therefore not the best place to chat).
Registration covers the entire week. While some people think this is unfair if they are only coming to one or two days, having a single fee prevents having to hire guards for each session to be sure that each person has the right kind of badge for that day. Further, it encourages people to come for more than just a single WG meeting and therefore learn more (and contribute more) in other WGs.
The "terminal room" in fact has no terminals. Instead, there are over 100 10BaseT connections and a smaller number of PCs that are hooked into the room's high-speed network. You can use the network to get your mail, print out papers and slides, and do your daily work when you aren't in meetings. The terminal room often opens on Sunday, but setup glitches (remember those?) sometimes delay the opening a bit.
The hotel that the meeting is held in often sells out well before the meeting. The IETF Secretariat often has alternate hotels that are close by, usually at similar rates as the main hotel. While some prefer to stay in the meeting hotel for convenience, many prefer to stay in the other hotels so that they get outside at least once every day. Also, you can often find a lower room rate at nearby hotels.
Remember to socialize, both with other folks in the WGs of interest to you and other people. Many IETF protocols are improved because someone from one area happened to talk to someone from a different area and discover some interesting way of doing something.
One of the most common questions seasoned IETFers hear from newcomers is, "how do I get an IETF standard published?" A much better question is, "should I write an IETF standard?", since the answer is not always "yes". If you do decide to attempt to write a document that becomes an IETF standard, the process is not all that hard, and there is plenty of written guidance on how to do it.
Every IETF standard is published as an RFC (a "Request For Comments", but everyone just calls them RFCs), and every RFC starts out as an Internet Draft (often called an "I-D"). The basic steps for getting something published as an IETF standard are:
A much more complete explanation of the steps is contained in BCP 9, "The Internet Standards Process". Anyone who writes a draft that they hope will become an IETF standard must read BCP 9 so that they can follow the path of their document through the process. BCP 9 goes into great detail on a topic that is very often misunderstood, even by seasoned IETF participants: different types of RFCs go through different processes and have different statuses. There are six kinds of RFCs:
IETF standards exist so that people will use them to write Internet programs that interoperate. They don't exist to document the (possibly wonderful) ideas of their authors, nor do they exist so that a company can say "we have an IETF standard". If a standards-track RFC only has one implementation (whereas two are required for it to advance on standards track), it was probably a mistake to put it on the standards track in the first place.
The biggest reason some people do not want their documents put on the IETF standards track is that they must give up change control of the protocol. That is, as soon as you propose that your protocol become an IETF standard, you must fully relinquish control of the protocol. If there is general agreement, parts of the protocol can be completely changed, whole sections can be ripped out, new things can be added, and the name can be changed.
Some people find it very scary to give up control of their pet protocol; if you are one of those people, don't even think about trying to get your protocol to become an IETF standard. On the other hand, if your goal is the best standard possible with the widest implementation, then you might find the IETF process to your liking.
Incidentally, the change control on Internet standards doesn't end when the protocol is put on standards track. The protocol itself can be changed later for a number of reasons, the most common of which is that implementors discover a problem as they implement the standard. These later changes are also under the control of the IETF, not the editors of the standards document.
First thing first. Every document that ends up in the RFC repository starts as an Internet Draft. Internet Drafts are tentative documents that help bring comments to the author about something that might become an RFC. In order to remind folks of their tentativeness, Internet-Drafts are automatically removed from the on-line directories after six months. The are most definitely not standards or even specifications. As BCP 9 says:
An Internet-Draft is NOT a means of "publishing" a specification; specifications are published through the RFC mechanism.... Internet-Drafts have no formal status, and are subject to change or removal at any time. Under no circumstances should an Internet-Draft be referenced by any paper, report, or Request-for-Proposal, nor should a vendor claim compliance with an Internet-Draft.
You can always tell a person who doesn't understand the IETF (or is intentionally trying to fool people) when they brag about having published an Internet draft; it takes no significant effort.
An I-D should have approximately the same format as an RFC. Contrary to many people's beliefs, an I-D does not need to look exactly like an RFC, but if you can use the same formatting procedures used by the RFC Editor when you create your I-Ds, it will simplify the RFC Editor's work when your draft is published as an RFC. RFC 2223, "Instructions to RFC Authors", describes the nroff formatting used by the RFC Editor.
Before you create the first draft of your Internet Draft, you should read three documents.
When you are ready to turn in your Internet Draft, you send it to Internet Drafts editor at firstname.lastname@example.org. There is a real person at the other end of this mail address. That person's job is to make sure that you included the minimum things you needed for the Internet Draft to be published.
When you submit the first version of the draft, the draft editor gives the file name for the draft. If the draft is an official Working Group product, the name will start with "draft-ietf-" followed by the designation of the WG, followed by a descriptive word or two, followed by "00.txt"; for example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-00.txt". If it is not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt"; for example, a draft that I wrote might be named "draft-hoffman-keying-00.txt". You are welcome to suggest names; however, it is up to the Internet Drafts editor (and, if it is an official WG draft, the WG chair) to come up with the file name.
After the first edition of a draft, the number in the file name in incremented; for instance, the second edition of the S/MIME draft named above would be "draft-ietf-smime-keying-01.txt". Note that there are cases where the file name changed after the first version, such as when a personal effort is pulled into a Working Group.
When you think you are finished with the draft process and are ready to request that the draft become an RFC, you should definitely read Considerations for Internet Drafts, which is prepared by the IESG. In fact, you should probably read that document well before you are finished, so that you don't have to make a bunch of last-minute changes.
The procedure for creating and advancing a standard is described in BCP 9. After an Internet Draft has been sufficiently discussed and there is rough consensus that what it says would be a useful standard, it is presented to the IESG for consideration. If the draft is an official WG draft, the WG chair sends it to the appropriate Area Director after it has gone through Working Group last call. If the draft is an individual submission, the draft's author or editor submits it to the appropriate Area Director. BCP 9 also describes the appeals process for people who feel that a Working Group chair, an AD, or the IESG has made a wrong decision in considering the creation or advancement of a standard.
After it is submitted to the IESG, the IESG announces an IETF-wide last call. This helps get the attention of people who weren't following the progress of the draft, and can sometimes cause further changes to the draft. It is also a time where people in the WG who feel that they weren't heard can make their comments to everyone. The IETF last call is two weeks for drafts coming from WGs and four weeks for individual submission.
If the IESG approves the draft to become an Internet Standard, they ask the RFC Editor to publish it as a Proposed Standard. After it has been a Proposed Standard for at least six months, the RFC's author (or the appropriate WG chair) can ask for it to become a Draft Standard. Before that happens, however, someone needs to convince the appropriate Area Director that there are at least two independent interoperable implementations of each part of the standard. This is a good test for the usefulness of the standard as a whole, as well as an excellent way to check if the standard was really readable.
A few things typically happen at this point. First, it is common to find that some of the specifications in the standard need to be reworded because one implementor thought they meant one thing while another implementor thought they meant something else. Another common occurrence is that none of the implementations actually tried to implement a few of the features of the standard; these features get removed not just because no one tested them, but also because they weren't needed.
You should not be surprised if a particular standard does not progress from Proposed to Draft. In fact, most of the standards in common use are Proposed Standards and never move forwards. This may be due to no one taking the time to try to get them to Draft, or some of the normative references in the standard are still at Proposed Standard, or it may be that there more important things to do.
A few years after something has been a Draft Standard, it can become a Internet Standard, also known as "full standard". This doesn't happen often, and is usually reserved for protocols that are absolutely required for the Internet to function. The IESG does a great deal of scrutiny before making a Draft Standard an Internet Standard.
Writing specifications that get implemented the way you want is a bit of an art. You can keep the specification very short, with just a list of requirements, but that tends to cause implementors to take too much leeway. If you instead make the specification very wordy with lots of suggestions, implementors tend to miss the requirements (and often disagree with your suggestions anyway). An optimal specification is somewhere in between.
One method to make it more likely that developers will create interoperable implementations of standards is to make sure it is clear what is being mandated in a specification. Early RFCs used a variety of language to say how to do things, and this caused implementors to not know which parts were suggestions and which parts were requirements. Standards writers in the IETF generally agreed to limit their wording to a few specific words with a few specific meanings.
RFC 1123, "Requirements for Internet Hosts -- Application and Support", written way back in 1989, had a short list of words that had appeared to be useful, namely "must", "should", and "may". These definitions were updated and further refined in BCP 14, "Key words for use in RFCs to Indicate Requirement Levels", which is widely referenced in current Internet standards. BCP 14 also specifically defines "must not" and "should not", and lists a few synonyms for the words defined.
In a standard, in order to make it clear that you are using the definitions from BCP 14, you should do two things. First, you should refer to BCP 14 (although most people refer to it as RFC 2119, because that is what BCP 14 tells you to do), so that the reader knows how you are defining your words. Second, you should point out which instances of the words you are using come from BCP 14; the accepted practice for this is to capitalize the words. That is why you see "MUST" and "SHOULD" capitalized in IETF standards.
BCP 14 is a short document, and should be read by everyone who is reading or writing IETF standards. Although the definitions of "must" and "must not" are fairly clear, the definitions of "should" and "should not" cause a great deal of discussion in many WGs. When reviewing an Internet Draft, the question is often raised, "should that sentence have a MUST or a SHOULD in it?" This is, indeed, a very good question, because specifications shouldn't have gratuitous MUSTs, but also should not have SHOULDs where a MUST is needed for interoperability. This goes to the crux of the question of over-specifying and under-specifying requirements in standards.
One aspect of writing IETF standards that trips up many novices (and quite a few long-time IETF folk) is the rule about how to make "normative references" to non-IETF documents or to other RFCs in a standard. A normative reference is a reference to a document that must be followed in order to implement the standard; a non-normative reference is one that is helpful to an implementor but is not needed. As described above, a "MUST" specification would certainly be normative, so any reference needed to implement the "MUST" would be normative. A "SHOULD" or "MAY" specification is not necessarily normative, but it might be normative based on what is being required; there is definitely room for debate here.
An IETF standard may make a normative reference to any other standards-track RFC that is at the same standards level or higher, or to any "open standard" that has been developed outside the IETF. The "same level or higher" rule means that before a standard can move from Proposed to Draft, all of the RFCs for which there is a normative reference must also be at Draft or Internet Standard. This rule gives implementors assurance that everything in a Draft Standard or Internet Standard is quite stable, even the things referenced outside the standard. This can also delay the publication of the Draft or Internet Standard by many months (sometimes even years) while the other documents catch up.
There is no hard and fast rule about what is an "open standard", but it generally means a stable standard that anyone can get a copy of (although they might have to pay for it) and that was made by a generally-recognized standards group. If the external standard changes, you have to reference the particular instantiation of that standard in your specification, such as with a designation of the date of the standard. Some external standards bodies do not make old standards available, which is a problem for IETF standards that need to be used in the future. When in doubt, a draft author should ask the WG chair or appropriate Area Director if a particular external standard can be used in an IETF standard.
More and more IETF standards require the registration of some protocol parameters, such as named options in the protocol. The main registry for all IETF standards has been IANA. Because of the large and diverse kinds of registries that standards require, IANA needs to have specific information about how to register the parameters, what not to register, who (if anyone) will decide what is to be registered, and so on.
Anyone writing an Internet standard that may need an IANA registry needs to read BCP 26, "Guidelines for Writing an IANA Considerations Section in RFCs", which describes how RFC authors should properly ask for IANA to start or take over a registry. IANA also maintains registries that were started long before BCP 26 was produced.
The problems of intellectual property have cropped up more in the past few years, particularly with respect to patents. The goal of the IETF is to have its standards widely used and validated in the marketplace. If creating a product that uses a standard requires getting a license for a patent, people are less likely to implement the standard. Thus, the general rule has been "use good non-patented technology where possible."
Of course, this isn't always possible. Sometimes patents appear after a standard has been established. Sometimes there is a patent on something that is so valuable that there isn't a non-patented equivalent. Sometimes, the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed.
The IETF's methods for dealing with patents in standards are a subject of much debate. You can read about the official rules in BCP 9, but you should assume that the application of those rules is flexible and depends on the type of patent, the patent holder, and the availability of alternate technologies that are not encumbered by patents.
Patent holders who freely allow their patents to be used by people implementing IETF standards often get a great deal of good will from the folks in the IETF. Such generosity is more common than you might think. For example, RFC 1822 is a license from IBM for one of its security patents, and the security community has responded very favorably to IBM for this (whereas a number of other companies have made themselves pariahs for their intractability on their security patents).
As stated earlier, not all RFCs are standards. In fact, plenty of important RFCs are not on standards track at all. Currently, there are two designations for RFCs that are not meant to be standards: Informational and Experimental. (There is actually a third, Historical, but that is reserved for things that were on standards track and have been removed due to lack of current use or that more recent thinking indicates the technology is actually harmful to the Internet.)
The role of Informational RFCs is often debated in the IETF. Many people like having them, particularly for specifications that were created outside the IETF but are referenced by IETF documents. They are also useful for specifications that are the precursors for work being done by IETF Working Groups. On the other hand, some people refer to Informational RFCs as "standards" even though the RFCs are not standards, usually to fool the gullible public about something that the person is selling or supporting. When this happens, the debate about Informational RFCs is renewed.
Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them. That is, a specification might solve a problem, but if it is not clear many people think that the problem is important, or think that they will bother fixing the problem with the specification, the specification might be labeled an Experimental RFC. If, later, the specification becomes popular, it can be re-issued as a standards-track RFC. Experimental RFCs are also used to get people to experiment with a technology that looks like it might be standards track material, but for which there are still unanswered questions.
As much as many IETF participants would like to think otherwise, the IETF does not exist in a standards vacuum. There are many (perhaps too many) other standards organizations whose decisions affect the Internet. There are also a fair number of standards bodies who ignored the Internet for a long time and now want to get a piece of the action.
In general, the IETF tries to have cordial relationships with other significant standards bodies. This isn't always easy, since many other bodies have very different structures than the IETF, and the IETF is mostly run by volunteers who would probably prefer to write standards rather than meet with representatives from other bodies. Even so, some other standards bodies make a great effort to interact well with the IETF despite the obvious cultural differences.
At the time of this writing, the IESG has some liaisons with large standards bodies, including the ITU (International Telecommunication Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO-IEC/JTC1 (The Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission). The IETF list of liaisons shows that there are many different liaisons to ISO-IEC/JTC1 subcommittees.
Given that the IETF is one of the best-known bodies that is helping move the Internet forwards, it is natural for the computer press (and even the trade press) to want to cover the actions of the IETF. Such publicity is a good thing for the IETF if it is accurate. As you can imagine, it is easy for the press to get stories about the IETF wrong, and they seem to do so regularly.
Major press errors fall into two categories: saying that the IETF is considering something when in fact there is just an Internet Draft in a Working Group, and saying that the IETF approved something when all that happened was that an Informational RFC was published. In both cases, the press is not fully to blame for the problem, since they are usually alerted to the story by a company trying to get publicity for a protocol that they developed or at least support. Of course, a bit of research by the reporter would probably get them in contact with someone who can straighten them out, such as a WG chair or an Area Director. The official press contact for the IETF is Steve Coya, who leads the IETF Secretariat.
Reporters who want to find out about "what the IETF is doing" on a particular topic would be well-advised to talk to more than one person who is active on that topic in the IETF, and should probably try to talk to the WG chair in any case. It is impossible to determine what will happen with a draft by looking at the draft or talking to the draft's author. Fortunately, all WGs have archives that a reporter can look through for recent indications about what the progress of a draft is; unfortunately, few reporters have the time or inclination to do this kind of research. Because the IETF doesn't have a press liaison, a magazine or newspaper that runs a story with errors won't hear directly from the IETF and therefore often won't know what they did wrong, so they might easily do it again later.
Read -- Review the Internet Drafts in your area of expertise, and comment on them in the Working Groups. Participate in the discussion in a friendly, helpful fashion, with the goal being the best Internet standards possible. Listen much more than you speak.
Implement -- Write programs that use the current Internet standards. The standards aren't worth much unless they are available to Internet users. Implement even the "minor" standards, since they will become less minor if they appear in more software. Report any problems you find with the standards to the appropriate Working Group so that the standard can be clarified in later revisions. One of the oft-quoted tenets of the IETF is "running code wins", so you can help support the standards you want to see become more wide-spread by creating more running code.
Write -- Edit or co-author Internet Drafts in your area of expertise. Do this for the benefit of the Internet community, not so you have your name (or, even worse, your company's name) on a document. Draft authors are subject to all kinds of technical (and sometimes personal) criticism; receive it with equanimity and use it to improve your draft in order to produce the best and most interoperable standard.
Open -- Eschew proprietary standards. If you are an implementor, exhibit a strong preference to IETF standards. If the IETF standards aren't as good as the proprietary standards, work to make the IETF standards better. If you are a purchaser, avoid products that use proprietary standards that compete with the open standards of the IETF, and tell the companies you buy from that you are doing so.
Free -- If your company controls a patent that is used in an IETF standards, convince them to make the patent available at no cost to everyone who is implementing the standard. In the past few years, patents have caused numerous serious problems for Internet standards because they prevent some companies from being able to freely implement the standards. Fortunately, many companies have generously offered unlimited licenses for particular patents in order to help the IETF standards flourish. These companies are usually rewarded with positive publicity for the fact that they are not as greedy or short-sighted as other patent-holders.
Join -- Become a member of ISOC. More importantly, urge any company that has benefited from the Internet to become a corporate member of ISOC, since this has the greatest financial benefit for the group. It will, of course, also benefit the Internet as a whole.
BCP 9, "The Internet Standards Process"
BCP 10, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees"
BCP 11, "The Organizations Involved in the IETF Standards Process"
BCP 14, "Key words for use in RFCs to Indicate Requirement Levels"
BCP 22, "Guide for Internet Standards Writers"
BCP 25, "IETF Working Group Guidelines and Procedures"
BCP 26, "Guidelines for Writing an IANA Considerations Section in RFCs"
RFC 1123, "Requirements for Internet Hosts -- Application and Support"
RFC 1796, "Not All RFCs are Standards"
RFC 2223, "Instructions to RFC Authors"
Scott Bradner, a long-time IETF participant and process watcher, made many significant contributions to this document.
Many people offered substantial suggestions to this document. They include (so far) Patrik Fältström, April Marine, and Ryan Moats.
If you have any suggestions or corrections for this document, please send them to Paul Hoffman, Director of IMC.