This is the first part of a 2-part series article describing a method for voting among owners of domain names.

The primary intended use for this is to allow identifiable participants in the domain name system to vote on matters that affect the whole domain name system in an easy (and easily-verifiable) fashion. The method for voting is specifying a string in the whois data for a domain name.

Introduction

In 1999, ICANN attempted to create a mechanism for the bottom-up development of Internet policy. A major drawback to the balloting process was the high cost and the inconvenience of paper authentication. In this paper, I describe a method to disseminate a single ballot, a framework for identification of participants, a mechanism for collection of votes, and a methodology of validating the results.

The intent is to provide a low-cost, reasonably accurate gauge of the desires of domain name holders. The proposed result is a lightweight, non-anonymous representation of the opinion of domain name holders on policy that may affect their domain names.

Two of the main non-goals of this proposal are anonymity or individuality. While these are desirable goals for a national voting system, I have identified these as problems that are too hard to solve in this context. Also, while it might be desirable to identify the opinions of individual registrants, the proposed solution is optimized geared towards individual domain names.

By applying the 80/20 rule, this proposal is optimized for a system more like that of a corporation where shares are identified by domain ownership. While this may in some ways be similar to land-ownership being a requirement to access of voting privileges in the US in the 1800s, it still gives representation to a group that is fundamental to the domain name system. Later improvements (or different methods) can be added to address different groups of people affected by the domain name system.

This document is heavily slanted towards the com/net/org registries and registrars.  The maintainers of these zones have contracts with ICANN to use registrars, who in turn have their own contracts with ICANN. The method described can be used by any zones, but are currently tailored towards com/net/org.

Although some thought still needs to be given to how a ballot is developed and how and who says when a vote begins and ends, it is my desire to enable the public the mechanism for them to express their collective voice.

Overview

The basic idea is that ICANN or a major subgroup of ICANN would decide on issues that are important to domain name holders. Each issue would be formulated as a ballot, and that ballot would be distributed to registrars. Registrars would then tell their registrants about the ballot and explain how registrants could vote. One vote may be cast for each domain name owned.

Each vote is published in the whois for the associated domain name. After the voting period, each registrar tallies all the votes they received and sends a summary to a summary-counting agency, who then totals the votes for all registrars. The votes can be statistically validated by doing whois lookups.

The major limitation of this process is that voting is only by those who own domain names, and is proportional to the number of domain names they own. This is not a method for voting among Internet users.

Identification

In the com/net/org zones, domain registrants are the only entities that are authorized to update the domain information. Membership in the group covered by this document is thus defined as a domain name owner in com/net/org. A single domain represents a single registrant on a one-to-one basis. Although many registrants own more than one domain, attempting to develop normalization techniques to identify individual registrants are open to gaming. Because of this, domain ownership is equivalent to voter registration and each domain will be entitled to a single vote.

Although this process is optimized for com/net/org zones, it will work with any zone published under the root for which a registrar runs a whois service for.

Voting Process

A registrar will create a mechanism to uniquely identify the holder of each domain and will offer a mechanism that will allow the registrant to express their desire within the context of a ballot. The interfaces to registrants may be, but are not limited to, email, telephone, or the web.

Once a ballot opens, registrars will receive an XML file that will describe the ballot. An example of a ballot might look like:

[[ insert sample ballot ]]

Registrars MUST express the ballot exactly as in the XML file with equivilant options. Registrars may provide the ballot localized to a native language. in text or audio.

Registrars MUST present the options of the ballot EXACTLY as they are in the XML definition. That is, registrars may not reorder, rephrase, highlight, or default to an option that supports a position supported by the registrar.

The ballot MUST be represented in a neutral format. Ballots positions may not be encouraged in any marketing materials, nor may a registrar promote a position on web pages, in email, and so on. An example of a undesirable situation is where a registrar promotes a ballot position on a web page a registrant see to gain access to the pages where votes are cast.

Read Part 2