idnits 2.17.1 draft-dawkins-nomcom-3777-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 644. 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 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 (July 7, 2008) is 5771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 2027 (Obsoleted by RFC 2282) -- Obsolete informational reference (is this intentional?): RFC 5078 (Obsoleted by RFC 7437) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 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 Intended status: Informational D. McPherson 5 Expires: January 8, 2009 Arbor Networks 6 July 7, 2008 8 Nominating Committee Process: Issues since RFC 3777 9 draft-dawkins-nomcom-3777-issues-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 This document describes issues with the current IETF Nominating 39 Committee process that have arisen in practice. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Background of this document . . . . . . . . . . . . . . . . . 3 45 3. Issues that Affect NomCom Participation . . . . . . . . . . . 4 46 3.1. Shortening the NomCom Epoch . . . . . . . . . . . . . . . 4 47 3.2. Random Selection of NomCom Membership . . . . . . . . . . 4 48 3.3. Gaming NomCom Participation . . . . . . . . . . . . . . . 4 49 3.4. Affiliation and Related Issues . . . . . . . . . . . . . . 5 50 4. Issues Affecting NomCom Operation . . . . . . . . . . . . . . 6 51 4.1. Model for Candidate Evaluation . . . . . . . . . . . . . . 6 52 4.2. One NomCom for All Positions . . . . . . . . . . . . . . . 6 53 5. Candidate Issues . . . . . . . . . . . . . . . . . . . . . . . 7 54 5.1. Candidates Who Are Not Selected . . . . . . . . . . . . . 7 55 5.2. Running Against an Incumbent . . . . . . . . . . . . . . . 7 56 5.3. Soliciting Feedback on Non-Incumbent Candidates . . . . . 8 57 5.4. Interaction between Affiliation and Willingness to be 58 Considered . . . . . . . . . . . . . . . . . . . . . . . . 9 59 6. Confirming Body Issues . . . . . . . . . . . . . . . . . . . . 9 60 6.1. Role of the Confirming Body . . . . . . . . . . . . . . . 9 61 6.2. Confirming Body Liaisons . . . . . . . . . . . . . . . . . 10 62 6.3. What a Confirming Body Actually Confirms . . . . . . . . . 11 63 6.4. 2007-2008 Dispute Resolution Process Experience . . . . . 12 64 6.4.1. Selecting an Arbiter . . . . . . . . . . . . . . . . . 12 65 6.4.2. Scope of Dispute Resolution Process . . . . . . . . . 12 66 6.4.3. Constitutional Crisis . . . . . . . . . . . . . . . . 12 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . . . 15 76 1. Introduction 78 The Internet Engineering Steering Group (IESG), the Internet 79 Architecture Board (IAB), and at-large IETF representatives to the 80 IETF Administrative Oversight Committee (IAOC) are selected by a 81 "Nominating and Recall Committee" (universally abbreviated as 82 "NomCom"). [RFC3777] defines how the NomCom is selected, and the 83 processes it follows as it selects candidates for these positions. 85 This document describes issues with the current NomCom process that 86 have arisen in practice. It does not propose ways to resolve those 87 issues - that will potentially be the role of one or more follow-on 88 documents and/or IETF work items. 90 2. Background of this document 92 [RFC3777] is the latest in a series of revisions to the NomCom 93 process, which dates back to [RFC2027] in 1996. [RFC3777] has been 94 updated once since 2004, but this update ([RFC5078] did not change 95 normative text (it replaced a sample timeline, allowing more time for 96 required tasks and identifying a small number of tasks that are 97 performed every year but were not included in the sample timeline). 99 Although NomCom deliberations are held to a high level of 100 confidentiality, three recent NomCom chairs {Danny McPherson {2004- 101 2005}, Ralph Droms {2005-2006}, and Andrew Lange {2006-2007}) have 102 reported a variety of issues at IETF Plenaries. They reported 103 several issues (that arise across NomCom cycles), including 104 experience that NomComs seem to consistently "run out of time" at the 105 end of the process, a small number of candidates for at least some 106 positions, confusion with confirming bodies, and a tension between 107 confidentiality and an open request for feedback on candidates. 109 This document is a compilation of discussions among a number of 110 recent NomCom chairs (named in Section 9) who acted as a design team, 111 at the IETF Chair's request. In addition, we used Lakshminath 112 Dondeti's IETF 71 Plenary NomCom report, and subsequent on-list and 113 off-list discussions, as input, but Lakshminath was not included in 114 the design team because he was currently serving as NomCom chair. 116 This document is closer to being a union of views than a consensus of 117 views. Given that each NomCom operates behind a wall of 118 confidentiality, with the past NomCom chair as the only "common" 119 participant, it's difficult even for a group of former NomCom chairs 120 to agree on "what the problems common to all NomComs are". 122 3. Issues that Affect NomCom Participation 124 3.1. Shortening the NomCom Epoch 126 We struggled with several aspects of the length of the NomCom cycle. 127 Using the schedule suggested in ([RFC5078], the 2008-2009 NomCom will 128 be budgeting for a 43-week NomCom cycle. There are several concerns 129 that go along with a very long NomCom cycle: 131 o We have a sense that a longer NomCom commitment reduces the number 132 of NomCom volunteers who are willing to serve. 133 o A longer NomCom cycle can also affect the continued willingness of 134 candidates to be considered - candidates are contacted immediately 135 to see if they are willing to serve, and then immediately before 136 their names are sent forward - and there can be a 5-6 month delay 137 between these events, so candidates may lose enthusiasm, or may 138 experience personal/professional changes that prevent them from 139 serving, between the two contact points. 140 o A smaller number of NomCom volunteers raises concerns about large 141 "IETF sponsors" "gaming" the system. 142 o In a small minority of cases - IAB or IESG members who are serving 143 in a one-year term - the NomCom cycle starts almost immedately 144 after the member is seated (52 weeks in a year - 43 weeks in a 145 NomCom cycle = 9 weeks of experience when the process begins). 147 3.2. Random Selection of NomCom Membership 149 NomCom membership is selected randomly from a set of qualified 150 volunteers. This means that NomCom members are probably not 151 personally familiar with all of the candidates, and may not be 152 familiar with the required skillset for specific positions. This has 153 implications for the amount of time needed for NomCom to collect 154 inputs from the community. 156 We also discussed concerns about the level of awareness of IETF 157 culture for a randomly-selected NomCom - since an IETF attendee can 158 become NomCom-eligible in one year. 160 3.3. Gaming NomCom Participation 162 We have a sense that there are a small number of large sponsors for 163 IETF participants who provide a disproportionate number of NomCom 164 volunteers. 166 The issue isn't that a single sponsor can "pack" a NomCom - current 167 [RFC3777] rules limit that effect - but that large sponsors can be 168 almost assured of at least one participant being selected for NomCom, 169 year after year. We note that for several years, 50-60 percent of 170 NomCom participants have come from four large sponsors. We aren't 171 saying this is a problem, only that it's a trend worth noticing. 173 3.4. Affiliation and Related Issues 175 As described in [RFC3777], the term "primary affiliation" is used in 176 the following ways: 178 o A nomcom volunteer's "primary affiliation" is used in determining 179 whether a volunteer is eligible for membership on the nominating 180 committee (Section 4, point 17) 181 o Within the recall process, a signatory's primary affiliation is 182 used to determine whether a signature on a recall petition is 183 valid (Section 7). 185 Despite the importance of "primary affiliation" in determining 186 eligibility for the nominating committee and the validity of a 187 signature on a recall petition, the term is never defined within RFC 188 3777. 190 While a potential nominating committee member or signatory with a 191 single employer may not have difficulty in determining their "primary 192 affiliation", the "primary affiliation" of an individual with 193 multiple consulting clients or part-time employers may be less clear. 194 Such ambiguities can make it difficult to determine whether the RFC 195 3777 requirements for nominating committee balance are being 196 followed, and may even affect the ability of the nomcom to accurately 197 assess the "primary affiliation" of the candidates for the positions 198 that the nomcom is attempting to fill. 200 For its definition of "affiliation", IEEE has come up with the 201 following: 203 "An individual is deemed 'affiliated' with any individual or 204 entity that has been, or will be, financially or materially 205 supporting that individual's participation in a particular IEEE 206 standards activity. This includes, but is not limited to, his or 207 her employer and any individual or entity that has or will have, 208 either directly or indirectly, requested, paid for, or otherwise 209 sponsored his or her participation." 211 It should not noted that the above definition focuses on support for 212 a particular activity, and therefore it is possible for a participant 213 to have different "affiliations" while developing a standards 214 submission, participating in an chair position, or serving on one or 215 more committees. 217 There are plenty of corner cases here - "do a UCLA professor and UC- 218 Irvine grad student have the same affiliation?" - so what's needed is 219 guidance, judgement, and flexibility. 221 4. Issues Affecting NomCom Operation 223 4.1. Model for Candidate Evaluation 225 We discussed two models - a Personal Experience (PE) model, and a 226 Consultive (C) model. 228 Under the PE model, a NomCom member would use personal experience to 229 determine positions on candidates where the NomCom member has enough 230 background to support those positions, and would rely on candidate 231 feedback only for the positions where the NomCom member cannot 232 support a position based on personal experience. 234 Under the C model, a NomCom member would base candidate positions 235 almost exclusively on candidate feedback for all positions under 236 consideration. 238 We recognized that there's a tension in both directions - "personal 239 experience" can become "personal bias", while "consultive" can become 240 a popularity contest. 242 One former chair pointed out that the NomCom moved pretty quickly 243 from a model where a random sample of the community selects 244 leadership based on personal experience to a model where the random 245 sample of the IETF is expected to survey a large and increasing 246 percentage of the total community in order to select leadership. If 247 we expect NomCom to act as a PE group, the process would be less 248 intrusive to the rest of the community and would require less time 249 for NomCom deliberations. 251 We also noted that since NomCom voting members are unlikely to have 252 personal experience with all candidates in all areas, there's a 253 tendency for NomCom voting members to rely on other NomCom members 254 when considering an unfamiliar candidates in an unfamiliar area. 256 4.2. One NomCom for All Positions 258 We discussed whether having a single group of randomly-selected IETF 259 attendees working to fill all positions under consideration was the 260 right model. For example, one former NomCom chair noted that the 261 IAB's responsibilities have changed dramatically since the NomCom 262 structure was put in place, and a considerable amount of IAB time has 263 been spent on administrative restructuring, hearing appeals, and 264 representing the IETF in liaisons with other SDOs. Is the NomCom the 265 best way way to choose people with the required skillset to carry out 266 these tasks? 268 5. Candidate Issues 270 We had some discussions about a relatively shallow candidate pool for 271 some positions. We noted that it's not unusual for recent NomComs to 272 reopen specific positions for late nominations (an indicator that the 273 first round didn't generate enough candidates who were both qualified 274 and willing to serve) - this happened in both 2005-2006 and in 2006- 275 2007. 277 5.1. Candidates Who Are Not Selected 279 We noted that candidates must obtain confirmation of support from 280 employers for a multi-year commitment, including commitments to fund 281 travel for IETF meetings and workshops. There are IETF participants 282 who are willing to obtain these commitments every year, but other 283 participants are not willing to be considered every year when they 284 must obtain high-level approval to be considered, and then must 285 notify the same high approval levels that they weren't selected - 286 especially if business plans were adjusted to accommodate the 287 candidate serving and must now be adjusted again to accommodate the 288 candidate not serving. 290 Even if a candidate is willing to be considered every year, the 291 current NomCom cycle length requires serious candidates to "put their 292 lives on hold" for up to six months between first being approached/ 293 volunteering and ultimately being selected. Being in limbo for this 294 period of time may be a negative factor with respect to possible job 295 actions, especially new employment and promotions. 297 Potential candidates may be unwilling to be considered for leadership 298 positions, or may simply be unwilling to be considered during a 299 specific NomCom cycle (given a choice between standing for a position 300 against an incumbent finishing a first term and an incumbent 301 finishing a third or fourth term, a candidate may "lay out" for a 302 year to be considered against the long-time incumbent). 304 5.2. Running Against an Incumbent 306 For a variety of reasons, mostly good reasons, a NomCom may be 307 influenced by a candidate being an incumbent. 309 Rules we've heard discussed by various NomComs include: 311 o always return a first term incumbent unless there is a problem 312 (assume the first term was training), 313 o always return an incumbent unless there is a problem (keep good 314 incumbents until they are no longer willing or able to serve, or 315 until they are no longer good incumbents), 316 o apply term limits in some form, and 317 o "shoot them all" (never actually done to our knowledge, but 318 expressed in NomCom discussions) 320 Given the confidentiality requirements of [RFC3777], potential 321 candidates do not know what the informal rules a NomCom may choose to 322 follow. [RFC3777] encourages candidates to be considered, anyway, 323 but candidates may choose to "be conservative in when you are 324 considered", and may decline to be considered even if the NomCom 325 would like to replace an incumbent. 327 Recent experience seems to show that a higher number of candidates 328 emerge when incombents publicly state they are unavailable to return 329 for another term than when incumbents publicly state that they are 330 available to return for another term, although this is only an 331 impression. 333 Note that this effect exists today, before any proposed changes to 334 NomCom confidentiality rules are considered. We expect that the 335 effect would be more pronounced if candidate lists are made public 336 (more about this in Section 5.3). 338 When potential candidates refuse to be considered, this complicates 339 life for a NomCom evaluating an incumbent who is willing to serve 340 again, but really needs to be replaced. 342 We see no way for a NomCom to signal that a slot is "REALLY open" 343 under the current rules of engagement. 345 We note that spending effort on NomCom questionnaires when a NomCom 346 is ready to reappoint an incumbent wastes valuable IETF participant 347 time, and this is doubly wasteful when a NomCom requests input on a 348 "ringer" who was not under consideration, and was only added to the 349 list to obscure which candidates WERE under consideration. 351 5.3. Soliciting Feedback on Non-Incumbent Candidates 353 NomCom announces the slots being considered in each NomCom cycle, so 354 incumbents being considered are known publicly, but other candidates 355 are not made public. This complicates the decision to provide input 356 to NomCom, because community members may provide information about a 357 "candidate" who isn't being considered, or who isn't willing to serve 358 - or, equally likely, they may simply choose not to provide input 359 about non-incumbent candidates without being solicited to do so. 361 There isn't any formal guidance to NomComs about how to solicit 362 input, so each NomCom tends to use a modified version of what the 363 previous NomCom used to solicit input. Current NomCom practice is to 364 request feedback on lists of candidates from a large "private" 365 population - existing working group chairs, RFC authors in an area, 366 current document authors in an area, and the entire IESG and/or IAB 367 likely to see candidate lists which, although the lists contain 368 "ringers", necessarily expose the names of all candidates for a 369 position to a large and relevant portion of the IETF community. 371 Even with solicitation of feedback on large "private" distributions, 372 non-incumbents are at a disadvantage because the NomCom announcement 373 names the incumbents, but does not name the non-incumbents - who may 374 be tempted to do something that starts to look like campaigning, to 375 make sure that people who honestly believe they would be the best 376 candidate do provide input. 378 5.4. Interaction between Affiliation and Willingness to be Considered 380 We noted that there are unwritten rules about affiliation that affect 381 a candidate's willingness to be considered. For example, apparent 382 NomCom practice is that two area directors in the same area should 383 not have the same affiliation. If an area director is from company 384 X, possible candidates from company X may be less willing to be 385 considered for the second area director slot, assuming they will be 386 summarily rejected because of this affiliation. 388 Potential candidates for IAB slots may have similar concerns, and may 389 not be willing to be considered, if there are already two IAB members 390 with the same affiliation serving. 392 6. Confirming Body Issues 394 6.1. Role of the Confirming Body 396 In an e-mail on 2008/03/17, the IETF Chair asked the design team "to 397 propose a definition for the role of the confirming body. The 398 discussion in plenary indicates that this is a place where RFC 3777 399 is lacking. In part, this discussion has already taken place on the 400 IETF mail list, with members of the design team taking radically 401 different views. Please review the archives of the nomcom WG when 402 they are available." 404 We gave that our best shot. 406 We recognized a tension between a confirming body that is expected to 407 "rubber-stamp" a candidate slate, and a confirming body that expects 408 to "re-run the NomCom process" - ("show us the information the NomCom 409 used to select this candidate slate, and we'll see if you picked the 410 right candidates"). Conversations at IETF 71 frequently used these 411 terms. We don't think either extreme is desirable. In subsequent 412 discussions we noted that there is a middle ground - a confirming 413 body would use information forwarded by the NomCom as part of its 414 "sanity check" diligence. 416 We haven't agreed on a proposed definition of the role of the 417 confirming body (yet). This is where the editor thinks we are, as of 418 00 I-D submission cutoff for IETF 72 (and the editor apologizes in 419 advance if he has been unable to capture the group's consensus on 420 what we didn't have consensus about)... 422 o The role of the confirming body is the acceptance or rejection of 423 proposed candidates. 424 o The confirming body should confirm candidates it believes are 425 qualified for the nominated position AND whose selection would not 426 be disruptive to the IETF process by whatever measure the 427 confirming body chooses to use. Conversely, the confirming body 428 should reject candidates who do not meet these conditions. 429 o Although [RFC3777] states that confirming body deliberations are 430 under the same requirements for confidentiality as the NomCom 431 itself, recent experience shows that NomComs and confirming bodies 432 can, and do, disagree on how much information the NomCom should 433 share with confirming bodies. 434 o Although [RFC3777] assigns process guardianship roles to 435 confirming body liaisons (as well as to the past NomCom chair), 436 the confirming body itself must rely on confirming body liaisons 437 for its view into the NomCom, and the liaisons are often reluctant 438 to share information with the rest of the confirming body, citing 439 confidentiality concerns. 441 6.2. Confirming Body Liaisons 443 Two sets of concerns were expressed about liaisons: 445 1. Concerns relating to affiliation and diversity imbalances created 446 by liaisons; 447 2. Concerns relating to undue influence of liaisons on the nomcom 448 process. 450 Since [RFC3777] places no restrictions on the "primary affiliation" 451 of liaisons, it is possible for more than two NomCom members to share 452 the same primary affiliation. One example is the 2006-2007 NomCom, 453 where two voting members, the past NomCom chair, the ISOC Liaison and 454 the IESG liaison all shared a single primary affiliation. 456 In addition to affiliation imbalances, there is the issue of 457 diversity in liaison participation. While IESG and IAB liaisons 458 cannot serve in successive years (since IESG and IAB terms are two 459 years and a candidate whose position is being considered is not 460 eligible to serve as a liaison), no such restriction exists for other 461 liaisons and it has become common for other liaisons to return in 462 successive years. 464 While liaisons are non-voting, concerns were raised about the 465 influence that liaisons may have on NomCom voting members. Some 466 confirming bodies have explicitly instructed liaisons not to provide 467 any information unless the NomCom asks for the information directly, 468 and some NomCom chairs have set similar rules for liaisons. However, 469 there is a tension between being told "say nothing unless you are 470 asked directly", and participating in conference calls unable to say 471 anything when incorrect or incomplete factual statements are made. 473 We discussed how best to limit liaison participation in NomCom. 474 Currently, an important role of the liaisons is to monitor the nomcom 475 process and raise potential concerns about process violations. 476 However, currently [RFC3777] does not provide guidance on what a 477 liaison should do in the situation where a process violation occurs, 478 and it is not clear that this responsibility primarily resides with 479 the liaisons or with the past nomcom chair. If the primarily 480 responsibility for process monitoring is assumed to reside with the 481 past nomcom chair, then the role of the liaisons may be reduced or 482 eliminated, or the role may be restricted to those activities 483 required to supplement the past nomcom chair's responsibilities. 485 6.3. What a Confirming Body Actually Confirms 487 The 2006-2007 NomCom encountered a situation where they moved one 488 Area Director to IETF Chair and reopened nominations for the vacated 489 position - at this point, they had a complete slate, except for the 490 vacant slot, but IAB wasn't sure they could confirm a slate with one 491 vacancy or not. 493 Two considerations apply here. 495 1. Moving an incument, especially to IETF Chair, is "worst-case" - 496 it would be helpful to know that the incumbent will be seated in 497 the new position, before declaring the old position open. 498 2. Confirming bodies don't just consider each candidate in isolation 499 - there is also a sense that the confirming body ought to look at 500 the proposed slate, together with incumbents whose positions were 501 not considered during this NomCom cycle, as a group, to ensure 502 that the group will work well together. 504 While it would simplify the confirmation process if confirming bodies 505 were willing to confirm partial slates or complete slates with 506 problematic candidates and "fill in" the remaining slots later, the 507 design team members were aware of several cases where the confirming 508 bodies identified concerns about two candidates serving together. In 509 some cases, both candidates were asked if this was really a concern 510 ("can you let bygones be bygones?"). In other cases, the NomCom 511 provided a slate with a different candidate, to address the 512 confirming body's concern. 514 6.4. 2007-2008 Dispute Resolution Process Experience 516 The 2007-2008 NomCom exercised a new code path - for the first time, 517 a NomCom chair invoked the RFC 3777 dispute resolution process. This 518 means that a third-party arbiter is selected to investigate and 519 resolve the issue under dispute. 521 6.4.1. Selecting an Arbiter 523 The arbiter is selected by the ISOC President - but the ISOC 524 President has no way to know whether a proposed arbiter is also a 525 current "willing candidate" being considered by the same NomCom 526 committee. 528 6.4.2. Scope of Dispute Resolution Process 530 [RFC3777] names four cases where the dispute resolution process 531 should be invoked. None of the cases cover disputes between the 532 NomCom and a confirming body. 534 6.4.3. Constitutional Crisis 536 It is possible for either the Nomcom or a CB to wedge the process in 537 a way where it cannot proceed. The Nomcom can refuse to select a 538 candidate. A CB can refuse to either confirm or reject a proposed 539 candidate. It's unlikely that it would make sense to provide an 540 arbiter the powers to override either of these decisions. 542 Ultimately, we're dependent on the good will of both the Nomcom and 543 CB in the completion of the nominations process, and such good will 544 should be encouraged. The maxim is that "good fences make good 545 neighbors" - in this case, a better delineation of expectations 546 between the Nomcom and the CB is probably the best defense against a 547 future "Constitutional Crisis". 549 7. Security Considerations 551 This specification describes issues with the current IETF Nominating 552 Committee process ([RFC3777]). No security considerations apply 553 beyond those discussions regarding confidentiality of NomCom 554 deliberations. 556 8. IANA Considerations 558 No IANA actions are requested in this specification. 560 9. Contributing Authors 562 o 2006-2007 Andrew Lange 563 o 2005-2006 Ralph Droms 564 o 2004-2005 Danny McPherson 565 o 2003-2004 Richard Draves 566 o 2002-2003 Phil Roberts 567 o 2001-2002 Theodore Ts'o 568 o 2000-2001 Bernard Aboba 569 o 1999-2000 Avri Doria 570 o 1998-1999 Donald Eastlake 3rd 571 o 1997-1998 Michael St. Johns 572 o 1996-1997 Geoff Huston 573 o 1993-1994 Fred Baker 575 10. References 577 10.1. Normative References 579 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 580 Recall Process: Operation of the Nominating and Recall 581 Committees", BCP 10, RFC 3777, June 2004. 583 10.2. Informative References 585 [RFC2027] Galvin, J., "IAB and IESG Selection, Confirmation, and 586 Recall Process: Operation of the Nominating and Recall 587 Committees", BCP 10, RFC 2027, October 1996. 589 [RFC5078] Dawkins, S., "IAB and IESG Selection, Confirmation, and 590 Recall Process: Revision of the Nominating and Recall 591 Committees Timeline", RFC 5078, October 2007. 593 Authors' Addresses 595 Spencer Dawkins (editor) 596 Huawei Technologies (USA) 598 Phone: +1 214 755 3870 599 Email: spencer@wonderhamster.org 601 Danny McPherson 602 Arbor Networks, Inc. 604 Email: danny@arbor.net 606 Full Copyright Statement 608 Copyright (C) The IETF Trust (2008). 610 This document is subject to the rights, licenses and restrictions 611 contained in BCP 78, and except as set forth therein, the authors 612 retain all their rights. 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 617 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 618 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 619 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Intellectual Property 624 The IETF takes no position regarding the validity or scope of any 625 Intellectual Property Rights or other rights that might be claimed to 626 pertain to the implementation or use of the technology described in 627 this document or the extent to which any license under such rights 628 might or might not be available; nor does it represent that it has 629 made any independent effort to identify any such rights. Information 630 on the procedures with respect to rights in RFC documents can be 631 found in BCP 78 and BCP 79. 633 Copies of IPR disclosures made to the IETF Secretariat and any 634 assurances of licenses to be made available, or the result of an 635 attempt made to obtain a general license or permission for the use of 636 such proprietary rights by implementers or users of this 637 specification can be obtained from the IETF on-line IPR repository at 638 http://www.ietf.org/ipr. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights that may cover technology that may be required to implement 643 this standard. Please address the information to the IETF at 644 ietf-ipr@ietf.org.