Re: [ALSC-Forum] a proposed action statement

[Jeff Williams]

Alan and all stakeholders or interested parties,

  Thank you Alen for you thoughtful and insightful proposal.
Many of you points are well known and well founded.
We [INEGroup] have advocated a number of them
for some time now with respect to At-Large membership
and voting registration.

Alan Levin wrote:

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

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 118k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1800 x1894 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208