idnits 2.17.1 draft-dawkins-nomcom-dont-wait-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3777, updated by this document, for RFC5378 checks: 2002-06-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2009) is 5409 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 5078 (Obsoleted by RFC 7437) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Dawkins, Ed. 3 Internet-Draft Huawei (USA) 4 Updates: 3777 (if approved) July 6, 2009 5 Intended status: BCP 6 Expires: January 7, 2010 8 Nominating Committee Process: Earlier Announcement of Open Positions and 9 Solicitation of Volunteers 10 draft-dawkins-nomcom-dont-wait-04 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document updates RFC 3777, Section 4, Bullet 13 to allow 49 announcement of open positions and solicitation of volunteers to be 50 issued before a Nominating and Recall Committee Chair has been named 51 by the Internet Society President. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Updated text from RFC 3777 . . . . . . . . . . . . . . . . . . 4 59 5. Possible Topics for Later Discussion . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The Internet Engineering Steering Group (IESG), the Internet 71 Architecture Board (IAB), and at-large IETF representatives to the 72 IETF Administrative Oversight Committee (IAOC) are selected by a 73 "Nominating and Recall Committee" (universally abbreviated as 74 "NomCom"). [RFC3777] defines how the NomCom is selected, and the 75 processes it follows as it selects candidates for these positions. 77 This document describes an issue with [RFC3777] that causes an 78 avoidable delay in the NomCom process, and specifies a normative 79 update to resolve the issue. 81 2. Background 83 [RFC3777] is the latest in a series of revisions to the NomCom 84 process. [RFC3777] has been updated once since 2004, but the update 85 ([RFC5078]) did not change normative text (it replaced a sample 86 timeline). 88 [RFC5078] identified a serial delay in the process described in 89 [RFC3777], in section 4, "Nominating Committee Selection", bullet 13, 90 which states: 92 The Chair obtains the list of IESG and IAB positions to be 93 reviewed and announces it along with a solicitation for names of 94 volunteers from the IETF community willing to serve on the 95 nominating committee. 97 The solicitation must permit the community at least 30 days during 98 which they may choose to volunteer to be selected for the 99 nominating committee. 101 The list of open positions is published with the solicitation to 102 facilitate community members choosing between volunteering for an 103 open position and volunteering for the nominating committee. 105 The result is that the Incoming NomCom Chair is the only person who 106 can announce the list of open positions and solicitation for names of 107 volunteers, a process that requires 30 days for public solicitation. 109 Since this is the first step in organizing the NomCom committee, 110 delays in selecting the Incoming NomCom Chair translate directly into 111 delays in issuing the solicitation and organizing the NomCom. 113 This proved problematic in practice in 2008-2009, when Joel Halpern 114 was named NomCom Chair less than 30 days prior to the Second IETF 115 meeting. If the 30-day solicitation had already taken place, the 116 Nomcom could have conducted face-to-face interviews at the Second 117 IETF meeting, but since the required 30-day solicitation didn't start 118 until Joel was named, Joel was unable to assemble his NomCom before 119 the Second IETF meeting, and the NomCom had to carry out these 120 interviews using e-mail and conference calls. 122 It is desirable to allow the solicitation and announcement to take 123 place in a timely manner so that when an Incoming NomCom Chair is 124 named, the NomCom Chair can immediately begin executing the NomCom 125 process. 127 3. Discussion 129 This document proposes that four weeks after the First IETF meeting 130 each year, the Internet Society President will either announce an 131 Incoming NomCom Chair, or will direct the IETF Executive Director to 132 issue the announcement of open positions and the solicitation for 133 names of volunteers on behalf of the Incoming NomCom Chair. This 134 allows the search for the Incoming NomCom Chair and volunteers to 135 proceed in parallel. 137 This process change covers only the announcement of open positions 138 and solicitation for names of volunteers. This process change does 139 not allow the NomCom process to move to completion without an 140 Incoming NomCom Chair; it is only to ensure that the Incoming NomCom 141 Chair can begin executing the NomCom process without an avoidable 142 delay, and can use face-to-face time at the Second IETF meeting 143 effectively for this purpose. 145 During discussions in the IETF 74 timeframe, it was suggested that we 146 also allow the Secretariat to perform other clerical tasks that 147 aren't called out specifically in the NomCom process, but which 148 clearly do not require NomCom Chair judgment. This document does not 149 provide guidance about specific clerical tasks that would be 150 appropriate for the Secretariat to carry out. Instead, either the 151 Incoming NomCom Chair (if one has been selected) or the Outgoing 152 NomCom Chair (if the search for an Incoming NomCom Chair is still 153 underway) may request the Secretariat to perform these tasks, with 154 appropriate notification to the community. 156 4. Updated text from RFC 3777 158 For [RFC3777], in section 4, "Nominating Committee Selection", bullet 159 13, which states: 161 The Chair obtains the list of IESG and IAB positions to be 162 reviewed and announces it along with a solicitation for names of 163 volunteers from the IETF community willing to serve on the 164 nominating committee. 166 this text is replaced with the following text: 168 The Chair (or the IETF Executive Director, if no Chair has been 169 named four weeks after the First IETF meeting of the year) obtains 170 the list of positions to be reviewed and announces it along with a 171 solicitation for names of volunteers from the IETF community 172 willing to serve on the nominating committee. 174 If the IETF Executive Director issues the solicitation for 175 volunteers, the IETF Executive Director must also collect 176 responses to the solicitation and provide the names of volunteers 177 to the Incoming NomCom Chair when the Incoming NomCom Chair is 178 named. 180 At the Chair's request, the IETF Secretariat may perform other 181 clerical support tasks, as long as the task being performed does 182 not require NomCom Chair judgment, in the NomCom Chair's opinion, 183 and as long as the community is appropriately notified that this 184 request is being made. This request may come from the Incoming 185 NomCom Chair (if one has been selected for this NomCom cycle) or 186 the Outgoing NomCom Chair (if the search for an Incoming NomCom 187 Chair is still underway). 189 Note: This text no longer specifies the list of bodies that NomCom 190 reviews, rather than adding IAOC to the list of bodies in the text, 191 so that this text need not change further when NomCom 192 responsibilities change. 194 5. Possible Topics for Later Discussion 196 This section includes topics that came up during discussion of this 197 document, which were not included in the normative changes contained 198 in this document, because the goal for this document was incremental 199 improvement, and these topics were more than incremental changes. 200 They may be discussed further, or not, but we're less likely to 201 forget them completely if we write them down. 203 [RFC3777] tightly couples the announcement of open positions and call 204 for volunteers, and this document didn't try to unravel these two 205 separate actions. We had a request during discussion to separate 206 them, so that a NomCom could consider the management structure of the 207 IETF and the position descriptions that the leadership bodies 208 provide, before announcing the positions being reviewed. 210 6. Security Considerations 212 This specification describes issues with the current IETF Nominating 213 Committee process [RFC3777] and proposes an update to avoid a serial 214 delay. No security considerations apply. 216 7. IANA Considerations 218 {{{ RFC Editor: Please remove this section prior to publication. }}} 220 No IANA actions are requested in this specification. 222 8. Acknowledgements 224 The editor thanks the following folks who have provided useful 225 observations and guidance on previous versions of this draft: Scott 226 Bradner (who suggested that the IETF Secretariat have this 227 responsibility), Brian Carpenter, Ralph Droms, Jim Galvin, Joel 228 Halpern, Danny McPherson, and Pekka Savola. 230 The editor also thanks the Wednesday evening plenary session 231 participants during IETF 74 who provided useful feedback on previous 232 versions of this draft [w74plen]. 234 9. References 236 9.1. Normative References 238 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 239 Recall Process: Operation of the Nominating and Recall 240 Committees", BCP 10, RFC 3777, June 2004. 242 9.2. Informative References 244 [RFC5078] Dawkins, S., "IAB and IESG Selection, Confirmation, and 245 Recall Process: Revision of the Nominating and Recall 246 Committees Timeline", RFC 5078, October 2007. 248 [w74plen] "IETF 74 Wednesday Evening Plenary Minutes", March 2009. 250 Author's Address 252 Spencer Dawkins (editor) 253 Huawei Technologies (USA) 255 Phone: +1 214 755 3870 256 Email: spencer@wonderhamster.org