Finessing

Salon Magazine recently published an interview with Esther Dyson. I appreciate her reference to my own writings on the subject. Her main concern seems to be the challenge of transitioning from the existing system, flawed though it is, to a new system that doesn't have to bear the burden of providing meaning and stability. It's a concern that I share.

Or, at least, I did. After attending Inet2002 where I gave my talk on IPV6, I wrote about what I called Edge Protocol V6 or EPV6. The reason that we can't just assume that every machine has a first class present on the Internet is not because there is a shortage of IPV4 addresses. It is because we are trying to transition the whole Internet to a new protocol and have denied ourselves the benefits of the larger address space in the interim. Even though IPv4 itself was introduced in a forced transition the real story of the Internet is that changes are driven by the users and then shared. The Web is a dramatic example of this.

I have written about how to transition from the .COM model to one in which we separate naming from linkage. It is indeed a very hard problem and essentially impossible. So why bother? It (.COM) is what it is and we have a whole intricate system of concepts built upon it. So let it be.

Instead we can focus on the consequences of .COM and provide alternatives for those who have a need for an alternative. In reality things aren't that simple since those who adopt a new approach would be at a disadvantage in terms of the old metrics. A ".COM" name is nice because it is a short handle and is memorable. At least that is the fantasy. Only a small number of names work that way and that is unfair but trying to rectify this seeming injustice is foolish. It is far more productive to create a system that is so much better than the current one that such petty advantages become uninteresting.

As bad as the .COM problems are, it is hard to motivate people to want to fix a problem they don't recognize especially if the process seems painful. When ATT was broken up in the early 1980's many people feared that the phone network would become too complicated to use. And there was a period of confusion but one result was a significant reduction in the price of making phone calls one there was a modicum of competition.

It is more effective to view ourselves as creating a new product. Whatever our long term goals are we need to find a constituency that values the product and is capable of adopting it. As I pointed out in EPV6 this is how MIME was "sold", even if the advocates didn't view it that way. MIME built on top of the existing email transports and tools and provided those who needed it a standard way to represent pictures and graphics and exchange them via the existing transports. Though MIME was discussed at IETF meetings and via IETF RFCs the real value of the IETF was in giving MIME credibility. For the dotDNS product, ICANN would play a similar role.

You and I can exchange rich text messages without waiting for any others to implement the protocol. Yet the availability of MIME is facilitated because it leverages existing mechanisms and thus only requires a small amount of effort to take advantage of it.

We finesse the .COM by not trying to solve it. Instead we put our effort in providing a solution to those who want it. While we believe it is a superior product we can focus on customers who already understand the need.

The dotDNS Product: .DNS

The Product Itself

We're selling numbers. Big numbers and we promise that we'll never sell the same number twice. That's like saying we are selling uncooked raw fish. The problem is that most customers think they are in a restaurant and want their fish cooked and filleted and even those who want Sushi don't think of it in those terms.

In reality, we are in selling fish for others too cook and all the preparation just gets in the way. ICANN should be telling .COM buyers that they've come to the wrong place and send them to a restaurant. For now, we'll consider .COM the retail division and open our own wholesale mart.

More to the point, we are selling handles that can be used to maintain stable linkages across the Internet.

Our competition, .COM is selling finished product. But it is flawed and unsafe. If left unattended it rots and, worse, can go toxic when it is reissued and points to a site that violates the intent of those publishing the links. The .COM name is very pretty and tasty. You buy it premixed such as "KidsCandy.ABC". It looks pretty but you soon discover that it is increasingly hard to find even such a nice name amid all the other names and if you make the slightest mistake you lose it. You might make no mistakes and lose it if someone else challenges you. You may also lose it if you violate any rules that ICANN promulgates. In the end you have only a weak lease on an asset that is an essential part of your presence.

While we might mix our metaphors, our product, dotDNS is odorless and tasteless. The customer is free to add meaning or flavor in any way. It is yours no matter what and you can invest all your efforts in creating value.

Our product is also very inexpensive since it has no artificial value and is just a very low priced commodity.

I've purposely chosen to call this "dotDNS" for marketing reasons. Unlike .COM, we are selling pure DNS. In fact we can imagine .COM itself become aliased to an entry in DNS in the future. This would allow us to make dotDNS extra reliable by simplifying the root servers themselves with .COM and others being a level removed instead of adding complexity.

First Customers

The very first customers are those already hurting and who do not need to wait till the approach is widely supported with tools.

The P2P Community

Peer to peer connections need a way to maintain stable linkages for various purposes. Rather than arguing about various naming and handle schemes, dotDNS can provide a simple and bland basis for creating local namespaces. By binding to a dotDNS handle, linkages can be stable over the long term. The P2P effort can then focus on using the linkages rather than just maintaining them.

Schools Sites

Schools have found that it is not safe to put links on their web sites because such links don't just go bad, they are harvested and repurposed for marketing of products that can be very offensive to their users. Having a stable handle larges removes that risk. Of course the site provider itself can change but to the extent you trust the provider you can trust the link.

Archivists and Others

Very simply, these are people who value linkages that don't unravel if one forgets to pay a bill or has shirks responsibility by dying.

Site designers and providers

Instead of putting linkages among sites at the mercy of .COM names, linkages can use the stable dotDNS names. Sites already use long untypeable URLs so this is no different. Since dotDNS names readily available there is the added flexibility of using base names instead of building in the assumption that the identifiers share a common DNS suffix. The approach is both flexible and stable.

It is safe to embed dotDNS links into products be they software or hardware. These can range from help files to small devices inside walls.

Large Providers

AOL, for example, already has its own naming scheme so needn't be dependent upon .COM. It can easily use dotDNS in many of its services.

Next Customers

Basically everyone else. Even now one rarely has to type a URL. Instead you can type a search string into the browser. dotDNS should encourage the creating of even more effective tools once the perception of .COM magic has faded. For now, better to focus on the initial customers and simply making the capabilities available.

NonCustomers

There are a lot of people who care very much, even too much, about .COM names. We can simply ignore them. Of course we do want to sell them on the dotDNS concepts but we can accept their continued fixation on .COM as logn as we have a refuge in dotDNS.

Creating the Product

Establishing dotDNS

OK, we've got customers. Now we need to build the product. The good news it the product basically exists. It's the existing DNS. We aren't trying to fix the DNS, we're just providing access without the encrustations that interfering with its basic operation and with people's ability to create their own mechanisms.

The reason we can to use the DNS is that we gain the benefits of all the software that uses that particular mechanism. And the simplest way to make use of the DNS is to have ICANN suggest that the root servers support it. To put it in ICANN terms, we need ICANN to establish a new TLD called "DNS".

Unlike many detractors, I believe that the members of ICANN are doing their best to serve the public and thus there is no conflict with disputing ICANN's mission and asking for support for this particular TLD. Even if it means that ICANN itself will lose much of its importance as .COM becomes marginalized over time.

ICANN itself doesn't have to say that .COM is fatally flawed. Simply creating dotDNS is a sufficient step even without a strong endorsement. It allows us to proceed to the next step.

Making dotDNS Real

Each of the current TLDs has at least one registrar. Some of the TLDs are shared under a complex arrangement. The registrars are in business to make money. They can profit from leasing names or by using the names to support another revenue stream such as advertising. The root servers maintain the NS records for the millions of second level names. An NS record points to the server that contains the data for that name. Changing the NS record is considered to be an infrequent operation and in an effort to reduce the load on the root servers such changes can take a few days to propagate.

dotDNS is different. The names themselves have little commercial value. They have a very low price and are to be available essentially forever. Since the names themselves are not special, the number of dots isn't important either. Thus we can readily structure dotDNS to put little load on the root servers and distribute the load to second or lower level servers. The number of dots is significant only in that they represent a degree of dependency on the servers between the handle's server and the root server.

In order to provide stability we require that the principal dotDNS providers be able to assure permanence. Of course there is no such thing as perfection but we can use the current root servers as our standard. Second and third level dotDNS servers can use a similar system of mirroring to assure stability. To keep the problem manageable the second level would be used for registrars who can freely provide entries within their servers. This means that the root servers have only a modest load though it just pushes the problem off on level but that is a big step and can be repeated to a next level if necessary.

So who will take on the task of being a dotDNS registrar? It's hard to give a definitive answer since the lack of ICANN endorsement makes it difficult to get a serious answer. The current registrars don't have a strong incentive to take on the task of creating dotDNS. Once we're passed this hurdle the problem should be management since there are a number of organizations that are interested in facilitating the stability of the Internet. Unlike the other TLDs there isn't a conflict with the commercial value of the names. The main requirement is the ability to share in order to get enough redundancy to assure a high degree of long term availability.

The actual effort to be a dotDNS registrar is modest since the task is simply to maintain a pointer to the zone associated with the record. The actual process will require some design in order to assure that only those authorized can make a change. One approach would be to associate an authorization key (a crypto key) that acts like sufficient proof of authority. Registrars can offer servers such as holding the capabilities on behalf of their users. Of course such services would have a cost and the registrars would charge for it. There is no requirement that dotDNS be run as a charity service.

The actual cost of just keeping a pointer is very low and most changes would be done by the user directly using standard software interfaces. Even those changes might have a fee above a certain minimal level.

The primary cost is that of maintaining a few bytes (or even a few hundred bytes) on a disk. There is essentially no cost per entry. The main costs come from customer support which would be done for a fee.

Building upon dotDNS

We don't really have to answer this since we don't have to prove that we can do a better dotCOM than dotCOM. For the most part the current search engines and other tools continue to work as-is.

What will change is the assumption that such mechanism are competing with dotCOM even though the users are shifting away from guessing dotCOM names. dotDNS only makes this trend explicit, it allows us to think beyond the tree model of the net to a flatter and simpler model. A dotDNS name can be used like an ISBN number to identify a document independent of ownership. Of course, this means that we will also use up a lot of dotDNS keys and leave us with a few trillion bytes of stale pointers. Despite our tendency to worry about scarcity let me assure you that there is no shortage of integers or, for that matter, disks pace.

By freeing ourselves from seeing dotDNS as a competitor to dotCOM we can start to rethink the basic assumptions underlying the use of dotCOM in URLs. The Web took advantage of dotCOM and also is limited by it. dotDNS gives us a chance to address some of those limits.

Commencement

Creating dotDNS is not a goal in its own right. It is just a means. Once we have dotDNS then we can begin to explore the possibilities of the not beyond dotCOM.