Possible Disputes in the Registrar-Registry Protocol 1. Motivation The purpose of this paper is to give background to support other discussions. It is an attempt to lay out some common terminology and some common scenarios, and to give a framework by which design alternatives can be compared. I also slyly sneak in my opinions here and there. There have been expressions of disdain for anything that smacks of an "academic" approach, so perhaps I should have used a more earthy word, like "fights", or "crimes", instead of "disputes". But, on the other hand, sometimes it is good to step back for a moment and think calmly about the problems you are trying to solve. 2. Introduction In analyzing the tradeoffs between design alternatives it is important to keep in mind that all real costs will ultimately be reflected in the fees the consumers pay. Given the competition built into the gTLD system, it seems likely that profit margins for registrars will be very thin. It is quite possible that the average total cost per domain-year could be driven to less than $5. However, if coredb is run by a single contractor THERE IS NO COMPETITIVE PRESSURE ON THE COSTS INCURRED BY CORE. Furthermore, it is quite possible that CORE could run afoul of anti-trust laws. Therefore, low-cost operation is the paramount goal of the operation of registry databases, and of the protocols involved. To this end everything must be as automated as possible -- ideally, the default case should require no human intervention. In practice, we would like the average to get down to a couple minutes of a humans time per registration. Three major sources of cost are (probably in order) 1) hand-holding for new registrants 2) dispute resolution and 3) cost of technical infrastructure. Over time the revenue from continued registrations will become dominant over new registrations. So over time I believe *the* major cost will be dispute resolution. (There are other costs I ignore as uninteresting to this discussion -- the basic overhead of running a business, for example.) 3. Disputes [I am not a lawyer. A lawyer could add a lot to this, I'm sure.] The probability of disputes has been discounted on the grounds that it isn't worth fighting over the $20 someone might make for a single domain name registration. This overlooks two factors: first, *externally* domain names can be quite valuable; and second, many disputes will deal with practices that will affect multiple domains. Also, consideration of disputes is why I think that the various in-house database systems that have been proffered will probably not be good solutions for CORE -- inhouse products don't need to worry about disputes, because they operate under a single authority that can efficiently resolve internal disputes. But CORE is not such an efficient authority -- no entity international in scope, and operating in "the public interest", can be. 3.1 Types of disputes There are a lot of possible disputes, and we can't possibly foresee all possibilities. The problem, as has been pointed out several times, is compounded by the international scope of the gTLD registries. And even more, disputes very frequently develop an emotional dynamic that leads to fundamentally irrational behavior. However, at a gross level there are three types of entities (Registrars, Users, and Database Operators (DBOs)), and four classes of disputes we can consider: registrar-registrar (R-R), registrar-user (R-U), registrar-DBO (R-D), and user-DBO (U-D). [I ignore two large classes of disputes -- intellectual property disputes, because they have already been considered in great detail, and high level challenges to the whole MoU process.] Disputes in any of these categories could expand to include CORE. Each of these categories have a set of root causes for disputes -- here are some examples: 1) R-R disputes: unfair competitive practices (a huge category that needs to be studied in more detail); incompetent handling of records and transfers. 2) R-U disputes: mishandling of payments; mishandling of transactions with the registry database; failure to process transfers; misrepresentation; mishandling (exposure) of keys, and other keyring issues; "poor service". 3) R-D disputes: mishandling of the database records; collusion with other registrars; mishandling of payments; mishandling of DNS (if coredb handles dns for the gTLDs); overuse of bandwidth. 4) U-D disputes: mishandling of database records; mishandling of dns records. These should be very rare, but may come up as a spillover from a R-U dispute. 3.2 Minimizing disputes I can think of three important components to a successful dispute resolution: 1) clear policies; 2) an authority that can enforce those policies; and 3) clear information about the facts of the case. Our goal, then, would be to provide and/or maximize these things. 3.2.1 Clear Policies Policies, at the most practical level, are rules of the form "If such and such conditions apply, then the following actions are to be taken." At a more abstract level, however, we have statements like "The gTLD name space is to be managed as a public good", which give a vague idea of how things should be done, but not much practical guidance, especially when it comes to dispute resolution. To fill in this gap, I propose the following general guidlines that relate to dispute resolution [astute readers will note there is nothing original here]: G1) All dispute resolution policies will be neutral in effect (not just in wording) as far as location or economic status of disputants. G2) In any dispute, all other things being equal, an end user prevails over a registrar, and a registrar prevails over a registry. G3) As much as possible, disputes will be resolved by explicit policy, rather than through intervention of human judgement G4) When a dispute cannot be resolved by explicit policy, CORE/POC/PAB will attempt to formulate an explicit policy that will cover that case in the future -- policies will develop as the need arises Note that most policies at this level will be developed by CORE, with oversight from POC and advice/input from PAB. 3.2.2 Basis Authority The fundamental authority would seem to be contained in the legal infrastructure around the MoUs. However, we all know that the situation is much more complex, especially when it comes to resolution of disputes with end users. Any entity is free to use whatever legal means available to them to seek their own advantage. As far as I know, for example, there is nothing we can do to prevent a US entity from suing a US registrar under their common legal system. So, in fact, there is a second authority to consider -- the local legal infrastructure -- in practice it seems likely that users will tend to do business with registrars that share their legal infrastructure. This authority *will* be involved in disputes; we should explicitly plan for it by structuring things so that, as much as possible, end user contracts do not involve the registry database. That is, registrars should manage and implement their own end user (perhaps with guidance from CORE) to the greatest extent possible. [This is another factor that allows registrars to differentiate themselves competitively, incidentally.] Thus, Registrar-User conflicts will usually have a shared local legal system as the ultimate arbiter. 3.2.3 Clear Information All the facts necessary to easily decide a case should be easily available, public, and indisputable. A corollary is that you want to minimize the amount of trust necessary in the system -- that is, a system that assumes everyone lies is likely to be far more robust than one that assumes everyone is honest. In particular, the customers are dishonest, the registrars are thieves, and the registry db is run by crooks. We also assume that collusion is frequent, but defer that discussion to a later section. It is this principle that is the primary motivation for use of digital signatures -- assuming that the registry DBO will be dishonest implies that the database logs can be faked anytime the DBO is involve in a dispute. We can also assume that customers and users will fake records whenever it is to their advantage. Digital signatures are uniquely well suited to the task at hand. Not only are they very hard to refute, but they are uniquely portable. Anyone, anywhere in the world, can verify a digital signature over the internet -- no need to send witnesses to Geneva, no need to fax notarized documents. Registrar signatures on DB transactions are intended to minimize disputes between registrars, and between registrars and registries. A DB should also sign every response to every transaction. This gives the DBO and all the registrars an irrefutable history of all their transactions. Without this record all you have are logs on either side, logs that could easily be faked to say anything. For example, a transaction response signed by a DBO showing that a domain name was created for that registrar is very, very strong evidence to use in a dispute resolution proceeding -- so strong that under most circumstances the proceeding is moot. Another rule that follows is that *all* the data in the registry database should be public -- that is, there should not be any data private between a registrar and the registry. This may seem obvious, but an implication is that there should not be private billing records between the DBO and a registrar. 3.3 Collusion Collusion isn't a kind of dispute, it's more of a dispute amplifier or facilitator, and it must be guarded against. Basically, collusion is a secret arrangement between parties to accomplish some normally forbidden end. Examples in our context would be collusion between a registrar and user, or between a DBO and a user, or between a DBO and a registrar, or between a group of registrars. Bribes or kickbacks for services represents a particular kind of collusion. In the abstract such concerns may seem remote. However, if you replace "user" with "name broker" in the above paragraph, the issue becomes much more real. Some domain names are very valuable -- there are rumored cases of names trading hands for more than $100,000. A collusion between a name broker, a registrar, and a DBO could be quite hard to detect, and could be quite profitable for the colluding parties. Obviously, all other things being equal, a policy or protocol that made collusion difficult should be favored over one that made collusion easy. Collusion is more difficult when secrecy is difficult. This is another argument for requiring that *all* DBO transactions and records be public. 4. Conclusion. Disputes are a fact of life, and should be considered deeply before starting any new enterprise.