---------------------------------------------------------------------- Date: 9 Aug 1996 11:47:35 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: business model for shared tlds >> Same problem I discussed before: >> all registries have a strong interest in being able to register names, but >> they have only a faint interest in being the coordinator. > >I guess I don't see this as being a big factor, for a couple of >reasons. First, they only have a faint interest in paying their >electric bill, but they certainly will pay it. Second, it is >actually in their best interest to do a good job. If the TLD as a >whole isn't well managed they lose business too. Third, your >concern, as I recall, stems with some experience you had with PBX >operators? It's not clear to me that the cases are that comparable. Not PBX, ISP, Internet service providers, the very people who are most likely to want to be registries. Many of them are nice people, but they do not have a lot of technical depth. I don't doubt that they'd want their domains to work, but given that they have a broad range of problems to deal with on a daily basis (broken modems, spammers, routing flaps, etc.) and would only do the domain database merge once in a blue moon, I just can't see where the expertise to make the merge work will come from. If they blow the merge, it's in practice a one shot embarassment, since it won't be their turn again for a long time. If they don't keep the modems working every day, it's money out of their pocket every day. This is really a scaling problem. If there were three or five registries, it's not hard to see how you could make it work, since the coordination problems would be moderate and the incentive to grow the skills to make the merge work every three or five days would be great. But if there were hundreds or thousands of registries, you have hundreds or thousands of potential failure points, each with only a limited incentive to make the investment to get it right. >Hmm, and it's also interesting to consider how DNS supermarkets like >"Domains R Us" might effect the economics of the situation. I think it's reasonable to assume that every ISP will sign up as a registry for every domain they can afford to. Alternatively, there may well be DNS wholesalers who resell registration services to ISPs, which would not be a bad thing. I'd expect that for popular domains like .COM it'd be worth it for ISPs to join directly, while they'd use the wholesaler for less popular domains. >> I need to go look at my TODS and see if there's been any real work on >> distributed databases with large numbers of databases kept in sync. > >Ah yes. How do we keep all the other registries up to date? Damn. >This is a hard problem. Isn't that what I've been saying all along? - -- John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com "Space aliens are stealing American jobs." - Stanford econ prof ---------------------------------------------------------------------- Date: 9 Aug 1996 22:32:17 -0700 From: Kent Crispin Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES Perry E. Metzger allegedly said: > Kent Crispin writes: > > > The way Bob talks, you'd think this was rocket science. There are > > > hundreds of thousands of travel agencies in the world all booking > > > tickets for the same flights. Somehow, the world hasn't collapsed. > > > > Perry, correct me if I am wrong, but I am under the impression that a > > particular airline does have essentially a central database for all > > its flights. I would like a STLD solution that doesn't require a > > central database. > > I don't think there is any good reason to avoid a central > database. First of all, network capable databases are cheap and well > understood. Second of all, any mechanism that doesn't require a > central database ends up giving us an N phase commit, where N is a > factor of the number of registries. Ugly. Possibly impossible. > > > It seems fairly straightforward if we have only a few registries > > and they maintain a replicated database. However, that puts the IANA > > in the position of denying an application to run a registry for a > > particular TLD on grounds that there would be "too many" registries, > > and that seems unpleasant. I suppose there could just be a hard > > limit, like 13. > > Very ugly. > > I'd prefer to allow any organization that can show that it is in a > position to indemnify the central organization and operate a registry > to operate a registry. Absolutely no question about that. > > But the interesting case is where the IANA allows anyone with an > > adequate technical setup to run a registry for a shared TLD -- where > > there are no hard upper limits on the number of registries, and market > > forces operate without imposed hard limits. > > Exactly. > > > It appears that the network traffic for coordination gets pretty > > imposing, > > Nearly impossible, without a central lock. > > With a central locking database, however, the problem is trivial and > well understood, especially for a stupid case like this where we are > talking about only tens of thousands of transactions per week. > > The central locking system doesn't have to be particularly fancy. A > pair of Pentiums sitting in a closet running BSDI and Postgres might > be able to handle the whole thing -- complete with redundancy. Of course, I agree that a centralized database essentially makes the problem trivial -- it's hard to argue with O(1). :-) But there are several reasons I have for worrying about a central database. First, I worry about it being a monopoly point. Someone will control that database, and that database will become crucial to the business of several registries -- perhaps, in the case of .com, thousands of registries. Obviously you would not want that database to be under the control of any single one of those registries. But who will control it? A second, related concern: It creates a complex wrinkle in the legalities of the situation. What are the legal obligations of the organization that runs the database? Third, I worry about how to support it. I agree with your estimate for the compute power needed. But you neglect the infrastructure surrounding it. It will need a little more protection than just sitting in a closet. You don't want some 15 year old kid hacking his way in, and you don't want some sophisticated programmer from one of the registries getting in either. You want good backups. In short, you want it sitting somewhere in a well-run data center, with people who know about security and data integrity and so on. Even though I could run it from my garage, no one would agree to that. Do you have any ideas on how to address these concerns? - -- Kent Crispin "No reason to get excited", kent@songbird.com,kc@llnl.gov the thief he kindly spoke... PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
