Almost all of the discussion around whois has been based on implicit acceptance of the roles of registrant, admin contact and tech contact as if these had definite meaning. They don't. The person who actually controls the domain registration and the associated parameters, i.e. name servers, etc. is the person who has access to the account with the registrar. I don't know if there is widely agreed upon name of this role, so I'll call her the domain controller. If this group prefers a different name, I'll happily switch. It's the domain controller who populates the registrant, admin and tech fields. Most of the time, the names and contact information that is put into these fields is reasonably related to the common sense notion of what these terms mean, but unless I have missed something, there is nothing in either the rules or the operational practices that forces these to be meaningful. In the extreme, the controller can put in the names of people who have NO relationship with the domain. Viewed from this perspective, rather than decrying the high error rates, it might be more appropriate to be amazed at how well this system works. When the whois system was first created, the net -- and we're talking about the Arpanet, not the full blown Internet -- consisted of several dozen time-shared computers, each of which support several dozen users. The tech contact was what we'd now call the system administrator (sysadmin) and the admin contact was someone who had administrative authority over both the operations and the users. The list of contacts was intended to make it easy for the relevant people in authority to get in touch with each other when there was a problem. Those terms have been transliterated to the domain name system and scaled from hundreds to hundreds of millions. Nothing really survives being scaled up by a factor of a million without undergoing serious and substantial reworking. In my view, the extensive and overwrought discussion about who should have access to the contact information, how to validate the information, and how to reconcile all of this with privacy laws is troubled because there really isn't a firm foundation at to what this contact information means. The operational questions for contact information is fundamentally what obligation does the person designated in a particular role have when she's contacted, who should be allowed to contact the person, and under what circumstances. There is, of course, one particular role that is well defined. It's the billing contact. If the registrar sends a message to the billing contact and says the bill hasn't been paid, the billing contact either takes care of the problem or the registrar shuts down the account. There is also a reasonably well defined sequence related to domain name transfers. Is there more that is well defined? What are the implications of this line of reasoning? Well, for starters, what happens if we simply remove the admin and tech contacts? If there is an argument for continuing their existence, can we base it on operational authorities and responsibilities? Another, quite important but less obvious implication is to look at what information is NOT there that should be. The current ICANN contractual model is based on registries and registrars but pays no attention to name server operators. It's quite common for the registrar to operate the name servers for the registrant, but it is also quite common for the registrant to either operate her own name servers or to use a third party. There are companies that specialize in providing this service, and they are an important part of the ecosystem. Why does it matter that name server operators are not explicitly visible in the ICANN contractual model and registration data base? Because the name server operator sometimes needs to change the information in the registry that's associated with the domain name. There are two significant cases. One is when the name server operator changes the set of name servers associated with a domain name. This doesn't happen frequently, and when it does it usually affects a large fraction or all of the name server operator's customers. When that happens, the revised list of name servers has to be communicated to the registry and be published in the parent zone. Under the ICANN model, the only path for communicating with the registry is via the registrar, and the only path implemented by registrars is via the account holder, i.e. the person I called the controller. This means when a name server operator makes a change to its set of name servers, EACH of the name server operator's customers has to process an email message from the name server operator and make a manual change to the entry in her account. This is time-consuming, labor intensive and error prone. The other case is related to DNSSEC. The signatures associated with DNSSEC have expiration dates. If the name service is being provided by a name server operator, it will be the name server operator that will generate a new key and create a new DS record on a regular schedule and . This requires putting the new DS record in the parent. Again, since the only path is through the registrar... here are proposals for additional protocols to automate this process, but these have some complexity due to the need to work around the clumsiness of adhering to the limited business model. It ought to be possible for the domain controller to explicitly designate the name server operator and to authorize the name server operator to send changes to the name server records and/or the DS records whenever necessary. For those of you who have read this far and are wondering whether this really belongs in a discussion about RDS, the answer is yes, The RDS is a portion of the overall operation of the domain name system. It provides contact information for the essential functions of the system. In the ICANN system, the registrars are contracted parties and the name server operators are not, but that does not address the need for a more orderly operational relationship among these parties. More to come. Steve