Re: [ga] ICANN Board: Do you hear the people sing?
we should give domain owners the right to vote on issues that effect
*their* dns much like I have described in the attached document.
see (attached) draft-internet-ballot-01.txt
-rick
On Wed, 17 Sep 2003, George Kirikos wrote:
> Hello,
>
> Does ICANN have any comment to the petition at:
>
> http://www.petitiononline.com/mod_perl/signed.cgi?icanndns
>
> It's adding 10+ signatures per minute, many from very large companies,
> ISPs, small business, and individuals who recognize Sitefinder to be a
> fundamental abuse and subversion of the DNS by Verisign. ICANN doesn't
> need "2 or 3 days to make a comment" as suggested by Mary Hewitt. Call
> a Board meeting today, and put this to an end.
>
> I hope others will link to the petition, and thanks to those who
> already have spread the word via websites and forwarding emails to
> friends and colleagues. Let's keep up the pressure until ICANN does the
> proper thing, and either forces Verisign to stop (and repay their
> ill-gotten gains), or redelegates to a more worthy registry operator.
>
> Sincerely,
>
> George Kirikos
> http://www.kirikos.com/
>
Abstract
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.
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 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.
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.
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.