draft-postel-iana-itld-admin-01.txt J. Postel ISI June 1996 New Registries and the Delegation of International Top Level Domains draft-postel-iana-itld-admin-01.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a working draft or work in progress. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract This document describes a proposed policy, procedure, and control structure for the allocation of additional top-level domains. Further it discusses the issues surrounding additional international top level domains (iTLDs) and registries, qualification proposals for operating such a registry, and justifications for the positions expressed in this paper. This document describes policies and procedures to o allow open competition in domain name registration in the iTLDs, o and provide the IANA with a legal and financial umbrella Note that while cooperation between competing iTLD registries is allowed, it is not required. This is specifically not assumed in this proposal, and is considered to be an operational aspect of a registry best determined, and coordinated, by contractual agreements between private interests. Postel Expires 12-Dec-96 [Page 1] ...-itld-admin-01.txt New Registries and iTLDs June 1996 The NEWDOM, IETF, and related mailing lists are encouraged to read, and comment, on this material. Presuming a consensus can be found within these audiences, the distribution of this memorandum should be expanded to include general commentary from the Internet community. 1. Introduction For the purpose of delegation, the top level domains (TLDs) fall into the categories listed below. While all are described to provide context, only the last is the subject of this document. 1.1. National TLDs The two-character namespace is, and will remain, reserved for ISO country codes under existing accepted Internet RFCs. National TLDs such as AF, FR, US, ... ZW are named in accordance with ISO 3166, and have, in the major part, been delegated to national naming registries. Any further delegation of these TLDs is undertaken by the Internet Assigned Number Authority (IANA), in accordance with the policies described in RFC 1591. It is good practice for these delegated TLD registries to publicly document the applicable management policies and further delegation procedures for these national domains, as, for example, RFC 1480 does for the US domain. 1.2. US Governmental TLDs 1.2.1. Delegation of the GOV TLD is described by RFC 1816, and is under the authority of the US Federal Networking Council (FNC). 1.2.2. Delegation of the MIL domain is under the authority of the DDN NIC. See RFC 1956. 1.3. Infrastructure TLDs TLDs such as IN-ADDR.ARPA and INT are under the authority of the IANA and may be delegated to others, e.g., IN-ADDR.ARPA is currently delegated to the Internic for day-to-day management. They are created for technical needs internal to the operation of the internet at the discretion of the IANA in consultation with the IETF. See RFC 1591 for general guidance on the use of the INT and ARPA domains. Postel Expires 12-Dec-96 [Page 2] ...-itld-admin-01.txt New Registries and iTLDs June 1996 1.4 The EDU TLD Delegation of the EDU domain is under the authority of the FNC and is currently delegated to the NSF which has contracted to the Internic for registration. See RFC 1591 for general guidance on the use of the EDU domain. Over time, the FNC and NSF may decide to use other delegation models, such as those described below for non-governmental TLDs. 1.5 The International Top Level Domains (iTLDs) COM, ORG, and NET COM, ORG, and NET are the current generic international top level domains (iTLDs) which are open to general registration. They are currently delegated to the Internic by the authority of the IANA. See RFC 1591 for general guidance on the use of the COM, NET, and ORG domains. The INT top level domain is also used for a very restricted class of international organizations established by treaties between the governments of countries. See RFC 1591 for general guidance on the use of the INT domains. 1.5.1. The intent for these iTLDs is discussed in RFC 1591. Generally, COM is for commercial organizations (e.g., companies and corporations), NET is for the internal infrastructure of service providers, and ORG is for miscellaneous organizations (e.g., non-profit corporations, and clubs). 1.5.2. There is a perceived need to open the market in commercial iTLDs to allow competition, differentiation, and change, and yet maintain some control to manage the Domain Name System operation. The current situation with regards to these domain spaces, and the inherent perceived value of being registered under a single top level domain (.COM) is undesirable and should be changed. Open, free-market competition has proven itself in other areas of the provisioning of related services (ISPs, NSPs, telephone companies) and appears applicable to this situation. It is considered undesirable to have enormous numbers (100,000+) of top-level domains for administrative reasons and the unreasonable burden such would place on organizations such as the IANA. It is not, however, undesirable to have diversity in the top- Postel Expires 12-Dec-96 [Page 3] ...-itld-admin-01.txt New Registries and iTLDs June 1996 level domain space, and in fact, positive market forces dictate that this diversity, obtained through free competition, is the best means available to insure quality service to end-users and customers. 1.5.3. As the net becomes larger and more commercial, the IANA needs a formal body to accept responsibility for the legal issues which arise surrounding DNS policy and its implementation. 1.6. This memo deals with introducing new registries for iTLDs and additional iTLDs names, it does not deal with the longer term issue of the management and charter of the current iTLDs (COM, NET, and ORG), or the specialized TLDs (EDU, GOV, MIL, INT, and ARPA). The current iTLDs may come under the provisions of this document when their current sponsorship relationship ends. The specialized iTLDs have such restrictive requirements for registration that they do not play a significant role in the competitive business environment. 1.7. Trademarks Domain names are intended to be an addressing mechanism and are not intended to reflect trademarks, copyrights or any other intellectual property rights. Except for brief mentions in sections 6.1, 6.4, and 9.3, trademarks are not further discussed in this document. 1.8. Observations There seem to be three areas of disagreement about the proposal to increase the number of top level domains: (1) trademark issues, (2) competition, and (3) directory service. 1.8.1. Trademark Issues The statement is made that "increasing the number of top level domains does not solve the trademark problem". This may be because "the trademark problem" has no solution. The Domain Name System was created to simply name computers attached to the Internet. There was no intention that domain names identify products or services in any way, or that domain names have any relationship to trademarks. Postel Expires 12-Dec-96 [Page 4] ...-itld-admin-01.txt New Registries and iTLDs June 1996 Two points must be kept in mind: (a) domain names are and must be unique, and (b) trademarked names are not necessarily unique (and the are many examples of non-unique trademarks). There are no international trademarks. There is no official international registry of world wide trademarks. Trademarks may be registered per country (and in the United States (at least) per State). The World Intellectual Property Organization offers an international arbitration service on such matters. There are "strong" trademarks that are registered in many countries and are vigorously defended. These may come close to being unique. There are many "not so strong" trademarks that may be regional or business sector specific (for example, United Air Lines and United Van Lines, or the Acme Brick Company and the Acme Electric Corporation)). There are two conflicting goals of different trademark holders with respect to domain names: (a) to protect their trademarks against infringement, and (2) to have access to the domain name system to use their trademarks in a domain name. Trademark infringement is the use of a trademarked name in a way that may confuse the consumer about the source or quality of a product or service. For strong trademarks there may also be infringement if the use of a trademarked name dilutes the value of the trademark. Holders of strong trademarks want to control every use of their trademark. These people would say it is pointless to create additional top level domains since they will acquire, reserve, and otherwise protect their trademarked name in every top-level domain so no new users will get access to domain names this way, and besides you are just making more work for the lawyers. While these holders of strong trademarks might not actually acquire their names in all the possible top-level domains (no extra income to the registries), they probably would take steps to stop any infringement thus making those name unavailable to anyone else (extra income to the lawyers). Holders of not so strong trademarks want the ability to use their trademarked name in a domain name while some other holder of the same mark for a different purpose also can use their trademarked name in a domain name. These people would say it is essential to create additional top-level domains to permit fair access to domain names by holders of not so strong trademarks. Postel Expires 12-Dec-96 [Page 5] ...-itld-admin-01.txt New Registries and iTLDs June 1996 I would suggest that the number of not so strong trademarks far exceeds the number of strong trademarks and that the domain name system should provide for the needs of the many rather than protecting the privileges of the few. Thus new top-level domains should be created. 1.8.2. Competition Another concern with the current situation in the Domain Name System is that there is one registry for the top-level domain names and it is charging fees apparently unconstrained by effective regulation or competition; it is in a monopoly position. Given this, it is reasonable to introduce competition in the form of other registries to provide equivalent services. There is a question, though, about how equal the service must be to provide effective competition. Does the establishment of new registries provide effective competition with the existing registry and the most popular top-level domain (that is, the COM domain)? Will people be willing to change their domain name to get better service or lower price? A name acquires substantial value as it is used and it becomes a significant undertaking to change a name. It is unlikely that many companies registered in one domain (for example COM) will change to another (new) domain. Can other top-level domains be successful? It seems that it is most likely that for new top-level domains to be successful they will have to attract users new to the Internet. This may require marketing efforts and promotion (that is, exactly the competition that is currently missing). This can have a significant impact very quickly. Given that the number of users of the Internet is doubling every year, in three years the current population of Internet users - and domain names - will be a small minority of only one-eighth of the population. Is there a practical way to share a single domain name between competing registries? There are technical solutions to this problem. But are there are manageable administrative arrangements for this situation. I am not convinced there are. Even if a manageable administrative arrangement for competing registries to operate in the same top-level domain can be found, these arrangements can be introduced in multiple top- level domains in the future. Postel Expires 12-Dec-96 [Page 6] ...-itld-admin-01.txt New Registries and iTLDs June 1996 While new single registry top-level domains may allow only a limited form of competition, it is a better situation than we have now, and it can be generalized in the future. Thus there is no "competition" argument to prevent creating new top-level domains. 1.8.3. Directory Service Is the Domain Name System a directory service? Is it reasonable to expect that if one thinks of a company name that the string "www.company-name.com" will be the locator for that company's web page? Even though it works some of the time now, it is less likely to work in the future even if all company names are registered in the COM domain due to more frequent clashes in names and the requirement of uniqueness. The creation of additional top-level domain names allows companies to have more natural names in one of the various top-level domains. This will make it harder to guess the actually domain name for a company, but probably no harder that it will become if all companies must find unique names in the COM domain. This directory problem is not really a Domain Name System problem. The Domain Name System provides a name to address look up service. It assumes that one starts with the exactly correct name and allows the look up of information associated with that name. The Domain Name System does not (and never was) intended to provide a general search facility. It is much more appropriate to use application level search tools like the various web search systems, or directory services like the X.500 directory service to find the exact Domain Name System based on a fuzzier description of the company identity. The nub of this issue is the question "Should domain names be guessable?" My answer is that it is not possible in general to have guessable domain names, so we shouldn't try too hard. Thus there is no "directory service" argument to prevent creating new top-level domains. 1.8.4. Side Remarks 1.8.4.1. Case Law on Trademarks and Domain Names Trademark holders must assume that domain names are related to trademarks. One of the requirements to keep a trademark is that it be defended. If a trademark holder becomes aware Postel Expires 12-Dec-96 [Page 7] ...-itld-admin-01.txt New Registries and iTLDs June 1996 of something that might be an infringement of the trademark, it would be folly not to pursue the issue, lest it turn out to be important, and they loose their trademark because of lack of action. That they take this action doesn't mean that it is required, just that there is some doubt. Until one of these cases actually makes it to a high-level court, no one is going to know for sure. The courts will either decide that domain names don't infringe trademarks, simply because of their existence (unless possibly someone has a trademark on a full name like "isi.edu" or "cisco.com") at which stage the trademark holders will know that they don't have to go chasing every domain that happens to use their magic word somewhere in it, or they made decide that the use of "foo.com" is actually a violation of someone's trademark on "foo", in which case people may make trademark searches before registering domain names. Even if the use of a trademarked word in a domain name is ruled to not inherently infringe the trademark it is still possible use the domain name in a way that would be an infringement of the trademark. It is also possible that creating new top-level domains will strengthen the interpretation that the Domain Names System simply names computers and is not related to trademarks by making it clear that in a domain name like "foo.com" or "foo.bus" the "foo" part cannot be extracted and be left with any meaning at all, it means something only with the complete suffix appended as an indivisible string. Treating the Domain Name System as a directory service may also strengthen the arguments that domain names identify products and services and thus are subject to trademark considerations. In two real cases in the United States courts have found that use of the equivalent of the "foo" in "foo.com" is a violation of trademark. For practical purposes the law is now established - the use of someone else's trademark in a domain name in and of itself can be an infringement of trademark. 1.8.4.2. Proposal to Eliminate International Top-Level Domains There is a viewpoint that the problems generated by the Unites States legal system should be confined there (and the Postel Expires 12-Dec-96 [Page 8] ...-itld-admin-01.txt New Registries and iTLDs June 1996 same for every country in the world). This argues to eliminate the the international top-level domains (COM, NET, and ORG) altogether and proposes to sweep the current users of those domains into the country code domains. One logical consequence of this view is that corporations in the Unites States should be registered in COM.US. This argument suggests that the trademarked words versus domain names issue is a United States only phenomenon. While this might be possible, i think it is short sighted. When the number of companies registering domain names in other countries reaches a large number or a substantial percentage of the number of companies in that country, i think they will find they have substantially the same problems as currently occur with the COM domain. This proposal would not fix the trademark, competition, or directory issues, but it would repatriate them. There is presumably no existing law, but it might be relatively easy to establish that acme-cleaners.co.uk and acme- cleaners.com.us were distinct and non-confusing to consumers. So there may be actually some improvement with respect to not so strong trademarks. While this is an interesting suggestion, it is completely unrealistic. The concept of moving - renaming - all the over 200,000 companies now registered in the COM domain is simply a non-starter. So, the argument goes, just close the COM (and NET and ORG) domain to new registrations and tell all those making registration requests "were sorry, COM was a mistake, you now have to register under your country code". After all, by the growth argument, in a couple of years the number of companies in COM will be a small percentage of the total population. I don't think this will work. There would certainly be a lot of complaints (and probably legal actions) suggesting that some unfair practices were being followed and that the new requesters were being arbitrarily disadvantaged. I think it would be hard to argue that over 200,000 registrations following a procedure in place over 5 years was a small mistake. By the way, i've explored the possibility that there might be technical reasons to limit the size of a domain. For example, not enough disk space, or too big to transfer for Postel Expires 12-Dec-96 [Page 9] ...-itld-admin-01.txt New Registries and iTLDs June 1996 backup, or whatever. The technical experts say not to worry, there are solutions for all those possible problems. A key point in this little story is the statement "This would not fix the trademark, competition, or directory issues, but it would repatriate them.", which is an admission that no problem is solved by this proposal, rather the problem is moved to some other sphere of responsibility. As a practical matter, the suggestion is to close COM and open COM.US. The result would be a lot of pain for registration authorities and staff as well as the companies denied registration in the COM domain, and not much else. All the existing conflicts would emerge at once. Much pain, no gain. A side point to this proposal is that it reinforces nationalistic tendencies rather than supports the shared world spanning community feeling. 2. Goals To facilitate administration of the domain name subsystem within the Internet by ensuring that there is an open and competitive marketplace for clients to obtain and subsequently maintain delegation of subdomains within the iTLDs, while preserving the operational integrity of the Internet DNS itself. The specific measures to achieve this objective are as follows: 2.1. Provide the IANA with the international legal and financial umbrella of the Internet Society (ISOC), 2.2. Allow open competition in domain name registration in the iTLDs, which will then allow registries to charge for their services, 2.3. Allow multiple registries to operate cooperatively and fairly in the existing iTLDs and/or other multi-registry iTLDs which may be created, 2.4. Facilitate creation of new iTLDs in a fair and useful, but reliable, fashion, 2.5. Provide for reliable maintenance of the registrants of an iTLD should the current delegatee no longer wish to maintain it, and Postel Expires 12-Dec-96 [Page 10] ...-itld-admin-01.txt New Registries and iTLDs June 1996 2.6. Define iTLD policies and procedures by open methods, modeled on the IETF process and/or using IETF mechanisms when appropriate. 3.0 Scope of this Document This document describes the administrative structure for the operation of the iTLDs. While other administrative issues may exist within the broader domain of the DNS, they are not addressed in this document. Specifically: 3.1. Only those relationships between the IANA, IETF, and ISOC which are specifically necessary for responsible maintenance of the iTLDs are described. 3.2. The Board of Trustees acts for the ISOC, the IAB for the IETF, and the IANA for itself. 3.3. Long range maintenance of the IANA is not described; although it is believed that the IANA should draw financial support from a wide community. 3.4. The IETF is not directly involved in operation of the net. Hence it serves the iTLD administrative work mainly in a technical capacity, such as the formalization of new protocols and the handling of technical appeals. 3.5. The ISOC does not directly operate the net. But it takes legal responsibility for standards processes and some network management processes, manages funds, and participates in the appeals process. 3.6. The IANA and any necessary ad hoc groups deal with operational details. 3.7. The ISOC, the IETF, and the IANA are not to be legally or financially responsible for the registries. The registries must be responsible for themselves. 3.8. Creation of a large staff is not desired. Postel Expires 12-Dec-96 [Page 11] ...-itld-admin-01.txt New Registries and iTLDs June 1996 4. Technical Assumptions Further growth within the iTLDs can be accommodated technically, and tools are in evidence to automate much of the process of registration and maintenance of entries within the DNS as well as multiple administrative access to a single delegated domain. 4.1. The size of current TLD databases such as COM, while large, is not really a burden on servers, nor is it expected to become so in the near future. 4.2. Procedures which allow mutual exclusion for the creation of names within a single TLD are being developed within the IETF's "dnsind" and "dnssec" working groups, and a test implementation is available. 4.3. Tools are being developed to ease the processes of registration and running the information servers which are expected of registries. 5. The Process 5.1. The IANA continues to supervise and control all operational aspects of the iTLDs, and is the second level of the appeals process after the registries (which are the first level). It appoints three members to the ad hoc iTLD group. The IANA may directly review appeals and/or it may ask the Internet DNS Names Review Board (IDNB) to participate in the review of an appeal. The IANA has the option of asking the IDNB to review an appeal, or the IANA may handle the appeal itself. As described in RFC 1591 regarding a dispute between parties contending for the management of a national TLD, the IDNB, a committee established by the IANA, will act as a review panel for cases in which the parties can not reach agreement among themselves. Now the role of the IDNB is expanded to include appeals on a technical basis of the process documented in this memo. 5.2. The IETF, as part of its normal procedures, publishes documents which describe technical and operational aspects of the domain space including the iTLDs. It also provides an appeals procedure for process issues and appoints two members to the ad hoc iTLD group(s). That is, it reviews appeals that question whether the process was properly followed. Postel Expires 12-Dec-96 [Page 12] ...-itld-admin-01.txt New Registries and iTLDs June 1996 5.3. The ISOC provides the legal and financial umbrella, and the final level of the appeal process. It provides an appeals procedure for procedural issues and appoints two members to the ad hoc iTLD group(s). The ISOC assumes legal liability for the process and the iTLDs. The ISOC reviews appeals that question the fairness of the process itself (not the application of the process to a particular case). 5.4. The ad hoc working group, for developing procedures and deciding creation of new iTLDs and chartering of registries, consist of seven members appointed by the IANA (3), the IETF (2), and the ISOC (2). 5.5. Note that 'ad hoc' means 'for this purpose only.' In this case, a new ad hoc group is created and convened on a periodic basis (probably annual) when needed to change procedures or to review registry and iTLD applications. 5.6. It is estimated that approximately thirty (30) new iTLDs allocated to approximately ten (10) new registries will be created per year. It is expected that this will continue for the next five years - unless something significant happens to change this plan. In this first year of this plan significantly more new iTLDs and registries may be chartered, perhaps up to one-hundred-fifty (150) iTLDs allocated to up to fifty (50) registries. 5.7. The policies and procedures to be used by the ad hoc working group will be decided by the first ad hoc group in an open process and will be clearly documented. This group will be appointed and convene in in the next few months. It is expected that these policies and procedures will mature over time. 5.8. Multiple registries for the COM TLD database, and multiple registries for other (new and old) iTLDs may be created in the future. 5.9. New iTLDs and registries will be created over time. This is a direct change to RFC 1591. New iTLDs may be created with a non- exclusive administration arrangement (multiple registries for one iTLD). 5.10. The intent is similar to the licensing of radio stations in some countries. Postel Expires 12-Dec-96 [Page 13] ...-itld-admin-01.txt New Registries and iTLDs June 1996 5.11. Registries pay for charters, and the fees collected are kept in a fund managed by the ISOC and used for the iTLD process (such as for insurance against an iTLD registry withdrawal or collapse), and possibly to support an evolved future funding model for the IANA. 6. Selection of iTLDs and Registries 6.1. The New Registries and iTLDs There will be up to one-hundred-fifty (150) new iTLDs allocated to as many as fifty (50) new registries, with no more than two thirds (2/3) in the same country, created in 1996, and chartered to operate for up to five years. In the case that all the applications are from one country (for example, United States) then only thirty-three (33) new registries and only ninety-nine (99) new iTLDs would be established Up to three iTLDs may be operated by any single organization. Each new registry will choose up to 3 new iTLD names it will manage under its charter. There will be no institution of multiple registries per iTLD in 1996 by the ad hoc committee. Registry operators are encouraged to make such arrangements on their own initiative. Summary: A new registry gets up to three new iTLDs for exclusive management for a period of up to five years; if the registry chooses it may establish a joint management of one or more of its iTLDs with other registries. All registries will be reviewed after five years, it is very likely that registries that provide good services will be rechartered. 6.1.1. The new iTLD Name Space It is desirable to maintain a "short" suffix on these iTLDs to permit easier use by the public. As such, the presumption will be that only three-character alphanumeric iTLDs will be assigned. The space of new iTLD names will be restricted to alpha numeric strings of exactly 3 characters. iTLD names are case independent (i.e., COM = com = cOm). Postel Expires 12-Dec-96 [Page 14] ...-itld-admin-01.txt New Registries and iTLDs June 1996 ::= ::= | ::= A | B | C | ... | Z ::= 0 | 1 | 2 | ... | 9 These names must be generic, i.e., not well known company identifiers or trademarks. iTLDs which are previously registered trademarks are specifically excluded from consideration as appropriate assignments. A possible exception might be for a generic term that is trademarked substantially world wide and is not associated with a particular product or service or purpose other than domain name registration. This condition may be impossible to enforce, since on a world wide basis in may be very difficult to determine if a particular string of letters is a trademark in any country or is the identification of a well known company in any country. In any case the neither the IANA nor the ad hoc committee plan to spend any time or energy on research in this area. The applicants to operate registries and manage iTLDs are on their honor not to select iTLD names knowingly in violation of this condition. 6.2. Who May Apply Persons or organizations wishing to operate registries and manage iTLDS shall send applications to the IANA in accordance with the provisions of this memo. A "person or organization" may be a single person or organization or any group of persons and organizations which may combine to offer registration services under one name as a cooperative or competitive provider of services, provided that all partners in the confederation or alliance shall otherwise be in compliance with the terms of this document. Organizations granted iTLD names may add or remove additional cooperating registration partners at their discretion, provided that doing so does not violate the provisions of this memorandum. Postel Expires 12-Dec-96 [Page 15] ...-itld-admin-01.txt New Registries and iTLDs June 1996 6.3. Open Process The applications for iTLD domain names and registries shall be evaluated in a neutral, impartial, and open manner. The proceedings and evaluations of the applications submitted shall be available for public inspection via an on-line procedure (e.g., web site) along with the decisions made. Financial and business aspects of proposals are kept confidential during the evaluation process. The complete proposal of the successful applicants, including these aspects, will be made public at the completion of the ad hoc committee process. 6.3. Review Criteria All applications are judged on three criteria: Registration Services, Operational Resources, and Business Aspects. Business aspects are not necessarily the most important criteria, reliability, quality of service, sustainability, are also important aspects. When a registry which has provided good quality and reliable service comes up for charter renewal, barring unusual circumstances, the charter renewal application should be approved. 6.3.1. Registration Services Each registry provide the following administrative services and policies for each iTLD they administer: 1) Access to the Registration Database The DNS database files and "whois" databases maintained by any iTLD operator are deemed to be publicly available and public, non-protected, information. The intent is to allow easy access to the information needed to investigate and correct operational problems. A registry shall provide guaranteed availability of the registration data in a useful form should transfer of responsibility become necessary, e.g., regular publication of the information, or regular deposits of copies of the information with a reputable "escrow holder" instructed to release the information to the IANA. The IANA is authorized to designate an organizations as the Postel Expires 12-Dec-96 [Page 16] ...-itld-admin-01.txt New Registries and iTLDs June 1996 escrow holder of said database information for the purposes described below under "Termination of Registries". The escrow holder will have to keep very up to date copies of the database probably through some automated system that makes a copy on a daily basis. There may be reasons (other than "transfer of responsibility" or "termination of registries") to provide controlled access to the data held by the escrow holder for special purposes, such as legal proceedings in trademark cases. The registry must provide a means, via the "whois" protocol, to search the database of second-level domains maintained by this registry and return common directory information. This information shall include, but not necessarily be limited to: a) The "owner" of the second-level domain, including contact name(s), physical address(es), and telephone number(s) of the persons responsible for the operation of the second- level domain. b) The nameserver hostnames and IP addresses serving that second-level domain. c) The current status (operational, on hold, pending, etc) of that second-level domain. There is no intent to have a "global phonebook" of second-level domain holders. The intent is to provide information necessary for tracking down and resolving operational problems. iTLD registries are expected to provide their own directory service, and "rWhois" is designated as one of the operational choices which a registry may wish to utilize. However, no attempt is made to mandate any particular technical or organizational requirements from a registry to service requests for lookups of a domain holder in other, competing registries and iTLDs. Internal database and operational issues are to be decided by the registry. These issues, including pricing to customers of the registry, are properly free-market issues and are excluded from the control of the IETF, IANA, ISOC and other related organizations. 2) A help desk and staff to answer questions via electronic mail, fax and normal telephone during customary business hours. Postel Expires 12-Dec-96 [Page 17] ...-itld-admin-01.txt New Registries and iTLDs June 1996 3) Published policies on services offered, registration procedures, and fees. 4) A clear description of the appeals mechanism within the registry, including the entry point for appeals and the expected response time. 5) All of the public information identified in points 1 through 4 above shall be made available via WWW, FTP, and automated email responder at an address associated with the organization. 6.3.2. Operational Resources 1) Internet Connectivity A description of the Internet connectivity to the site where each nameserver for each iTLD will be located. For example, a diagram showing full multi-homed connectivity to the organization's computers which will serve as the iTLD nameservers, with each leg of that connectivity being at a non-aggregated data rate of <*** whatever ***>. And route advertisement via BGP4 for this organization's connectivity must be operational for the connections maintained under this provision, and the network involved should be operating in a "defaultless" configuration. 2) Nameserver Performance The description of at least two (2) nameservers for the iTLDs in question. These nameservers shall run the latest "consumable" release of the BIND code (4.9.x at present), and may include local enhancements, changes, or operational improvements. The names and IP addresses of the hosts which are proposed to serve the iTLDs. 6.3.3. Business Aspects A description of the applicant which shows sufficient business viability that the registry is likely to operate successfully for at least five years (this is not a business plan, rather some documentation that lends credibility to the applicant's proposal). An initiation fee of USD 10000 payable to the "Internet Postel Expires 12-Dec-96 [Page 18] ...-itld-admin-01.txt New Registries and iTLDs June 1996 Society" to be deposited in the "iTLD fund"; and each registry established under this plan will contribute one percent (1%) of its gross income from fees, dues, or other charges to its customers to the "Internet Society" to be deposited in the "iTLD fund", to be paid on a quarterly basis. 6.4. The Application All of the information required to be supplied with an application should be prepared for transmission via email in plain ASCII text, in English. The details of the submission of applications will be determined by the ad hoc committee. The application shall include the following: 6.4.1. Applicant Name The name of the applicant, including the contact information. 6.4.2. iTLD Names The three three-character iTLDs proposed, along with an statement indemnifying the IANA and the ISOC for any infringement of trademark which may be created by the IANA authorizing this assignment. 6.4.3. The Criteria Statements The applicant's approach to the three criteria of section 6.3, Registration Services, Operational Resources, and Business Aspects. These statements should include: A clear statement of the charter, policies, and procedures, a statement of registrant qualification procedures, a statement that they will be non-discriminatory in the sense of treating all applicants equally (if a registry chooses to operate the iTLD "CHM" for companies in the chemical business it may decline to register companies not in that business) a description demonstrating the organizational and technical competence to run a registry and the expected accompanying information services, a statement that the registry will Postel Expires 12-Dec-96 [Page 19] ...-itld-admin-01.txt New Registries and iTLDs June 1996 (1) abide by the results of the appeals process (as described in this memo) and the direction of the IANA, and (2) hold harmless ISOC, IANA, IETF, the ad hoc committee, and (3) obtain the usual prudent insurance. 6.4.4. The Application Fee A non-refundable application fee of USD 1000 payable to the "Internet Society" to be deposited in the "iTLD fund". 6.5. Charters are for a period of five years, but annual progress reports are submitted for review by IANA and the ad hoc group. Only in exceptional cases of radical change or abuse of a charter may the IANA or the ad hoc group recommend to the IANA and ISOC that the charter be reevaluated before the charter period is reached (see appeals process, and termination of registries sections). 6.9. Sorting Out the iTLD Requests It is fairly likely that severral applicants will request the same iTLDs. Suppose that two or more of the registry applicants that have been otherwise approved by the ad hoc committee have requested the same name as one of their new iTLDs. The ad hoc committee will have to use an unbiased and fair method to select which applying registry is to manage that iTLD. This could result is some approved registries having fewer than three iTLDs to manage. After all the original iTLD requests of the approved registries have been resolved any registries with fewer than three iTLDs to manage will be asked to propose additional iTLD names until three non- conflicting names have been selected. 6.10. Contract The actual agreement to establish a new registry will take the form of a contract between the registry organization and the Internet Society (ISOC). Postel Expires 12-Dec-96 [Page 20] ...-itld-admin-01.txt New Registries and iTLDs June 1996 6.11. Schedule There are several stages that each take some time: forming the ad hoc committee, finalizing the procedure, accepting the applications, and evaluating the applications. 6.9.1. Assume the ad hoc committee is be formed day 1. 6.9.2. The ad hoc committee will finalize and announce its procedures by day 30. 6.9.3. The ad hoc committee will accept applications until day 90. 6.9.4. The ad hoc committee will review the applications and announce its selections by day 135. For example suppose the ad hoc committee was formed on 1-May-96. Then the schedule would be: 01-Jul-96 ad hoc committee formed 01-Aug-96 procedures finalized, begin accepting applications 01-Oct-96 stop accepting applications, begin evaluation 15-Nov-96 announce selections 7. Termination of Registries iTLD registries may decide they no longer wish to operate their registry. Likely, the operation will not be profitable when this occurs, yet the registrants under the iTLD may need to be supported for a considerable time. Some portion of the fees in the ISOC-managed iTLD fund may be used to pay for some other organization to operate the failing iTLD or registry until it again becomes viable or until the registrants have safely migrated elsewhere. While it is unclear how expensive providing even temporary service for the iTLDs of a failed registry might be, the iTLD process must be prepared for the case where a very popular, possibly because it is low cost, iTLD or registry fails. Some views on the possible scenarios: Postel Expires 12-Dec-96 [Page 21] ...-itld-admin-01.txt New Registries and iTLDs June 1996 It will be very expensive. Bailing out the registrants of a failing domain could be very expensive, even on the order of a million USD (remember, a likely failure mode may be because someone thought they could do it for less). It is not a big deal. It is presumed that any registry with a significant client base will constitute a legitimate on-going business interest with revenue prospects sufficient to insure that the registry will in fact be transferred to another organization. As an example, presuming 5,000 registrants of a given registry and a fee of 50 USD per year, a revenue stream of 250000 USD per year would inure to the benefit of any organization taking over the services of a defunct organization. Should a registry close without having significant second-level registrations in place at that time, the impact to the Internet users as a whole will be minimal or non-existent. Succession issues related to the relationships between customers of a registry and that registry itself are properly contractual matters between the registry and its customers, and when properly attended to do not involve the IETF, ISOC, or the IANA. The IANA or its designee may operate an "escrow holder" to insure that the records contained in a registry will remain available in the event of intentional or accidental destruction due to a registry forfeiting a iTLD. Organizations providing registry services may elect to terminate their involvement in this program and release the iTLD namespace delegated to their organization under the following circumstances: 7.1. Any organization may transfer the authority for, and registration services provided, for a iTLD to any other organization provided that the new registration authority complies with all provisions of this memorandum. The business and financial terms under which this transfer is conducted shall be properly between the old and new registry organizations and not under the jurisdiction of the IANA, the IETF or the ISOC. However, the IANA must be notified of such a transfer, and the charter of the registry for the management of these iTLDs shall be reviewed as a renewal of the charter at the next normal session of the ad hoc committee. Postel Expires 12-Dec-96 [Page 22] ...-itld-admin-01.txt New Registries and iTLDs June 1996 7.2. iTLDs which are "orphaned" by a registry that constructively abandons them or ceases business operations without first securing a successor organization to assume the authority and registration services for that namespace shall be deemed "abandoned". Abandoned iTLD namespace shall be auctioned to the highest bidder by an open, competitive bid process adjudicated by the IANA or its designees, which shall be conducted without undue delay. During the interim period in question the IANA shall be authorized to designate one or more firm(s) to hold the existing registration records to prevent the interruption of service. 7.3. An organization that is found by the IANA to be in violation of the terms of this delegation memorandum shall be given notice by the IANA of intent to recover the iTLD domain space allocated under this policy via normal postal mail. Within 30 days, the organization against which the complaint has been lodged shall a) cure the violation(s) of this policy, (b) transfer authority to another organization under 7.1 above, or (c) constructively abandon for public auction the namespace under the provisions of 7.2 above. Where the facts are disputed regarding possible violations of this policy, the IANA is authorized to promulgate reasonable adjudication policies which should include an arbitration provision. 8. Finances It is desirable to keep the ISOC, IANA and IETF from becoming involved in operational and contractual aspects of the iTLD registries, and it is further desirable to separate, to the extent possible, the IETF and IANA funding from these organizations. It is presumed in the best interest of the IETF, the IANA, ant the ISOC to see that this separation of function is preserved. Note: Indemnification provisions from the registries to the IANA and related organizations may not serve to properly insulate the ISOC, IANA and IETF from legal proceedings, as it should be presumed that any organization which is legally challenged in a significant fashion may be unable to properly pay any judgments levied against it. Current "deep pockets" legal practice exposes related organizations to the negative effects of these legal actions should the original organization be unable to fulfill its financial obligations. There is a concern that the presence of a funding path creates a tying arrangement between for-profit organizations and a set Postel Expires 12-Dec-96 [Page 23] ...-itld-admin-01.txt New Registries and iTLDs June 1996 of non-profit organizations which up to now have not been legally, financially, or otherwise encumbered by the actions of these registries. 8.1. A registry may charge as it sees fit, within the bounds of the policy published when it is chartered. 8.2. The ISOC manages all finances in a separate iTLD fund with open reporting and published budgets. Agreement of the ISOC, the IANA, and the IETF is required on all budgets. 8.3. Charter fee income may be used to pay legal costs of the IANA, IETF, ISOC, and ad hoc groups when legal disputes arise from the iTLDs process. 8.4. Charter fee income is also used to pay modest and publicly visible costs of the chartering process, e.g., the costs of the ad hoc committee, the administrative staff, and costs incurred by the ISOC. 8.5. Charter fee income may also be used to fund the IANA if and when it becomes necessary. 8.6. Should the reserves be too large, a consensus of the IANA, IETF, and ISOC would allow disbursements for the general network good, e.g., scholarships for engineers from developing countries. 8.7. The ISOC may charge a modest amount for administering the iTLD account. 9. Appeals Arbitration to resolve conflicts is encouraged. That an appeals process is specified should not preclude use of arbitration. The appeals process described here is for when arbitration has failed or when the parties decide not to use arbitration, yet they do not wish to exercise recourse to lawyers and courts. 9.1. The appeals process does not apply to disputes over Intellectual Property Rights on names (trademark, service mark, copyright). These disputes are best left to arbitration or the courts. Registries may require appropriate waivers from registrants. 9.2. The appeals process does not apply to charging and billing. This is left to market forces, arbitration, and the courts. Postel Expires 12-Dec-96 [Page 24] ...-itld-admin-01.txt New Registries and iTLDs June 1996 9.3. The appeals process applies to all other aspect of registry processing of registration requests. 9.4. A registrant's first recourse is to the registry which has denied them registration or otherwise failed to provide the expected service. 9.5. All registries must specify in their applications an entry point and a process for appeals, as well as a response time, and must subsequently conform to them. 9.6. If appellant is dissatisfied with the registry response, appeal may be escalated to the IANA. The IANA hears appeals based only on technical issues. Note that the IANA may use the IDNB to process the appeal. 9.7. The IANA must define its entry point for appeals and must respond to appeals within four weeks. 9.8. If appellant is dissatisfied with the IANA response, and the appeal has nontrivial process aspects, the appeal may be escalated to the IETF. The IETF hears appeals based only on process issues, that is, claims that the procedure was not followed. 9.9. If appellant is dissatisfied with the IANA and, if invoked, the IETF response, appeal may be escalated to the ISOC. The ISOC appeals process hears appeals only about the fairness of the procedure. I.e. the decision of IANA and/or IETF is final, unless there is an appeal that the procedure itself is unfair. 9.10. The appeals process works by email. Appellant must provide concise history of the case and summarize grounds of appeal. The IANA, the IETF, or the ISOC may ask for information from third parties. All information is normally treated as nonconfidential and may be made publicly available. Confidential information is considered only in special circumstances. 9.11. The IANA, the IETF and the ISOC may establish appeals sub- committees chosen either from their own membership or outside of it by whatever means each deems reasonable for their procedures and purposes. 10. Security Considerations There are no known security considerations beyond those already extant in the DNS. Postel Expires 12-Dec-96 [Page 25] ...-itld-admin-01.txt New Registries and iTLDs June 1996 11. Acknowledgments This memo is a total rip off of a draft by Randy Bush, combined with substantial inclusion of material from a draft by Karl Denninger. The appeals section was originally written by Brian Carpenter. To this base i've made many changes small and large. So to the extent you like this it is probably their work, and to the extent you don't like it it is probably all my fault. A lot of significant and constructive input and review was received from the following: Alan Barrett Randy Bush Brian E. Carpenter Karl Denninger Robert Elz Geoff Huston John Klensin Lawrence Landweber Nick Trio 12. Author's Address Jon Postel IANA Phone: +1 310 822-1511 USC/Information Sciences Institute Fax: +1 310 823-6714 4676 Admiralty Way Marina del Rey, CA 90292 Email: Postel@ISI.EDU Postel Expires 12-Dec-96 [Page 26]