---------------------------------------------------------------------- Date: 10 Aug 1996 07:06:23 -0700 From: "David R. Conrad" Subject: Re: Coordination protocols (was Lightweight vs. heavyweight registries) Hi, >> The owner of D could be the person who gets the domain name and then >> sells access to the server. > >"The owner of D..." is exactly what we are trying to get away from >with shared TLDs. The owner of D is effectively the owner of the TLD, >and has a monopoly. I see your point, however I would note that there already is a monopoly inherent in the system, namely the root. One solution would be that the IANA runs D or delegates it out as is done with the root nameservers. >I contend that >unless we solve the distributed coordination problem we are not >solving *the* problem. Well, we're not solving *a* problem -- I'm not a distributed DB kind-of-guy, but it looks to me like this would be a *really* hard problem to solve on a global network (if it was easy, everybody would be doing it). The problem I'm looking to solve is the removal of monopoly status by the organizations which are providing the DNS registry services -- a mail server or lightweight registry solves this problem as long as the organization running the lightweight registry/mail server isn't involved in doing the actual delegations. >Right -- it's essentially a cost-free monopoly, Not quite cost free, gotta pay for the hardware and a person to babysit. >The IANA could put language in the license that >requires costs to be equally shared. But writing language like that >into the license would be, IMO, a legal nightmare for the IANA. You can look at the operation of a lightweight registry/mail server as a public service paid for via a "tax" instituted by the IANA on the organizations running the delegation registries (who would, in turn pass that cost on to their customers as part of the overhead). Regards, - -drc ---------------------------------------------------------------------- Date: 10 Aug 1996 08:55:35 -0700 From: Kent Crispin Subject: Re: Coordination protocols (was Lightweight vs. heavyweight registries) David R. Conrad allegedly said: > > Hi, > > >> The owner of D could be the person who gets the domain name and then > >> sells access to the server. > > > >"The owner of D..." is exactly what we are trying to get away from > >with shared TLDs. The owner of D is effectively the owner of the TLD, > >and has a monopoly. > > I see your point, however I would note that there already is a > monopoly inherent in the system, namely the root. Good point :-) > One solution would > be that the IANA runs D or delegates it out as is done with the root > nameservers. > > >I contend that > >unless we solve the distributed coordination problem we are not > >solving *the* problem. > > Well, we're not solving *a* problem -- I'm not a distributed DB > kind-of-guy, but it looks to me like this would be a *really* hard > problem to solve on a global network (if it was easy, everybody would > be doing it). I'm not a distributed DB kind-of-guy either -- it probably shows :-). But I am not yet totally convinced that there isn't a reasonable distributed solution. There are some unique characteristics to problem that might make it tractable -- in particular, the fact that collisions should be almost totally non-existent -- what are the odds that two separate parties are asking for exactly the same domain name at exactly the same time? You could, for example, just forget coordination altogether, assign the domain name, and eventually get back an error from DNS itself saying the name had been assigned already. Use a timestamp to resolve such conflicts, with the caveat that any name that has been in DNS for a week takes precedence, regardless of the date of initial registration. Introduce a week's delay between initial registration and finalization of the deal. What do you think of such a scheme? > The problem I'm looking to solve is the removal of monopoly status by > the organizations which are providing the DNS registry services -- a > mail server or lightweight registry solves this problem as long as the > organization running the lightweight registry/mail server isn't > involved in doing the actual delegations. Another good point. > >Right -- it's essentially a cost-free monopoly, > > Not quite cost free, gotta pay for the hardware and a person to > babysit. > > >The IANA could put language in the license that > >requires costs to be equally shared. But writing language like that > >into the license would be, IMO, a legal nightmare for the IANA. > > You can look at the operation of a lightweight registry/mail server as > a public service paid for via a "tax" instituted by the IANA on the > organizations running the delegation registries (who would, in turn > pass that cost on to their customers as part of the overhead). Your proposal is quite reasonable, IMHO. It would fit in with a reasonable fee structure of say $2500 for initial delegation of a registry, and $400/year thereafter -- this would probably be an adequate funding stream to maintain the LWRs and the IANA -- in the case of a big TLD like .com, significant revenue would be generated without requiring any kind of tax on lower level domain names. If the LWRs are run by a centralized entity they become a much bigger deal, because the centralized entity then essentially maintains a database for *all* domain names. Such a database could become very large. It also has a considerable overlap with the DNS database. In fact, the DNS database could be used -- the only thing missing is a backpointer to the original registry (which presumably would keep the contact information etc). While I stubbornly continue to hope for a distributed solution, I am honestly very encouraged that people are coming up with reasonable schemes for managing LWRs in a way that addresses my monopoly concerns. I think it would be good if there was more discussion on these lines. - -- 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 ---------------------------------------------------------------------- Date: 10 Aug 1996 10:20:33 -0700 From: Dan Busarow Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES On Fri, 9 Aug 1996, Kent Crispin wrote: > 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? The new incarnation of IANA. I believe consensus has been reached that IANA be reorganized as either a Swiss corporation or an agency of the ITU. Their only interest is to see that the global name space remains pure. The fees payed by registries support the database and related infrastructure. This database would be used to build the zone files for all shared TLDs, not just one. The sTLD name servers would be required to load their zone data from this database. Bypassing the system would result in the sTLD as a whole or the rogue name server(s) being removed from the roots. It leaves IANA-NG in a monopoly of sorts, much like the benevolent dictatorship of today, but it is a monopoly with a vested interest in assuring fair service to all comers. They are its revenue stream. As long as there is legal protection for the database operators then the problem is reduced to a fairly trivial database system like the airline reservation system. Dan - -- Dan Busarow 714 443 4172 DPC Systems dan@dpcsys.com Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82 ---------------------------------------------------------------------- Date: 10 Aug 1996 11:49:52 -0700 From: Kent Crispin Subject: Re: business model for shared tlds John R Levine allegedly said: > > 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. I don't see a great deal of human intervention in the merge -- I would expect the whole process to be done automatically. Human intervention is really only necessary when there are decisions to be made, and I don't see any discretionary behavior anywhere. Given a reasonable initial configuration, and the normal skills necessary to keep a machine running, the database activity would be completely behind the scenes. > >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. In fact, I'm not sure I think having every ISP be a registry for every domain would be a good thing at all -- a good reason to make the cost of entry fairly high -- I have been thinking in terms of $2500 entry fee, and $1000/year thereafter. That would keep all but very large ISPs from being registries for every TLD under the sun. At $1000/year, and $50/registration, you would only need 20 registrations to recover the fee for any domain, but only a very large operation could afford to be a registrar for 100 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? Yes, I guess you have. I've never thought it would be easy, but I keep hoping that a reasonable solution will come up. As I said in another post, the problem domain is actually rather special, and, while it is clear that standard database methods apply, they have more general constraints. In particular (to repeat myself) close-call collisions should actually be exceedingly rare. For the most part, a DNS query will tell you if a name is already taken. Even in a busy domain, there would only be a few cases per year where effectively simultaneous requests for exactly the same name would come in. Earlier on I mentioned that the coordination database and the DNS database overlap a lot. DNS could actually be used as the coordination database, if there was a field that referred back to the initiating registry. Of course, if the DNS database itself is distributed, the problem will already have been solved :-) - -- 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 ---------------------------------------------------------------------- Date: 10 Aug 1996 13:32:19 -0700 From: perry@piermont.com Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES Kent Crispin writes: > 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? I would suggest an industry organization or the ISOC as logical choices. By very tightly constructing the legal agreements that create the central point and define its relationship to the competing registries, one can avoid the problem of the unexpected showing up later on. > 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? I would say that it should be contractually obliged to operate the shared lock, and very little else. The smaller it is, the better. > 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. Presumably, a very small amount of money could be raised by fees collected from the registries in order to run the thing. The "right thing" is to contract out the system to a UUNet or BBN or something similar. The contracts would need to be set up to assure that very little money (a few tens of thousands at most) is spent a year on the central systems. Perry ---------------------------------------------------------------------- Date: 10 Aug 1996 14:03:02 -0700 From: perry@piermont.com Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES Dan Busarow writes: > The new incarnation of IANA. I believe consensus has been reached that > IANA be reorganized as either a Swiss corporation or an agency of the ITU. > Their only interest is to see that the global name space remains pure. Really? From whom was there a consensus of that sort? Understand, I think that maybe having the ISOC be a swiss nonprofit might be useful, but I saw no consensus on that or anything else similar. Perry ---------------------------------------------------------------------- Date: 10 Aug 1996 14:08:41 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: business model for shared tlds >I don't see a great deal of human intervention in the merge -- I >would expect the whole process to be done automatically. Human >intervention is really only necessary when there are decisions to be >made, and I don't see any discretionary behavior anywhere. What do you do when two registries give you conflicting data for the same domain? When the data from a registry has a syntax error? (Do you throw out the bad record, the entire domain with the syntax error, try and fix it, something else?) When the data from a registry is missing? (Leave it out, use yesterday's version, something else?) Again, it's the scaling problem. If there were three registries, you could fix any problems with a phone call or two. With a thousand registries, the chances of a few of them sending you bogus data is very high, and the chances of finding the appropriate people and working things out quickly considerably less. >In fact, I'm not sure I think having every ISP be a registry for every >domain would be a good thing at all -- a good reason to make the cost >of entry fairly high -- I have been thinking in terms of $2500 entry >fee, and $1000/year thereafter. That would keep all but very large >ISPs from being registries for every TLD under the sun. Indeed. Instead of having 10,000 registries, you'll only have 1,000 but that's still far too many to play round robin. I think even 25 would be a problem. >> >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? > >Yes, I guess you have. I've never thought it would be easy, but I >keep hoping that a reasonable solution will come up. Me too. Still thinking. - -- 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: 10 Aug 1996 14:11:46 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: Coordination protocols (was Lightweight vs. heavyweight registries) >[re name collisions] -- what are the odds >that two separate parties are asking for exactly the same domain name >at exactly the same time? You could, for example, just forget >coordination altogether, assign the domain name, and eventually get >back an error from DNS itself saying the name had been assigned >already. Use a timestamp to resolve such conflicts, with the caveat >that any name that has been in DNS for a week takes precedence, >regardless of the date of initial registration. Introduce a week's >delay between initial registration and finalization of the deal. > >What do you think of such a scheme? What do you do when a customer wants to move his registration from one registry to another? >If the LWRs are run by a centralized entity they become a much bigger >deal, because the centralized entity then essentially maintains a >database for *all* domain names. Such a database could become very >large. It also has a considerable overlap with the DNS database. In >fact, the DNS database could be used ... You could certainly keep a backpointer in a DNS comment, but you'd also want whois info and possibly some billing stuff. This isn't a hard database problem (at least the non-distributed version isn't) but it does need some thought and a real database. >While I stubbornly continue to hope for a distributed solution, I am >honestly very encouraged that people are coming up with reasonable >schemes for managing LWRs in a way that addresses my monopoly >concerns. I think it would be good if there was more discussion on >these lines. Agreed. - -- 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
