As mentioned above, technical provisions for both voter registration and the general election had significant shortcomings. During voter registration, over 170,000 registrants crowded ICANN's servers, overloading them and precluding an uncounted number of individuals from joining the At-Large Membership. The servers' inability to keep up with demand traces back to decisions made early in the planning stages of the election.
Early in its thinking about the election, the Board severely underestimated the Internet community's interest in its election. In late 1999, ICANN President and CEO Mike Roberts referred to the election's "minimum goal of 5000 members," [ 22 ] and ICANN staff seem to have designed the registration servers with an extremely limited electorate in mind. Servers began accepting registrations as early as February 2000, but, as is discussed above, the election plan went through significant changes between then and the end of registration on July 31. At the Yokohama meeting, Roberts stated that the servers had been designed with the February-March specifications in mind; they could handle approximately 100 registrations/day, with peaks of up to 500/day. Already by the Yokohama meeting, the servers had seen demand of about 1,000 applications/day, with peaks as high as 2,000/day. As a result, the servers were stumbling, and frequent service outages were the result. However, Roberts maintained that, while a few limited changes could be made, the system was basically resistant to upgrade, and reminded the Board that their design was consistent with original goals.
Server capacity was eventually increased, however, and ultimately permitted as many as 24,000 registrations per day. Such an increase in capacity indicates that the system was less resistant to scaling than had been thought; ICANN has not commented on the types of upgrades that were made.
The activation process, in which voters confirmed their registration by entering information mailed to them by ICANN, ran more smoothly. Problems in server capacity seemed to be resolved. But anecdotal evidence still suggests that many would-be voters had difficulty activating their membership. Lost (and ultimately irreplaceable) documentation, problems in the postal return system, and an unfamiliar activation system all contributed to creating a group of unsatisfied would-be members, able to register but not to "activate" their membership. However, since the size of this group cannot be objectively measured, it's impossible to determine whether their participation (or lack thereof) might have influenced the election's outcome.
By contracting actual election administration to the U.S.-based election.com, ICANN attempted to bring professional-grade resources and experience to bear on the task of providing robust, fraud-free election service. While generally successful, election.com's service failed at two critical moments, making voting service inaccessible for a substantial amount of time - about an hour early in the election cycle, then for approximately forty minutes at the very end. While it may be neither possible nor productive to debate the cause of these outages, they raise obvious concern about voters' access to the tools of voting, and about ICANN's responsibility to find and provide truly robust voting systems.
While the Election Committee had a lot of collective expertise and experience to offer, it is not clear that ICANN made best use of that expertise in soliciting bids for the election. Inflexible time restrictions, a lack of clarity in its specifications and, as discussed above, a certain vagueness in its intentions may have prevented ICANN from finding the provider best suited to the job. And while election.com's lack of disclosure to date about its election systems prevents an objective analysis of its service, service outages are clearly unacceptable in any serious election, online or otherwise.
| 2.1.4. Decisions Regarding Membership Relations | 2.1.6. Conclusions |
© 2001 NAISProject.org
Privacy Policy
webmaster@naisproject.org