Internet-Draft Letter to 2020 NomCom September 2020
Carpenter Expires March 15, 2021 [Page]
Intended Status:
B.E. Carpenter
Univ. of Auckland

Open Letter to the 2020-21 IETF Nominating Committee


This is a personal open letter to the IETF Nominating Committee for 2020-21.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 15, 2021.

Table of Contents

1. Letter

Dear NomCom members,

Thank you for serving on NomCom. It's not an easy task.

This is an open letter. These are general remarks intentionally exposed to the whole IETF community, by posting as an I-D. I do not intend to update this I-D, although of course community comments are welcome.

The IETF is at a critical moment. Various pressures have been building up for several years. They have been made worse by COVID-19, since face-to-face contact reduces misunderstandings. Clearly, change is needed. You are therefore possibly the most important NomCom since the first one in 1992.

We should not blame the individuals currently in service for the pressures that have arisen. Everybody has tried to do their best. But nevertheless, your choices for the empty seats in March 2021 matter a lot.

Of course, we need technical experts. The IETF will no longer be the IETF if you appoint people to the IESG and IAB who are not highly competent engineers. But in addition, we need people with a deep understanding of and belief in the IETF's approach to standards-making. We need people who believe in rough consensus as the best way to make effective standards, who will never use their leadership position to bias the consensus, yet will use their technical skills to achieve the best possible result. They must be open to change, and also act as agents of change themsleves. And of course, they must leave loyalty to their own employers at the door. If this sounds like an impossible target, that's because it is, but we must try.

A specific problem I have noticed in recent years is that the barrier for Proposed Standard publication has been pushed ever higher. Often this is due to IESG "DISCUSS" positions that arguably breach the IESG's own criteria for a DISCUSS, and that do not correspond to the RFC2026 definition of Proposed Standard:

  "A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances."

In other words, a PS must be good enough, but not perfect. A PS might contain errors and might fail. It is important that all IESG members understand and practice this. If not, IETF progress is severely slowed down; to get running code, we need rough consensus, not perfection.

Another general problem I have sometimes noticed among IESG and IAB members is a failure to treat their roles as servants of the community and its consensus, but rather to behave as if they are in charge. I don't want to give specific examples, because that might seem to point at individuals, and that is not my goal. But it's important that (however the outside world views their roles) they remember every day that they are the servants and the community is in charge.

It's very hard work being an IESG member, and demanding work to be an IAB member. The community should be grateful that there are always people willing to take on these roles. However, I urge NomCom to carefully verify that all the nominees understand their roles, and that they are motivated to change and improve the IETF.

Best wishes for your work, and again, thank you.

      Brian Carpenter

2. Security Considerations

Security issues are not discussed in this memo.

3. IANA Considerations

This document makes no request of IANA.

Author's Address

Brian E. Carpenter
The University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand