Being effective in the IETF

A few specific approaches and practices can make participation in the IETF more effective.

Introduction

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.

It takes many people with many different views to build a resilient protocol

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.

Doing the backgound reading

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.

Send text

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.

Following the IETF cadence

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.

Working with asynchronous mailing lists

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.

Keeping up with IETF Meetings

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 when all the participants are able to get together in realtime.

The IETF comes together for a meeting three times a year and the cadence of participation changes significantly as people aim to get the most from a week long meeting. In the run ip to a meeting, there is always a flurry of new I-Ds and new versions of I-Ds, often preceded by lots of mailing list activity to agree changes to go into those new versions.

Then, during the meeting itself, there are the sessions (not all WGs meet at any IETF meeting, but most do) often with intense, in-depth discussions. These are often followed by significant mailing list activity and new versions of documents based on the discussions.

However, and this is a key point to remember, meetings are non-decision making - any proposed decisions have to be taken to the mailing list after the meeting to ensure that anyone who could not make the meeting has a chance to engage.

If you can't make a session for a WG that you are actively tracking, then it is strongly recommended that you watch the video of the session otherwise you will miss out on some important context. The video recordings are in the public video archive and the materials for each session (presenations, notes, agenda) are posted for every past meeting on the IETF Datatracker.

Using email for a structured discussion

Email is a tool that can be used in many different ways, and in the IETF there is a particular way that is the most productive and the most effective. This is not about netiquette or some old-fashioned idea of how email should be used - this is a specific method that uses email very similarly to issue trackers such as GitHub, and thereby makes it as easy as possible for other readers to follow and later reference a discussion.

Remember, reading email is time-consuming and takes mental effort. Nobody is required to read your emails, not even document authors or WG chairs. The more you can do to structure your emails to mimimise the time and effort required by other readers, the more effective your emails will be.

Short and to-the-point

If you write a very long email without breaking it up with headings and other structure then people will either skim read it and miss important nuances, just read the first few lines, or not even read it at all.

There are times when you might have good reason to write a very long email. In these cases, use structure to help people read them - headings, bullets, introductions, summaries, etc. Alternatively, consider if the ideas you want to put forward would be better presented as an Internet-Draft.

Threads and useful subject lines

A sequence of emails, replies to replies, is called a thread and most email clients arrange emails into threads to make them easier to read. The IETF mailing list archive, displays all messages as threads.

When you have something new to say, start a new thread with a new email that is not a reply to another email. You do not need any permission to do so. Seperate threads are much easier for people to read and refer to later.

If your reply to an existing thread is moving to a different topic from the subject line, then change the subject line to indicate this. It is not rude or presumptuous to change the subject line of a thread, it is a necessary discipline so that readers know what the emails are about.

Replying below quoted text

It is common practice in business email for people to press reply and write something at the top, keeping a copy of every previous reply in the message below. In the IETF context this is a real problem for these reasons: 1. It makes it much more difficult for people to follow a complex discussion with multiple points being made by multiple people. 2. Some participants use email clients that do not hide quoted text very well and so this makes it much harder for them to follow the discussion. 3. Every message appears in the public archive, and this practice clutters the archive, reducing its utility as a reference tool.

Instead, the following practice is recommended:

  • Reply to individual points individually, below quoted text from the message that you are replying to. This allows the reader to immediately understand the context of your reply and makes your reply much more effective, particularly if you want the reader to act on it.
  • Cut down the quoted text that you are replying to, to the minimum required to provide the context for your reply. It is not rude to remove 99% of someone's message and just quote the sentence/phrase that you want to reply to. This focuses the conversation and ensures that other readers do not waste time re-reading unnecessary text.

As an example, if someone writes:

I think we should add X to this because 1. Reason A. My explanation for reason A is ... 2. Reason B. My explanation for reason B is ... 3. Reason C. My explanation for reason C is ...

If you want to say something about reasons A and C you should reply as follows (note the editing of the quoted text to remove the explanations and to remove everything about reason B):

I think we should add X to this because 1. Reason A.

My thoughts on reason A are ...

  1. Reason C.

My thoughts on reason C are ...

It is fine to reply to multiple messages in one response, if the points they have made are sufficiently related that this is needed. All you need do is quote one message and add your reply, and then quote the next message and reply.

Problems with rich text formatting

Using rich text formatting attributes, such as colour or italic, to highlight specific text (e.g. "replies in red") is problematic for a number of reasons: it is insensitive to those with vision disabilities; a surprising number of people use mail clients that do not show HTML; and all of that context is lost in the archives as those are only plain text. If possible, it is better to avoid rich text altogether as the message you think you are sending may not be what is received. Most modern email clients have a setting that will allow you to compose emails using plain text only.

General style of communications

The IETF is an engineering organisation, where many participants write/talk directly and concisely and similarly expect to read/listen to direct and concise communication. This can sometimes come across as rudeness or impatience when neither were intended. Of course, politeness helps with participant interaction and is positively encouraged.

Reading words as written, without assuming any tone or underlying intent, can be difficult at times and a good tip when you are reading an email (or even when you are writing your own emails), is to imagine it being spoken in a slow, neutral, engineering tone, even if you know the author.

The IETF has clear expectations for participant behaviour and 'communication style' can never be an excuse for inappropriate behaviour.