< draft-carpenter-community-leaders-00.txt   draft-carpenter-community-leaders-01.txt >
Network Working Group B. Carpenter Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational September 8, 2018 Intended status: Informational June 20, 2019
Expires: March 12, 2019 Expires: December 22, 2019
Some Thoughts on IETF Community Leadership Some Thoughts on IETF Community Leadership
draft-carpenter-community-leaders-00 draft-carpenter-community-leaders-01
Abstract Abstract
This is a personal view of what the IETF community might expect of This is a personal view of what the IETF community might expect of
its members who serve in leadership positions such as Area Directors its members who serve in leadership positions such as Area Directors
and IAB members. It is intended as personal input to the Nominating and IAB members. It is intended as personal input to the Nominating
Committee, but posted as a draft since there is nothing private about Committee, but posted as a draft since there is nothing private about
it. it. A particular emphasis is placed on the need for such members to
be responsive to the community as a whole rather than to impose
personal opinions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2019. This Internet-Draft will expire on December 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 17 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Expectations . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Expectations . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
The IETF has a relatively open but not exactly democratic way of The IETF has a relatively open but hardly democratic way of choosing
choosing those who serve the community as Area Directors, members of those who serve the community as Area Directors, members of the
the Internet Architecture Board, and as IETF Chair. Job descriptions Internet Architecture Board, and as IETF Chair. Job descriptions are
are open and candidate lists are open. Feedback on individuals is open and candidate lists are open. Feedback on individuals is
intentionally confidential to the NomCom, which in my opinion is intentionally confidential to the NomCom, which tends to limit
correct. We shouldn't be in the business of naming and shaming those transparent discussion of both abilities and potential problems.
who are willing to serve us. As a community, we must not hesitate to Indeed, we shouldn't be in the business of naming and shaming those
make a fuss about decisions we don't like, or to insist when we see a who are willing to serve us. However, as a community, we must make a
technical error going uncorrected. We do have a formal appeals fuss about decisions we don't like, and persist when we see a
mechanism, we do have the opportunity to send frank feedback to the technical error going uncorrected. In particular we should make a
NomCom every year, and we do in theory have the ultimate weapon of a fuss about failures to adequately consult the community about
recall procedure. important decisions, when leaders appear to impose personal opinions.
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. But ultimately, if
the NomCom appoints someone, they are normally there for several
years.
However, there's a gap in the above mechanisms. The job descriptions 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 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 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 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 give the community as a whole the chance to say what we think we
expect of those who serve in leadership positions, beyond their expect of those who serve in leadership positions, beyond their
obligations to the IETF process rules and their technical expertise. obligations to the IETF process rules and their technical expertise.
Also, even with the best of intentions, those bodies write job Also, even with the best of intentions, those bodies write job
descriptions to replicate themselves and what they see as a smooth- descriptions to replicate themselves and what they see as a smooth-
skipping to change at page 3, line 7 skipping to change at page 3, line 14
leadership is expected to behave. This draft is a personal version 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 of a more explicit approach. It's by no means definitive and has no
authority. Discussion (on ietf@ietf.org?) is welcome. authority. Discussion (on ietf@ietf.org?) is welcome.
A personal note: I have served in the past on the IAB (including a 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 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 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 serve on the IESG and IAB are fallible humans. But it seems
reasonable to tell them, and the NomCom, what we'd like. reasonable to tell them, and the NomCom, what we'd like.
The NomCom also has responsibilities to select members of the future The NomCom also has responsibilities to select members of the IETF
IETF Administration LLC Board and of the IETF Trust. Most of the LLC Board and of the IETF Trust. Most of the considerations below
considerations below apply also to those positions, even though the apply also to those positions, even though the emphasis here is on
emphasis here is on the IESG and IAB. My request to the NomCom is to the IESG and IAB. My request to the NomCom is to consider the issues
consider the issues below when evaluating all candidates. below when evaluating all candidates.
2. Expectations 2. Expectations
First, we expect leadership. Although the IETF is basically an First, we expect leadership. Although the IETF is basically an
organisation of equals, we need Area Directors, the IESG as a whole, 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 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 we make progress in those directions. (Yes, the IETF has to move in
multiple directions at once.) So whatever else happens, we need the multiple directions at once.) So whatever else happens, we need the
ADs, the IAB members, and the IETF Chair to behave as leaders. In 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 this draft, I'll refer to them as "leaders" from now on. However, as
leaders, they are servants of the community, not autocrats. leaders, they are servants of the community, not autocrats. They are
not in charge and must not imagine that they are in charge; they
should not impose personal opinions. People who think they are being
appointed to be in charge hould not be appointed.
But at the same time, the IETF is based on rough consensus. So we The IETF is based on rough consensus. So we expect the leaders to
expect the leaders to listen carefully to the community, and not just consult and listen carefully to the community, and not just to the
to the loudest or most articulate voices in the community. We expect loudest or most articulate voices in the community. We expect them
them to be assiduous in seeking consensus, and in understanding the to be assiduous in seeking consensus, and in understanding the
reasons for dissent. In fact, we expect them to enquire carefully reasons for dissent. In fact, we expect them to enquire carefully
into the reasons for dissent, and to treat dissenters respectfully. into the reasons for dissent, and to treat dissenters respectfully.
Specifically, consensus in the IESG (or IAB) is not the same thing as 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, 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 but only when it's time to do so: after consultations, after the
community consensus is clear. Decisiveness is good. Arbitrary or facts are in and the community consensus is clear. Decisiveness is
rushed decisions are bad. good. Arbitrary or rushed decisions are bad.
Precisely because dissent is healthy and consensus is usually rough Precisely because dissent is healthy and consensus is usually rough
rather than complete, we expect discussions among the leaders to be rather than complete, we expect discussions among the leaders to be
as public, transparent and documented as much as is reasonably as public, transparent and documented as much as is reasonably
possible. possible. Fuzzy explanations of decisions are not good enough.
We expect the leaders to question the way the IETF does business and We expect the leaders to question the way the IETF does business and
to change it if appropriate, subject of course to community debate to change it if appropriate, subject of course to community debate
and consensus. and consensus.
We naturally expect the leaders to leave their company and personal We naturally expect the leaders to leave their company and personal
loyalties at the door. More difficult, we expect them to set aside loyalties at the door. More difficult, we expect them to set aside
their own technical biases and preferences. This is tricky, because their own technical biases and preferences. This is tricky, because
we need their technical expertise. But arbitrary decisions are bad. we need their technical expertise. But arbitrary decisions are bad.
We expect the leaders to remember that a much wider technical We expect the leaders to remember that a much wider technical
community looks to the IETF (and to the IRTF, the IANA service, and 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 the RFC series) to serve and protect the technical future of the
Internet. So listening to the community is more than just listening Internet. So listening to the community is more than just listening
to the IETF. to the IETF.
The IAB and the IESG both have important responsibilities in The IAB and the IESG both have important responsibilities in
appointing community members to various positions, such as WG chairs, appointing community members to various positions, such as WG chairs,
specific oversight committees, and the like. We expect them to make specific oversight committees, liaisons, and the like. We expect
these appointments based on the good of the community as a whole, not them to make these appointments based on the good of the community as
on their own preferences or biases. a whole, not on their own preferences or biases. In some cases, such
as the RFC Series, the IETF Trust, or IANA, the community is much
wider than the IETF: it is the entire Internet technical community.
We need our technical leaders to be patient with those who don't 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 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 hopefully 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, 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 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 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 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. for years. Not so obvious to the rest of the world.
We expect the leaders not to work too hard. The IESG in particular 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 works just as hard as it makes itself work. More precisely, today's
IESG defines the work load for its successors, by approving WG IESG defines the work load for its successors, by approving WG
charters. If fewer WGs are approved or renewed today, there will be charters. If fewer WGs are approved or renewed today, there will be
skipping to change at page 4, line 39 skipping to change at page 5, line 4
expect the IAB to recommend "no" quite often. Of course, the "no" expect the IAB to recommend "no" quite often. Of course, the "no"
should be clearly explained, and rooted in community consensus and should be clearly explained, and rooted in community consensus and
technical evaluations technical evaluations
Of course, the leaders will follow IETF process rules and IETF Of course, the leaders will follow IETF process rules and IETF
etiquette. But we also expect them to use common sense when the etiquette. But we also expect them to use common sense when the
rules turn out to be stupid, or simply inapplicable to a particular rules turn out to be stupid, or simply inapplicable to a particular
situation. Either suggest a change in the rules, or make an situation. Either suggest a change in the rules, or make an
exception, while telling the community what's going on and asking for exception, while telling the community what's going on and asking for
feedback. (One of the historical strengths of the IETF relative to feedback. (One of the historical strengths of the IETF relative to
competing bodies is our ability to put good sense over over-specific competing bodies was our ability to put good sense over over-specific
rules.) rules. We need to regain that.)
Finally, there is a well-known and very human side effect of serving Finally, there is a well-known and very human side effect of serving
in a leadership position: hubris. The modern definition is in a leadership position: hubris. The modern definition is
"excessive pride or self-confidence" but the ancient Greeks had a "excessive pride or self-confidence" but the ancient Greeks had a
more dramatic version: "excessive pride towards or defiance of the more dramatic version: "excessive pride towards or defiance of the
gods, leading to nemesis." Whichever version you choose, it's bad. gods, leading to nemesis." Whichever version you choose, it's bad.
We expect the leaders to remember that they are fallible and that, We expect the leaders to remember that they are fallible and that,
after a few years, they will be ordinary members of the IETF after a few years, they will be ordinary members of the IETF
community again. community again. If they become arbitrary or peremptory in their
temporary leadership roles, they may well regret it later.
3. Security Considerations 3. Security Considerations
Security considerations are not discussed in this memo. Security considerations are not discussed in this memo.
4. IANA Considerations 4. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
5. Acknowledgements 5. Acknowledgements
skipping to change at page 5, line 26 skipping to change at page 5, line 38
also on comments and suggestions from several members of the also on comments and suggestions from several members of the
community over the years. Of course I am solely responsible for the community over the years. Of course I am solely responsible for the
current text. current text.
Appendix A. Change log Appendix A. Change log
draft-carpenter-community-leaders-00, 2018-09-08: draft-carpenter-community-leaders-00, 2018-09-08:
Initial version Initial version
draft-carpenter-community-leaders-01, 2019-06-20:
Update for 2019-20 NomCom
Author's Address Author's Address
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
 End of changes. 16 change blocks. 
39 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/