| Network Working Group | B. Carpenter |
| Internet-Draft | Univ. of Auckland |
| Intended status: Informational | September 8, 2018 |
| Expires: March 12, 2019 |
Some Thoughts on IETF Community Leadership
draft-carpenter-community-leaders-00
This is a personal view of what the IETF community might expect of its members who serve in leadership positions such as Area Directors and IAB members. It is intended as personal input to the Nominating Committee, but posted as a draft since there is nothing private about it.
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 https://datatracker.ietf.org/drafts/current/.
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 12, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The IETF has a relatively open but not exactly democratic way of choosing those who serve the community as Area Directors, members of the Internet Architecture Board, and as IETF Chair. Job descriptions are open and candidate lists are open. Feedback on individuals is intentionally confidential to the NomCom, which in my opinion is correct. We shouldn't be in the business of naming and shaming those who are willing to serve us. As a community, we must not hesitate to make a fuss about decisions we don't like, or to insist when we see a technical error going uncorrected. We do have a formal appeals mechanism, we do have the opportunity to send frank feedback to the NomCom every year, and we do in theory have the ultimate weapon of a recall procedure.
However, there's a gap in the above mechanisms. The job descriptions mentioned above are written by the body where there is a vacancy: by the IESG for Area Directors and the IETF Chair, and by the IAB for its own membership. That's logical as far as it goes, but it doesn't give the community as a whole the chance to say what we think we expect of those who serve in leadership positions, beyond their obligations to the IETF process rules and their technical expertise. Also, even with the best of intentions, those bodies write job descriptions to replicate themselves and what they see as a smooth-running operation. There is little scope in the job descriptions for describing desirable changes in the status quo.
To some extent this gap is filled by the formal documents that describe the IETF process, in the IESG and IAB charters, and in the Tao of the IETF. But there is little explicit description of how the leadership is expected to behave. This draft is a personal version of a more explicit approach. It's by no means definitive and has no authority. Discussion (on ietf@ietf.org?) is welcome.
A personal note: I have served in the past on the IAB (including a spell as Chair), and on the IESG as IETF Chair. I'm quite sure that I didn't live up to the expectations that follow. The people who serve on the IESG and IAB are fallible humans. But it seems reasonable to tell them, and the NomCom, what we'd like.
The NomCom also has responsibilities to select members of the future IETF Administration LLC Board and of the IETF Trust. Most of the considerations below apply also to those positions, even though the emphasis here is on the IESG and IAB. My request to the NomCom is to consider the issues below when evaluating all candidates.
First, we expect leadership. Although the IETF is basically an organisation of equals, we need Area Directors, the IESG as a whole, the IETF Chair, and the IAB to set directions and gently ensure that we make progress in those directions. (Yes, the IETF has to move in multiple directions at once.) So whatever else happens, we need the ADs, the IAB members, and the IETF Chair to behave as leaders. In this draft, I'll refer to them as "leaders" from now on. However, as leaders, they are servants of the community, not autocrats.
But at the same time, the IETF is based on rough consensus. So we expect the leaders to listen carefully to the community, and not just to the loudest or most articulate voices in the community. We expect them to be assiduous in seeking consensus, and in understanding the reasons for dissent. In fact, we expect them to enquire carefully into the reasons for dissent, and to treat dissenters respectfully. Specifically, consensus in the IESG (or IAB) is not the same thing as consensus in the IETF. We do expect the leaders to take decisions, but only when it's time to do so: after the facts are in and the community consensus is clear. Decisiveness is good. Arbitrary or rushed decisions are bad.
Precisely because dissent is healthy and consensus is usually rough rather than complete, we expect discussions among the leaders to be as public, transparent and documented as much as is reasonably possible.
We expect the leaders to question the way the IETF does business and to change it if appropriate, subject of course to community debate and consensus.
We naturally expect the leaders to leave their company and personal loyalties at the door. More difficult, we expect them to set aside their own technical biases and preferences. This is tricky, because we need their technical expertise. But arbitrary decisions are bad.
We expect the leaders to remember that a much wider technical community looks to the IETF (and to the IRTF, the IANA service, and the RFC series) to serve and protect the technical future of the Internet. So listening to the community is more than just listening to the IETF.
The IAB and the IESG both have important responsibilities in appointing community members to various positions, such as WG chairs, specific oversight committees, and the like. We expect them to make these appointments based on the good of the community as a whole, not on their own preferences or biases.
We need our technical leaders to be patient with those who don't understand. This isn't so much about technical issues, which we all presumably know how to deal with, but about the reasons why some part of IETF process is the way it is, or why a BOF proposal was refused, or why a WG wasn't chartered, or why a topic belongs in the IRTF, or why some work has been redirected to the Independent Stream, or whatever. It's all very obvious to people who've been in the IETF for years. Not so obvious to the rest of the world.
We expect the leaders not to work too hard. The IESG in particular works just as hard as it makes itself work. More precisely, today's IESG defines the work load for its successors, by approving WG charters. If fewer WGs are approved or renewed today, there will be fewer drafts to process in two years' time. We expect the IESG to say "no" quite often. In the case of BOFs and workshops, we also expect the IAB to recommend "no" quite often. Of course, the "no" should be clearly explained, and rooted in community consensus and technical evaluations
Of course, the leaders will follow IETF process rules and IETF etiquette. But we also expect them to use common sense when the rules turn out to be stupid, or simply inapplicable to a particular situation. Either suggest a change in the rules, or make an exception, while telling the community what's going on and asking for feedback. (One of the historical strengths of the IETF relative to competing bodies is our ability to put good sense over over-specific rules.)
Finally, there is a well-known and very human side effect of serving in a leadership position: hubris. The modern definition is "excessive pride or self-confidence" but the ancient Greeks had a more dramatic version: "excessive pride towards or defiance of the gods, leading to nemesis." Whichever version you choose, it's bad. We expect the leaders to remember that they are fallible and that, after a few years, they will be ordinary members of the IETF community again.
Security considerations are not discussed in this memo.
This document makes no request of the IANA.
I decided to write this based, not only on my own observations, but also on comments and suggestions from several members of the community over the years. Of course I am solely responsible for the current text.
draft-carpenter-community-leaders-00, 2018-09-08:
Initial version