INTERNET-DRAFT Expires June 1997 INTERNET-DRAFT STLD Working Group K. Crispin Category: Informational November 1996 Creation and Operation of a Shared International Top-Level Domain Licensing Authority Status of this Memo This document is a submission to the Internet Ad Hoc Committee. 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: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This Internet-Draft describes the Shared Top-Level Domain Licensing Authority (sTLD-LA, or just LA). The LA is an administrative entity chartered by the ISOC and the IETF that grants Registry Licenses to individuals or organizations, maintains a "registry of registries", coordinates conflict resolution procedures, receives and processes all applications for new sTLDs and new sTLD registries, and makes zone information available to the root name-servers. As a chartered agent of the IETF and the ISOC, the LA operates on their behalf, and it is expected that the IETF and ISOC will maintain active committees dealing with LA issues. In particular, 1) some of the work of conflict resolution in the LA context falls upon committees from the IETF and the ISOC, and 2) sTLD name creation is mediated through Ad Hoc committees chosen from the IETF and ISOC membership. In the past the IANA has had responsibility for licensing domains, and in the future it may take the role of the sTLD-LA as well. However, the LA could just as well be a completely separate entity. Table of Contents Status of This Document.................................xx Abstract................................................xx Table of Contents.......................................xx 1. Introduction.........................................xx 2. Definitions..........................................xx 3. Background and Motivation............................xx 4. Nature of the LA's Authority.........................xx 5. Description of the Licensing Authority...............xx 6. Characteristics of the Registry License Agreement....xx 7. Dispute Resolution Procedure.........................xx 8. Transition Issues....................................xx Notes...................................................xx Author's Address........................................xx 1. Introduction The idea of "Shared Top Level Domains" has been active in various forums dealing with TLD issues for some time now. In general, there seems to be a lot of support for the idea, but also much hand wringing as to how it could be implemented. There is some concern about the technical problems of running sTLDs, but more concern has been expressed over perceived administrative difficulties. It is the author's belief that sTLD registries are more complex to oversee than monopoly TLDs only because there are many more of them. Also, implementing Shared TLDs requires solving many small problems, whereas implementing monopoly TLDs requires solving some small problems and a few extremely large problems. Thus, the effort to set up the administrative infrastructure for sTLDs is no greater than the effort to create the administrative infrastructure for monopoly TLDs, and may actually be less. Furthermore, the benefits of adopting an sTLD scheme are substantial, and the transition to a scheme where all iTLDs are shared is, contrary to what might be thought, a straightforward process. This draft defines the Shared TLD Licensing Authority as mainly an administrative function, and puts a large amount of decision making responsibility in committees of the IETF and the ISOC. Other models are of course possible. A technical model for maintaining a cohort of registries through the Domain Name System is described in a companion draft, draft-iahc-stldtech-crispin-00.txt. 2. Definitions Cohort registries: The set of registries that serve a single TLD are "Cohort registries" for that domain. It is both a singular and a collective noun: saying a registry is a cohort of other registries is equivalent to saying it is a member of that cohort. DNS service: A DNS service is an administrative/technical entity that provides DNS services for a domain. Note that it is not necessary that a registry also be a DNS service -- a single DNS service organization could support many registries, for example, and of course, a single registry could deal with many DNS services. Note too that competent and reliable DNS services are actually more important to the Internet than competent and reliable registries. Master DNS service: One of the registries, either directly or through subcontract, supports the master DNS server, which maintains the authoritative zone information for the TLD. Monopoly TLD: A TLD that is served by a single registry that has an exclusive license to serve that TLD. Registry: A registry is the administrative entity that mediates and administers the binding between domain names and IP addresses. In the case of a single TLD, we may speak of "a registry" for that domain, though of course that registry may serve other domains as well. Registry Customer Database: The Registry customer database contains all the standard information about registry customers -- the billing contact, administrative contact, technical contact, and so on. Each registry maintains data for its direct customers only. There is no central repository of contact information. Registry License: The registry license is a signed contract between the registry and the LA. It is the formal document that "grants" the registry the right to be a registry. Shared TLD (sTLD) : Registry Licenses for Shared TLDs allow for the existence of other registries for the same TLD. The license may mandate a certain level of cooperation between all the cohort registries for that TLD. [1] Shared Registry: A registry that serves a Shared TLD is a shared registry. SLD: A "Second Level Domain". Synchronization Database (SDB): A SDB provides the locking mechanism by which cohort registries update DNS coherently. Each TLD needs an SDB; one SDB could service many or all TLDs; the obvious SDB for a TLD is DNS itself, in the Master DNS server. However, any protocol identified as a standard for registry sharing in an RFC, or any protocol approved in the TLD charter, may be used. [Also called a "Coordination Database", or CDB.] TLD: Top Level Domain. 3. Background and Motivation In the IAHC mailing list two competing models of TLD registries have been proposed -- the "shared TLD" model and the "monopoly TLD" model. In either case some administrative body (eg, the IANA) "grants" the right to register subdomains of a TLD. In the past all such grants have been for "monopoly" TLDs, and the operational effect of such a grant was to have NS records placed in the root name-servers that linked the new domain name with the "grantee's" name-servers. The operators of the root servers installed these records because the IANA has been the accepted clearinghouse for coordinating them. As far as I know, there is no legal arrangement that requires any of the root operators to follow the dictates of the IANA. That is, the IANA has essentially served as the Root Registry, and it's authority ultimately stems from the good will of the operators of the root name-servers. However, the evolution of the net has led to a current situation where the primary registry for domain names is a commercial enterprise operating as a near total monopoly. This situation is undesirable in the short run and untenable in the long run, because as the net continues its exponential growth the power of that monopoly will grow with it. Shared TLDs are seen as a way to convert the registry business from a multi-million dollar profit center to a hoard of much smaller scale profit centers -- perhaps several tens of thousands of registries that are run as small businesses, or from educational institutions, or non-profit organizations, or small departments of larger corporations. It is emphatically desirable that a registry could be a profitable business. It is also emphatically desirable that competition be sufficient to prevent any single registry from becoming a cash cow gold mine. An infrastructure that allows potentially tens of thousands of registries to exist has technical, administrative legal, and organizational components. This draft will concentrate on the administrative, organizational, and legal components [the latter qualified by the fact that the author has only general legal knowledge]; the technical components are discussed in a companion draft. There are several potential advantages to having many, many sTLD registries, particularly this proposed implementation of them: 0) They can be set up purely within the context of the current IETF/ISOC environment, without the creation of any new government rules, or any new national or international legal framework. 1) Economic efficiency: Registration of domain names would become essentially a commodity service, where competition keeps prices only a few percent above the actual cost of providing the service. 2) Self policing: A side effect of intense competition is that registries will not tolerate "cheating" on the part of other registries. 3) Fault tolerance: Temporary unavailability of a registry would would not stop registration for a particular TLD; total failure of a single registry would only affect the customers of that registry, and transferring their SLD to another registry would be trivial. 4) Registry licenses would not be extremely high-value items that could motivate legal battles with stratospheric costs. 5) Similarly, legal liability would be distributed -- there is no large, single entity that is a potential target for legal action. In fact, since the registries would be distributed internationally, it would be singularly difficult to instigate an action against all the registries for a sTLD. 6) Having a large number of registries gives a constituency for developing and enforcing consensual standards among registries. That is, the thousands of registries would form a cooperating web of organizations, and they collectively will have a strong vested interest in standards for that cooperation. 7) The small average size of registries would be a strong encouragement for the development of customer policies that avoid legal conflicts. 8) Local service and diverse policies: Customers could find "local" registries for every domain -- the registry could conduct business according to local custom, speak the local language, and so on. Furthermore, it would be easy to start registries with special policies, services, or intended customer base. 9) The particular implementation of shared registries presented here provides an orderly and explicit method by which the standardization activities of the IETF can be reflected in the operation of the registries and the domain name service in a timely manner. 10) This is vague and subjective, but I think many people would agree that the notion of shared registries fits well with the general design philosophy of the Internet. 4. Nature of the LA's Authority The IETF is the de facto standards body for the Internet. However, there is no contractual relationship between the IETF and those who actually operate the network software and hardware -- they are under no legal compulsion to follow the IETF standards. Thus, the authority behind the IETF standards is the result of consensus, trust, and respect. Thus, the "IETF name" carries de facto authority. The Internet Society is also a respected organization of people associated with the internet, and it's approval has similar weight. This weight is the fundamental source of authority for the LA. It is chartered by both the IETF and the ISOC, directly overseen by committees in each organization, and indirectly overseen by the membership at large of these organizations. [2] While this authority is real, it has no legal basis, and furthermore, given the international nature of the Internet, any reasonable legal authority will take some time to develop. And, I would argue, an authority based in law is unnecessary, and perhaps even undesirable: there are many advantages to an organization that is founded on mutual trust, consensus, openness, and respect. Thus, any contract (or license) between a registry and the LA essentially follows this form: the registry agrees to meet certain requirements, in return for which the LA, as the official representative of the IETF/ISOC, certifies it as meeting those requirements. If the registry fails to meet the requirements the LA will de-certify it. The consideration supplied by the LA is IETF/ISOC certification, the consideration supplied by the registry consists of an agreement to abide by certain standards and to support the activity of the LA through fees. The IETF and the ISOC charter the LA through their own procedures. An RFC would presumably constitute the IETF charter for the LA. And presumably the ISOC officers and/or membership at large would vote to accept that RFC as defining their relationship with the LA as well. But of course the *mechanism* of the charter is not important. Given the non-legal basis for the LA's authority, whatever mechanism is acceptable to the organization is, by definition, adequate. 5. Description of the Licensing Authority The sTLD-LA is an administrative entity chartered by the IETF and the ISOC to designate registries and DNS services that meet the standards and conditions described in the LA charter, other applicable RFCs, and other documents associated with the LA. 5.1. The responsibilities of the LA 1) Accept and process applications for the creation [3] of sTLDs, and coordinate with an Ad Hoc committee composed of IETF and ISOC members that will make the decision about the particular sTLD. 2) Process applications and grant licenses for sTLD registries. 3) Act as a point of contact for all claims for action under the dispute resolution policy, and, when called for, take appropriate action to enforce the results of the dispute resolution policy. 4) Keep a database of public information regarding registries. 5) Keep a database that provides the basis for the root zone. 6) Collect certain fees, which are deposited in a trust account with the ISOC/IETF to cover LA-related activities. 7) Manage the events that surround the termination of a registry. 5.1.1. Process applications for the creation of sTLDs. Individuals and organizations that wish to become a registry for a new sTLD must submit an application to the LA, a charter for the sTLD, and an application fee of $XXXX [5]. Anyone may submit an application. The LA accepts the application, and examines it for obvious problems, such as names with obvious intellectual property concerns, or charters that have problems [4]. If the application and charter pass this initial step, the application is published in an internet forum designated for this purpose, and a 60 day comment period ensues. The application and any comments collected are then passed to an Ad Hoc committee formed from the membership of the IETF/ISOC, where there is further examination and discussion of the suitability of the sTLD. The committee will decide whether or not to accept the application. If it is accepted, it is passed back to the LA for action. Upon approval of a proposed sTLD, the LA presents the applicant with a Registry License Agreement, which all parties sign. After this applicant is free to implement the sTLD, and the LA will publish the results to the root zone. [The characteristics of the Registry License Agreement are described in a separate section below.] 5.1.2. Process applications and grant licenses for sTLD registries. Individuals and organizations that wish to become a registry for an already existing sTLD must submit an application to the LA, together with an application fee of $XXXX. The LA will review the application, and publish it for a 30 day comment period. [6] After this period the LA will examine the comments, and either A) approve the license, B) disapprove the license, or C) pass it to an Ad Hoc committee for further consideration. [7] Upon approval of a proposed registry, the LA presents the applicant with a Registry License Agreement, which all parties sign. The applicant is then free to set up a synchronization method with the other registries for the sTLD, and start registering names. 5.1.3 Act as a point of contact for dispute resolution. The Registry License Agreement refers to a dispute resolution process [described below] that all registries must follow for inter-registry disputes. When disputes between registries cannot be solved among the registries a complaint is forwarded to the LA, which deals with it according to the Dispute Resolution Process. 5.1.4. Keep a database of registry public information. The LA will keep current and historical records about all registries. This data should be preserved in a high-integrity database. The actions of the LA are a matter of public record on the Internet, and all official decisions will likewise be recorded in a public, high-integrity database. 5.1.5. Keep a database for the root zone. The LA is essentially the single registry for the root zone, and as such it must keep an appropriate database for building that zone. 5.1.6. Collect Fees. There are fees associated with the creation of an sTLD, licensing of a registry, and yearly running of a registry. These fees are used to support the activities of the LA, through a fund managed by the IETF/ISOC 5.1.7. Manage termination of registries and TLDs Registries will terminate from time, and the LA manages the timely and orderly dispersal of their customer base and DNS services. A registry may cease to function due to business failure, termination for failure to follow the terms of the Registry License Agreement, or voluntarily. [There is no penalty for quitting a registry.] If the registry that terminates is the one that runs the Master DNS for the sTLD, then the LA will select another registry for the sTLD to take over the Master DNS function. If there are no other registries for the TLD, the LA will temporarily assign the zone information to a registry for another domain, and try for 120 days to find a registry willing to take over as a permanent registry for the TLD. If none can be found the zone will be removed after 120 days, and the TLD will be available for a new charter. In all cases, the LA will take the latest available customer database from the terminated registry (either from the escrow site, or directly) and send a "registry termination" email message to the administrative contact for each domain. This message will inform the customer to transfer their domain names to their pick of an alternate registry. If there is no alternate registry the customers will be so informed. After 120 days domain names that have not transferred will be removed from DNS. [9] 5.3. Structure and Composition of the Licensing Authority This document leaves the actual structure and composition of the Licensing Authority undefined. It seems likely that the work of the Licensing Authority would require full-time effort on the part of several people, especially in the early stages. These people need to be paid, housed, and supplied with equipment. Costs could range up to several hundred thousand dollars per year. In the early stages some of this cost would be born by the IETF/ISOC, but soon the LA should be self-supporting through the fee structure. These details certainly need to be worked out, but they are not addressed further here -- the author doesn't have the knowledge to fill in such details. 5.4. Other Issues This document does not deal directly with intellectual property concerns surrounding TLD names. However, it is my belief that the only way the LA could be *sure* that a name did not cause trademark problems would be for the LA to trademark the name itself. It is my preference that the LA require any entity creating a TLD to warrant that the name is free of encumberance, and to sign a document releasing any ownership the creating agency might claim (essentially a quitclaim of some form). 6. Characteristics of the Registry License Agreement The Registry License Agreement (RLA) is a contract between the Registry and the LA. Within limits it doesn't matter under which national jurisdiction the contract is drawn, but as a matter of practical fact, the LA will probably be located in the USA, and the USA still supports a majority portion of Internet infrastructure and users. Thus, the RLA will probably be be based on the laws of the USA. However, the goal is to reduce the dependence on a national legal system to the bare minimum, so the RLA will, in the strongest possible legal terms, try to move all disputes into an Internet-wide common arbitration and resolution process. The RLA is a legal document drafted by lawyers, and thus is covered only in general terms here. The RLA contains clauses that bind the registry to 1) agree to the Dispute Resolution Process, and agree to abide by any sanctions the LA may impose on a cohort. [10] 2) to share synchronization and other information necessary to run a shared registry with all registries in the current cohort, and to likewise share with all later additions to the cohort. Registries are required to support at least one standard sharing protocol (defined by an RFC) [This requirement may be modified by an approved charter for the TLD]. 3) in general to cooperate with all present and future cohorts to provide a reliable and efficient service to customers. 4) to not engage in practices commonly considered as "cheating" [8] 5) provide information from the customer database as a common distributed database of standard contact information in the standard "whois" form. 6) provide, either directly or through sub-contracts, adequate secondary DNS services for the sTLD, and be prepared, either directly or through sub-contracts, to provide adequate master DNS service for the sTLD. [12] 7) in the case of the registry that charters the sTLD, either directly or through subcontract provide master DNS service for the sTLD. 8) to escrow the customer database information on a timely periodic basis with an agreed neutral third party. 9) an agreement to pay the LA a yearly fee of $XXX for dispute resolution and other centralized services. 10) an agreement to keep the LA apprised of any significant changes in the configuration or capability of the registry. 11) an understanding that the License confers IETF/ISOC certification, and that therefore the registry agrees to adhere to future Internet standards that may be developed by these bodies that pertain to the running of registries. [11] Failure to adhere to any of the above clauses may result in termination of the certification of the registry. Note that the RLA does *not* contain clauses that require any particular level of performance as a registry, such as 24/7 help desks or such. These are characteristic that are left to the marketplace. There are requirements for adequate DNS performance, but they are in general terms, and relative to the usage of the TLD. 7. Dispute Resolution Process The intent of the Dispute Resolution Process (DRP) is to, as much as possible, get inter-registry disputes involving Registry License Agreement issues out of the court system of any country, and into an internet standard procedure that can be followed throughout the world. For purposes of the DRP, a dispute is defined as a claim by a registry that another registry is not following the terms of the Registry License Agreement, or the charter of the sTLD, or standards of operation and technical merit adopted by the IETF/ISOC. (Note that an approved charter may in fact modify dispute resolution procedures.) The DRP is *not* intended to address other conflicts between registries. If two registries enter into a separate contract, perhaps for example, shared purchase of office equipment, then the terms of that separate contract are outside the scope of the DRP. Note also that the DRP does *not* address dispute resolution at the customer level. The DRP is a separate document, drafted by lawyers, and is covered only in general terms in this document. The authority for the dispute resolution process stems from the Registry License Agreement that all registries sign -- it contains a clause that binds them to accept the DRP. Normally, it is expected that problems between cohort registries be resolved by good-faith effort within the cohort. Only when this first effort fails does the LA enter the picture, through a formal request by one or more registries to the LA. When such a formal request is received, the LA collects the written complaint, any written defense, and any evidence either side may present. If the dispute involves a question concerning interpretation of the License Agreement, the TLD charter, or Internet standards for the operation of registries, the LA may give its interpretation and return the matter to the registries. If the dispute involves a clear problem in DNS the LA may act quickly to solve that problem. Other, more complex problems may be forwarded to a Dispute Resolution committee for resolution. Example: Suppose that Registry A is a cohort of the .TLD shared registry. A has hired a new DNS administrator to maintain the secondary DNS server required for the .TLD registry, but this new administrator has proven incompetent. The cohort registries first talk to A's owner, but the administrator is A's boyfriend, and nothing changes. The other members of the cohort then go to the LA, and complain. Because the bad DNS records are demonstrable, and they are harming the name resolution for the whole domain, the LA acts swiftly, telling A to suspend operations for a week, and telling the root servers to remove A's NS records for the domain. 8. Transition Issues 8.1 The "NSI Problem" Any realistic proposal for shared TLDs must deal with the issue of how we get from here to there. And the biggest single problem is what to do about NSI and .COM, .ORG, and .NET. Briefly, .COM, .ORG, and .NET will become shared TLDs as soon as technically feasible. NSI will of course apply for licenses for these sTLDs, and the licenses will almost certainly be granted. Under the circumstances they would probably also provide Master DNS services for the TLDs as well. Any organization that wishes to become a registry for any of these TLDs may apply for a license, and, if they have adequate technical resources to support DNS for those domains and meet the other requirements, they will get licenses. Note that it is perfectly reasonable that they subcontract the DNS service, perhaps to NSI itself. The new registries would be free to drastically undercut NSI's prices, and advertise different policies concerning dispute resolution. However, NSI has a big presence, and will remain profitable through this transition. The one restriction I would place on NSI is that they not be allowed to be registries for new TLDs for a period of several years. In the meantime, new TLDs can be licensed immediately, with the same condition that would exist for .COM, .ORG, and .NET -- they will be shared as soon as technically feasible. The early licensees will have a window of perhaps 4 years to develop their presence in the new TLDs, before NSI would be allowed to compete. [Very early licensee's would have the advantage of not being required to share at all until sharing protocols were standardized.] Thus, in the long run NSI will be moved into a competitive situation. However, it will have time to plan a new course, and ample opportunity for profit under the new constraints. 8.2 Remaining Work If the IAHC decided to substantially accept this proposal, there are several significant items of work that remain to be done: 1) Several documents must be completed: An RFC defining the LA's charter, the Registry License Agreement, the Dispute Resolution Procedure, guidelines for TLD charters. 2) Actual staffing, funding, and other issues concerning the LA must be decided. 3) One or more synchronization protocols need to be finalized and implemented. 4) Details of IETF/ISOC committee involvement need to be worked out. This clearly represents a lot of work. However, a careful appraisal of what is necessary to necessary to set up a clean and *legally defensible* monopoly TLD system will reveal a lot of work as well, including many of the above steps. Unfortunately, there is no easy way to resolve all the issues surrounding TLDs. ------------------------------------------------------------------------- Notes [1] An interesting alternative to explore would be to not specifically mandate cooperation in the license, and instead mandate adherence to a "code of conduct" for shared registries that would be a separate document, maintained by, say, an association of shared registry owners. [2] The root name-servers are under no contractual obligation to provide their services, they are in no contractual relationship with the current LA, the IANA, and thus there is no contractual compulsion to accept the IANA's view of the contents of the root zone. There is (to my knowledge) no "money trail" between the IANA and the operators of the root servers. Some find it hard to believe, but it really seems to be the case that this vital component of the infrastructure of the Internet is based on consensus, good will, community service, and volunteer effort. Interestingly enough, at this point in time the root name-servers are I believe the most vulnerable to effective legal pressure of any of the Internet institutions. Consider a restraint of trade lawsuit brought against them for not accepting a particular TLD in the root zone. If the root servers were widely dispersed around the world, however, it would be impossible to get any large set of them in a single national jurisdiction. [3] "Creation" of an sTLD refers to the initial approval of the sTLD as an IETF/ISOC standard. [4] Because charters for the creation of an sTLD may be quite complex, there may be significant work in the initial examination. The LA will publish guidelines for charters. [5] The application fee is non-refundable, though the LA may at its discretion simply return the application and fee if it is immediately obvious that the application will fail. [6] During this comment period other registries for the same TLD have an opportunity to argue for or against the new registry. Arguments might concern how the new registry would fit with the charter of the sTLD, or technical issues concerning difficulty of sharing information, and so on. [7] Under normal circumstances, approval is the common response. [8] A common example of cheating is name hoarding. However, *any* claim of cheating would be worked through the Dispute Resolution Process. [9] Total collapse of a TLD should be very rare, and arguably every such instance should be treated as a special case requiring IETF/ISOC intervention. [10] For example, the LA may, as part of a decision in a Dispute Resolution case, suspend registrations from a particular registry for a time. Under such circumstances the cohort registry running the master DNS server would not accept new domains from the suspended registry. [11] It might be argued that no one would sign a contract that would allow for modifications of the standards under which they had to perform. I don't think it is a serious problem in this case because 1) we are presuming that running a registry is a small activity, not a large one, and that most registries will be run as sidelights to another business (probably most registries will be run by ISPs). It is easy to stop being a registry, thus, if the IETF/ISOC were to impose an onerous new rule, the company could simply walk away. 2) It is in the best interest of the IETF/ISOC to maintain running registries, so they will not instigate such onerous rules to begin with. 3) The registries will be well represented in the IETF and the ISOC, and thus will have a great deal of influence on standards for registries. In fact, I would expect that *most* standardization efforts will actually spring from the registries themselves. [12] "Adequate" means providing hardware, software, and network resources sufficient to provide reliable and efficient name-service for the sTLD. A registry that intended to share .COM, for example, would require a hefty investment in hardware, software, and network connectivity. Author's Address Kent Crispin L-61 Lawrence Livermore National Laboratory PO Box 808 Livermore, CA 94550 kc@llnl.gov kent@songbird.com +1 510 422 4273 INTERNET-DRAFT Expires June 1997 INTERNET-DRAFT