Network Working Group A. Main Internet-Draft: draft-main-sane-tld-00 Black Ops Ltd Category: Informational October 2001 Expires: April 2002 Plea for a Sane Top-Level Domain Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo examines practical problems in the use of the ICANN generic top-level domains, in particular that they fail to provide a stable namespace that is required by some protocols. The practical problems are traced to underlying problems in domain name allocation policy in those domains. Possible solutions to the problem are discussed, including the possibility of a new top-level domain to be managed in accordance with IANA assigned-numbers principles. 1 Introduction Many applications and protocols, as well as people's informal expectations, treat the domain name system as a stable, persistent namespace, with persistent delegation. The current generic top-level domains ("com", "net" and "org") manifestly fail to provide such a namespace. In the gTLDs there are frequent disagreements over who has the right Main expires April 2002 [Page 1] Internet-Draft Plea for a Sane Top-Level Domain October 2001 to a particular domain. We hear reports daily about rights to domain names being forcibly revoked from their original registrant and granted to other parties, usually big businesses, that have some disagreement with the original registrant. Among the technically- literate of the Internet community there is widespread despair at the way these TLDs are operated. Plainly this is not a sane state of affairs. Section 2 of this document outlines the need for stable domain names. Section 3 examines the operation of the current gTLDs in more detail, speculates on the origin of the current problematic situation, and explains why the current situation is a problem. Section 4 examines possible solutions. 2 Why We Need Stable Domain Names 2.1 DNSSEC DNSSEC [DNS-SEC] is intended to authenticate DNS lookups. It does this by cryptographically verifying the chain of delegations leading to a domain name and the data held under that name. This authenticates the entire name-to-data mapping that makes up a DNS lookup. Superficially, DNSSEC appears to authenticate an object identity-to- data mapping. It does not in fact do this; doing that requires, in addition to DNSSEC, an authenticated object identity-to-name mapping. In all uses of DNSSEC, this step has been glossed over: it has been assumed that the process will start with the correct name. But the correct name can only be reliably known if it is stable. Users of DNSSEC are thus implicitly using domain names as persistent identifiers. In failing to fully authenticate an identity-to-data mapping, DNSSEC is, of course, working as designed. It is solving part of that problem, and leaving the other part to be solved elsewhere. But a name-to-data mapping, however authentic, is quite useless without an identity-to-name mapping. DNSSEC is thus useless without either domain names being persistent identifiers or some new mechanism to authenticate a transient identity-to-name mapping. Persistent domain names appears to be by far the simpler engineering solution. 2.2 URI Resolution The URI resolution process defined by [NAPTR] refers URI resolvers through a series of domain names to route a resolution request to the appropriate authority that can give a location or other information for a resource. These referrals, being by name, implicitly assume Main expires April 2002 [Page 2] Internet-Draft Plea for a Sane Top-Level Domain October 2001 that the name/identity mapping is persistent. In particular, consider URN types that are managed and resolved by a single organisation, for example the "ISSN" URN namespace described in [ISSN-URN]. In cases like this, resources critical to the handling of all URIs of a particular type are named within a domain managed by the single organisation responsible for that URI type. Any interruption of name resolution in that domain, or any compromise of the name/identity correspondence for that domain, would be highly disruptive. It is necessary in these cases that the name of a privately-managed domain be reliably persistent. 2.3 A6 Resolution The resolution of IPv6 addresses using A6 records [DNS-IP6AA] has, as one usage option, end-user sites referring to their ISP-provided address prefixes via records managed by their service provider, rather than giving complete addresses themselves. The address prefix records are referenced by name. If this mode of use is ever deployed, then the accuracy of the most commonly-requested information about a host, namely its network protocol addresses, will depend critically on the stability and availability of names that are administered by a completely separate organisation, namely the service provider. In order to avoid organisations risking their reachability on an uncontrolled risk accepted and nominally borne by another party, it will be necessary for service providers' A6 records to reside under persistent domain names, that end users can be confident will remain stable. It would help if end users could instantly know that they are delegating the address prefix information to a persistent domain name. 2.4 Natural Expectations In both formal and informal contexts, people use domain names to identify organisations. There is a natural tendency to think of a domain name as an unambiguous means of identifying an organisation, because, unlike common names, there can never be two organisations simultaneously with the same domain name. The technical and precise nature of domain names leads people to expect that domain names can be treated similarly to other technical identifiers: that they will have the same meaning in all contexts and at all times, that they can be safely embedded into code, and generally that they can be treated as persistent identifiers. As an example of the use of domain names as identifiers, some cryptographic key certificates use domain names to identify the key Main expires April 2002 [Page 3] Internet-Draft Plea for a Sane Top-Level Domain October 2001 owner. In such security-relevant contexts, and particularly with long-lived keys, it is critical that a domain name used in this way remains a valid identifier for the same organisation for a long time, at minimum for the lifetime of keys that are certificated in this manner. 3 Current Generic Top-Level Domains 3.1 Current gTLD Name Allocation Policy The current gTLDs all operate under the same name allocation policy. This policy was been put in place well after the gTLDs were invented and became popular. It filled a void: originally there was no formal allocation policy specified for these domains. The current name allocation policy is first-come-first-served for the initial registration of a name, but has a concept of a priori rights to a domain name. These rights are enforced by revocation of a previously established name registration. ICANN's UDRP (Uniform Dispute Resolution Policy) [UDRP] provides the official procedure for determining who has what rights to a domain name, and the procedures for executing a revocation of a registration. Some highlights: o Domain name registrations can be forcibly revoked or suspended without advance notice as a result of legal processes. o Owning some kind of trademark that resembles a domain name grants some rights to to that domain name. o The type of use that is made of a domain name is significant in determining the rights that domain registrant has to that domain name. In particular, rights are quite different depending on whether the use made of a domain name is primarily commercial, or is non-commercial, or violates any meatspace laws. o "Confusing similarity" is sufficient to create a name clash for the purposes of determining rights. These rules are, as one might gather from the above excerpts, typical of meatspace legal constructs, and in particular resemble US trademark law. But there is an inherent conflict within the rules: the space in which the rules are applied does not resemble the space in which trademark laws have previously been applied. o Trademark laws have traditionally been applied to matters of commercial identification, whereas domain names can (and do) identify anything. Main expires April 2002 [Page 4] Internet-Draft Plea for a Sane Top-Level Domain October 2001 o Trademark laws allow for the coexistence of identical names, in cases where context is sufficent to disambiguate. (Companies in different industries or different localities do not conflict in the use of a particular name.) o Trademarks are used through the mechanisms of human language, where words need not have a precise standard form and fuzzy matching is normal. Hence trademark rights cover anything very similar to the official mark, as compared by human language processors (namely humans). By contrast, domain names are very precise conceptual entities, being strings of characters from a well-defined set; matching is normally performed by computers, which look for an exact character-by-character match. It is this inherent tension between the legal realm of trademarks and the technical realm of domain names that has resulted in the manifest problems of the UDRP. The rules effectively governing the gTLDs are the union of the legal and technical rules; thus we have a situation where names can clash either by character-by-character equivalence (the technical rule) regardless of contextual disambiguation or by natural-language similarity (the legal rule) regardless of technical difference. This kind of uncomfortable merging of the legal and technical domains is entirely out of character for the Internet. It is evidently a result of the historical accident that led to domain name registration becoming big business; once it was a business matter, rather than a technical matter, it started to be handled the way businesses handle things, i.e., with contracts and legal action. Thus the stage was set for what those with a technical viewpoint see as the encroachment of legal machinery onto technical territory. 3.2 What is Wrong with Current gTLDs Having deconstructed the UDRP situation to its origin in the influence of meatspace business concerns, let us consider what would have happened if the gTLDs had always been managed purely by the technical Internet community. Domain names would have been managed more according to the natural technical principles inherent in the design of the DNS. In contrast to the UDRP features listed in the previous section, we would have features such as: o Domain name registrations would be irrevocable. This is, of course, a basic requirement to provide a stable namespace. o Domain names would have no connection whatsoever with trademarks. The use of a domain name would not be seen as having any relevance to any trademarks that happened to look similar, and there would Main expires April 2002 [Page 5] Internet-Draft Plea for a Sane Top-Level Domain October 2001 be no perceived need to make domain names resemble any trademarks owned by the controller of the domain. Domain names would thus be a completely separate namespace from trademarks and everything else. o The type of use, or lack of use, of a domain name would have no bearing on the validity of its registration. o Domain names would be seen as different precisely when computers (applying the DNS matching rules) can tell them apart. Thus "foobarco" and "fubarco" would be accepted as unrelated labels. These principles are familiar to the technical Internet community: they are natural requirements of a stable, persistent namespace. They are principles applied to protocol parameter assignments. We all understand that the Internet operates as well as it does largely because of IANA's excellent stewardship of many protocol-established namespaces. What we want, then, is a domain that is managed according to IANA principles, using a well-known set of guidelines. 4 Possible Solutions For the reasons detailed in [UNIQ-ROOT], this document does not consider potential solutions that would compromise the concept of a single DNS root. Most of the discussion below is actually orthogonal to the issues of root zone management. 4.1 Use of the "arpa" TLD So far, where there has been a particular need for stability in the DNS it has been special-cased, by placing protocol-defined domains that need to be stable into the IAB-managed "arpa" TLD [ARPA-MGMT], for example the "ip6.arpa" address mapping domain [IP6-ARPA]. This is neither a sustainable nor an appropriate solution to the wider problem. As explained in section 2, there is a need for stable domain names under the control of many disparate Internet users, not just a handful of centrally-managed domains. There is also need for organisations' general-purpose domains to be stable in this way; the problem is not limited to the kind of special-purpose domains that have been placed under "arpa". 4.2 Changing the Policy of the Existing Domains The most obvious solution is that the UDRP should be abandoned as a means of administering the gTLDs, and replaced by an allocation policy that meets the technical requirements outlined in section 3.2. This type of change would be fraught with political, commercial and Main expires April 2002 [Page 6] Internet-Draft Plea for a Sane Top-Level Domain October 2001 legal obstacles, and even if achieved it would cause huge upheaval in the gTLDs. It does not seem to be a feasible approach. This leaves the only way to get the domain we need to be to create it anew. We can leave .com to those content to pay the Verisign tax, and have a sane domain alongside the commercial gTLDs. 4.3 OID Mapping There is already a well-known stable namespace used in several protocols: OSI OIDs [OSI-GEN]. An obvious solution to the problem of stable domain names would be to define a mapping from OIDs into domain names. Suppose for the sake of argument that it is to be to be rooted in a TLD named "oid". (It could perhaps reasonably be "oid.arpa", to go alongside the other mappings from other address spaces). We would have, for example, the domain 14.1.4.1.6.3.1.oid (the mapping of OID 1.3.6.1.4.1.14) irrevocably owned by BBN, and 113556.840.2.1.oid (OID 1.2.840.113556) by Microsoft. The use of OIDs in this way has some great benefits. By making use of a pre-existing delegated persistent namespace, there is no question of how to allocate names, or of who has the right to use a particular name. There is also not even a perception of trademark- relevance: because the labels are numeric, rather than character strings, even those unfamiliar with the technicalities of persistent namespaces do not expect the names to have any connection with trade names that they use in informal contexts. Before an OID mapping zone can be established there needs to be some research into how it could be operated. Because most OIDs don't need to be mapped into domain name space, there is a significant question of how the delegations should be managed. Should IANA delegate directly to individual OID owners from the "oid" zone? At what level should organisations be expected to manage the DNS delegations themselves alongside their actual OID delegations? Fortunately, the definition of the OID mapping domain would be such that these management policies could be changed, non-disruptively, subsequent to initial deployment of the mapping zone. Such a mapping of OIDs into domain names seems worthwhile on its own merits, even without the problems discussed in this memo. This is recommended as an area for IETF study. 4.4 A Sane Top-Level Domain Although mapped OIDs would satisfy our basic technical requirements, they don't look the way we expect domain names to look. Traditionally, in Internet protocols, in cases where there is no Main expires April 2002 [Page 7] Internet-Draft Plea for a Sane Top-Level Domain October 2001 pressure for a particularly compact representation, we use mnemonic character string identifiers. Domain names follow that convention of character string names. Furthermore, domain names, to the extent that they can be regarded as persistent identifiers, have really the Internet's equivalent of OIDs: the DNS is a structured, delegated namespace, and we use domain names to name any object of interest. For the purposes of illustration, suppose that the new domain will be called "tech", reflecting its primary use in technical systems that require persistent object naming. This document does not advocate this or any other name as the actual name to use for this domain, should it eventually be created; the name "tech" should be interpreted as a placeholder for whatever name might later be chosen. 4.4.1 Why it Has to Be a Top-Level Domain As described in section 2.2 of [ARPA-MGMT], the IAB-managed "arpa" domain has to be a TLD in order to avoid potential operational instabilities that would result from a deeply nested domain. While our hypothetical "tech" domain might not be as operationally critical as "arpa", the stability of its name will be crucial. If the new domain were to be created under a gTLD (e.g., as "tech.net"), it would be subject to all those problems of gTLDs that it is intended to avoid, not least the risk of the domain's delegation being suspended by the registry due to legal action. The new domain doesn't appear to fit reasonably under any of the existing special-purpose TLDs. The only possible exception is the "arpa" TLD, but "arpa" is intended for specific infrastructure domains, whereas the hypothetical new domain would have wider use. This leaves only the root domain itself as an appropriate parent for the new domain. 4.4.2 Pre-Deployment Requirements Before it can be deployed, there are three major matters that need to be determined for the "tech" domain: 1. its name 2. its allocation and assignment policy 3. who is to manage it This memo does not provide firm answers to any of these questions; these matters can only be determined through IETF study. Main expires April 2002 [Page 8] Internet-Draft Plea for a Sane Top-Level Domain October 2001 4.4.3 Who Will Manage a Sane Domain Who could manage a persistent namespace within the DNS? Obviously IANA has a lot of experience of managing persistent namespaces, making them a natural choice. There are two major questions concerning IANA's competence to manage this namespace. Firstly, whether IANA can handle the huge number of name registrations that might be very rapidly requested after deployment of the domain, which would likely be well beyond the behaviour of any other namespace ever managed by IANA. Secondly, whether IANA can withstand the political pressure that would inevitably be exerted by parties wishing to compromise the technical persistence requirements in the "tech" domain. These same problems would face any body chosen to manage the "tech" domain or delegated the responsibility by IANA. 4.4.4 Name Allocation Policy Basics The basic requirements in any name allocation policy for the "tech" domain are: o A name assignment, once made, cannot be revoked or transferred for any non-technical reason. This is the fundamental requirement of a stable namespace. See section 4.4.5 for more discussion. o The mere existence of a name assignment, or the attachment of data in the DNS to such a name, must not be considered to be relevant to trademark law. See section 4.4.6 for more discussion. o A domain name must be available to any organisation that has reasonable need for one. See section 4.4.7 for more discussion. Other than these requirements, most aspects of name allocation policy are yet to be decided. It would be perfectly possible to have multiple "tech" domains, with different allocation policies operating in each, just as any "tech" domain would coexist alongside the UDRP gTLDs. 4.4.5 Irrevocability of Domain Name Registrations In order to provide persistent identifiers, the persistence of names in the "tech" domain must be enforced. To be precise, the persistence required is that after a name has been firmly assigned to a particular entity, such that other people might reasonably start to rely on that assignment (for example by using the name as an identifier for the assignee), then that name must never later be assigned to a different entity (which would break people's reasonable Main expires April 2002 [Page 9] Internet-Draft Plea for a Sane Top-Level Domain October 2001 reliance on the name/entity correspondence). Although this strong persistence can be relied on at the "tech" domain level, it cannot be enforced at any lower level of subdomain. Whether a similar policy is applied within any particular "tech" subdomain is a matter to be decided by the entity to which that subdomain has been assigned. Consequently, the use that a third party can make of a domain name under the "tech" domain depends on the persistence policy operated by the subdomain assignee; the strong persistence at the higher level is necessary in order to give name assignees full flexibility in determining their own persistence policy. Strong persistence requires that a domain name cannot be transferred, even with the full cooperation of the previous registrant. In addition to the obvious problem of transfers violating third parties' expectations of persistence, transfers open up an avenue of legal attack. If transfers are permitted at all, then contracts and courts will be able to force a transfer from a registrant that doesn't want to transfer, thus compromising the stability of the namespace just as the UDRP does in the current gTLDs. If an assigned name is no longer used for any purpose, at the request of the assignee, the delegation for that name in the "tech" zone might be removed. However, even on request, the name must not be removed from the list of registered names and made available for reassignment. Reassignment of the name to a different entity would result in any old uses of that name to refer to the old registrant, such as in long-lived key certificates, now unintentionally referring to the new registrant. This is exactly the kind of problem that "tech" is supposed to avoid. Therefore, rather than disused "tech" domain names being deregistered, they must be permanently retired. A related requirement of persistent domain names is availability. Where an organisation has been assigned a persistent domain name, it may reasonably start to rely on the availability of that name as a means to refer to its data in the DNS. The name registrar, therefore, must not revoke the delegation of an assigned name once made, except with the cooperation of the assignee (who is in any case entitled to call for changes to the delegation details). This must apply even if the name was assigned erroneously (e.g., a second name assigned to an entity if there is a policy of only assigning one name). 4.4.6 Trademark Status of Domain Names Although it is argued that assignment of a name in the "tech" TLD should be considered irrelevant to trademark law, it remains possible Main expires April 2002 [Page 10] Internet-Draft Plea for a Sane Top-Level Domain October 2001 that mentioning such a domain name in some circumstances could violate trademark law. If a company that happened to have a domain name that resembled the name of one of its competitors were to advertise in a way that made the domain name particularly prominent, it is likely that they would be found to be passing themselves off as their competitor, and if the competitor's name is a trademark then they would be violating the trademark. Note that it is the advertising in this case that violates the law, not the registration or operation of the domain. The same issues apply with any laws that restrict speech. For example, if there were a domain "jesus-was-a-rapist.tech" (perhaps owned by the Jesus-was-a-Rapist Theological Research Foundation), then many forms of advertising of that domain name would be illegal in the many countries that have blasphemy laws that apply to the Christian religion. [DNS-STRUCT] suggests that the above situation is what was originally intended for the gTLDs. In particular, Postel says "The registration of a domain name does not have any Trademark status.". It is perhaps unfortunate that this part of that document has been ignored; it is also arguable that Postel's suggestion that "the registration authority shall have no role or responsibility" in domain name disputes hasn't been taken seriously enough, or perhaps was not a sufficiently strong statement. This is why we need the stricter rules described in section 4.4.5 to rule out any possibility of dispute. 4.4.7 Registration Eligibility Issues As explained in section 2, there is a need for ordinary end-user organisations to acquire persistent domain names. Consequently, any organisation that can give reasonable justification for needing a persistent domain name must be able to get one. Particularly with the use of domain names as general-purpose persistent identifiers, this qualification is likely to be met by almost every organisation; it may be preferable, therefore, not to impose any such requirement, and to assign a persistent domain name to any organisation that requests one. This raises the question of whether an organisation should be limited to a single name. Because of the capability to arbitrarily create and delegate subdomains, an organisation has no technical need for more than one persistent domain name to be assigned to it and under its complete control. Restricting organisations to a single domain each would make the job of managing the "tech" domain much smaller: the enormous size of the current gTLDs is largely attributable to many organisations registering huge numbers of domain names each. Main expires April 2002 [Page 11] Internet-Draft Plea for a Sane Top-Level Domain October 2001 Because the "tech" domain would be intended for technical uses of the DNS that require persistent names, there is not the same aesthetic pressure that leads to such a flat use of the gTLD namespaces. Enforcing the limitation also makes "tech" domain names more effective as identifiers, but there would always be occasional failures in enforcement, so the name-to-identity mapping would be technically many-to-one in any case. Although it is necessary that any organisation be able to acquire a persistent domain name, it is not necessary that all such registrations be immediately under the "tech" domain. It would be possible for there to be a handful of domains directly under "tech" and to make end-user name allocations from within those subdomains. There are several possible justifications for such hierarchical allocation: for example, to qualify an organisation's domain name with some indicator of its industry or geographical area, or to divide namespace management duties among several organisations. However, if considering such a scheme, the lessons from "com", "net" and "org" should be borne in mind: some organisations will try to acquire names in as many namespaces as possible, leading to pointless duplication. Interaction with any single-name-per-entity policy should also be considered. 4.4.8 Selection of Domain Names One of the major name allocation issues that needs to be decided before name registrations can commence is how to decide what name to allocate to a particular entity that wants a "tech" domain. In particular, should there be some attempt to make domain names resemble organisations' common names even if the organisation wishes for a different name? Interestingly, IANA is already managing a namespace that assigns persistent character string labels to organisations. [MIME-REG] defines the "vnd." tree for MIME media subtypes. One of the forms of a "vnd." subtype name has an "IANA-approved designation" of the responsible organisation immediately following the "vnd.". It may be convenient not only to adopt this standard for determining the name to allocate in the "tech" domain, but also to unify these two namespaces. Unification would force stricter rules on the names used for MIME subtypes: it would require that the names there be limited to hostname label syntax (which all current assignments match). 5 Security Considerations The need for stable domain names described in section 2 is very security-relevant; the present situation of unstable domain names opens up various security problems. Anywhere that a message of any Main expires April 2002 [Page 12] Internet-Draft Plea for a Sane Top-Level Domain October 2001 kind refers to a domain name, such that the recipient of the message needs to do a DNS lookup on that name, then any change in the assignment of that domain name will change the effective meaning of the message without changing the verifiable raw data of the message. There is a broad class of object substitution attacks that are made possible by the capability to modify a domain name delegation through legal procedures. DNSSEC makes it possible to cryptographically verify a name-to-data mapping within the DNS, but by following the chain of cryptographically-authenticated delegations to the name of interest, one acquires data that is only as trustworthy as all of those delegations. One view of the resolution process is that the DNSSEC verifier must trust all of the ancestor zones to maintain the delegation that it expects. In this sense, a UDRP zone is inherently untrustable, because by explicit policy it fails to consistently maintain delegations. Domain names are already being used to identify organisations, for example to identify the owners of cryptographic keys. The fact that domain names are not reliably persistent identifiers leads to some potentially serious problems of misidentification. More conceptually, in the case of key certificates, it leads to questions of whether a key is being associated with a particular domain name or with a particular organisation. 6 IANA Considerations Because this memo does not call for the immediate creation of any new domain, there are no resulting name assignments for IANA to register and no new namespaces for IANA to manage. Documents creating the new domains suggested in this memo would have to specify management considerations for those new domains in considerable detail. Section 4.3 raises questions concerning the management of an OID mapping domain, and sections 4.4.3 to 4.4.8 discuss issues concerning the management of the proposed "tech" domain. 7 References [ARPA-MGMT] G. Huston, "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, September 2001. [DNS-IP6AA] M. Crawford, C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. Main expires April 2002 [Page 13] Internet-Draft Plea for a Sane Top-Level Domain October 2001 [DNS-SEC] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [DNS-STRUCT] J. Postel, "Domain Name System Structure and Delegation", RFC 1591, March 1994. [IP6-ARPA] R. Bush, "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001. [ISSN-URN] S. Rozenfeld, "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001. [MIME-REG] N. Freed, J. Klensin & J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [NAPTR] M. Mealling, R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [OSI-GEN] ISO, IEC, ITU, "Information Technology - Open Systems Interconnection - Systems Management Overview - Procedures for the Operation of OSI Registration Authorities: General Procedures", ISO/IEC 9834-1:1993, 1993. [UDRP] ICANN, "Uniform Domain Name Dispute Resolution Policy", 24 October 1999. http://www.icann.org/udrp/udrp- policy-24oct99.htm [UNIQ-ROOT] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. 8 Author's Address Andrew Main Black Ops Ltd 36 Cannon Hill Road Coventry CV4 7DE United Kingdom Phone: +44 7887 945779 EMail: zefram@fysh.org Main expires April 2002 [Page 14]