idnits 2.17.1 draft-iab-isocbot-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 8, 2003) is 7505 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2727 (ref. '1') (Obsoleted by RFC 3777) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Daigle 3 Internet-Draft Editor 4 Expires: April 7, 2004 Internet Architecture Board 5 IAB 6 October 8, 2003 8 IETF ISOC Board of Trustee Appointment Procedures 9 draft-iab-isocbot-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 7, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This memo outlines the process by which the IETF makes a selection of 41 an Internet Society (ISOC) Board of Trustees appointment. 43 1. Introduction 45 The Internet Society (ISOC) provides organizational and financial 46 support for the IETF. As stipulated in ISOC's by-laws the IETF is 47 called upon to name 3 Trustees to its Board (BoT), with staggered 3 48 year terms. This requires that the IETF name one Trustee each year. 50 This memo outlines the process by which the IETF makes that 51 selection. This process will also be used in the event of mid-term 52 vacancies that may arise with IETF nominated Board positions. 54 1.1 Overview of Selection Process 56 In brief, this document describes the timeframe and procedures for 57 the IAB to solicit public input and make a selection for the open 58 position each year. 60 1.2 Rationale 62 An alternative approach to making a selection for these positions 63 would be to use the IETF's NomCom (RFC 2727 [1] and its revisions). 64 However, that NomCom is chartered and defined specifically to the 65 task of making selections for IETF organization tasks, and the ISOC 66 BoT appointment process does not fit that in 2 ways: 68 1. the timeframe of the appointment does not mesh with the IETF 69 appointment cycle 71 2. the nature of the deliberations and the type of information 72 solicited would be significantly different for an external 73 appointment, such as this appointment to the ISOC BoT 75 The first issue (timing) could be resolved fairly easily for this 76 specific appointment. The second issue is more general, and not 77 reasonably reconciled with the IETF NomCom task as currently 78 specified. 80 The process described in RFC 2727 oriented toward soliciting feedback 81 from the IETF community with respect to individuals and technical 82 positions with which they have personal experience. To make a good 83 decision on external appointments, in general, the NomCom would have 84 to understand the requirements for those positions, and attempt to 85 evaluate candidates for a very different set of skills than is 86 required of IAB/IESG members. It might also require soliciting 87 feedback from outside the IETF community. There is no question that 88 the individuals that constitute the IETF NomCom each year have the 89 competence to carry out such a search; the issue is that it is a very 90 different task, would require additional time and resources, and 91 therefore is a side effort that could very well undermine the 92 effectiveness of the NomCom in carrying out its primary task for the 93 IETF. 95 By contrast, the IAB is chartered to be responsible for IETF external 96 liaisons, is a standing body that works with ISOC (and the ISOC 97 Board), and therefore has a working knowledge of the requirements of 98 the specific position discussed here. 100 At some future point, if there is a more general need to make 101 external appointments, the IETF may consider broadening the scope of 102 the IETF NomCom role, or create a separate nominating committee for 103 such external non-liaison appointments. This document proposes that 104 is not necessary or desirable for the purposes of this one annual 105 appointment. 107 2. Desirable Qualifications and Selection Criteria for an IETF-Nominated 108 ISOC Trustee 110 Candidates for an ISOC Trustee should have a demonstrable involvement 111 in the IETF with a particular focus on active participation in IETF 112 Working Groups. 114 The candidate is expected to possess clearly demonstrated technical 115 competence in Internet technology, and be able to articulate 116 technology issues such that the ISOC Board can be provided with sound 117 technical perspectives. The candidate is also expected to be able to 118 understand the respective roles and responsibilities of the IETF and 119 ISOC and be able to articulate these roles within both organizational 120 communities. 122 The candidate will also be expected to exercise all the duties of an 123 ISOC Board member, including fiduciary responsibility, setting of 124 policies, oversight of the operation of the Society, representing 125 the interests of the members and stakeholders of the Society and 126 participation in all Board meetings and Board activity programs. 128 The candidate is not a representative or a delegate of the IETF and 129 is not chartered to represent the IETF or the IETF Standards Process 130 within the ISOC Board or the broader ISOC community. However it is 131 expected that the candidate would be able to call on experts in the 132 IETF community as required, to ensure that the ISOC Board receives 133 the highest quality technical advice available. 135 3. IETF ISOC Board of Trustees Selection Process 137 3.1 Nominations and eligibility 139 Each year, the IAB will make a public call for nominations on the 140 ietf-announce@ietf.org mailing list. The public call will specify 141 the manner by which nominations will be accepted and the means by 142 which the list of nominees will be published. 144 Self-nominations are permitted. Along with the name and contact 145 information for each candidate, details about the candidate's 146 background and qualifications for the position should be attached to 147 the nomination. All IETF participants, including working group 148 chairs, IETF NomCom members, IAB and IESG members are eligible for 149 nomination. 151 IAB and IESG members who accept nomination will recuse themselves 152 from selection and confirmation discussions respectively. 154 3.2 Selection 156 The IAB will publish the list of nominated persons, review the 157 nomination material, and make a selection. 159 The selection criteria will include additional consideration of any 160 nominated candidates who are concurrently members of the IAB or IESG 161 members such that at the time of selection no more than two of the 162 three IETF-appointed ISOC Trustees are IAB and IESG members. 164 3.3 Confirmation 166 The IESG will act as the confirming body for the selection. In the 167 event that the IESG determines not to confirm the nominated 168 candidate, the IESG will provide the IAB with the basis for this 169 determination and the IAB will nominate another candidate. 171 3.4 Timeframe 173 ISOC expects to seat new Board members at its annual general meeting 174 in June of each year. Basic timeframe requirements for the IETF 175 process are as follows: 177 o 4-6 weeks for solicitation of nominations 179 o 4-6 weeks for review of nominees, deliberation and selection 181 o 4-6 weeks for confirmation (and re-selection as necessary) and 182 delivery to ISOC 184 In January of each year, the IAB will announce the specific dates for 185 the IETF ISOC Trustee selection process for that year (taking into 186 account the particular dates of the first IETF meeting of the year, 187 etc), following the guidelines above. 189 3.5 Mid-term Vacancies 191 This document describes the process for the general, annual 192 appointment of ISOC Trustees to fill the seats of Trustees whose 193 terms are ending. However, if an IETF-appointed Trustee is unable to 194 serve his or her full term, the IAB may, at its discretion, 195 immediately select a replacement to serve the remainder of the term 196 using the interim process defined in Section 3.5.1. If the IAB does 197 not invoke the interim process, the next annual selection process 198 will fill the vacancy (if the vacant term does not end at that point) 199 as well as the regular appointment for that selection cycle. 201 3.5.1 Interim Appointment Process 203 If the IAB elects to fill the mid-term vacancy before the next annual 204 selection, a separate timeline will be announced and the rest of the 205 process described in this document will be followed. 207 4. Security Considerations 209 This document does not describe any technical protocols and has no 210 implications for network security. 212 References 214 [1] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 215 Process: Operation of the Nominating and Recall Committees", BCP 216 10, RFC 2727, February 2000. 218 Authors' Addresses 220 Leslie Daigle 221 Editor 223 Internet Architecture Board 224 IAB 226 EMail: iab@iab.org 228 Appendix A. IAB Members at the time of this writing 230 Bernard Aboba 232 Harald Alvestrand 234 Rob Austein 236 Leslie Daigle 238 Patrik Faltstrom 239 Sally Floyd 241 Mark Handley 243 Geoff Huston 245 Jun-ichiro (Itojun) Hagino 247 Charlie Kaufman 249 James Kempf 251 Eric Rescorla 253 Mike St.Johns 255 Full Copyright Statement 257 Copyright (C) The Internet Society (2003). All Rights Reserved. 259 This document and translations of it may be copied and furnished to 260 others, and derivative works that comment on or otherwise explain it 261 or assist in its implementation may be prepared, copied, published 262 and distributed, in whole or in part, without restriction of any 263 kind, provided that the above copyright notice and this paragraph are 264 included on all such copies and derivative works. However, this 265 document itself may not be modified in any way, such as by removing 266 the copyright notice or references to the Internet Society or other 267 Internet organizations, except as needed for the purpose of 268 developing Internet standards in which case the procedures for 269 copyrights defined in the Internet Standards process must be 270 followed, or as required to translate it into languages other than 271 English. 273 The limited permissions granted above are perpetual and will not be 274 revoked by the Internet Society or its successors or assigns. 276 This document and the information contained herein is provided on an 277 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 278 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 279 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 280 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 281 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 283 Acknowledgement 285 Funding for the RFC Editor function is currently provided by the 286 Internet Society.