Skip to main content

The Tao of IETF

A Novice's Guide to the Internet Engineering Task Force

The "Tao of the IETF", previously published as a very long individual webpage, is in the process of being replaced by other documents covering the same topics.

This page now contains only the remaining content still to be moved across, and retains the numbering scheme from the stand-alone document for that content (i.e. it starts at "4").

The new pages that have replaced sections of the Tao of the IETF are:

Table of Contents

4 Working Groups
4.1 Working Group Chairs
4.2 Getting Things Done in a Working Group
4.3 Working Group Documents
4.4 Preparing for Working Group Meetings
4.5 Working Group Mailing Lists
4.6 Interim Working Group Meetings

5 BOFs

6 RFCs and Internet-Drafts
6.1 The Overall Process
6.2 Common Issues
6.3 Writing an Internet-Draft
6.3.1 Internet-Draft Language
6.3.2 About References
6.3.3 About Required Content
6.4 Standards-Track RFCs
6.5 RFCs Other than Standards-Track

7 How to Contribute to the IETF
7.1 What You Can Do
7.2 What Your Company Can Do

8 IETF and the Outside World
8.1 IETF and Other SDOs
8.2 Press Coverage of the IETF

4 Working Groups

The vast majority of the IETF's work is done in its many Working Groups; at the time of this writing, there are well over one hundred different WGs. BCP 25, "IETF Working Group Guidelines and Procedures," is an excellent resource for anyone participating in WG discussions. The full list of working groups can be found on the datatracker.

A WG is really just a mailing list with a bit of supervision and facilitation. You "join" the WG by subscribing to the mailing list; all mailing lists are open to anyone. Anyone can post to a WG mailing list, although non-subscribers have to have their postings approved first.

More importantly, each WG has a charter that the WG is supposed to follow. The charter states the scope of discussion for the Working Group and its goals. The WG's mailing list and face-to-face meetings are supposed to focus on only 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 Working Groups are supposed to be doing. Each WG has its own page on the datatracker.

4.1 Working Group Chairs

Each Working Group has one or two (or, rarely, three) chairs. The role of the WG chairs is described in both BCP 11 and BCP 25.

Chairs have responsibility for the technical and non-technical quality of WG output. The chair must keep the WG productive, and making progress on its drafts. Sometimes there is a WG Secretary to help. Document editors, too, are usually incentivized to make progress on their drafts. The chair must manage WG discussion, both on the list and by scheduling meetings when appropriate. Sometimes discussions get stuck on contentious points and the chair may need to steer people toward productive interaction and then declare when rough consensus has been met and the discussion is over. Sometimes chairs also manage interactions with non-WG participants or the IESG, especially when a WG document approaches publication. As you can imagine given the mix of secretarial, interpersonal, and technical demands, some Working Group chairs are much better at their jobs than others.

4.2 Getting Things Done in a Working Group

One fact that confuses many newcomers 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. This is sometimes phrased as "at the last WG meeting, we decided XXX; if you disagree please speak up by the end of the week" and you'll therefore often hear the phrase "to be confirmed on the list." There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. Finally, WG meetings aren't "drafting sessions" as they are in some other standards bodies: in the IETF, drafting is done elsewhere.

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, and that those in the minority have had a chance to explain why. Generally consensus is determined by humming: if you agree with a proposal, you hum when prompted by the chair. Most hum questions come in three parts: you hum to the first part if you agree with the proposal, to the second part if you disagree, or to the third part if you do not have enough information to make up your mind. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus; sometimes the responsible AD will also do so.

The lack of formal 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 invites all interested individuals to participate, and when it's impossible to count the participants?) A common definition and practice of humming can be found in RFC 7282: On Consensus and Humming in the IETF.

A related problem is that some people think that their topic should be discussed in the WG even when the WG chair believes it is outside the scope of the charter. If the WG agrees, they can work to re-charter so that the topic is in scope. The individual can also bring their concerns to the responsible AD.

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 Working Group 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.

4.3 Working Group Documents

There is an official distinction between WG I-Ds and individual I-Ds. A WG will have to review an individual draft before deciding if it should be adopted by the WG. The WG chairs appoint who will be the authors or editors of the I-Ds; often those who wrote the initial draft continue work on behalf of the WG. Procedures for Internet-Drafts are covered in much more detail later in this document.

For Working Group documents, the document editor serves at the pleasure of the WG Chair. There is often more than one editor for Working Group documents, particularly for complex documents. The document editor is responsible for ensuring that the contents of the document accurately reflects Working Group decisions; when a document editor does not follow the WG consensus, the WG Chairs will either be more forceful about getting changes that match the consensus or replace the document editor with someone more responsive to the WG. As a Working Group document is progressing, participants suggest changes on the Working Group's mail list (or online if the document is maintained somewhere accessible); the editors are expected to follow the discussion and make changes when there is consensus.

Sometimes a Working Group will consider several alternatives before selecting a particular Internet-Draft as a Working Group document. A Working Group will often take ideas from several of the alternatives to create a single Working Group document; in such a case, the chair determines who will be listed as authors on the title page and who will be acknowledged as contributors in the body of the document.

When a WG document is ready to progress beyond the WG, the WG Chairs will assign a "shepherd" to take over the final process. The role of the document shepherd is described in RFC 4858: Document Shepherding from Working Group Last Call to Publication. The chair, who knows the history of the draft within the WG, often does the shepherd write-up.

4.4 Preparing for Working Group Meetings

The most important thing that everyone should do before coming to a face-to-face meeting is to read the Internet-Drafts and RFCs ahead of time. WG meetings are explicitly not for education: they are for developing the group's documents and often the documented is presented as a set of slides saying "here's what changed since last meeting." Even if you do not plan to say anything in the meeting, you should read, or at least skim, the group's documents before attending so you can understand what is being said.

It's up to the WG chairs to set the meeting agenda, usually a few weeks in advance. 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 on the datatracker, and links to will be found on every full meeting agenda. Unfortunately, some WG chairs are lax (if not totally negligent) about turning them in.

The Secretariat only makes the full IETF meeting schedule 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 Working Group's meeting changes schedule. Be sure to keep track of the current agenda so you can schedule flights and hotels. But, when it comes down to it, you probably shouldn't 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 I-Ds and RFCs for those groups. Work in the IETF is often reciprocal, contribute positively to others work and you are more likely to receive comments and feedback on your work.

If you are on the agenda at a face-to-face meeting, you should prepare a few slides and mail them to the chair before the meeting. Don't come with a tutorial; people are supposed to read the I-Ds in advance. Projectors for laptop-based presentations are available in all the meeting rooms.

And here's a tip for your slides: don't put your company's logo on every one, even though that is a common practice outside the IETF. The IETF frowns on this kind of corporate advertising (except for the meeting sponsor in the plenary presentation), and most presenters don't even put their logo on their opening slide. The IETF is about technical content, not company boosterism. Slides are often plain black and white for legibility, with color used only when it really adds clarity. Again, the content is the most important part of the slides, not how it's presented.

One thing you might find helpful, and possibly even entertaining, during Working Group sessions is to follow the running commentary on the Jabber room associated with that Working Group. Jabber is a free, streaming XML technology mainly used for instant messaging. You can find pointers to Jabber clients for many platforms at (https://xmpp.org/xmpp-software/clients). The Jabber chatrooms have the name of the Working Group followed by "@jabber.ietf.org". Those rooms are, in fact, available year-round, not just during IETF meetings, and some are used by active Working Group participants during protocol development.

4.5 Working Group Mailing Lists

As we mentioned earlier, the IETF announcement and discussion mailing lists are the central mailing lists for IETF activities. However, there are many other mailing lists related to IETF work. For example, every Working Group has its own discussion list. In addition, there are some long-term technical debates that have been moved off of the IETF list onto lists created specifically for those topics. It is highly recommended that you follow the discussions on the mailing lists of the Working Groups that you wish to attend. The more work that is done on the mailing lists, the less work that will need to be done at the meeting, leaving time for cross pollination (i.e., attending Working Groups outside one's primary areas of interest in order to broaden one's perspective).

The mailing lists also provide a forum for those who wish to follow, or contribute to, the Working Groups' efforts, but can't attend the IETF meetings. That's why IETF procedures require all decisions to be confirmed "on the list" and you will often hear a WG chair say, "Let's take it to the list" to close a discussion.

Every WG has a dedicated page on the datatracker site, and the "About" tab will point to mailing list subscription and archives.

4.6 Interim Working Group Meetings

Working Groups sometimes hold interim meetings between IETFs. Interim meetings aren't a substitute for IETF meetings, however — a group can't decide to skip a meeting in a location they're not fond of and meet in Cancun (or even someplace mundane) three weeks later, for example. Interim meetings need to be announced at least one month in advance. Location and timing need to allow fair access for all participants. Like regular IETF meetings, someone needs to take notes and the group needs to take attendance. Decisions tentatively made during an interim WG meeting must still be confirmed on the mailing list. Interim meetings are subject to the IETF Note Well. Most interim meetings are virtual these days and have the same reporting requirements as face-to-face virtual meetings.

The IESG has rules for advance notice on time and place of interim Working Group meetings, as well as reporting the results of the meetings. The purpose of these rules is to make interim meetings accessible to as many Working Group members as possible and to maintain the transparency of the Working Group process.

5 BOFs and Dispatching

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 without an initial meeting.

A Birds of a Feather (BOF) meeting has to be approved by the Area Director in the relevant area, in consultation with the IESG and the IAB, before it can be scheduled. If you think you need a new WG, approach an AD with your proposal and see what they think. You will have to write some informative background text, and they will work with you to get it scheduled. Of course, you can also gather interested people and work on a draft charter in the meantime.

BOF meetings have a very different tone than do WG meetings. The purpose of a BOF is to make sure that a good charter with good milestones can be created, that there are enough people willing to do the work needed in order to create standards, and that any standards would get adoption. Often a self-selected group of key people will get together after the BOF to refine the draft charter.

Generally, there are only two BOF meetings allowed for the same topic. Sometimes it is obvious after one meeting that a WG should be created, and sometimes it is obvious a WG would not be successful.

If you have a draft already written, you can submit it to the relevant "dispatch" WG. Each area has one of these. Their job is to review submitted documents, and come to a decision about the next steps: possibilities include create a new WG, send to an existing WG, hold a BOF, and so on.

An advantage of using the dispatch WG compared to a BOF is that the discussion is more limited and focused. On the other hand, a draft might tend to limit what the other folks in the BOF want to do in the charter. Remember that most BOFs are held in order to get support for an eventual Working Group, not to get support for a particular document.

6 RFCs and Internet-Drafts

This section discusses Internet-Drafts and RFCs in the IETF stream, that is, it describes how documents are produced and advanced within the IETF. For a brief note on other RFC streams, see above.

If you're a new IETF participant and are looking for a particular RFC or Internet-Draft, you can use the IETF Datatracker. This website, https://datatracker.ietf.org/, has a text search capability (including content, keywords, author, and so on), and the search results point to the document status, page count, and other useful information. A little-known hint is that dt.ietf.org is an abbreviation (a DNS CNAME entry) for the longer "datatracker.ietf.org" hostname.

Most RFCs in the IETF stream follow the same process, and the sections below discuss the process and some of the issues. Note that there are other ways to get an RFC published, particularly if it is not intended for the standards track. For the sake of brevity, we will not mention those here. After all, this document is about "the Way of the IETF" and the main Way is "developing standards."

If you are interested in learning more about how to author an Internet-Draft yourself, the I-D Authors website has a lot of information and resources, including pointers to online tools that can help.

6.1 The Overall Process

The very first step is to have a draft document. Internet-Drafts should follow a specific format, and are required to have particular sections. This will be discussed more below.

RFCs are generally written by a Working Group. If an appropriate WG doesn't seem to exist, then the BOF or Dispatch process mentioned above can be used to learn which one is appropriate, or start the process to create one.

Once a potential WG exists, the document must be adopted. To do this, you submit your individual draft to the datatracker. It should start with draft-YOURNAME-brief-subject where YOURNAME is your name. Send a note to the WG mailing list, with an introduction to the draft, and why you think it is appropriate. After any discusison, the WG Chair will issue a call for adoption. If consensus is to adopt the draft, you will be asked to submit it with the name draft-ietf-WGNAME-brief-subject; you can probably guess what WGNAME should be.

At this point, the IETF, notably the IETF Trust, now owns the copyright on the document and the IETF owns the right of "change control." This means the WG, and the overall IETF, can make any changes to the document, the one you initially wrote, that they want. If you are not comfortable with this, then the IETF is not the place for your document. There are a few more details on this below.

The WG now "works on" the document. This will be a combination of mailing list discussion, perhaps agenda time at a meeting, and publishing updated drafts. (Every draft ends with -NN where the digits indicate the draft number.)

At some point, the document will seem finished. The WG Chair will put the document in WG Last Call (WGLC) which gives the members of the WG a chance for last-minute changes. It can be frustrating to get a bunch of changes after you think you're done, but don't take it personally. Like many things, people are often deadline-driven.

After WGLC, the responsible AD (the one who oversees the WG) does a review. They will probably have comments that must be resolved by you and the WG; it's quite likely you'll have to publish a new draft. Then the IESG and the overall IETF reviews the draft, as mentioned above. The purpose of IETF Last Call is to get community-wide discussion on documents before the IESG considers them. Note the word discussion here. It is generally considered bad form to send IETF Last Call comments on documents that you have not read, or to send comments but not be prepared to discuss your views. The IETF Last Call is not a vote. Having said that, IETF Last Call comments that come from people who have just read the document for the first time can expose issues that IETF and WG regulars may have completely missed, which is why the discussion is open to everyone.

Finally, the draft is given to the RPC Production Center (RPC), and prepared for publication. There might be other changes required, including reviews by IANA for registrations and the like. The most common item you'll hear about this is AUTH48 state, which means the document is in the final stages of copy-editing by the RPC and you. The publication process can take weeks, but be patient, and you'll eventually see an email announcement saying that your brand-new RFC has been published. Congratulations!

A much more complete explanation of these steps is contained in BCP 9. This set of documents 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 rankings.

6.2 Common Issues

There are two major issues that often come up while preparing I-Ds: copyright and patents.

We discussed copyright above, but expand on it here. When the IETF adopts a Internet-Draft, it is required that the boilerplate, the common text that appears in every draft, has a notice that says the IETF, and the document authors own the copyright. This means that while the IETF can do what it wants with the document, within limitations so can you. You cannot, for example, claim this is an IETF standard, nor use the IETF trademarks.

Incidentally, the change control on Internet standards doesn't end when the RFC is published. Things can be changed later for a number of reasons, such as to solve a newly-discovered problem or address new use-cases. These later changes are also under the control of the IETF, not the editors of the standards document.

The second issue is patents. The goal of the IETF is to have its standards widely used and validated by 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. Not surprisingly, then, 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 and there is little the IETF can do about that. Sometimes there's a patent on something that is so valuable that there isn't a non-patented equivalent, and generally the IETF tries to avoid it.

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. Ideally, and this is the common case when a patent-holder is active in a document, the patent holder will grant free use of the patent to implement the specification.

The official rules for all intellectual property rights (IPR) in IETF documents, not just patents but also code samples and the like, are covered in BCP 78 and BCP 79.

If you are writing an Internet-Draft and you know of a patent that applies to the technology you're writing about, don't list the patent in the document. Instead, consult the IPR disclosures page. If you still have issues, consult with the WG Chair or the responsible AD. Intellectual property rights aren't mentioned in RFCs because RFCs never change after they are published, while knowledge of IPR can change at any time. Therefore, an IPR list in an RFC could be incomplete and mislead the reader. BCP 79 provides specific text that should be added to RFCs where the author knows of IPR issues.

6.3 Writing an Internet-Draft

Every RFC starts its life as an I-D. Internet-Drafts have the same format as an RFC, and are required to have all the content that should appear in the RFC. This includes a couple of sections detailed below. A draft may also have more information, such as an incremental list of changes from previous versions of the draft, or pointers to online locations for raising issues and suggesting changes.

For the past several years, the official canonical source of RFCs as RFC 7991: The "xml2rfc" Version 3 Vocabulary. Some people enjoy writing in XML, and some don't. An alternative for the second group is to use a specific dialect of markdown, which is then converted to XML as needed (and especially during the publication process). A recent trend is the increasing use of markdown, and hosting I-Ds on GitHub to attract a wider audience of Internet-savvy users. Some information on this can be found at RFC 8874: Working Group GitHub Usage Guidance.

The IETF is setting up a new site, https://authors.ietf.org, to contain guides and online tools to help both new and experienced authors. As of this writing, it's still a draft but it does contain a great deal of useful content. You should feel free to use the site, and offer feedback.

Outside of the formatting decision, the most important document you can read is Guidelines to Authors of Internet-Drafts. That document explains the naming conventions, formatting requirements, required content, and details of how to submit (also called post) your draft.

6.3.1 Internet-Draft Language

It is common for Internet-Drafts that revise existing RFCs to have draft names with "bis" in them, meaning "again" or "twice." For example, a draft might be called "draft-ietf-uta-rfc6125bis" meaning that this is intended to be a revision of, and eventual replacement for, RFC6125.

Writing clear specifications can be a bit of an art, particularly for people who don't have English as their native language. 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 way to make it more likely that developers will create interoperable implementations of standards is to be clear about what's being mandated in a specification. Over time, the IETF has realized that defining a few words with specific meanings helps a great deal. BCP 14 defines about a dozen keywords that can be used to clarify what are requirements, as compared to what is purely informative. It defines the meaning of words like MUST and points out that it has to appear in all uppercase to its special meaning.

It is not uncommon for feedback on standards-track I-Ds to question the particular uses of what is called "2119 language." For example, "The document says MAY but doesn't explain why not; should it be a MUST?"

6.3.2 About References

One aspect of writing IETF standards that trips up many newcomers 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 (sometimes called an informative reference) is one that is helpful to an implementor but not strictly needed to implement it.

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 Internet Standard, all of the RFCs that appear as a normative reference must also be an Internet Standard. This rule gives implementors assurance that everything in a Internet standard is quite stable, even the things referenced outside the standard. This rule, and its exceptions, is described in BCP 97.

There is no hard-and-fast rule about what is an "open standard", but generally this means a stable standard that was made by a generally-recognized SDO, and that anyone can get a copy of, although not necessarily for free. If the external standard changes, you have to reference the particular instantiation of that standard in your specification, as with a designation of the date of the standard. Some external standards bodies don't make old standards available, which is a problem for IETF standards that need to be used in the future. When in doubt, ask the WG chair or AD if a particular external standard can be used in an IETF standard.

6.3.3 About Required Content

Every draft is required to have some content. Some of this is boilerplate text about copyright, "2119 keyword," and so on. The document formatting tools will generate this for you automatically if you use the right keyword. In addition, there are special sections that might be required for your draft, and you (and the WG) will have to write them.

Many IETF standards have extension points, such as unassigned fields in a message header, or for something like email or HTTP, an actual message header. As mentioned above, IANA maintains online registries for these. Because of the large and diverse kinds of registries that standards require, IANA needs to have specific information about how to register parameters, what not to register, who (if anyone) approves any registration requests, and so on.

Anyone writing a draft that needs one or more registries, or adds values to existing registries must have an "IANA Considerations" section. Authors should read BCP 26, "Guidelines for Writing an IANA Considerations Section in RFCs," which describes how to properly ask for IANA to make the changes requested in their draft. If there are no considerations, it is a good idea to have the section and explicitly say "This document has no IANA requests."

Every draft must have a "Security Considerations" section. This describes possible threats or attacks, known vulnerabilities, information that could be exposed, and so on. It should also describe any strategies or mechanisms to mitigate them. When the security directorate (SECDIR) reviews your draft, this section will be one of their major focuses. Don't gloss over the section, or say things like "use TLS to get security" without explaining how the protocol uses TLS and what it provides. See BCP 72, "Guidelines for Writing RFC Text on Security Considerations", for more information on writing good security considerations sections.

Also, a draft might have a "Privacy Considerations" section. An Informational RFC, RFC 6973: Privacy Considerations for Internet Protocols, written by the IAB, is intended to raise the general awareness of privacy on the Internet. It also provides advice for when a draft should have an explicit privacy section.

Some drafts benefit from having an "Implementation Status" section, as explained by BCP 205: Improving Awareness of Running Code: The Implementation Status Section.

More detail on the required content can be found online.

6.4 Standards-Track RFCs

If the IESG approves the draft to become a standards-track RFC, they ask the RPC to publish it as a Proposed Standard.

Don't be surprised if a particular standard doesn't progress from Proposed Standard to Internet Standard. To become an Internet Standard, an RFC must have multiple interoperable implementations and the unused features in the Proposed Standard must be removed; there are additional requirements listed in BCP 9. Most of the protocols in common use are Proposed standards and never move forward. This may be because no one took the time to try to get them to Internet Standard, or some of the normative references in the standard are still at Proposed standard, or it may be that everyone found more important things to do.

6.5 RFCs Other than Standards-Track

As mentioned earlier, not all RFCs are standards. In fact, many important RFCs are not on the standards track at all. At the time of writing, there are also categories for Informational, Experimental, Best Current Practice, and Historical for standards that are no longer recommended for use. The role of Informational RFCs can be confusing, and people sometimes refer to them as "standards," when they are not.

Experimental RFCs are for specifications that are interesting, but for which it is unclear if there will be widespead deployment, or if they will scale to work after such deployment. That is, a specification might solve a problem, but there might not be IETF consensus that the problem is worth solving or that the specification is complete enough to address the problem. 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.

The IESG has created guidelines that can help choose between Informational and Experimental classification. This is a short informal read, and if are not sure where your document fits, it is worth reading.

Finally, there are two sub-series of RFCs: Best Current Practice (BCP) and Internet Standards (STD). BCP describes the application of various technologies in the Internet, and are also commonly used to document the many parts of the IETF process. The STD sub-series was created to identify RFCs that do in fact specify Internet standards.

These are an example of the aphorism that everything in computer science can be solved by a layer of indirection. For example, a single BCP can refer to one or more RFCs, and the specific RFCs can change such as when a new version of a protocol is published. Likewise, some STDs are actually sets of more than one RFC, and the "standard" designation applies to the whole set of documents.

7 How to Contribute to the IETF

7.1 What You Can Do

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. If you disagree, debate the technical issues: never attack the people.

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. Remember the tenet, "rough consensus and running code," so you can help support the standards you want to become more widespread by creating more running code. You can help the development of protocols before they become standards by implementing I-Ds (but not doing wide-spread deployment) to ensure that the authors have done a good job. If you find errors or omissions, offer improvements based on your implementation experience. A great way to get involved in this is by participating in the Hackathons.

Write: Edit or co-author Internet-Drafts in your area of expertise. Do this for the benefit of the Internet community, not to get your name (or, even worse, your company's name) on a document. Draft authors receive kinds of technical (and, sadly, sometimes personal) criticism. Take the technical comments with equanimity and use it to improve your draft in order to produce the best and most interoperable standard, and ignore the personal ones.

7.2 What Your Company Can Do

Share: Avoid proprietary standards. If you are an implementor, exhibit a strong preference for IETF standards. If the IETF standards aren't as good as the proprietary standards, work to make the IETF standards better. If you're a purchaser, avoid products that use proprietary standards that compete with the open standards of the IETF and tell the vendors that you are doing so.

Open Up: If your company owns a patent that is used in an IETF standard, convince the company to make the patent available at no cost to anyone who is implementing the standard. Patents have previously caused many serious problems for Internet standards because they prevent some companies from being able to freely implement them. 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.

Support: The IETF has sponsorship opportunities and an endowment which can also take individual-sized donations. Become a member of ISOC. Urge any company that has benefited from the Internet to contribute, since this has the greatest financial benefit for the group. It will, of course, also benefit the Internet as a whole.

8 IETF and the Outside World

While some IETF participants would like to think otherwise, the IETF does not exist in a standards vacuum. This section discusses two important groups.

8.1 IETF and Other SDOs

There are many other standards organizations whose decisions affect the Internet. Some of them 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 SDOs. This isn't always easy, since they usually have different structures and processes than the IETF does, 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, man SDOs make a great effort to interact well with the IETF despite the obvious cultural differences.

As stated in BCP 39, the IAB Charter: "Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications." In practice, the IETF prefers liaisons to take place directly at the WG level, with formal relationships and liaison documents in a backup role. The best place to check to see whether the IETF has any formal liaison at all is the list of IETF liaisons.

At the time of this writing, the IETF has around two dozen liaisons. Some of these liaison tasks fall to the IESG, whereas others fall to the IAB. Full details about the processes for dealing with other SDOs can be found in BCP 102 and BCP 103.

8.2 Press Coverage of the IETF

Given that the IETF is one of the best-known bodies that is helping move the Internet forward, it's natural for the media to cover its actions. But it can be hard to cover the IETF; a common mistake is reporting an individual's Internet-Draft as something the IETF is working on, or that the IETF has approved a new standard when it was an Informational or Individual RFC. Often, the press is not really to blame for the problem, as they might have been alerted to the story by a company trying to get publicity for a protocol, or they see the latest "controversy" on social media.

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's 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.

Reporters looking for information about the IETF, or pointers to IETF participants working on a particular topic relevant to the IETF, should send a message to media@ietf.org, and a full page of contacts for a variety of needs is available online. Replies are usually sent within a day. Even if a direct answer to a particular query is not available, pointers to resources or people who can provide more information about a topic are often provided.

Next IETF Hackathon

The IETF 119 Hackathon will be held Online and in Brisbane.

Register for the next IETF Hackathon!