Internet IAHC J. Levine IAHC Document Draft I.E.C.C. 7 December 1996 A Structure for Shared International Top Level Domains Status of this Memo This memo is a draft document for the consideration of the IAHC. Distribution of this memo is unlimited. 1. Overview and Rationale Every Internet top-level domain has until this point had a single registry. In some cases, the single registrar has been satisfactory to the community using the domain, but in many other cases, the single registry has become a point of controversy. This memo describes a structure that permits multiple registries to handle one or more domains, avoiding the problems associated with single registries. 2. Motivation for Shared iTLDs Historically, new domains were registered into iTLDs on an informal volunteer basis. In 1993, the InterNIC became the registrar for the iTLDs usable by the public (COM, ORG, and NET) until 1998. In the past year or two, many people have expressed dissatisfaction with the way that registrations in these iTLDs have been handled. Significant concerns have included the prices charged, the level and reliability of service provided, and the manner in which conflicts over the use of a domain are addressed. These concerns have become more pronounced since there are few alternatives to the InterNIC for people who wish to register a domain, yet are dissatisfied with the InterNIC's service. Users inside the United States can use the .US domain, although the problem can recur should the service provided by the registrar for the registrant's city or county also provide unsatisfactory service. Registries for other countries have widely varying policies, many of which are perceived as being as onerous as those of the InterNIC if not more so. My observation is that although obtaining a domain name is a necessary prequisite to offering a service on the Internet, it is far from the only prerequisite, so the same providers who offer other Internet infrastructure services should be able to offer domain registration. All iTLDs, and ideally all TLDs, should be offered through multiple registries to provide the widest possible range of services at a low competively determined price. 3. Shared vs. unshared iTLDs At this point, there are three general-purpose iTLDs, COM, NET, and ORG, that accept registrations from the public, two private iTLDs, GOV and MIL, that accept registrations only from the U.S. government, and two specialized iTLDs, EDU and INT, that accept registrations only from specified types of organizations. There appears to be no demand for new private or specialized iTLDs. The GOV and MIL domains accept registrations only from the U.S., and EDU primarily from the U.S., so parallel domains for other countries would more apppropriately be created as second level domains within the country's ISO TLD, e.g., GOV.AQ or MIL.CR or EDU.NT. The INT zone is open only to international treaty organizations, of which there are only a few dozen and unlikely to be significantly more in the future. Hence if any new iTLDs are created, they will be general-purpose. But if a new general-purpose iTLDs had a monopoly registry, it would be subject to all of the problems already encountered with COM, ORG, and NET. The way to avoid such problems is to require that all new iTLDs be shared. Furthermore, the existing general-purpose iTLDs should become shared as soon as possible, probably in 1998 when the incumbent registrar's contract expires. 4. The 800/888 Model Toll free 800 and now 888 numbers have been offered in the U.S. for close to 30 years. Early on, particular 800 numbers had a geographic significance, but for several decades, any 800 number could ring literally anywhere in the world. In this way, they're similar to iTLD domains which can equally map to hosts anywhere in the world. In the 1980s, immediately after the Bell System breakup, specific 800 prefixes were assigned to individual long distance carriers. For example, 800-343 belonged to AT&T, 800-950 to MCI, and 800-877 to Sprint. If a customer wanted a particular 800 number for mnemonic or marketing reasons, he had to go to the carrier who controlled that number. Furthermore, if a customer using an 800 number became dissatisfied with the carrier, he could only switch carriers if he were willing to change to an 800 number, a very large hurdle if the number spelled something or was widely known to the his employees and customers. This situation is analogous to the situation with TLDs today -- the only way to change registries is to change your domain name. To improve competition in the 800 industry, the FCC mandated 800 portability, which made it possible for any 800 (and now 888) number to be handled by any carrier, and required that once a customer is using an 800 number, he can switch to any carrier he wants and take the number with him. Portability has had the effect of largely wiping out competition based on a carrier's position as the sole provider of particular 800 numbers, and has moved the competition to criteria of price and service. There is a low-profile company called DSMI that maintains the database, and all the long distance companies which submit updates to that database and actually provide the 800 service. DSMI's database contains little more for each 800 number than the name of the long distance company to route it to and maybe the name of the underlying customer, for verification when the customer switches LD companies. 5. Organizational Implementation of Shared iTLDs Maintaining a shared TLD is a pretty straightforward database problem if there's a central registry, and a fascinating research problem in distributed shared updates if there isn't. Although I certainly won't rule out the possibility of distributed databases for iTLDs in the future, I assume here that for every iTLD there is a single authoritative database containing the DNS and WHOIS information for the TLD. This database must be kept by a neutral party, subsequently referred to as a database company or DBCO. To ensure its neutrality, the DBCO should be jointly owned in equal shares by its registries, with a procedure that permits a new registry to buy a share in the DBCO from the existing registries if the new registry wants to do so, and to sell its share in the DBCO to the remaining registries should a registry leave. Such a database company may handle a single domain's information, or could handle multiple domains. The DBCO's policies, procedures, and prices will be determined by its owning registries. The DBCO can make whatever financial arrangements it wants with its registries, subject to a few overarching fairness rules: * All registries must be offered arrangements at least as favorable as those offered to any other registry using the DBCO. Terms may include combinations of a fixed periodic fee, recurring per-domain charges, or per-update charges. * The DBCO must treat registrations equitably, first-come first served except as described under Conflict Resolution, below. * The DBCO must meet any other rules applicable to all iTLDs, such as paying the proposed support fee for the IANA or root servers, if imposed. * Registries must have an actual customer for each domain registered, to avoid domain name hoarding and speculation by registries. It might be appropriate to permit a short grace period of a day or so, allowing a registry tentatively to register a domain for a new or potential customer before the paperwork is complete. (The 800/888 database has a similar rule.) Some registries may resell registration services to smaller organizations who cannot or choose not to meet the criteria for being a direct registry. This is analogous to the telephone industry situation, where smaller carriers and resellers use larger carriers and service bureaus to handle their database updates. 6. Technical Implementation of Shared iTLDs I do not propose that the IAHC mandate a specific technical implementation for shared TLDs. For operational purposes it would be convenient if the interface between the registries and DBCOs were standardized, to ease the likely situation where a single registry handles registrations for many TLDs and hence needs to deal with multiple DBCOs. The interface might work via e-mail, the World Wide Web, or a dedicated application using CORBA or other tools. Analogous to the 800/888 model, the DBCO need track only enough information for each domain to provide domain service and identify the registry for the domain (to validate updates) and the ultimate registrant (to validate registry changes.) Registered names are assigned to a customer, with a registry acting as agent for that customer. A customer may change registries without changing his domain name if he is not satisfied with the service that his current registry is providing, or if he believes that a different registry would be more desirable. To register a new domain, a registry sends the DBCO a request identifying the domain name, the registry, and the registrant. If the name isn't already in use, the name is assigned to the registry. Once the domain is registered, the registry can send updates as required, and can delete the domain if the registrant so requests or stops paying for it. The registry is expected to send only technically valid registrations and updates, e.g. no lame delegations nor non-existant servers. To change registries, a registrant applies to the new registry, who sends a registry-change request to the DBCO with the name of the domain and the identification of the registrant, which must match the existing identification. The technical means of identification used are beyond the scope of this proposal but might include a password, a PGP key, or an off-line identification such as a notarized letter. The technical means proposed for validating DNS updates in the DNSSEC working group may be useful here to identify customers. There is an existing mailing list for a working group on shared TLD implementation. Archives and subscription information may be found at: http://www.higgs.com/mail/lists/shared-tld/ Some people have suggested using the DNS itself as the shared database, using the recently proposed incremental update changes to the DNS protocols, making the DBCO unnecessary. I believe this is impractical for several reasons. The DNS doesn't store all the information needed for the DBCO, nor do any of the existing or proposed protocols maintain the logging information necessary to audit questionable transactions and resolve questions relating to domain hoarding, order of registration requests or other issues. Also, the proposed DNS update schemes provide no way to change the ownership of an existing DNS entry, an essential feature of a competitive registry environement. 7. Abandoned Domains If all of the registries for a TLD leave, the DBCO would have no support, and the domain would appear to be abandoned. This situation isn't very different from the one that would arise should the registry for a single-registry domain fail or leave the business. I specifically do not suggest that there be any procedure mandated by the IAHC for this situation. Any users of the domain would be inconvenienced, but if users believe that continuous domain service is important, they should choose a registry, and indirectly a DBCO, that offers assurances of continuous service such as strong financing, database escrow, and contingency plans for technical or financial problems. On the other hand, should customers want to use a registry that provides lousy service at rock-bottom prices and might vanish at any moment, there's no reason to prevent them from doing so. 8. Conflict Resolution All of the registries for a domain must agree to a common and consistent conflict resolution policy for situations where multiple registrants claim a single name. I suggest the following policy: * Registrations are accepted by the DBCO on a first-come-first-served basis. The DBCO's time stamp determines the order of receipt. * Should a challenger claim ownership of a domain registered by a different registrant, if the registrant and challenger are in a common jurisdiction, the DBCO's only response will be to tender the domain name to a competent court for that jurisdiction. Should the registrant and challenger not be in a common jurisdiction, the DBCO will tender the domain to a competent court for the DBCO's own jurisdiction. In either event, the DBCO will follow the decision of the court. The DBCO will specifically not rule on the relative merits of the registrant's and challenger's cases. It may be advantageous for DBCOs to incorporate themselves as Swiss international orgnizations or otherwise place themselves in as neutral a jurisdiction as possible. 9. Economic Implications of Shared iTLDs The shared TLD design places treats domain name registration more as an administrative service than as a free-standing business. Since no single registry would have a monoply on individual TLDs, in a competitive environment the price of registrations would tend to be driven down to a level that matches the costs. Registries will have little incentive to promote a particular domain, unless all of the registries for that domain agree to do so. Most likely, providers of connectivity, web hosting, and other Internet- related services will become registries for all the domains of interest to their customers so they can provide domain registration as necessary to support their customers. Author's Address John R. Levine I.E.C.C. 24 Washington Street Post Office Box 640 Trumansburg NY 14886-0640 Phone: +1 607 387 6869 Fax: +1 607 387 5244 EMail: johnl@iecc.com Levine [Page 7]