[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                             June 20, 2019
Expires: December 22, 2019


               Some Thoughts on IETF Community Leadership
                  draft-carpenter-community-leaders-01

Abstract

   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.  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

   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 December 22, 2019.

Copyright Notice

   Copyright (c) 2019 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



Carpenter               Expires December 22, 2019               [Page 1]


Internet-Draft            Community Leadership                 June 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Expectations  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The IETF has a relatively open but hardly 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 tends to limit
   transparent discussion of both abilities and potential problems.
   Indeed, we shouldn't be in the business of naming and shaming those
   who are willing to serve us.  However, as a community, we must make a
   fuss about decisions we don't like, and persist when we see a
   technical error going uncorrected.  In particular we should make a
   fuss about failures to adequately consult the community about
   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
   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



Carpenter               Expires December 22, 2019               [Page 2]


Internet-Draft            Community Leadership                 June 2019


   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 IETF
   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.

2.  Expectations

   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.  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.

   The IETF is based on rough consensus.  So we expect the leaders to
   consult and 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 consultations, 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.  Fuzzy explanations of decisions are not good enough.





Carpenter               Expires December 22, 2019               [Page 3]


Internet-Draft            Community Leadership                 June 2019


   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, liaisons, 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.  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
   understand.  This isn't so much about technical issues, which we all
   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,
   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



Carpenter               Expires December 22, 2019               [Page 4]


Internet-Draft            Community Leadership                 June 2019


   competing bodies was our ability to put good sense over over-specific
   rules.  We need to regain that.)

   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.  If they become arbitrary or peremptory in their
   temporary leadership roles, they may well regret it later.

3.  Security Considerations

   Security considerations are not discussed in this memo.

4.  IANA Considerations

   This document makes no request of the IANA.

5.  Acknowledgements

   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.

Appendix A.  Change log

   draft-carpenter-community-leaders-00, 2018-09-08:

   Initial version

   draft-carpenter-community-leaders-01, 2019-06-20:

   Update for 2019-20 NomCom

Author's Address

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com



Carpenter               Expires December 22, 2019               [Page 5]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/