> On Wed, 30 Jun 2021, Michael StJohns wrote: > > > First, you may want to give yourself a few days between close of > > challenges and doing the pull. If there are challenges and they need > > to be resolved, you need to be able to reschedule *before* ANY of the > > random sources are resolved without looking like you're putting your > > thumb on the scale. If you've already resolved the randomness, it's > > possible to game things a slight bit by announcing changes of affiliation or > withdrawals. > > Thanks for flagging this Mike. > > As I understand it, the current "challenge period" is one the current NomCom > chair adopted - it is not required by 8713 nor 8989. 8713 does, though, require > a challenge period AFTER the selection is run - see section 4.17. Yes, I shouldn't have called what we're in right now a "challenge period" (it actually has no name). There is really only one "challenge" period in the milestones: https://datatracker.ietf.org/nomcom/2021/ ...and it is mandated by https://www.rfc-editor.org/rfc/rfc8713.html#section-4.17 to start immediately after the first announcement of the voting member selection. We're not there yet. What we are in is a period with no name during which we're still tweaking the eligible volunteer list, as has been done by all recent NomComs. Just found about another one last night, for example. This period right now is required by https://www.rfc-editor.org/rfc/rfc8713.html#section-4.16. > I think the NomCom chair can proceed down this path, perhaps with the > precaution that the order and numbering of the current list be fixed as it is > now - and anyone later disqualified (even in the interval before the selection) > will be skipped over. > > This would be consistent with the practice in 8713 section 4.17 when > challenges are raised after the selection runs. During this current period the NomComs tweak the list with additions and deletions, but not with gratuitous reorderings. And then a final list is published before selection starts. Mike has a good point about there being only one source of randomness after the current "tweaking" period is over (thanks for the math!). I have added one more source of randomness to be drawn after this period is over to increase entropy. This implies some additional days of delay in the schedule, but we are still ok per RFC8713. Timelines have been updated accordingly. Thanks, Gabriel
