Re: [ALSC-Forum] a proposed action statement

[Alan Levin]

Dear ALSC,

I accept and could support your proposed action statement and believe that
it is a good starting point for this next ICANN meeting, yet I do not agree
with the examples that you use in points b) and c). I hope this email
contributes to your thinking and proposes viable alternative examples.

I have not seen any good reason to use the Domain Name System for a purpose
which is totally unrelated to why it was originally developed. The fact that
it is a system that is somewhat governed by ICANN is not sufficient
validation for application in the At Large.

The purpose of this email is to explain - in my simple understanding - how
the domain name system (DNS) works, and why this is an inappropriate
platform on which to base ICANN At Large membership rights.

The ALSC wish to use the DNS as an authentication - and registration or
other - mechanism, and therefore make domain name ownership a prerequisite
for At Large membership. I here explain why this undermines the initial,
current and future purpose and efficiency of this open system standard, and
suggest two alternative authentication mechanisms.


Background
The domain name system (DNS) was originally developed to make the Internet
(a dispersed network of computers) usable. Internet Protocol (IP) assigns
each host computer (a 'host' is a computer connected to the Internet) an IP
Number, which consists of four groups of number (1 to 255) each separated by
a dot.

IP numbers are grouped according to the network(s) that the host - which
they represent - is connected. Consequently, if a host is physically moved
from one network to another - which happens naturally as networks develop
and evolve - then the associated IP number changes also.

The DNS was developed so that hosts could easily be identified by names
rather than by numbers. Rather than 'name' each host solely with an IP
number, the DNS allows for a word ('domain name') to be associated with each
IP number. Thus, rather than the e-mail address 'sam@196.25.151.244', the IP
number is associated with a name, so that the address becomes
sam@jones.com,where 'jones.com' is the domain name representing the IP
number 196.25.151.244. This is more practical and hence, user friendly.

A benefit of the DNS is that the registrant of a name is separated from the
number of a host. Whilst a registered domain name must be associated with an
IP address, the name can be transferred from host to host, remaining the
property of the registrant. This logical infrastructure enables applications
to be developed in an object manner so that Internet services are easier to
use.

The DNS therefore must allow individuals or organizations to register a name
and assign that name to any host. For example:
- www.jones.com will be translated by a user's browser to the IP number of
the web host of jones.com
- e-mail address to sam@jones.com will be sent by an email client to the
mail server with the IP number associated with jones.com

Numerous documents have been developed - by the IETF - to clearly define the
domain name system in more depth with more accurate detail, including the
way in which domain names are registered, and the way in which domain names
and associated IP addresses are propogated throughout the system so that
routers (computers which form the interconnection points of the Internet)
'know' which IP address to associate with each domain name, and thus where
to 'find' any given host.

Once an Internet user has registered a domain name, this name is controlled
by the registrant and in most cases may be retained as an asset. (e.g. the
owner of jones.com can select the most competitive ISP to host this domain
and retain the same email address sam@jones.com). However, the majority of
Internet users rely on the domain name of their Internet Service Provider
(ISP).


Complexity
The DNS essentially comprises the root server system. This can be compared
to a tree with many branches. Using this analogy, the root server(s) are the
'trunk' and the levels of the domain name system are the branches. The first
split (branching) in the tree breaks into over 270 branches known as
'top-level domains' (TLDs). These either represent a country - e.g. '.uk' -
or a are non-specific - e.g. '.com'. These latter are termed 'generic TLDs'
(gTLDs).

Each of these top-level domains is controlled by a specific and different
TLD manager that may assign any number of further splits in each of their
branches (known as second level domains).

There is no defined limit in the number of generic top-level domains, and in
principle there can be an unlimited number. However, deepening the domain
tree is recognized as best technical practice - that is increasing the
number of branches below the TLDs rather than increasing the number of TLDs.
In the case of country code top-level domains (ccTLDs), the TLD manager may
allow the number of secondary splits to be unlimited - as in is the case in
Germany, or may have highly restricted the number (e.g. South Africa has
only 18). In the case of the restricted second level domain, it is usually
impossible for an individual or company to register (or purchase) a new
second level domain. Instead, individual registrations are available on the
third or fourth branch (or level of domain) blow the TLD. For example, the
.us domain has adopted a geographically defined mechanism where individual
domains can be registered only on the fourth or fifth level.

For example: Sam Jones can - on a first-come, first-served basis - register
'jones.net.za' in South Africa, or 'jones.orange.ca.us' in the United States
(if he lives in Orange County, California). 'jones.com' can be registered
anywhere.

Registration of a domain by a registrant requires not only contracting with
a registrar who is contracted to do so by the TLD registry; it also requires
access to two domain name hosts (a primary and a secondary - redundancy is a
critical element of the DNS) on which to 'park' or 'host' the domain. These
may also host web based applications operating at that domain - for example,
a web site or e-mail service - or may 'point' to other computers linked to
them (on the same local network or remotely else where on the Internet) that
do.

Some registrars do offer domain-parking services, but registries do not. In
many countries interested domain name registrants must therefore contract
with both a registry and one or two domain hosting services, increasing not
only the complexity but also the cost in both time and money.


Restrictive
Not least as a consequence of this complexity, the number of the potential
At Large voters that own domain names is considerably smaller than those
that would consider themselves At Large members, or those Internet users
that would like to become members of the At Large either now, or in the
future. In addition, these people may not need or want to own a domain name.

If domain ownership is to be a requirement for effective membership, then
this will force those that consider it important to participate in ICANN At
Large elections to register a domain name.

The creation of domain names solely for this reason will add an unnecessary
burden on the DNS system; the domain may never be used besides to vote.
Effectively this will be using the DNS for voter authentication - which it
was not designed to support, and cannot without significant modification to
the detriment of its primary function.

Effective participation will be further restricted due to financial cost.
The retail purchase price of a new domain name is nowhere less than $15 per
year (incl. hosting costs). A university professor in some parts of Africa
may earn as little as $120 per month for a permanent post. This cost is
therefore an effective barrier to legitimate participation.

It is conceivable that subsidized 'domains' could be created to facilitate
voting - even though their primary purpose would be authentication of the
owner. Any such subsidized domains would in all likely-hood either be
restrictive in functionality, or - if not - then costly.  Such a set up is
effectively a customized open system application resembling the DNS in
structure. Further, it would be using the DNS for a function (voter
authentication) that the DNS was not designed to support. Any such
application should more appropriately use a protocol number.


Insecure
Regardless of the above, registrars do not currently properly authenticate
any registrant information during the course of the registration process.
The only usual prerequisite requirements are a functional email address, and
for payment to be made.

A competent systems administrator who wished to do so could enable a Web to
DNS registration system that would operate freely and register hundreds of
domains per minute without any authentication of registration details other
then an email address. This effectively means that domain ownership is no
different from voting using nothing but an authentic unique email address.

Alternatively, a registrar or number of registrars could undergo a selection
process to be defined for voter-accreditation and contracted to provide
domain ownership information to ICANN for voting purposes. Such registrars
could be required to charge a fee for domain registration as the method for
authenticating an email address. As noted above, this would effectively be
an open systems software application resembling the DNS, and additionally
using the DNS to support a function that it was not intended at its design.

Alternative working models
There is now one experience of an ICANN election for which 158,000 email
users registered as ICANN voters, using a PIN sent by snail mail.

- Distributed snail mail distribution
Using this initial membership as a base estimate, and using attendance at
ICANN meetings or public participation in ICANN as a further indicator, it
is reasonable to envisage a controlled registration process of interested
Internet users using a distributed email enrollment system.

Instead of ICANN contracting with registrars to undertake domain name
ownership authentication, ICANN could simply contract with geographically
defined registries to distribute PINs by local snail mail.  This would be
less complex, more secure and is more appropriate to the mission of ICANN
keeping in mind that registries (gTLD and/or ccTLD) are natural monopolies.
RFC 1581 already recommends that ccTLD registries perform this type of role.

Although as yet there are no formal contracts between ccTLDs and ICANN,
there is nothing to prevent this limited number of contracts being
negotiated. Further, this approach helps to build the relationship between
ICANN and the ccTLDs. In addition, this model allows those registries that
are operated on a not-for-profit basis (and that consequently often retain a
large surplus) with a mechanism to contribute appropriate value back into
their customer communities.

This distributed enrollment model would effectively allow all e-mail users
who wished to do so to register for ICANN At Large elections. (Such a model
that has been discussed on the ALSC mailing list.) Fully subsidized support
by registries (ccTLDs) has already been obtained in several developing
countries subject to an agreed contract process with ICANN. If appropriate
(such as in the case of gTLD registries), full-subsidy could be capped (by
geographic region) to a certain number using some formula (e.g. first-come,
first-served such as is already the case with most registry systems). A
combination of subsidy/donation together with a capped number and a charge
to (or fee from) ICANN may be applied depending on contract terms.

Other recommendations on improving the process of e-mail registration with
PIN sent by snail mail are found in the NAIS report.


- IVR telephone collection of PINs
Further to the distributed postal mechanism recent thinking has developed
into using the global public telecoms network to facilitate the delivery of
PINs. The following is a simple example of how this could be implemented.

1. User registers via Web form or simple text email form (this registration
must include a personal code created by the user - personal code could be ca
lled a password)
2. Email address verification is sent by email to user with the telephone
number (same for all users) and a computer generated (unique) user code
3. User calls a telephone number and at the prompt enters personal code and
then prompted to enter a user code
4. If the personal code and user code is correct then the IVR (Interactive
Voice Response) reads out a PIN number (which can be replayed if you press
'1')

This has the advantage:
A. uses a 'similar' system to last elections (replace postal pin with
telephone pin)
B. personal code is separate from user code (will not be in the email
verification) to ensure acceptable level of security
C. because of the cost of the telephone call - some commitment must exist
D. cost of posting pins is eliminated
E. IVR can include an additional fee charged to the caller and recovered by
the organization - i.e. can be used as an international membership payment
mechanism
F. Entire registration and activation process is automated and hence no time
delays!

Disadvantage:
A. user must have international calling capability (low penetration in
developing countries)
B. phone must be tone (this includes most developing countries that have
telephone systems)

Hope this helps,

Alan

_______________________________
       Alan Levin
       AfriDNS
       http://www.afridns.org/
       tel: +27 21 4097025


----- Original Message -----
From: "Denise Michel" <dmichel@atlargestudy.org>
To: <forum@atlargestudy.org>
Sent: Friday, October 26, 2001 5:50 AM
Subject: [ALSC-Forum] a proposed action statement


>
> The ALSC would appreciate hearing your thoughts on the following draft
> statement proposed for ICANN consideration.  Although it seems highly
> unlikely that the Board will take final action on At-Large this year, it
has
> been proposed that the Board should acknowledge the progress that has been
> made in this area.  The statement recognizes key aspects of At-Large
(there
> should be an At-Large membership, organization and seats on the Board),
> while acknowledging that consideration and comment on the ALSC's report
will
> continue.
>
> *Draft* Proposed Action Statement for ICANN's Board
>
> Based on an extensive outreach, discussion, research, and
consensus-building
> campaign the ALSC recommends that, on November 15, 2001, the ICANN Board
> adopt the following recommendations concerning At-Large participation
> and representation.
>
> (1) The Board affirms that individual Internet users have a significant
> stake in ICANN's activities and should have the opportunity of fully
> participating in ICANN.
>
> (2) While the ALSC's final report remains open for comment and
> consideration, the Board acknowledges that the following basic principles
> should guide expedited action on At-Large:
>
> (a) Create an At-Large Supporting Organization (ALSO) as a
regionally-based
> framework for informed participation of any interested individual and for
> At-Large involvement in ICANN policy and decision-making (including
> mechanisms to foster discussion among individuals and with ICANN's
> decision-making bodies);
>
> (b) Focus At-Large membership on an identifiable and vested community (an
> ALSO electorate) to provide a practical mechanism for voter registration
and
> self-funding (e.g. The ALSC recommends that membership be based on
> individual domain name holders);
>
> (c) Provide a proportionate role for At-Large members in selecting ICANN's
> Board (along with other ICANN constituencies) (e.g. The ALSC recommends 6
> At-Large Directors in a 19 member Board).
>
> (3) The Board requests that the ICANN CEO solicit expressions of interest
to
> determine the degree of interest in creating local and regional ALSO
> entities that would support informed participation of interested
individuals
> and At-Large involvement in ICANN, and report the results to the Board at
> the March 2002 ICANN meeting.
>
> (4) The Board authorizes the extension of the ALSC until March 31, 2002 to
> work with the Supporting Organizations, other interested parties, and
ICANN
> staff on proposing detailed plans for an At-Large membership, voter
> registration, and a regionally-based, self-supporting ALSO.
>
>
> Denise Michel
> Executive Director
> At Large Study Committee
> dmichel@atlargestudy.org
>