IETF | Being effective in the IETF

The IETF works on a broad range of networking technologies that provide the foundation for the Internet's growth and evolution.
While most IETF work takes place online, meetings and other events such as Hackathons provide in-person opportunities to advance work within the IETF.
The IETF is the premier Internet standards organization. It follows open and well-documented processes for setting these standards. Once published, those standards are made freely available.
The global IETF community works together in many different ways to produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
By supporting the IETF today, you are ensuring a free and open Internet exists tomorrow.
A few specific approaches and practices can make participation in the IETF more effective.
Participating in the IETF and having your views listened to and your contributions actively shaping the work is a very rewarding experience. Getting to that point means acquiring knowledge of IETF processes and adopting a small set of helpful practices. What follows is a guide to that set of practices, a guide to being effective in the IETF.
The IETF has, for decades, successfully produced protocols that are resilient and performant at Internet scale. The core reason for this is because each protocol has been built by the combined efforts of many people with many different views scrutinising every aspect of the design until consensus is reached. Ideas brought to the IETF do not belong to individuals and may change shape beyond all recognition from conception to completion. To be effective in the IETF it is essential that you recognise this and embrace that way of working.
This means that when somebody raises a point that you do not think is relevant, or do not think is important enough to address, try hard to see if you can adjust your own desired outcome to incorporate this point. Your aim should not be to get the outcome that you want, but an outcome that you can live with. This is key to reaching consensus.
The other side of this, is that as an IETF participant you are free to comment on any idea that is proposed. You do not need an invitation.
The context for any IETF discussion is in the relevant Internet-Drafts, related RFCs and list archives. Doing the background reading to understand this context is vital for effective participation.
Internet-Drafts (I-Ds) are the core mechanism for IETF participants to share ideas. These often refer to RFCs or other I-Ds by way of background. If you want to fully participate in any discussion in the IETF then you will need to read the I-Ds related to that discussion and any RFCs or other documents that they refer to. Each WG has a page that lists that group's published RFCs and adopted I-Ds. WGs are notified about unadopted but relevant I-Ds via the WG mailing list by the authors.
All IETF mailing lists have a public archive and there are many times when it is important to read the list archive in order to participate effectively. These include: * If you want to raise something and have a suspicion that this might have been raised before. * If you think you may have missed some important context. * If other participants say that something has been raised before and that's why they don't want to discuss it again.
Altogether, this can mean a lot of reading, but if you do not do it then you are unlikely to have the necessary context to engage in the discussion and there is a risk that others recognise this and choose not to listen to you.
The IETF works on proposed text and proposed changes to that text. It is so much better to say "I don't like this text because of X, and here is some alternative text that fixes that" because this turns your point into something actionable. It is common to see the two-word response to a point raised - "send text".
There are two other major benefits from sending text. The first is that it will help you focus your thoughts into clear and precise language that says what you want it to say. The second is that it helps people understand what you are saying, particularly because of the focus it brings. Every IETF participant will have come across a situation where a point only becomes clear when someone turns it into proposed text.
The importance of sending text cannot be overstated - this is possibly the most common reason that people feel rejected, because they make a good suggestion but don't propose text and nobody else does it for them. There are some circumstances when WGs expect document editors/authors to produce text to cover the points raised, but this is imperfect and can be missed, or the text may not be as you expect it.
The IETF is a global organisation with its participants spread across so many different timezones. Added to this, most IETF participants are volunteers with other responsibilities to balance. For those reasons, the IETF has a natural cadence to participation that is slow and asynchronous most of the year round, but then bursts into rapid activity three times a year when the IETF comes together for a meeting. Understanding and following this cadence is important as it drives so much of the progress on the work of the IETF.
The latency between messages on IETF mailing lists can run into days or even weeks. As this is quite different from what people are used to, some useful tips are: * Do not feel obliged to reply quickly to a point. A quick reply will generally have less impact than a reply that comes some time later after careful thought. * Don't assume that if you don't receive any replies to your email the same day (or even longer) that nobody has anything to say.
Working Group (WG) sessions at IETF meetings (and interim meetings) are a crucial way of speeding up the usually asynchronous process as they enable a lot of issues to be discussed in a very short session. There are many examples of long and protracted discussions on a mailing list being resolved in minutes w