Bringing new work to the IETF

A guide for people who have a new idea or some proposed work they wish to bring to the IETF.

A guide for people who have a new idea or some proposed work they wish to bring to the IETF.

Introduction

The IETF sees over a thousand new ideas brought to it each year from a wide variety of people. Some of these ideas lead directly to new work items, while others contribute to other work. But many go nowhere. This guide explains how to bring new work to the IETF and what that entails.

Is the IETF the right place to bring this work?

The IETF is a Standards Development Organization (SDO) that standardizes Internet protocols, operational best practice and Internet governance processes. This checklist is to help you decide if you need an SDO, whether the IETF is the right one, and what part of the IETF you need.

Is the work suitable and ready for standardization?

The IETF prefers work where there is an identified set of likely users who are committed to working on the specification. A successful standard requires interest and active participation from a diverse community of implementers with a need to interoperate.

  • Will it be used and who will use it?. A protocol used by only one party does not need a standard. Standards help coordinate independent parties that interact to solve a problem.
  • Is there interest in an interoperable solution?. If there are already non-interoperable alternatives then the participation of the implementers of those alternatives would be an advantage.
  • Are stakeholders willing to collaborate? The standardization process entails collaboration and compromise.

If the work is suitable for standardization but not yet ready, there can still be value in bringing it to the IETF as explained further below. If the work is ready but not suitable for standardization, you may wish to consider the Independent Submissions Stream.

Is the work within scope for the IETF?

The IETF has a specific focus and so it is important to check that your proposed work item is appropriate for the IETF. What follows is a general checklist but it is not exhaustive and there are exceptions:

  • Is this an Internet-layer protocol or related operational best practice?. 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.
  • Is this work addressing a well-articulated problem?. A common cause for new work not being adopted by the IETF is that it is proposed as a solution without a clear articulation of the problem it is intended to solve.
  • Is this engineering and not research? The IETF is an engineering body and not a research body. If your proposed work is closer to research, then it would be more appropriate for the IRTF.

More information can be found in Section 4 of RFC 3935 "A mission statement for the IETF".

Write up the idea as an Internet-Draft (I-D)

If you want to bring an idea to the IETF then you should to write it up as an Internet-Draft (I-D) and submit it to the IETF or it is highly unlikely to be properly considered by other IETF participants. Writing an Internet-Draft allows you to clearly explain your idea, provide references to related work or other sources, set out your goals for the idea, and cover the key questions above. Anyone can write and submit an Internet-Draft on any subject, no permission is required.

See the Authors website to learn how to write and submit Internet-Drafts.

When you submit an I-D, you grant the IETF the necessary rights to work on the idea. This grant cannot be revoked later. You are free to patent your idea, but you are required to disclose the existence of any such patent and patents will be taken into account when deciding whether or not a particular proposed work item should progress. See our Guide to Intellectual Property Rights and the IETF for a basic introduction, and references to the relevant BCPs.

Build a community of interest

New work that has strong interest within the IETF community generally has a greater chance of making it to an RFC. There are a number of routes that can be used to build this community of interest. Proposing new work without doing the work to socialize and promote it rarely results in uptake. If no support emerges for the new work, it is unlikely to proceed.

HotRFC

Each IETF meeting opens with Requests for Conversation (HotRFC). Presenters are given four minutes each to introduce an idea or topic to the IETF community and solicit follow-up discussions in another forum. This can be an excellent way to identify others who are interested in your topic and begin collaboration. Details of how to request a slot are sent to the meeting announcement list in the weeks leading up to the meeting.

Non-WG mailing list

If a community of interest is beginning to form and it needs a place to discuss the work before taking it to a WG or DISPATCH group, then a non-working group mailing list can be requested as the place for that discussion.

Side meetings

During IETF Meetings, space is set aside for individual participants to book a room for a self-managed side meeting, a commonly used method for trying find a community of common interest. RFC6771 "Considerations for Having a Successful "Bar BOF" Side Meeting" provides advice on building a community of interest this way. Side meetings are often combined with a non-WG mailing list to allow both modes of engagement.

Find the most appropriate part of the IETF to share your I-D

There are many entry points to bring your idea to the IETF. These are not necessarily exclusive; you can try one or several.

Existing Working Groups

The IETF has over 100 Working Groups (WG), organised into several Areas. It may take some time, but you should read through the list of WGs to see if one of those covers the subject area of your proposed work item and if the charter of the WG covers the specific problem/solution described in your Internet-Draft.

When you have identified the appropriate WG for your proposed work, read our Guide to IETF Working Groups to understand how to introduce this to the WG.

Dispatch or Area Working Groups

Some areas use "DISPATCH" groups, particularly during sessions at IETF meetings, for a community discussion on new proposals. These are special groups that discuss new work and provide guidance on how and whether an idea should proceed. The specific DISPATCH sessions held at each IETF meeting vary, but could include DISPATCH (for Applications and Real-Time, Security, and/or Web and Internet Transport) and GENDISPATCH (for process-related items).

DISPATCH groups help participants identify whether the work is a good fit for the IETF, and whether it should be advanced in a particular working group, might justify a new working group, or requires further progress before entering the standards process. The DISPATCH process is limited and focused, and tends to be the best choice for I-Ds that propose a specific technology, but is equally appropriate for all types of I-D.

While presentations at DISPATCH sessions are typically focused on an I-D, the associated mailing lists can be useful places to begin a discussion even before an I-D has been written.

Each IETF Area also has an area working group; for areas without a dedicated dispatch group, one function of these area groups is to help guide new work.

Request a BOF

When you know there is good community of interest and you have a clear idea of how your ID might progress, then you can consider requesting a BOF (Birds of a Feather), which is the normal pathway to create a new WG.

Next steps

Taking an idea from initial Internet-Draft to RFC is a long process. It requires considerable skill and effort in listening, finding creative solutions, working with others, and writing clearly.

We recommend reading Being effective in the IETF as your next step and familiarizing yourself with the IETF Standards Process.