This is the second part of a 2-part series article describing a method for voting among owners of domain names. To read the first part of this article click here.

Publishing Results

Each ballot will be denoted by a ballot identifier. The ballot will be published in a well-known place.

Results must be published in the port 43 whois that accompanies a domain registration whois output. Registrars may also make publicly available lists of domains and the associated ballot ID and vote cast.

[[ insert sample whois output with ballot answer ]]

After a ballot closes, each registrar will send the summary results to at least two vote counting entities. These organizations will tally summary results obtained from each registrar.  The totals of the summary results will be cross-checked against totals from the other vote counting entities.

Only summary information is sent to the summary-counting entities. Since the results are also published in the whois, any entity may audit the results by performing a whois on a sample of the domains to check the accuracy of the vote.  If a serious discrepancy develops, further analysis is available through complete reports.

Auditing Results

One of the requirements is to provide a framework for auditing the results of a ballot. Because only summary information is sent to the counting agencies, there needs to be a mechanism where a statistical study can be applied to the set of domains participating in a vote.

In the ICANN structure, the registrant of a domain is the only agent that may modify a domain, specifically the domain’s whois information. Thus, only the registrant of a domain may vote. Since the whois output of a domain is publicly available and may be looked up through whois queries, analysis of a vote may be preformed in a publicly visible and automateable fashion. Should a registrar provide false summary information, anyone may go and check the results through a completely open and transparent method.

Vote counting and auditing can be analyzed to prevent registrars from providing skewed results. If a registrar is found to have provided inaccurate results, that registrar’s customers may want to move their domains to a more reputable registrar. However, because the results of a ballot are auditable, registrars have little incentive to misrepresent results.

Registrars SHOULD be required to provide reports to the auditing agencies and MAY decline requests after providing at least one report to three different auditing agencies.

Ballot Development

After an issue has been identified as worthy of querying domain name owners, the ballot of issues is developed in a XML format as specified in draft-wesson-xml-ballot-00.txt. The ballot is published in a public place and disseminated to participating registrars. Registrars would notify registrants that have expressed a desire to know about new ballots.

Counting Agencies

A counting agency will work with the registrars to collect and aggregate the summary results of a ballot.  Performing the function will incur little cost. The requirement is to accept XML messages of totals and sum the results from each registrar into a total count for the vote.

Since all the parties participating in the ballots MAY have an interest in the outcome, the use of third-party vote aggregaters will provide a necessary role in validating the vote.

Counting agencies may decide to do further validation of the vote by requesting a detailed report which would list each domain and the vote, but it is up to the registrar to provide this information to a counting agency.

Additional Issues

ICANN needs to develop a process to develop ballots. A suggested mechanism is to allow the GA chair to determine when an issue needs to be put to a ballot.

Balloting does cost time and effort, and registrars will be collectively paying the bill as they will need to create, maintain, and manage polling areas for their registrants. An initial limit on the number of ballots that can be put to registrants during a time interval should be considered, such as no more than three ballots per year, or one ballot every N months where N may be 4, 6, or 12. A ballot may contain more than one ballot-issue.

The whois SHOULD only be used to validate the vote from statistical analysis and not from mining the complete results.  Registrars may limit access to authorized auditing agencies through the use of a AUP.

A balloting process should be reserved for those issues of significant importance, such as representation on the ICANN board or major changes in ICANN policy.

Ballot purchase and sales should be planned for, discouraged, and accepted as yet another form of capitalism. Though we may not like it, it will happen.

Ballots needed to be worded in a fair and neutral way.

We should recognize that we will have failures.  Still, it is better to have a voice than have no voice, and the good will created by registrars embracing this endeavor is well worth any hardship in aiding our customers in their ability to participate in the ICANN process.

ICANN Considerations

While it would be beneficial for all registrars to participate, this is not a requirement. Because this process does not constitute a regulated service, there are no conditions that require ICANN’s approval or an update to the contracts a registrar has with ICANN.

Thou it would be of some benefit to have the vote counting and auditing agencies receive some accreditation to some baseline specification none is required.

It would be beneficial if the outcome of ballots were taken as consensus from the holders of domain names within the ICANN framework.