Re: [ALSC-Forum] a proposed action statement

[Jefsey Morfin]

Dear Alan,
the most obvious reason why the naming plan cannot support the @large 
identification is given by the ALSC itself. They know the ICANN does not 
control the naming plan so they only can use the one part they control 
through a contarct and excluded the ccTLDs...

If a ccTLD sarted to support New.net, NameSlinger, PacificRoot, ORSC, 
CINICs, Boroon, etc... this would obviously be a problem as many @large 
would certainly enjoy supporting them too. What would be a real problem for 
people engaged into the "International TLD (sales) business".

Now, you want to make sure ICANN do not use the domain names to know if 
someone is an @large, very easy. Document them that by the time they 
eventually decide most of the Registrars will sell New.net, NameSlinger, 
XTNS, PacificRoot, ORSC, CINICs, Boroon registrations....

Jefsey

PS. Your analysis of the DNS is nice, but the naming plans existed before. 
What you describe is more BIND and a gateway access.


On 10:20 29/10/01, Alan Levin said:

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