idnits 2.17.1 draft-dawkins-iesg-nomcom-advisor-iaoc-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2, 2017) is 2427 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 4071 (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 7437 (Obsoleted by RFC 8713) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IESG S. Dawkins 3 Internet-Draft Wonder Hamster 4 Updates: 7437 (if approved) September 2, 2017 5 Intended status: Best Current Practice 6 Expires: March 6, 2018 8 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: 9 IAOC Advisor for the Nominating Committee 10 draft-dawkins-iesg-nomcom-advisor-iaoc-03.txt 12 Abstract 14 This specification formalizes an ad hoc practice used to provide 15 advice to the IETF Nominating Committee about the operations of the 16 IETF Administrative Oversight Committee. 18 This document updates RFC 7437. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 6, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Background on 'IAOC Liaisons' to Nominating Committees . . . 2 57 4. BCP Text Changes . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Change to Section 4.3, 'Structure' . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Appendix A. Discussion Points . . . . . . . . . . . . . . . . . 5 64 A.1. Why is this Role an Advisor? . . . . . . . . . . . . . . 5 65 A.2. Why is this Role not a Liaison? . . . . . . . . . . . . . 5 66 A.3. Why is this Role not required to be a Sitting IAOC 67 Member? . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 A.4. Why Does the Nominating Committee Request an IAOC 69 Advisor? . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 This specification formalizes an ad hoc practice used to provide 75 advice to the IETF Nominating Committee about the operations of the 76 IETF Administrative Oversight Committee (IAOC) (described in 77 [RFC4071]). 79 This document updates [RFC7437]. 81 2. Discussion Venue 83 Please direct questions and comments to the IETF Discussion mailing 84 list, at https://www.ietf.org/mailman/listinfo/ietf. 86 Please note that background on discussion points that have come up 87 previously on the public IETF Nomcom discussion mailing list, at 88 https://www.ietf.org/mailman/listinfo/ietf-nomcom, during review is 89 provided in Appendix A. 91 3. Background on 'IAOC Liaisons' to Nominating Committees 93 When RFC 7437 [RFC7437] was approved, it explicitly charged the 94 Nominating Committee with selecting and reviewing certain members of 95 the IAOC. However, [RFC7437] did not provide for the IAOC to send a 96 liaison to the Nominating Committee. 98 This was not thought to be an obstacle, because [RFC7437] allowed any 99 committee member to propose a liaison from the IAOC: 101 Any committee member may propose the addition of a liaison from 102 other unrepresented organizations to participate in some or all of 103 the deliberations of the committee. The addition must be approved 104 by the committee according to its established voting mechanism. 105 Liaisons participate as representatives of their respective 106 organizations. 108 Beginning in 2010, the IAOC provided a liaison to each Nominating 109 Committee. In 2016, the IAOC did not provide a liaison because the 110 Nominating Committee was not appointing an IAOC member. The previous 111 Nominating Committee had filled a mid-term vacancy, using the process 112 described in Section 3.5. of [RFC7437], appointing an IAOC member for 113 a term longer than two years. In 2017, the NomCom was selecting an 114 IAOC member, but the opportunity to request a liaison from the IAOC 115 was overlooked, because because this practice wasn't part of the 116 documented process in [RFC7437]. 118 This specification adds the previously ad hoc role to [RFC7437], so 119 future Nominating Committees will be less likely to overlook it. 121 Although past ad hoc practice has characterized this role as a 122 "liaison", this specification labels the role as an "advisor". The 123 rationale for this change in nomenclature is provided in 124 Appendix A.1. 126 4. BCP Text Changes 128 This section provides the updated BCP text for [RFC7437]. 130 For each OLD text selection, NEW text is provided that replaces the 131 OLD text in [RFC7437]. 133 4.1. Change to Section 4.3, 'Structure' 135 OLD 137 Any committee member may propose the addition of an advisor to 138 participate in some or all of the deliberations of the committee. 139 The addition must be approved by the committee according to its 140 established voting mechanism. Advisors participate as 141 individuals. 143 NEW 144 Any committee member may propose the addition of an advisor to 145 participate in some or all of the deliberations of the committee. 146 The addition must be approved by the committee according to its 147 established voting mechanism. Advisors participate as 148 individuals. 150 Committee members are encouraged to propose the addition of an 151 advisor who is knowledgeable about the operations of the IAOC, 152 whether or not that Nominating Committee is reviewing an IAOC 153 position. The Nominating Committee may choose to ask the IAOC to 154 suggest an advisor who is knowledgeable about IAOC operations, but 155 may select any advisor they vote to approve. 157 5. Security Considerations 159 This document updates an IETF process BCP and has no direct Internet 160 security implications. 162 6. IANA Considerations 164 This document makes no requests of IANA, and the RFC Editor can 165 safely remove this section during publication. 167 7. Acknowledgements 169 Thanks to Adrian Farrel, Alissa Cooper, Andy Malis, Alvaro Retana, 170 Joel Halpern, John Klensin, Leslie Daigle, Michael Richardson, Robert 171 Sparks, Russ Housley, S. Moonesamy, Scott Bradner, Stephen Farrell, 172 and Ted Hardie for providing feedback on early versions of this 173 document. 175 Joel Halpern (2009/2010 past Chair/advisor) and Michael Richardson 176 (2014-2015 Chair) are especially appreciated, because only a few 177 people can provide a Nominating Committee Chair's perspective on how 178 useful representation from the IAOC has been in practice. 180 8. Normative References 182 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 183 IETF Administrative Support Activity (IASA)", BCP 101, 184 RFC 4071, DOI 10.17487/RFC4071, April 2005, 185 . 187 [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, 188 Confirmation, and Recall Process: Operation of the 189 Nominating and Recall Committees", BCP 10, RFC 7437, 190 DOI 10.17487/RFC7437, January 2015, . 193 Appendix A. Discussion Points 195 This section preserves discussions and explanations that came up 196 during document discussions. Ordinarily, this section might be 197 deleted during the evaluation process, but some questions came up 198 repeatedly and consistently, so the editor plans to leave them for 199 anyone who also shares those questions. 201 A.1. Why is this Role an Advisor? 203 The editor of this document briefly considered proposing a new and 204 IAOC-specific role to [RFC7437], but considered such a proposal to be 205 complex. Anticipating every corner case in IETF process BCPs is 206 challenging and error-prone, and as this specification was being 207 written, the IETF Chair was sponsoring a design team reviewing all 208 aspects of the IETF Administrative Support Activity (IASA), so the 209 structure and membership of the IAOC itself could change in the near 210 future. Instead, the specification describes how the Nominating 211 Committee requests advisors, building on mature text that has 212 survived many Nominating Committee cycles. 214 After choosing to reuse existing roles defined in [RFC7437], the 215 definition of Advisor in Section 4.9 seemed appropriate. 217 An advisor is responsible for such duties as specified by the 218 invitation that resulted in the appointment. 220 Advisors do not vote on the selection of candidates. 222 The position described in this specification could be filled by an 223 advisor who would be a non-voting member of the Nominating Committee, 224 who is knowledgeable about the operations of the IAOC, with duties 225 that could evolve over time as the IAOC itself evolves. 227 The only difference between this advisor that requires an update to 228 [RFC7437] and and any other advisor is that committee members are 229 explicitly encouraged to suggest that this advisor be appointed, as 230 described in this specification. The text updating [RFC7437] is 231 found in Section 4. 233 A.2. Why is this Role not a Liaison? 235 Discussions on the IETF-Nomcom mailing list led to the recognition 236 that "liaison" was not the best description of this role. 238 The role of liaison defined in [RFC7437], Section 4.7 places some 239 significant obligations on liaisons that aren't necessary for 240 Nominating Committee to ask questions and get answers about the IAOC 241 that come up in deliberations. These obligations include 243 o Liaisons are responsible for ensuring the nominating committee in 244 general and the Chair in particular execute their assigned duties 245 in the best interests of the IETF community. 247 o Liaisons from the IESG, IAB, and Internet Society Board of 248 Trustees (if one was appointed) are expected to review the 249 operation and executing process of the nominating committee and to 250 report any concerns or issues to the Chair of the nominating 251 committee immediately. If they can not resolve the issue between 252 themselves, liaisons must report it according to the dispute 253 resolution process stated elsewhere in this document. 255 o Liaisons may have other nominating committee responsibilities as 256 required by their respective organizations or requested by the 257 nominating committee, except that such responsibilities may not 258 conflict with any other provisions of this document. 260 Finally, in [RFC7437],Section 4.6, all of the liaisons are included 261 in the pool of people who are eligible to be selected as a 262 replacement for a Chair. 264 There are a variety of ordinary circumstances that may arise from 265 time to time that could result in a Chair being unavailable to 266 oversee the activities of the committee. The Chair, in 267 consultation with the Internet Society President, may appoint a 268 substitute from a pool comprised of the liaisons currently serving 269 on the committee and the prior year's Chair or designee. 271 Note: During discussion of this specification, we noted that any 272 liaison would be part of the pool of potential substitute 273 Nominating Committee chairs. It wasn't clear to the people in the 274 discussion that making liaisons who are voted onto the Nominating 275 committee eligible to be substitute Chairs is intentional. That 276 potential change is out of scope for this specification, but may 277 be a conversation worth having separately. 279 All of these obligations are important, but there are always at least 280 two full liaisons from the confirming bodies already responsible for 281 those responsibilities. It is simply not necessary to make the job 282 of helping Nominating Committee understand the IAOC more demanding 283 than it must be. 285 So, requiring the IAOC to name a formal liaison to the Nominating 286 Committee isn't justified. 288 A.3. Why is this Role not required to be a Sitting IAOC Member? 290 In addition to the reasons given in Section Appendix A.2, the 291 requirement that the IAB and IESG liaisons to the Nominating 292 Committee be sitting members of the organizations they represent, 293 whose positions are not being reviewed by this Nominating Committee, 294 is especially challenging for the IAOC. 296 Because so many IAOC positions are filled by members who are already 297 members of IETF leadership who are subject to review by the 298 Nominating Committee, limiting an IAOC liaison to one of the sitting 299 members would mean that in some years, only the person who was 300 appointed by the previous Nominating Committee and not being reviewed 301 by this Nominating Committee, and the person who was appointed by the 302 IAB or IESG and not being reviewed by the IAB/IESG, would be eligible 303 sitting members of the IAOC who could serve as a liaison for the 304 Nominating Committee. "Eligible" does not also mean "willing and 305 able to serve", so it is not impossible that in some years, an IAOC 306 might find itself with no sitting member to send as advisor. 308 Although all IAOC liaisons to the Nominating Committee have served as 309 sitting members of the IAOC, given 10 years of IAOC operation, this 310 specification assumes that other members of the community have 311 sufficent experience to provide guidance if the IAOC chooses to 312 suggest such a person. If any given IAOC thought that was important, 313 they could certainly continue to suggest sitting members, but if no 314 sitting member was willing and able to serve, the IAOC would be free 315 to do the next best thing, and would likely be the best qualiified 316 group to decide who to send. 318 A.4. Why Does the Nominating Committee Request an IAOC Advisor? 320 This specification could have described the mechanism in one of two 321 ways. 323 o The IAOC could simply provide the name of the advisor to the 324 Nominating Committee, or 326 o The Nominating Committee could request the name of an advisor from 327 the IAOC. 329 Either choice could work. The reason that this specification chose 330 to have the Nominating Committee make the first move is that this is 331 more similar to the way other advisors to the Nominating Committee 332 are selected, except that the Nominating Committee is asking the IAOC 333 for a suggestion before inviting the advisor to join the Nominating 334 Committee. 336 The suggestion is, in fact a suggestion, and the Nominating Committee 337 still votes to invite this advisor, as they would vote to invite any 338 advisor, as described in [RFC7437], Section 4.3. 340 Author's Address 342 Spencer Dawkins 343 Wonder Hamster Internetworking LLC 345 Email: spencerdawkins.ietf@gmail.com