INTERNET-DRAFT Expires June 1998 INTERNET-DRAFT Policy Study K. Crispin Category: Informational January 1998 Characteristics of a Root Zone Registry Status of this Memo This document is a submission to the general internet community. 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) ftp.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Terms Root Registry (RR) -- the registry for the root zone Public Policy Body (PPB) -- a body especially for gathering public input into global DNS policies Registry -- the database and operational mechanism associated with a TLD Registry Management Board (RMB) -- the oversight non-profit corporation that is the legal entity responsible for management of registries. Registry License Agreement (RLA) -- the contract between the RMB and the RO Registry Operator (RO) -- a company or organization that runs a registry TLD Charter -- a legal document in the form of a MoU(?) that provides the basis for installing a TLD in the Root Registry The Root Zone Authority (RZA) This short Draft describes the characteristics of a Root Zone Authority (RZA). You will see many similarities between many of the components described here, and components of the structure defined by the gTLD-MoU. However, these are *components*, and there are other, similar organizations that could be seen as models. The RZA serves three distinct, but related functions: 1) It runs the registry for the root zone. 2) It approves charters for TLDs. A TLD charter is a legal document that defines policies concerning a particular TLD (or set of TLDs). 3) It issues Registry Licenses. A registry license is a legal document binding the RZA and a Registry Operator (RO). The RZA is organized as three parts, corresponding roughly to the three functions: 1) An operational component, concerned with the technical aspects of running a root zone. Because DNS will surely evolve, this component will have a long, interesting life, and will be deeply involved in standards activities. (Call this the "Root Registry" (RR).) 2) A public input component, concerned with approval of Charters, and general RZA policy. Approval for new TLDs should only come after a lengthy period of public debate. A clear model for this is the process in the IETF by which new internet standards are approved. (Call this the "Public Policy Body" (PPB).) 3) A non-profit corporation component, entrusted with managing registries. It is this component that contains the legal liability and policy enforcement responsibility. (Call this the "Registry Management Board" (RMB).) Root Registry (RR) The RZA is the top level registry for the DNS. Like all registries, it is a natural monopoly. The RZA is also a *registrar* for the root zone, the only registrar. That is, the root zone is *not* a shared registry. Again, like all registries, the RZA imposes its policies on the subzones it delegates. These policies are enforced through Registry License Agreements, and will be described in a later section. As the top level registry the RZA is responsible for maintaining a primary nameserver for the root zone. Operational aspects of this function could be subcontracted. Administrative aspects should not be. Besides the purely operational aspects, there is an obvious strong necessity that the RZA be completely abreast of all technical and standards developments that will concern DNS. The RR would be funded on a cost-recovery basis through fees paid by registries, perhaps as described below for the RMB. Other sources of funding (research grants, etc) could be considered, but a self-supporting registry would be best. Public Policy Body (PPB) Policy issues concerning the RZA, including proposed charters for new TLDs, are brought to the PPB. The PPB should have very open membership, and work according to rough consensus rules. In detail there are all kinds of different ways this could work -- imagine the IETF model: someone sees a needs for a new TLD. They talk with their friends, write a proposal for a WG, the WG works for a while on a charter, the charter goes through some standardization process (including a thorough legal vetting), and eventually is approved. At that point it is given to the RMB, which can then let a registry license for that TLD. Or, they could put together a charter from already existing charters, and try to get that to fly. Note that, while I talk of the IETF model, the IETF itself would probably not be an appropriate organization to do this. The germane issues are not primarily technical, but rather public policy. The professional expertise most required would probably be knowledge of the law. Policies concerning the operation of the RZA itself could also be processed through through this forum. PPB activities would be mostly voluntary. Administrative costs should be minimal, and could be funded in a variety of ways. Registry Management Board (RMB) The RMB is the central legal entity of the RZA. It would be a non-profit corporation with a structure similar to the POC, and like that proposed in the GP -- with a large board of directors chosen across a wide variety of internet stakeholders. The primary purpose of the RMB is oversight of TLD registries. The basic tools for this purpose are TLD charters and Registry License Agreements. These are described in a later section. The RMB is funded through registry license fees. These fees are part of the costs that a registry sustains, and thus is recovered through the fees that the registry charges registrars. Thus ultimately the cost of the RMB is born by domain name owners, as part of the cost of running the whole domain name system. Basic Policies of the RZA Non-profit Registries Experience has shown that control of a TLD can be a valuable economic asset. This value stems from two facts: first, some names are psychologically more appealing; and second, a TLD is an intrinsic natural monopoly -- especially after a period of use it becomes a significant inconvenience to change domain names, and, potentially, fairly expensive. The high profit potential of a TLD registry makes it worth fighting for. So any model that allows high profit registries will also expose the RZA to high stake legal battles indefinitely into the future. The cost of litigation insurance, and litigation itself, to the greatest extent possible, is something to be avoided. To repeat: The only way to prevent the RZA from turning into a large expensive cancer on the net is to arrange policy so that it doesn't control the spigots to lots of money. Therefore, a fundamental policy of the RZA should be that all registries to which it delegates subdomains must be run on a non-profit, cost-recovery basis. However, ensuring that registries actually run on a non-profit basis is in itself something of a job: regulation also can costly. [Regulation mechanisms will be described a little later.] A fundamental difficulty with a non-profit requirement for a registry is often posed: why would anyone want to do it if they couldn't make money at it? Fortunately, the answer to this is easy: Non-profit corporations are not forbidden from paying salaries; they can have a CEO that makes good money; and many people like working for non-profits. Also, when it gets right down to it, the CORE model, where a non-profit registry is run by a consortium of for-profit registrars, has a lot to offer. Shared Registries The goal is to have hundreds, perhaps thousands, of registrars that can register names in any TLD. Thus, the default policy for any TLD registry liscensed by the RZA is that it be required to allow any registrar to register names, without prejudice, and that the registry support a standard protocol for this purpose. [With suitable justification, the charter for the TLD may specify restrictions on registration -- for example, the charter for a ".med" TLD might specify that the domain holder must show membership in a recognized medical professional society. But the registry must not restrict any registrar that is willing to agree to the conditions in the charter.] TLD Charters and Registry Licenses TLD charters and Registry Licenses are rather complex legal documents. I am not a lawyer. But I think it is safe to say that most of the work of implementing something like this proposal will be in exploring the legal structure and environment necessary to support these documents. TLD Charters A TLD Charter is essentially a MoU, signed by the RZA, the RO, and any registrar that wishes to register names in the TLD. It must include at least the following: 1) A rationale for the TLD 2) criteria for names and entities that could be registered in it. 3) measures the registry must take to enforce the above standards (which might involve revoking a registrars's permission to register names in the TLD) 4) measures the registrars must take to enforce the above standards (which might include removing a customer from the registry.) 5) some of the conditions that a RO must meet to remain as the RO. TLD charters can be quite flexible -- one could imagine a .ham registry run on a completely volunteer basis, with the requirement that all registrants in the .ham domain provide proof of a ham radio license before they can register a name. Ham radio operators could run free registrars (for-profit registrars could also register in the .ham domain, but there would be little money in it competing against the free amateur registrars). Registry License Agreements RLAs are a contract between the Registry Operator and the RMB. They must specify the operational requirements the registry operator must meet. (As the .ham example hints, the operational requirements need not be the same for every registry.) They must specify what happens if the RO can no longer function. They might specify requirements for escrowing the registry database. Certainly they must specify penalties for non-conformance. They must form the legal underpinings for regulation of registries. Regulation of registries The registries must be regulated; regulation costs money. As mentioned above, the fundamental base of authority for the regulation is in the Registry License Agreement (RLA). Several things can mitigate the cost of regulation. First of all, without too much effort, things can be structured so that end users and registrars actually do most of the policing. The registries will be required by the RLA to keep public records of all transactions, business operations, and financial condition. Thus, the RZA does not need to keep a "police" force on hand -- instead it merely needs to have a Registry Review Board that hears complaints against registries. Also, one of the advantage of having several non-profit registries is that a realistic idea of the cost of running a registry will quickly develop, and ones that are seriously out of line will stand out. It is true that the range of penalties that the RZA can bring to bear against a registry are limited -- the ultimate penalty that can used is the penalty of disenfranchisement of the management of the registry. In this extreme case the management of the registry is given over to another organization already running a registry that is doing a good job, or a new organization that promises to do a good job. Funding The most likely source of funding for the RZA would be yearly fees from each registry. As described above, these fees would be part of the business costs of the registry, and would be recovered through fees the registry would charge to registrars, and therefore ultimately the cost would be born by the users of DNS. Author's Address Kent Crispin kent@songbird.com +1 510 886 7410 INTERNET-DRAFT Expires June 1997 INTERNET-DRAFT