Andrew Lange <andrew.lange@xxxxxxxxxxx> wrote: > > A few members of the community have expressed concern over two issues with > the selection process for this year's NomCom. I'm taking the liberty of responding to the second first. > Second: A sitting member of the IAB's name appeared on the candidate > list. According to 3777, section 15, sitting IAB, IESG and ISOC members > are not eligible to serve on the Nomcom. This was an oversight on my > part. Ordering in the list does matter for the selection process. > Although this person was not selected to serve, and the harm done is > minimal, it is important that the IETF follow our own processes as closely > as possible. This is not a good reason to restart the process. Although the inclusion of an ineligible name does affect the selection, there is no improvement in randomness from restarting vs. eliminating after the selection is complete. Restarting, however, introduces problems: - an inevitable suspicion that an unhappiness with the result may have influenced the decision to restart; - the possibility that members initially selected may have already incurred costs from planning changes necessary for them to serve; - the likelihood that members initially selected may have made plans which may prevent them from serving. (I do not, however, challenge the authority of the Nomcom Chair to restart the process.) > First: The list of volunteers was published later than recommended by RFC > 3777. This happened because, after the nominations period closed, there > was some dispute on the eligibility of a number of NomCom volunteers. > They were not on the secretariat's list, but they had attended the > requisite number of IETF's. I chose to provide the secretariat some time > to look into their eligibility... Here's our bug! " 14. Members of the IETF community must have attended at least 3 of " the last 5 IETF meetings in order to volunteer. " " The IETF Secretariat is responsible for confirming that " volunteers have met the attendance requirement. There is no way to ensure that this confirmation is timely. Nor is there any practical way to challenge Secretariat records. The Nomcom Chair must accept their finding (and risk challenge for exclusion) or give them whatever time they need. I strongly recommend that future Nomcom Chairs allow more time for this. > This resulted in the list being sent to the secretariat later than I > would have liked, and the message then got hung up in the secretariat's > queue. Again, future Nomcom Chairs should allow more time. RFC 3777 asks for " " The announcement should be made at least 1 week prior to the date " on which the random selection will occur. Any plan which doesn't allow three weeks seems unwise... > The selection is still deterministic, because the list ordering algorithm > used (alpha by first name) is deterministic. However, since the list was > published late, the appearance is not ideal. One must assume that this was the source of the challenge " " The first announcement should occur as soon after the random " selection as is reasonable for the Chair. The community must " have at least 1 week during which any member may challenge the " results of the random selection. " " The challenge must be made in writing (email is acceptable) to " the Chair. The Chair has 48 hours to review the challenge and " offer a resolution to the member. If the resolution is not " accepted by the member, that member may report the challenge " according to the dispute resolution process stated elsewhere in " this document. See section 6 of RFC 3777 for the dispute process. I agree that resetting the selection process is arguably better than starting this process; but I most sincerely hope we can avoid this problem in the future. -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf