Inside ICANNWatch  
Submit Story
Lost Password
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)

    Membership Issues Voting Your Name
    posted by michael on Monday August 25 2003, @08:01PM

    Rick H Wesson writes "This document describes 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."


    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 light weight, non-anonymous representation of the opinion of domain name holders on policy that may effect 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.


    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.


    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.

    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."

      ICANNWatch Login  


    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

      Related Links  
  • Rick H Wesson
  • More on Membership Issues
  • Also by michael
    This discussion has been archived. No new comments can be posted.
    Voting Your Name | Log in/Create an Account | Top | 5 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Vote on What?
    by cambler (chris@ambler.net) on Tuesday August 26 2003, @06:45AM (#12127)
    User #36 Info | http://onthenet.ambler.net/
    What exactly would you have domain holders vote on, and why?

    That said, the idea is interesting, if even for technical hack value.

    But I don't see how registrars would pay for development costs when this "service" has absolutely no value to anyone except a very few people. Most customers won't care that they can vote, and hence, won't use this as an influencing factor in choosing a registrar.

    If I, as a consultant, went to a registrar and said, "I can code you the voting interface for a cool and cheap $5,000," the registrar would say, "Yeah? And what's that get me?"

    Rick? What's that get them?

    Ambler On The Net [ambler.net]

    [ Reply to This | Parent ]
    • 1 reply beneath your current threshold.
    by ldg on Wednesday August 27 2003, @02:59AM (#12132)
    User #2935 Info | http://example.com/
    Assuming that there is a reason for this, having one vote per domain is like handing the result over to speculators and corporations, leaving the average domain name holder with no influence at all. If anything, it should be one vote per registrant.

    Now, as Chris asked, what are we voting on? If there are no board seats, what's the point?
    [ Reply to This | Parent ]

    Search ICANNWatch.org:

    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com