idnits 2.17.1 draft-halpern-nomcom-report-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 24, 2009) is 5480 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 3777 (Obsoleted by RFC 7437) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF J. Halpern, Ed. 3 Internet-Draft Ericsson 4 Expires: October 26, 2009 April 24, 2009 6 NomCom Chair's Report: 2008-9 7 draft-halpern-nomcom-report-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 26, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 This document reports on the work of the 2008-2009 IETF nominating 46 committee (NomCom). This draft summarizes the process steps that 47 were used this year, and the work that was done. This is followed by 48 a discussion of process issues which caused difficulties for the 49 committee, but which require community agreement to before changes 50 can be made. Finally, there are some observations about things which 51 can help future committees, and which may help the community to 52 understand. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Getting Started . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Randomness and Voting Member Selection . . . . . . . . . . 3 59 2.2. Selection . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Liaisons and Confirming Bodies . . . . . . . . . . . . . . 4 61 2.4. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Organization, Scheduling, and Planning . . . . . . . . . . . . 5 63 3.1. Job Descriptions . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Questionnaire . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Collection of Feedback . . . . . . . . . . . . . . . . . . . . 7 66 5. Candidate Selection Process . . . . . . . . . . . . . . . . . 9 67 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. Volunteer exclusion . . . . . . . . . . . . . . . . . . . 9 69 6.2. Liaison participation . . . . . . . . . . . . . . . . . . 10 70 6.3. Nominee List Confidentiality . . . . . . . . . . . . . . . 10 71 6.4. The IAB Roles . . . . . . . . . . . . . . . . . . . . . . 11 72 6.5. Multiple Leaders from a Company . . . . . . . . . . . . . 12 73 6.6. ADs and chairs . . . . . . . . . . . . . . . . . . . . . . 12 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 This document provides a set of observations from the 2008/2009 84 nominating committee (NomCom) chair to the community. These are 85 provided in an Internet-Draft, to complement the report provided by 86 the chair at the March 2009 plenary. This is not a formal report 87 from the committee, and this report represents only one of many 88 possible views of the process. 90 In discussing the work of the NomCom, this document often refers to 91 the committees judgment of the wishes of the community. (Or other 92 similar words.) The committee is tasked by the RFCs with making such 93 judgments, and acting upon them. As noted, in some places it is even 94 expected to report those judgments as part of confirmation processes. 95 However, these judgments should not be confused with formal 96 determinations of rough consensus of the community, particularly as 97 might apply to changing procedures. It is not the NomCom's purview, 98 nor their right, nor is it practical with the processes that are 99 used, to make that sort of determination. For any process changes to 100 actually be made, separate determination of the actual rough 101 consensus of the community is needed. 103 2. Getting Started 105 The 2008-2009 IETF Nominating committee, like all nominating 106 committees for this community constituted since June 2004, was 107 appointed and operated according to the rules defined in [RFC3777]. 108 Lynn St. Amour (ISOC President and CEO) announced my appointment on 109 July 12, 2008. 111 2.1. Randomness and Voting Member Selection 113 I sent out the first call for volunteers to serve on the nominating 114 committee on July 15th, with the list of positions to be filled. 115 Several additional calls for volunteers were made, including a 116 presentation at the Thursday Plenary at the Dublin IETF meeting. 118 In my announcement send on August 1, 2008, I included a planned time 119 line, and the random seeds to be used in conjunction with the 120 procedure described in [RFC3797]. The seeds were the same as those 121 used by Lakshminath Dondeti the previous year: 122 o UK National Lottery 123 * http://www.national-lottery.co.uk/player/p/results/results.do 124 * All 7 numbers (5 numbers from 1 - 50 and 2 Lucky Stars from 1 - 125 9) 127 o US National debt ("Debt Held by the Public"), published by the 128 Treasury department as of August 28, 2008 (Published on August 29, 129 2008) 130 * http://www.treasurydirect.gov/NP/BPDLogin?application=np 131 * Last 8 digits, ignore the commas and periods 132 o US National debt ("Intragovernmental Holdings"), published by the 133 Treasury department as August 28, 2008 (Published on August 29, 134 2008) 135 * http://www.treasurydirect.gov/NP/BPDLogin?application=np 136 * Last 8 digits, ignore the commas and periods 137 o Megamillions Lottery, Friday August 29, 2008 138 * http://www.megamillions.com/numbers/pastdrawings.asp 139 * All 6 numbers (including the Mega Ball) 141 2.2. Selection 143 The NomCom volunteer list was announced, with affiliations, for 144 challenge on August 18. No challenges were received, and the list 145 was re-announced (minus the IAOC removal) on August 25. The random 146 selection URL was updated, as one of the announced URLs did not work. 147 On August 30, the results of the random selection, along with the 148 affiliation of the selected individuals, and all of the seed 149 information was announced, starting a challenge period. On September 150 8 the NomCom was seated and I began working with the members to get 151 the actual selection process in place. The selected volunteers with 152 their announced affiliation, as they were announced by email, were: 153 Wasserman, Margaret; of ThingMagic moving to Sandstorm 154 Isomaki, Markus; of Nokia 155 Hoeneisen, Bernie; of Swisscom 156 White, Russ; of Cisco 157 Lepinsiki, Matthew; of BBN Technologies 158 Hanna, Stephen; of Juniper Networks 159 Tschofenig, Hannes; of Nokia Siemens Networks 160 Aboba, Bernard; of Microsoft 161 Livingood, Jason; of Comcast 162 Hartman, Sam; of Painless Security 164 The liaisons were Lakshminath Dondeti of Qualcomm as the previous 165 year's chair, Dave Oran of Cisco as IAB Liaison, Ross Callon of 166 Juniper as IESG liaison, and Bert Wijnen as ISOC Board of Trustees 167 liaisons. 169 2.3. Liaisons and Confirming Bodies 171 I met with the IAB chair and liaison, and exchanged email with the 172 ISOC liaison, to work out some of the processes. The two topics were 173 what information would be provided for confirmation, and how 174 confirmation issues would be handled. 176 Even if it appears that everything is simple and clean, such 177 conversations between the NomCom chair and the confirming bodies in 178 advance of the work are a very good idea. 180 It was agreed with regard to confirmation information that in 181 addition to the descriptions of the candidates and the explanation of 182 why they are being nominated, the nominating committee would provide 183 most of the questionnaire to the confirming body. The exact method 184 for defining what would be kept confidential to the NomCom would be 185 worked out once the NomCom was seated. 187 With the IAB, it was also agreed that while the IAB would approve or 188 reject an entire slate, they would provide information to the 189 nominating committee with as much clarity as possible as to what the 190 problems were, if there were problems. 192 2.4. Tools 194 One of the most important aspects in practice for the NomCom, and the 195 NomCom chair, is the tools setup. Henrik Levkowetz built and 196 maintains an extremely useful tool suite for the nominating 197 committee. Henrik does not participate in the nominating committee 198 activities. However, nominating committee chairs may wish to ask him 199 to officially serve as an adviser to the committee. This allows him 200 to see information needed to diagnose problems with the tools. 202 The tools need to be configured properly each year. The first piece 203 of configuration required is a public / private key pair created by 204 the NomCom chair. The public key will be used by the tools. The 205 chair must arrange to deliver the private key to the NomCom members. 206 The email lists are an interesting case. The usual practice has 207 been, and is recommended to be, to use a two part list. The public 208 list is maintained by the secretariat, without an archive. It copies 209 all received email to all members of the NomCom, and to a private 210 list on the tools site. The private list is indexed and archived, 211 and stored encrypted with the years public key. Via the tools, 212 members can get at the full indexed, processed, email information, by 213 providing the private key the NomCom chair gives them. 215 The tools assist in keeping track of nominations, acceptances (or 216 turn-downs), questionnaires, and feedback. They are extremely 217 useful. 219 3. Organization, Scheduling, and Planning 221 Starting on September 8, 2008 the NomCom organized itself, scheduled 222 conference calls, and began getting its work done. 224 While I issued the initial calls for volunteers, the NomCom needed to 225 get several items sorted out as quickly as possible. Specifically, 226 the job descriptions needed to be understood, and the questionnaires 227 needed to be defined. 229 Once those two items were clarified, the NomCom moved on to working 230 out the interview process. Interviews were conducted with a number 231 of people. Some interviews were conducted to understand the needs of 232 bodies or slots to which the NomCom was responsible for making 233 appointments. Some interviews were conducted to better understand 234 existing people, issues, or situations. And interviews were 235 conducted to get opinions on nominees under consideration (within the 236 constraints of the confidentiality rules.) Many people from the 237 leadership bodies were interviewed. Not all the people on any body, 238 nor all the incumbents, were interviewed. Interviews were scheduled 239 based on either the committees perception that incremental 240 information could be obtained usefully, or because an individual 241 requested an interview. While it has the potential to produce an 242 excess of interviews, the nominating committee was able to interview 243 all individuals who requested time from us. Most interviews were 244 conducted by two volunteer members of the committee. A few of the 245 interviews were conducted by larger numbers of people due to the 246 importance of the topic and the potential information. One of the 247 chairs jobs became making sure that folks who had agreed to perform 248 interviews actually did them. Not due to lack of willingness, but 249 because many of the committee members were quite busy. 251 There were many teleconferences. Initial calls were every two weeks, 252 and then during the busy part of the cycle they were as often as 253 every 6 days. This year Cisco and Microsoft provided the conference 254 call facilities, for which I thank them. We tried a free conference 255 call facility, but it had very bad international access. 257 3.1. Job Descriptions 259 The procedures call for the various bodies (IESG, IAB, and IAOC) to 260 provide job description for the jobs that need to be filled. 261 However, the nominating committee is responsible for deciding what 262 qualifications and skills to actually look for, based on the provided 263 job descriptions and the community feedback. 265 This leads to an interesting question. If the nominating committee 266 decides that somewhat different qualifications are needed than were 267 asked for, what should it do? At the very least, it is required to 268 provide the list of what it actually looked for to the confirming 269 body. It would seem helpful if, when there is a difference, the 270 nominating committee could tell the community what it really wants. 271 We could not find a good way to do this. As there was no significant 272 initial difference (minor issues were discussed with liaisons), the 273 nominating committee simply published the provided job descriptions. 274 Later community input was used to complement those descriptions. 276 3.2. Questionnaire 278 There were two issues the NomCom needed to work out for the 279 questionnaires. First was what questions to ask. This sounds easy, 280 but is actually a good opportunity for the NomCom to start thinking 281 about what matters to the volunteers and how they will gather 282 information. After significant exchanges, the content of the 283 questionnaires was worked out. 285 It probably was unfortunate that I had posted the previous years 286 questionnaires on the web site, as this confused some people about 287 what they were supposed to do. 289 In conjunction with this, the nominating committee needed to work 290 out, and coordinate with the confirming bodies, what information 291 would be provided from the questionnaires in the confirmation 292 process. Two specific decisions were made, and worked well. 294 The questionnaires were explicitly and clearly labeled as to what 295 information would be provided to the confirming bodies, and what 296 would be kept confidential to the nominating committee itself. It 297 was concluded based on prior years that clear communication about the 298 expectation that most of the information would be shared with the 299 confirming body was necessary. 301 The nominating committee debated what was the best way to ask for 302 private information. The decision was that a single question at the 303 end of each questionnaire would ask for further input not to be 304 shared with the confirming bodies. This allowed folks to tell the 305 NomCom what they thought was important while clearly allowing the 306 NomCom to share enough information with the confirming body to help 307 them perform their job. 309 4. Collection of Feedback 311 The nominating committee can not evaluate the nominees on its own. 312 The 10 volunteers, even with the help of the liaisons, simply do not 313 know all the people, or all the relevant information even about the 314 people they individually know. Community feedback is an essential 315 part of the process. 317 In order to get this feedback, the nominating committee reviews the 318 nominees, and then sends out requests for feedback. These requests 319 must be done in a fashion that complies with the confidentiality 320 rules in place. The practice that has developed is to send the 321 request to a list of people who may have useful information. The 322 list includes not just people under serious consideration, but also 323 some number of folks who are not being considered, typically because 324 they are not willing or able to serve. This padding is intended to 325 provide some confidentiality to the actual process. 327 In some cases, because the list of nominees was very long, the 328 committee also made a first pass at removing people from the list 329 before soliciting feedback. This is useful to help the community 330 focus where it will do the most good. But it has the drawback of 331 requiring certain preliminary decisions (which can be changed later) 332 before there really is sufficient information. 334 It would probably have been useful if I could have found a good way 335 to tell the community what constitutes helpful or unhelpful feedback. 336 Helpful feedback is specific and clear. "Person X did action Y which 337 had benefit / drawback Z." This can be coupled with indications as to 338 whether the commenter thinks this was isolated, or a pattern (for 339 good or ill.) General descriptions of patterns of positive or 340 negative behavior are helpful, but nowhere near as helpful as 341 specifics. General comments like "A would make a good IAB member" or 342 "how could you possibly consider B for that IESG slot?" are actually 343 relatively unhelpful. The NomCom process is not voting, and the 344 committee does not count support. While it means something if 345 several vague positive notes are received, and no negative ones, it 346 does not actually help the committee evaluate whether this person 347 would make a better or worse candidate than some other nominee. 348 Another common kind of response that is less helpful on its own is 349 simple ranked lists of nominees. If coupled with feature 350 descriptions ("I prefer L to M because of property N" then such lists 351 gain some value. 353 In keeping with the confidentiality rules, one of the properties of 354 the tool is that a person will never see their own name on the list 355 of names on which feedback is solicited. This is to avoid telling 356 the person whether they are, or are not shortlisted. It is presumed 357 that the individual is capable of providing feedback on themselves 358 anyway. As noted below, this particular piece of opacity does not 359 work. Folks can just ask around, find someone else they know who has 360 also solicited, and usually find out if their name was on the list. 361 (Yes, it can be argued that the confidentiality rules tell people not 362 to relay that sort of information. But since we know from individual 363 reports that this happens frequently, the reality seems more relevant 364 than the theory.) 366 5. Candidate Selection Process 368 The process of selecting candidates for confirmation, and then 369 working with the confirming body, is a complex and mostly 370 confidential one. It is the nominating committee chair's job to find 371 a process which will work, and then shepherd it through to 372 completion. 374 The nominating committee used many different tools, with 375 conversations (both voice and email) being the most important one. 376 At various points, selection processes were applied to individuals or 377 slates of individuals. When explicit votes were needed, preferential 378 ballots were used, with resolution based on Condorcet voting with 379 Instant-runoff voting (IRV) for resolving those situations where 380 Condorcet was inconclusive. (These techniques are described in many 381 web sites, and references were provided to the committee as part of 382 the process of agreeing to use this resolution mechanism. I do not 383 know how authoritative any one site is, so the reader is advised to 384 search on their own if they are interested in more details on 385 preferential voting resolution methods and their pluses and minuses.) 386 This was managed through open source tools, and proved quite 387 effective. 389 Candidates were selected, approved by confirming bodies, and their 390 willingness and availability verified by a few days after the RFC 391 specified February 22nd deadline. 393 6. Issues 395 A number of issues of various types were encountered during the 396 nominating committee process. As a rule of thumb, it seems the best 397 thing a nominating committee chair can do when planning the schedule 398 is to assume things will go wrong. So push the schedule hard even 399 when it looks like there is plenty of time. You will need it. 401 The following sections describe some of the issues which in my 402 personal opinion, based on what I observed, should be kept in mind in 403 working with the process. It is my recommendation that some of these 404 issues be addressed by changes in the defined processes. 406 6.1. Volunteer exclusion 408 One of the first items of confusion was when it was noticed that the 409 spirit of the exclusion from eligibility to serve on the NomCom and 410 the letter of the law do not match. The spirit is that folks serving 411 on bodies to which the NomCom is making appointments shall not 412 themselves be volunteer members of the NomCom. The letter of the law 413 lists the IAB and IESG. It does not list the IAOC. 415 One volunteer realized after he volunteered that as a sitting IAOC 416 member, he should not be a volunteer member of the NomCom. So he 417 politely asked to remove himself from the list. I removed him. But 418 the letter of the law ought to match the intent. Until it does, 419 NomCom chairs should keep an eye open for this potential 420 inconsistency. If the defining documents are revised for any reason, 421 the text there should be repaired as well. 423 6.2. Liaison participation 425 As mentioned earlier, I, as chaired worked out with the confirming 426 bodies and the liaisons the rules for the liaison participation in 427 the NomCom. The goal of this was to enable the liaisons to provide 428 useful input while avoiding the reported historical problems of some 429 liaisons in some years having too much influence in the deliberation 430 process. There is distinct ambiguity in the written rules as to the 431 intended and desired scope of participation by the liaisons in the 432 NomCom discussions. 434 As per the rules, and in order to permit the liaisons to be present 435 for as much of the discussion as possible, the liaisons were 436 permitted to participate in the discussions of how often we met or 437 held phone calls, and when such activities occurred. 439 The terms of participation in the discussion of individuals and 440 positions were designed to allow useful information, while preventing 441 excess. 442 o Liaisons are always permitted to provide information from the 443 bodies they represent, and to answer questions about those bodies 444 o Liaisons are permitted to provide, during email, phone, or face to 445 face discussions, factual information that they know personally 446 that they feel is helpful to the committee 447 o Liaisons are permitted and encouraged to use the same tools the 448 community uses to provided opinions, feedback, or other 449 information to the committee. 450 o Liaisons were prohibited from providing personal opinions in the 451 discussions of nominees. 453 6.3. Nominee List Confidentiality 455 The RFCs defining the NomCom process require that all information, 456 including the lists of nominees, who has accepted nomination, and the 457 lists of who is under actual consideration by the nominating 458 committee, be kept confidential. While this is an attractive rule, 459 it has resulted in a major problem and I believe needs to be revised. 461 As described above, the nominating committee needs information from 462 the community. To comply with current rules a padded set of names is 463 sent to a portion of the community for feedback. This has multiple 464 problems. First and foremost, it does not achieve the objective. 465 Folks will learn if they are on the list being solicited. With the 466 number of people who see the list, folks who want to know can find 467 out who is on the list. (People are people, and they will talk to 468 each other. Pretending otherwise is unrealistic. Hundreds of people 469 do not keep a secret.) And people will determine who the pads are. 470 Many times, no matter how hard the committee works, it will be 471 obvious which names are padding. 473 As a minor point, the padding is extra work. The committee has to 474 come up with credible names that they think won't be well known as 475 having turned down the nomination. And then the chair really should 476 check with those folks before using them as padding. I made some 477 mistakes in that regard, and it caused some people difficulty. 479 The most important reason for removing the confidentiality of the 480 nominees list is that the current process prevents the most important 481 source of input. The community members who are not the leadership, 482 the grass roots if you will, are the people who may well know 483 important and useful information about nominees, but are not going to 484 be solicited, much less interviewed. One of the main points of this 485 nominating committee process is to avoid having the leadership self- 486 appoint. Having a large portion of the community know the list of 487 nominees, and another large portion not know the list, is counter to 488 the goals. 490 My personal recommendation would be that the list of all individuals 491 who have accepted nomination for any given position be available 492 publicly starting 24 hours after the initial solicitation of 493 nominees. This should include the individual, affiliation, and 494 position, but no information as to where the nomination came from. 495 Incumbents should be treated as anyone else in terms of listing, 496 listing them when they have agreed to be considered as nominees. 497 Treating the incumbents any differently from other folks would merely 498 confuse the feedback. 500 6.4. The IAB Roles 502 Appointment of members to the IAB (either new members, or 503 reappointment of existing members) is an important part of the 504 nominating committee job. This year there was a complication in this 505 task. As far as the nominating committee could determine, the 506 community at large had very little understanding of what the IAB did, 507 or what made a good or bad IAB member. There was also, for a variety 508 of reasons, very little documentary evidence as to what individual 509 participants in the IAB had done in that role. This was further 510 complicated by confusion in the community, and possibly on the 511 nominating committee, as to what actions were just a person being a 512 good IETF member, and what actions were a person being a positive IAB 513 member. It is presumed that the two are not interchangeable. 515 Part of what made this particularly complex is that the issue was not 516 about whether the IAB is a positive part of the IETF. The community 517 sees the IAB as an important and positive part of the IETF. But when 518 asked to take that a step further, into the details which affect the 519 selection process, there was significant difficulty. 521 6.5. Multiple Leaders from a Company 523 For many very good reasons, the IETF does not have strict rules on 524 how many people from a company may serve on the IAB or IESG (or 525 IAOC.) At the same time, it is understood by the nominating 526 committee that having a large number of people from one company on 527 any given body is not a good idea. 529 The only reason this is even an issue is that when it comes time to 530 decide, different members of the NomCom, and of the community, will 531 weight this differently. That too is fine. It is merely important 532 to understand that this is a legitimate issue for nominating 533 committee members to consider. 535 There is a potential side-issue, which I would also prefer not result 536 in an additional rule. The nominating committee rules cover the 537 affiliations of the volunteers. They do not count the affiliation of 538 the liaisons or the chair. It would probably be a good idea for 539 those bodies appointing liaisons to keep an eye open for extreme 540 cases. It would be awkward to have a committee with two volunteers, 541 two liaisons, and a chair all from the same company. It would not 542 violate the letter of the rules, but would certainly be seen as 543 unfortunate. 545 6.6. ADs and chairs 547 One of the topics that came up this year is the policies with regard 548 to ADs and chairs. As with other things, this is a matter where the 549 nominating committee must judge the temper of the community. The 550 conclusions described here are this years committees understandings 551 of the community view. There are two loosely related issues. 553 The first is the question of ADs serving as working group chairs. 554 This can occur across areas, or within an area. The sense we 555 understood from the community is that even across areas this is not a 556 good idea. ADs serving as chairs clearly have much more influence 557 with their Area Director, and as such weaken the checks and balances 558 of the system. Within their own area, even with their co-AD serving 559 as responsible AD, this is seen as even more of a bad idea. 560 Obviously, there are transition situations (it takes time to find new 561 chairs) and special situations ("I thought it was done already") that 562 complicate any hard rule. But as a sense of the community, this 563 seemed to this committee to be a bad idea. It is not clear where, 564 other than this sort of document, these observations about "bad 565 practices" can be recorded to assist future activities. 567 A much subtler and more nuanced situation is the way that various ADs 568 go about picking chairs for working groups. It is very common for 569 ADs to want to pick chairs that they can work with. It makes life 570 MUCH easier. This does however have a tendency to center the pool of 571 chairs in an area around a few small groups. Some ADs have used 572 public calls for nominations as a way to counter this trend. Such 573 public calls often bring forward names that the AD would not have 574 considered who are strong, capable individuals. Sometimes even more 575 complex canvassing for good chairs is needed, particularly when the 576 working group has a complex set of constraints it needs to work 577 within. 579 7. IANA Considerations 581 There are no IANA Considerations in this document, as no computer 582 protocols are discussed, and no code points assigned. This section 583 may be removed by the RFC Editor. 585 8. Security Considerations 587 This is a report on an activity that occurred. Every effort has been 588 made to respect the mandatory confidentiality aspects of that 589 activity. Some of the proposals in this document would change those 590 properties, and such effect are clearly an important part of the 591 consideration of such changes. It is the author's view that the 592 trade-off would be to the benefit of the community. 594 The NomCom this year followed the practices of the last several years 595 with regard to managing information confidentiality. The archives of 596 the comments, questionnaires, and other email to the committee are 597 stored encrypted on a server manage by Henrik, with the decryption 598 key known to the committee members. Distribution of that private key 599 used a private password protected web site, with the password 600 provided to committee members by phone. If the committee can be 601 organized before the second face-to-face IETF meeting of the year, 602 the decryption key can be distributed manually at that meeting. 604 9. References 606 9.1. Normative References 608 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 609 Recall Process: Operation of the Nominating and Recall 610 Committees", BCP 10, RFC 3777, June 2004. 612 9.2. Informative References 614 [RFC3797] Eastlake, D., "Publicly Verifiable Nominations Committee 615 (NomCom) Random Selection", RFC 3797, June 2004. 617 Author's Address 619 Joel M. Halpern (editor) 620 Ericsson 621 P. O. Box 6049 622 Leesburg, VA 20178 623 US 625 Email: jhalpern@redback.com