idnits 2.17.1 draft-crocker-nomcom-process-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 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.) ** There are 3 instances of too long lines in the document, the longest one being 49 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2010) is 5015 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3777' is mentioned on line 592, but not defined ** Obsolete undefined reference: RFC 3777 (Obsoleted by RFC 7437) == Unused Reference: 'RFC3777bis' is defined on line 759, but no explicit reference was found in the text -- No information found for draft-barnes-Nomcom-report-2009 - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 2777 (ref. 'RFC3797') (Obsoleted by RFC 3797) -- Obsolete informational reference (is this intentional?): RFC 5078 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 5680 (Obsoleted by RFC 7437) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker, Ed. 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Informational S. Brim 5 Expires: January 27, 2011 Cisco 6 J. Halpern 7 Ericsson 8 B. Wijnen 10 B. Leiba 11 Internet Messaging Technology 12 M. Barnes 13 Polycom 14 July 26, 2010 16 Nomcom Enhancements: Improving the IETF leadership selection process 17 draft-crocker-nomcom-process-00 19 Abstract 21 Every year the IETF's Nominating Committee (Nomcom) reviews and 22 selects half of the IETF's leadership on the IESG, IAB and IAOC/ 23 Trust. In the 18 years since the inception of the Nomcom process, 24 the Internet industry and the IETF have gone through many changes in 25 funding, participation and focus, but not in the basic formation, 26 structure or operation of Nomcom. This paper explores challenges 27 that have emerged in the conduct of Nomcom activities, particularly 28 due to changing IETF demographics. The paper reviews the nature, 29 causes and consequences of these challenges, and proposes a number of 30 specific changes. The changes provide better communication of Nomcom 31 institutional memory, enhance Nomcom membership expertise, and 32 produce stronger confidentiality and etiquette practices among Nomcom 33 participants. Some changes require formal modification to Nomcom 34 rules; others can be adopted immediately. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 27, 2011. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Nomcom Management . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Nomcom Member Knowledge . . . . . . . . . . . . . . . . . . . 8 73 4. Nomcom Confidentiality . . . . . . . . . . . . . . . . . . . . 11 74 5. Nomcom Independence . . . . . . . . . . . . . . . . . . . . . 14 75 5.1. Liaison Influence . . . . . . . . . . . . . . . . . . . . 14 76 5.2. Politicking . . . . . . . . . . . . . . . . . . . . . . . 16 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 8. Informative References . . . . . . . . . . . . . . . . . . . . 17 80 Appendix A. Draft IETF Nomcom Independence and 81 Confidentiality Policy . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 The IETF conducts an annual process, selecting half of its 87 leadership. Selections are made by a Nominations Committee (Nomcom) 88 of randomly chosen volunteer participants. Each Nomcom spends more 89 than 6 months, recruiting nominees, interviewing them and the 90 community, and laboring over criteria and trade-offs. The Chair of 91 Nomcom and the liaisons from IETF-related groups are appointed, non- 92 voting members. The selections made by a Nomcom are reviewed by 93 Confirming Bodies that consider the conduct of the Nomcom process 94 and, to some extent, the adequacy of selected candidates. The Nomcom 95 process was developed in 1992. In the 18 years since then, the 96 Internet industry and the IETF have gone through many changes in 97 funding, participation and focus, but not in the basic formation, 98 structure or operation of Nomcom. The only significant changes were 99 to add to Nomcom's workload, by creating more staffing positions for 100 the recently-formed IAOC/IETF Trust and the RAI area, and to its 101 disclosure by making the list of nominees public. [RFC5680] 103 When the Nomcom process was created, most IETF meeting attendees were 104 heavily involved in a range of IETF work; most really did see 105 themselves as integral to an IETF "community". Today there is 106 significantly greater diversity in IETF participants' background, 107 knowledge, and working styles. Many participants still are deeply 108 involved in the IETF, but many others are more narrowly focused, with 109 limited IETF involvement. Often they track only one working group 110 and contribute to none of its discussion, writing or leadership. 111 Many participants are more familiar with the process and culture of 112 another standards body and are therefore more likely to use that 113 frame of reference when pursuing IETF work. This results in 114 volunteers with potentially less IETF experience, less understanding 115 of IETF culture and less appreciation of the specific strengths (and 116 weaknesses) of the IETF approach to standards development. Instead, 117 they bring their own norms, often including a stronger sense of 118 loyalty to other groups. 120 This can create conflicting goals. One of the cornerstones to the 121 IETF's cultural model is that an individual participates as a private 122 individual rather than as a representative of their employer. The 123 IETF Nomcom process requires confidentiality among participants. For 124 example it is not acceptable for a participant to report details of 125 the process to their work supervisor. Violation of confidentiality 126 threatens participant willingness to be candid in interviews and 127 discussions. Equally, politicking intimidates participants and makes 128 political leverage more important than the skills of an applicant. 130 Nomcom decisions are to be based on individual merit, such as quality 131 of technical contributions. The model of personal participation 132 encourages individual assessments based on professional judgment, 133 rather than on expedient corporate preferences that are driven by 134 current business interests. Certainly Nomcom takes note of 135 organizational affiliation, but this is for better understanding the 136 current perspective of the individual and for attempting to ensure 137 diversity of views. Still some participants have difficulty making 138 the distinction between their role as an individual, versus their 139 role as a corporate representative. 141 Whatever their causes, some significant problems are affecting the 142 operation of Nomcoms. (For example, see [Nomcom2009].) The 143 recommendations made here cover four basic areas of concern: 145 Knowledge of IETF culture, rules and processes 147 IETF leaders do work that is substantial and difficult. It is 148 not possible to choose among different nominees without knowing 149 the depth and breadth of that work, since different nominees 150 will have different skills and limitations. Some IETF 151 leadership work is managerial, some is conceptual, some is 152 administrative and some is legal. 154 A Nomcom voting member must understand which position requires 155 which talents. By itself, attending a few IETF meetings cannot 156 ensure enough experience with IETF leadership work to 157 understand the current demands. 159 Nomcom Confidentiality 161 Nomcom performs a human resources personnel hiring, firing and 162 retention process for the IETF. In order to obtain accurate 163 and meaningful input from the community and in order to have 164 full and frank discussions about nominees, the details of a 165 Nomcom's work must be restricted to the current members of the 166 Nomcom. The need is not merely for confidentiality of the 167 comments made about nominees but also those made about everyone 168 else. For example it can be extremely destructive to have a 169 candid comment about the IESG get back to the IESG. Any 170 pattern of such leakage makes it unlikely that candid comments 171 will be offered. 173 Nomcom Independence 175 Since Nomcom is tasked with selecting IETF leadership, 176 credibility in the Nomcom process relies on having Nomcom's 177 operation be meaningfully independent of the current IETF 178 leadership. At the same time, the process requires oversight, 179 to ensure that it is fairly conducted. One source of tension, 180 given these two requirements, is in having liaisons from 181 leadership groups be responsible for oversight. They represent 182 core IETF authority. Particularly within interviews, the fact 183 of their role with those groups can sway participants away from 184 full candor. This threatens the ability of Nomcom to obtain 185 sufficiently complete information that is needed for making 186 truly independent assessments. 188 Politicking for Nominees 190 An organized campaign that seeks selection of a particular 191 nominee directly works against the Nomcom effort to select 192 candidates based on merit. The use of political leverage is 193 destructive to efforts at evaluating skills and 194 accomplishments. However such politicking is common in some 195 other standards groups and has been observed in the IETF. 197 The basic concepts of confidentiality and protection against conflict 198 of interest are intended to ensure that those entrusted with an 199 important process are free to perform it, without any appearance or 200 reality of external pressures and with strict focus on the quality of 201 the process. This is not a question of individual integrity, but 202 rather of inherent confusion created by any participant exerting 203 undue influence on the Nomcom process. 205 This note discusses some of these challenges and offers 206 recommendations for alleviating them. The recommendations are 207 specific. However the reader should distinguish between a suggested 208 framework for action, configured according to a number of types of 209 choices. That is, definition of parameters, versus the specific 210 values assigned to those parameters. Therefore, the reader should 211 separately consider the approach being suggested for solving an 212 issue, versus the specific details suggested when using that 213 approach. 215 For example, there is a suggestion to have two different pools for 216 selecting Nomcom members and criteria that would distinguish between 217 the pools. It is possible to debate whether to have multiple pools, 218 as distinct from debating whether the number should be two or whether 219 the offered criteria for the second pool compose an acceptable set. 220 Readers are encouraged to separately consider the broader 221 recommendations versus the details that make the recommendations 222 concrete. Equally, some recommendations lack complete detail. The 223 details matter, of course, but first there must be agreement about 224 the approach. The details should be developed after that. 226 Readers are encouraged to offer alternatives and garner support for 227 them, should they consider specific recommendations problematic. 229 2. Nomcom Management 231 There are informative specifications for the selection of Nomcom 232 participants, for Nomcom's primary deliverables and for its major 233 deadlines. [RFC3777] [RFC5078]. The documents provide little detail 234 about Nomcom internal operations, and each Nomcom is both free and 235 required to make many decisions about the details of the way it will 236 operate, in terms of meetings, interviews, nominee analysis, 237 decision-making methods and candidate selection criteria. Much of 238 this flexibility is useful, to allow each Nomcom to determine the 239 operating style that best suits the current year's Nomcom 240 participants, as well as the current year's priorities that should 241 guide its selections. However the fact that each Nomcom starts from 242 what is essentially a clean operational slate makes its initial 243 organizing efforts rather daunting. 245 In order to develop sufficient understanding of the task and to 246 review and resolve the logistical details, each Nomcom must scale a 247 very large, initial hurdle. Although a Nomcom has the considerable 248 benefit of on-going participation by the previous Nomcom's chair, 249 there is no organized documentation to help Nomcom's benefit from the 250 long history of Nomcom's useful or problematic self-management 251 choices, although Nomcom Chair reports may contain some examples of 252 guidance. 254 RECOMMENDATION -- Nomcom Operations Guide 256 A collection of past Nomcom chairs and participants should 257 write non-normative guidance about common Nomcom operational 258 process choices that have been made, when these choices seemed 259 to work and what their limitations appeared to have been. A 260 Nomcom remains free to make its own organizational decisions, 261 but it has the option of simply adopting procedures and 262 milestones recommended by a group that has had extensive 263 experience in the process. 265 (Implementation) This requires no formal authorization to start 266 happening. While it might be appropriate to publish as an RFC 267 and therefore might need a degree of formal IETF approval, it 268 appears better to pursue this as an IETF wiki, to encourage 269 continuing enhancement by the community. A basic wiki could 270 easily be in place for the 2010-2011 Nomcom. 272 Each Nomcom is created as a new group. One challenge in the 273 management of new groups is to ensure that fair and thorough 274 discussion takes place. Any group has the risk of excessive 275 participation by one or another participant. This is exacerbated 276 when that participant carries additional power, such as being the 277 liaison of a confirming body. However the general concern about 278 dominating discussion applies for all participants. 280 RECOMMENDATION -- Nomcom Discussion Management 282 It is primarily the job of the Nomcom Chair to ensure that no 283 individual dominates the group. All participants in Nomcom 284 discussions are encouraged to assist the Chair in assuring that 285 no participant dominates Nomcom discussions. 287 (Implementation) The conduct of meetings and the staffing of 288 interviews is already under the control of the Nomcom chair. 289 So this topic requires no change to Nomcom rules. However it 290 will probably be helpful for the operations Guide and an RFC 291 3777 revision effort to emphasize this issue. 293 RECOMMENDATION -- Selective Exclusion 295 The Nomcom Chair may selectively exclude any participant from a 296 single Nomcom activity. This action may be overridden by a 297 majority of Nomcom Voting Members. Reasons for exclusion 298 include, but are not limited to a conflict of interest, 299 potential for violation of confidentiality, and potential for 300 intimidation of other participants. 302 (Implementation) This is a formal change to rules concerning 303 Nomcom "members", which will require a modification to RFC 304 3777, presumably as an enhancement to an RFC 3777 revision 305 effort. 307 3. Nomcom Member Knowledge 309 Anyone who merely attends a few recent IETF meetings is allowed to 310 volunteer for Nomcom. This rule has the considerable benefit of 311 being highly inclusive, but it does not guarantee that a volunteer 312 has any meaningful, direct experience in the IETF's technical or 313 leadership processes. That is, the criteria and the selection 314 process for members make it quite easy to have a Nomcom in which no 315 voting members have ever written RFCs, participated in formal reviews 316 of drafts, chaired working groups, or served on the IESG, IAB or 317 IAOC/Trust. In fact given the proportion of IETF participants that 318 have low levels of IETF process experience, the statistical 319 probabilities over time make it virtually inevitable. 321 The issue is a matter of insights and skills, not of motivations. 322 Direct participation does not guarantee an understanding of what is 323 needed to make the IETF work successfully, but it makes it more 324 likely. 326 The danger of a Nomcom with voting members who have little experience 327 in making the IETF work is that they will have little direct 328 knowledge of the qualities necessary for the people being selected to 329 run the IETF. Job descriptions exist for the positions that are to 330 be filled, and the descriptions are generally viewed as being useful. 331 However they cannot provide insight into practical aspects of 332 performing the jobs they describe, nor problems with the way those 333 jobs are done. In addition, the jobs being filled are for leadership 334 and oversight activities, yet Nomcom members often only have 335 experience as individual contributors. So the nature of leadership 336 skills also is not within their direct experience. 338 A special comment should be made about filling the IAOC/IETF Trust 339 position. The IAOC and IETF Trust perform the administrative and 340 legal work of the IETF. The work, and the members doing it, tend not 341 to be in the spotlight of the IETF and very few IETF participants 342 have much understanding of the required knowledge or activities. 343 Hence, even very active IETF participants are likely to have little 344 insight into the details of that position. That makes it extremely 345 difficult to evaluate nominees. The most recent Nomcom pursued a 346 series of tutorials with IAOC/Trust, in an effort to improve Nomcom's 347 ability to assess candidates. The tutorials were extremely helpful. 349 RECOMMENDATION -- Nomcom Tutorials 351 In order to select personnel for the IAB, IESG, and IAOC/Trust, 352 Nomcom members need to understand the current responsibilities, 353 activities and problems with these groups. To this end, it 354 would be extremely helpful to hold a series of scheduled 355 tutorials, during the first IETF meeting of a new Nomcom, by 356 representatives of IAB, IESG, and IAOC/Trust. They should be 357 closed, to permit more candid discussion. These tutorials will 358 be important, independent of the knowledge level of a Nomcom's 359 voting members. In addition to providing basic introductions 360 to the nature of the work done by members of each group, it can 361 highlight nuances of operation and current challenges. A 362 Nomcom would, of course, be free to use or ignore the 363 information from the tutorials, as it sees fit. 365 (Implementation) This does not require any formal approval. It 366 does require the collaborative concurrence of those presenting 367 material and those attending. It could easily be put in place 368 for the 2010-2011 Nomcom. 370 The random selection of Nomcom members usually produces a number who 371 have extensive IETF experience, but this really is merely a matter of 372 statistical happenstance. The criteria for volunteers and the manner 373 of selecting them make it statistically likely that some Nomcom will 374 eventually have none of these "senior" participants. That is, the 375 methodology makes it possible to have a Nomcom whose voting members 376 have no meaningful expertise about the IETF's operation. Repeated 377 application of this sampling rule means that the "possible" is 378 certain to eventually occur. 380 A Nomcom whose voting members lack sufficient expertise about IETF 381 management issues is overly dependent on its advisers and liaisons. 382 Such a dependence is a matter of strategic weakness that requires 383 making changes to the criteria and procedures for selecting at least 384 some Nomcom members to guarantee a basic level of expertise among 385 voting members. 387 RECOMMENDATION -- Nomcom Expertise Requirement 389 There needs to be review and agreement on the baseline level of 390 expertise that must be represented within Nomcom's voting 391 members. This requires agreeing on the details of the 392 expertise and on the minimal proportions of Nomcom that must 393 have that expertise, as well as on the means by which 394 differential expertise levels are selected. 396 Based on this requirement, here is a specific proposal... 398 RECOMMENDATION -- Selection Pool 400 There needs to be assurance of a minimum presence of Nomcom 401 voting members who have meaningful knowledge of IETF "decision 402 and leadership processes". A greater level of knowledge is 403 acceptable and preferred, but it is important to ensure a 404 minimum, while avoiding turning the Nomcom into an exclusive 405 committee of long-time participants. 407 Therefore, create a second pool of volunteers who satisfy more 408 stringent Nomcom participation rules. 410 Volunteers in this 'expertise' pool must have been on the IESG, 411 IAB or IAOC/Trust, or have been a working group chair. These 412 positions require a degree of direct involvement in the process 413 of IETF leadership. 415 Three (3) volunteers from the 'expertise' pool are selected 416 first. Those who are not selected from that pool are then 417 added to the general pool of volunteers, for the second round 418 of selection. Nomcom is not limited to having only three of 419 its members be experienced. 421 Various selection mechanisms are possible and reasonable. The 422 specific details are less important than is the requirement for 423 ensuring knowledge of IETF workings among the voting members. 425 (Implementation) This is a formal change to Nomcom selection 426 rules, which will require a modification to RFC 3777, 427 presumably as an enhancement to an RFC 3777 revision effort. 428 This enhancement might also require a change to [RFC3797], or 429 the Nomcom chair might need to accurately describe this when 430 they publish the seeds for the random selection. 432 4. Nomcom Confidentiality 434 The IETF mandates that Nomcom's internal activities be confidential. 435 Nomcom is a personnel hiring process and confidentiality is, 436 therefore, an appropriate professional standard. Sensitive 437 information about nominees and discussions needs to be kept internal 438 to the Nomcom. 440 Nominees, nominee's companies, the IAB, the IESG and others typically 441 know more about the internal workings of each current Nomcom than 442 they should. Examples abound. To cite one: with no prior discussion 443 of the topic by a Nomcom member with a particular nominee, that 444 nominee thanked the member for a comment the member made during the 445 previous day's internal Nomcom discussion about the nominee! 447 Leaks such as this are corrosive to the process. They mean that 448 participants must assume all of their comments will be reported to 449 others. This causes them to limit their comments, depriving Nomcom 450 of valuable information about nominees. 452 We need to reverse this tendency towards sloppiness. We need to make 453 clear that confidentiality is important and is expected to be 454 respected. Nomcom members need the understanding, incentives and 455 tools to preserve this confidentiality. 457 RECOMMENDATION -- Confidentiality Agreement 459 Everyone participating in Nomcom needs to sign a formal 460 Confidentiality Agreement. The Agreement needs to be carefully 461 tailored to cover the particular roles and relationships of 462 Nomcom members, especially including strictures against 463 discussing Nomcom activities with their friends, family, co- 464 workers, employer or other IETF participants who are not part 465 of Nomcom. For example, it needs to specifically state that 466 none of the covered information pertains to the signer's 467 employer. Having participants acknowledge the terms of the 468 Agreement means that the expectations on Nomcom members will be 469 explicit, detailed and documented. 471 A draft Confidentiality agreement is provided in Appendix A. 473 (Implementation) Requiring use of this Agreement probably needs 474 a formal change to Nomcom selection rules, which will require a 475 modification to RFC 3777, presumably as an enhancement to an 476 RFC 3777 revision effort. Note, however, that Nomcom members 477 and those participating in the Nomcom process can voluntarily 478 choose to sign the agreement, without any formal changes to RFC 479 3777. 481 RECOMMENDATION -- Anonymous Input 483 Any individual can submit anonymous comments, by approaching a 484 Nomcom voting member and requesting to have their comments 485 communicated with some obfuscation. 487 (Implementation) Private contact with a Nomcom members are 488 existing means of providing anonymous input. However this is 489 not necessarily well known to the community. It will probably 490 be useful to emphasize this alternative in the operations Guide 491 document and possibly the Nomcom web page. It might also make 492 sense to document them in an RFC 3777 revision effort. 494 RECOMMENDATION -- Liaison Disclosures 496 Liaisons are required to disclose some Nomcom information back 497 to their groups, but there is no clear guidance about what is 498 acceptable to disclose and what is not. Previous efforts to 499 specify this as a strict rule reached an impasse, as did the 500 effort to formulate one for this proposal. 502 Generally the point of a confirming body's questions should be 503 to ensure that the Nomcom was properly diligent in making their 504 selections, and not to second-guess the Nomcom's choices such 505 as by asking why a particular candidate was not chosen. 506 Broadly, then, it is reasonable and appropriate for the 507 confirming body and the Nomcom to discuss whether particular 508 skills or issues were considered, but not to discuss the 509 details about these skills or issues with respect to a 510 particular candidate. Some examples are provided here, to show 511 what types of interactions are viewed as acceptable and what 512 types are not. 514 Examples of interactions: 516 + "Did the Nomcom consider a particular candidate's lack of 517 skill in a specific technical area?" The question attempts 518 to pursue details about a specific candidate, but Nomcom 519 must not discuss candidate details. Hence a response of the 520 form "Nomcom had extensive discussion of the candidate's 521 technical skills" would be acceptable while a response such 522 as "Yes, the Nomcom noted that gap in the candidate's 523 skills, and chose the candidate in spite of it" would not. 524 The error could be compounded by then discussing the 525 particular deficiencies of competing candidates. 527 + "Doesn't the Nomcom see that choosing particular candidates 528 leaves a gap that a different, particular candidate would 529 have filled?" This asks about the details of at least three 530 candidates. A reasonable response would be limited to 531 noting that Nomcom considered these candidates carefully and 532 discussed the abilities of each and remains comfortable with 533 the selection(s) made. A problematic response would discuss 534 the details of particular candidates' skills or any 535 disclosure of the details of the discussion, or of why, 536 specifically, a particular candidate was not chosen. 538 + "Did the Nomcom consider a particular skill or factor for a 539 particular candidate, or compare particular candidates 540 according to particular factors?" This crosses into details 541 about specific candidates. On the other hand, it is 542 reasonable for Nomcom to respond that it considered the 543 importance of the skill, when evaluating candidates. 545 + "Why wasn't a particular candidate chosen?" Nomcom must not 546 discuss the details of its reasons for picking or rejecting 547 specific candidates. 549 + Did the Nomcom consider the disastrous personality conflicts 550 between a particular candidate and another IETF participant, 551 when they selected the candidate to work alongside that 552 participant?" If indeed this provides Nomcom with new 553 information, it could be reasonable for Nomcom to response 554 "No, the Nomcom may not have been aware of that situation." 555 Perhaps more safely, the Nomcom could respond that this 556 concern is indeed serious but that Nomcom still supports the 557 candidate, or that Nomcom wishes to instead select a 558 different candidate. Note that this responds to the 559 substance of the concern being raised, but not to its direct 560 application for a specific candidate. 562 + A confirming body might directly or indirectly recommend an 563 alternate candidate or, worse, suggest someone who was not 564 nominated. In general, the best response would be in the 565 style "Nomcom selected from among the nominated candidates 566 the one who exemplified the best available mix of 567 capabilities." 569 (Implementation) If a liaison is not completely certain that it 570 is acceptable to convey certain information to the confirming 571 body, or to answer a particular question, they should bring the 572 issue to the Nomcom chair and abide by the chair's guidance. 573 This practice would be useful to record in the proposed Guide. 575 5. Nomcom Independence 577 There are several concerns that have the potential to undermine the 578 independence of the Nomcom process. The multiple roles of liaisons 579 from the IETF groups for whom candidates are selected can produce 580 competing goals and their presence in portions of the Nomcom process 581 can produce distraction or intimidation. In addition, attempts to 582 assert undue influence in terms of promoting a nominee based 583 primarily on affiliation and politicking in general have become 584 problematic. Separately, any participant in Nomcom's internal or 585 interview processes can come to exert excessive influence. This last 586 concern is discussed in Section 2. 588 5.1. Liaison Influence 590 Liaisons to Nomcom serve multiple roles. In addition to the usual 591 job of "representing the views of their respective organizations" and 592 providing information to Nomcom, liaisons are tasked by [RFC 3777], 593 Section 4 #7 with a process oversight function for the IETF in 594 general and for their respective groups. Since Nomcom fills 595 positions in three of the groups that provide liaisons, these groups' 596 liaisons face inherent conflicts of interest. It can be difficult to 597 provide neutral oversight and maintain confidentiality to a group 598 which is judging the body that the liaison is representing. Still, 599 the need for oversight reasonably extends to include at least a 600 sampling of interviewing. Further, there might be specific concern 601 about a specific interviewer, prompting a need to observe their 602 interviewing behavior. 604 For example, the mere presence of some people who hold special 605 positions of authority (and therefore power) is sometimes problematic 606 in an interview. Interviewees making comments about one of these 607 groups have reported concern when a liaison from that group is 608 present, and are known to have avoided certain issues, for fear of 609 jeopardizing their working relationship with that group. Indeed, 610 liaisons have been known to report back to their groups the internal 611 discussions of a Nomcom. 613 Balancing these conflicting needs and concerns is challenging. The 614 concern for oversight has sometimes led to the extreme of having 615 liaisons participate as fully active Nomcom members, including 616 participating in every interview! The problem with suggesting that 617 they participate in only some is that this gives an appearance of 618 balance, but does not address the problem, for those interviews in 619 which a liaison is present. 621 Some obvious and reasonable choices appear not to be workable. For 622 example, one thought is to limit interview presence to liaisons who 623 are not part of a direct IETF leadership team. At best this reduces 624 to only the ISOC Liaison. However that would rely on the 625 interviewee's understanding the distinct difference in roles for that 626 liaison, and most will not. Further, it can reasonably be argued 627 that a representative from the group that supplies the IETF with much 628 of its funding should be counted as having significant (and 629 potentially intimidating) power. 631 RECOMMENDATION -- Interview Monitoring 633 Liaisons must not sit in on interviews without a specific 634 invitation. Liaisons currently have a monitoring 635 responsibility that reasonably includes sitting in on 636 interviews. However some interviewees are intimidated by 637 having liaisons present from IETF leadership groups -- 638 currently consisting of ISOC Board of Trustees, IAB, IESG and 639 IAOC/Trust. 641 In order to remedy this, Liaison participation in interviews 642 must be a considered exception, and not a regular practice. In 643 order to achieve the required monitoring of interviews, the 644 Chair and Advisors are tasked with attending interviews -- but 645 only as needed -- such as at the specific request of a Liaison. 646 [RFC3777] (section 4, rule 3) gives any committee member the 647 right to propose the addition of advisors to participate in 648 some or all of the deliberations of the committee. Under that 649 authority, committee members may choose to propose one or more 650 advisors to monitor interviews. The chair can therefore 651 appoint additional Advisors to assist with this, where the 652 Advisor is not affiliated with any IETF leadership group and is 653 not a candidate for any position with one. 655 This recommendation was the most difficult to develop, of those 656 in this proposal. It balances removing the inherent conflict 657 of interest and potential for intimidation from interview 658 situations, while ensuring that reasonable interview oversight 659 is possible. 661 This recommendation was the most difficult to develop, of those 662 in this proposal. It removes the inherent conflict of interest 663 and potential for intimidation from interview situations, while 664 ensuring that reasonable interview oversight is possible: 665 Liaisons currently have a monitoring responsibility that 666 reasonably can and should include sitting in on interviews. 667 However some interviewees are intimidated by having liaisons 668 present from IETF leadership groups -- currently consisting of 669 ISOC Board of Trustees, IAB, IESG and IAOC/Trust. In order to 670 remedy this, xxxLiaisons must not sit in on interviews. In 671 order to achieve the required monitoring of interviews, the 672 Chair and Advisors are tasked with attending interviews as 673 needed, possibly at the specific request of a Liaison. RFC 674 3777 (section 4, rule 3) gives any committee member the right 675 to propose the addition of advisors to participate in some or 676 all of the deliberations of the committee. Committee members 677 may choose to propose one or more advisors to monitor 678 interviews, under that authority The chair can therefore 679 appoint additional Advisors to assist with this, where the 680 Advisor is not affiliated with any IETF leadership group and is 681 not a candidate for any position with one. 683 (Implementation) As a formal prohibition, this is a formal 684 change to Nomcom selection rules, which will require a 685 modification to RFC 3777, presumably as an enhancement to an 686 RFC 3777 revision effort. Note, however, that the Nomcom Chair 687 is entirely responsible for defining Nomcom procedures; and 688 each Nomcom determines the attendance and style of the 689 interviews it conducts. Therefore as a practical matter, any 690 Nomcom can choose to exclude its liaisons from the pool of 691 interviewers. It also can choose to appoint additional 692 Advisors to assist with interview oversight. Still, this issue 693 is core and inherent; for the long-term, its handling should be 694 the result of a formal IETF consensus process. 696 5.2. Politicking 698 The current reality is that politicking during the Nomcom process 699 does take place, sometimes quite aggressively. It is one thing for a 700 nominee to make invididual and personal requests for support. It 701 quite a different thing to have an organized campaign by a business 702 associate, such as an employer. As an example, one company sought to 703 recruit the employees of its business partners who participate in the 704 IETF to register positive comments on the Nomcom wiki. 706 The IETF Nomcom process needs protection against these sorts of 707 attempts at manipulation. The IETF needs to make clear statements 708 about the behaviors that are acceptable, and those that are not, 709 among anyone involved directly or indirectly in the IETF process. 711 RECOMMENDATION -- Etiquette Guide 713 In order to ensure that every participant and organization 714 involved in the Nomcom process can be easily and adequately 715 informed of what is expected of them in the process, there 716 should be an "etiquette" guide supplied to all participants, 717 nominees, nominees' organization, interviewees, and others. 719 (Implementation) This is not, technically, a formal change to 720 Nomcom rules. It could probably be implemented informally. 721 However it asserts IETF norms. If only to add to its 722 credibility, this should be a normative document, detailing 723 desired and acceptable behaviors and those that are prohibited. 725 RECOMMENDATION -- Politicking 727 Any evidence of politicking should be reported to Nomcom and 728 should be treated as a significant, negative factor when 729 considering the nominee who is intended to benefit from the 730 politicking. 732 (Implementation) Nomcoms develop their own criteria. Hence the 733 use of this criterion does not require any formal change. It 734 will be useful to include this item in both the proposed 735 operations Guide and the Etiquette Guide. 737 6. Acknowledgements 739 This draft is the result of discussions among an ad hoc Nomcom 740 Selection Design Team, including Spencer Dawkins. Additional review 741 and suggestions have been provided by: Ross Callon, Olaf Kolkman, 742 Jason Livingood, Tony Hansen, Danny McPherson, Hannes Tschofenig. 744 7. Security Considerations 746 This document has no security implications, except for the viability 747 of the IETF's Nomcom process. 749 8. Informative References 751 [Nomcom2009] 752 Barnes, M., "Nomcom Chair's Report: 2009-2010", 753 I-D draft-barnes-Nomcom-report-2009, February 2010. 755 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 756 Recall Process: Operation of the Nominating and Recall 757 Committees", RFC 3777, June 2004, . 759 [RFC3777bis] 760 Galvin, J., "Operation of the Nominating and Recall", 761 I-D draft-galvin-rfc3777bis-00 762 (expired), March 2009. 764 [RFC3797] Eastlake, D., "Publicly Verifiable Nomcom Random 765 Selection", RFC 2777, June 2004. 767 [RFC5078] Dawkins, S., "IAB and IESG Selection, Confirmation, and 768 Recall Process. Revision of the Nominating and Recall 769 Committees Timeline", RFC 5078, October 2007. 771 [RFC5680] Dawkins, S., Ed., "The Nominating Committee Process: Open 772 Disclosure of Willing Nominees", BCP 10, RFC 5680, 773 October 2009. 775 Appendix A. Draft IETF Nomcom Independence and Confidentiality Policy 777 I am participating in the Internet Engineering Task Force's (IETF) 778 nominations process. Working with the independent IETF Nominations 779 Committee (Nomcom) often includes access to information that is 780 confidential. Preservation of the Nomcom's independence and 781 confidentiality are necessary to the integrity of that process. 783 In light of this I understand that: 785 I am participating as a private individual and not as a 786 representative of any organization. 788 The confidential information that is part of the Nomcom process 789 includes: 791 * The activities of IETF participants, as they are part of IETF 792 work, and 794 * Details of the IETF's Nomcom operation. 796 An example of confidential information that I am expected NOT to 797 disclose is information about my business associates, such as my 798 employer, that is not already public information. 800 I must not share any Nomcom confidential information with anyone, 801 unless the Nomcom Chair indicates it is acceptable. In particular 802 this means that I must not share any Nomcom information with co- 803 workers, family, friends or other IETF participants who are not 804 members of the current IETF Nominating Committee. 806 I understand that it is not possible to know what details are 807 harmless and what details are not. For example, people outside of 808 the Nomcom can combine small amounts of apparently harmless, 809 confidential information from multiple sources, in order to 810 generate a surprising level of insight into the workings of the 811 current Nomcom, and then disrupt its process. Therefore, I must 812 not communicate any of the Nomcom information to which I have 813 access. 815 Sometimes an employer, colleague, friend or family member will 816 attempt to pressure a Nomcom participant to reveal confidential 817 information or to take particular actions. I must explain to them 818 that the Nomcom confidentiality and independence policies do not 819 permit me to discuss this information or to act at their 820 direction. I should resign from the Nomcom, rather than allow my 821 employer or others to require that I disclose confidential Nomcom 822 information or change my interactions, preferences or voting. 824 I acknowledge that I have read and understand this Policy statement. 826 Participant: 828 Name (Print or Type): 830 Signature: 832 Date: 834 Authors' Addresses 836 D. Crocker (editor) 837 Brandenburg InternetWorking 838 675 Spruce Dr. 839 Sunnyvale 840 USA 842 Phone: +1.408.246.8253 begin_of_the_skype_highlighting +1.408.246.8253 end_of_the_skype_highlighting 843 Email: dcrocker@bbiw.net 844 URI: http://bbiw.net 846 Scott Brim 847 Cisco 849 Email: scott.brim@gmail.com 851 Joel Halpern 852 Ericsson 853 P. O. Box 6049 854 Leesburg, VA 855 USA 857 Phone: +1.703.371.3043 begin_of_the_skype_highlighting +1.703.371.3043 end_of_the_skype_highlighting 858 Email: Joel.Halpern@ericsson.com 860 Bert Wijnen begin_of_the_skype_highlighting end_of_the_skype_highlighting 862 Email: bertietf@bwijnen.net 864 Barry Leiba 865 Internet Messaging Technology 867 Email: barryleiba@computer.org 868 URI: http://internetmessagingtechnology.org/ 870 Mary Barnes 871 Polycom 873 Email: mary.ietf.barnes@gmail.com