idnits 2.17.1 draft-carpenter-nomcom2020-letter-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2020) is 1320 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 None B.E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational September 11, 2020 5 Expires: March 15, 2021 7 Open Letter to the 2020-21 IETF Nominating Committee 8 draft-carpenter-nomcom2020-letter-00 10 Abstract 12 This is a personal open letter to the IETF Nominating Committee for 13 2020-21. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on March 15, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Letter . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Security Considerations . . . . . . . . . . . . . . . . . . . 3 50 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1. Letter 55 Dear NomCom members, 57 Thank you for serving on NomCom. It's not an easy task. 59 This is an open letter. These are general remarks intentionally 60 exposed to the whole IETF community, by posting as an I-D. I do not 61 intend to update this I-D, although of course community comments are 62 welcome. 64 The IETF is at a critical moment. Various pressures have been 65 building up for several years. They have been made worse by COVID- 66 19, since face-to-face contact reduces misunderstandings. Clearly, 67 change is needed. You are therefore possibly the most important 68 NomCom since the first one in 1992. 70 We should not blame the individuals currently in service for the 71 pressures that have arisen. Everybody has tried to do their best. 72 But nevertheless, your choices for the empty seats in March 2021 73 matter a lot. 75 Of course, we need technical experts. The IETF will no longer be the 76 IETF if you appoint people to the IESG and IAB who are not highly 77 competent engineers. But in addition, we need people with a deep 78 understanding of and belief in the IETF's approach to standards- 79 making. We need people who believe in rough consensus as the best 80 way to make effective standards, who will never use their leadership 81 position to bias the consensus, yet will use their technical skills 82 to achieve the best possible result. They must be open to change, 83 and also act as agents of change themsleves. And of course, they 84 must leave loyalty to their own employers at the door. If this 85 sounds like an impossible target, that's because it is, but we must 86 try. 88 A specific problem I have noticed in recent years is that the barrier 89 for Proposed Standard publication has been pushed ever higher. Often 90 this is due to IESG "DISCUSS" positions that arguably breach the 91 IESG's own criteria for a DISCUSS, and that do not correspond to the 92 RFC2026 definition of Proposed Standard: 94 "A Proposed Standard specification is generally stable, has resolved 95 known design choices, is believed to be well-understood, has received 96 significant community review, and appears to enjoy enough community 97 interest to be considered valuable. However, further experience 98 might result in a change or even retraction of the specification 99 before it advances." 101 In other words, a PS must be good enough, but not perfect. A PS 102 might contain errors and might fail. It is important that all IESG 103 members understand and practice this. If not, IETF progress is 104 severely slowed down; to get running code, we need rough consensus, 105 not perfection. 107 Another general problem I have sometimes noticed among IESG and IAB 108 members is a failure to treat their roles as servants of the 109 community and its consensus, but rather to behave as if they are in 110 charge. I don't want to give specific examples, because that might 111 seem to point at individuals, and that is not my goal. But it's 112 important that (however the outside world views their roles) they 113 remember every day that they are the servants and the community is in 114 charge. 116 It's very hard work being an IESG member, and demanding work to be an 117 IAB member. The community should be grateful that there are always 118 people willing to take on these roles. However, I urge NomCom to 119 carefully verify that all the nominees understand their roles, and 120 that they are motivated to change and improve the IETF. 122 Best wishes for your work, and again, thank you. 124 Brian Carpenter 126 2. Security Considerations 128 Security issues are not discussed in this memo. 130 3. IANA Considerations 132 This document makes no request of IANA. 134 Author's Address 135 Brian E. Carpenter 136 The University of Auckland 137 School of Computer Science 138 PB 92019 139 Auckland 1142 140 New Zealand 142 Email: brian.e.carpenter@gmail.com