---------------------------------------------------------------------- Date: 7 Aug 1996 03:00:41 -0700 From: "David R. Conrad" Subject: Re: Coordination protocols (was Lightweight vs. heavyweight registries) Hi, > R D > 220 D Ready. > HELLO R > 250 Welcome, R. > REQUEST x.com > 550 x.com is taken > or > 250 ok, reserved for 10 minutes > DATA > 350 send data > > . > 250 data accepted, x.com is yours > BYE > 250 Nice talking to you, R. Why not simply use PGP signed email instead of coming up with an entirely new protocol? The perl script at the server end simply takes requests FCFS, does verification gunk, checks the name if it is taken and if not takes the verified data and dumps it into a registration database and generates the appropriate zone file. If the server is down, client enqueues. To simplify key handling a bit, the DNS registrars are the only ones allowed to submit to D. No mess, no bother. Just an application form and a single small(?) perl script to write. Could even steal the InterNIC form since people are used to it... The owner of D could be the person who gets the domain name and then sells access to the server. In the case of contention over a domain name, operation of the domain could be handled by a group of Rs where each of the Rs could pay a fixed percentage of the cost of D's operation. D would be operated by a neutral third party, preferably someone everybody trusts (sort of like how the CIX is operating the CIX router -- I'm sure Vixie Enterprises would be happy to help :-)). In both cases, the actual function of DNS registration as performed by D becomes a complete no brainer. The Rs which are providing the actual registration service and would likely need to compete on something else to make any money at all, perhaps hand holding, offering Internet services, etc. Note that in the second case, the larger number of Rs, the smaller the amount of money each R would pay for the operation of D. In the first case, the more Rs D gets, the more money (at no additional work). What a deal... :-) Regards, - -drc ---------------------------------------------------------------------- Date: 7 Aug 1996 09:36:01 -0700 From: Kent Crispin Subject: Re: Coordination protocols (was Lightweight vs. heavyweight registries) David R. Conrad allegedly said: > > Hi, > > > R D > > 220 D Ready. > > HELLO R > > 250 Welcome, R. > > REQUEST x.com > > 550 x.com is taken > > or > > 250 ok, reserved for 10 minutes > > DATA > > 350 send data > > > > . > > 250 data accepted, x.com is yours > > BYE > > 250 Nice talking to you, R. > > Why not simply use PGP signed email instead of coming up with an > entirely new protocol? The perl script at the server end simply takes > requests FCFS, does verification gunk, checks the name if it is taken > and if not takes the verified data and dumps it into a registration > database and generates the appropriate zone file. If the server is > down, client enqueues. To simplify key handling a bit, the DNS > registrars are the only ones allowed to submit to D. > > No mess, no bother. Just an application form and a single small(?) > perl script to write. Could even steal the InterNIC form since people > are used to it... While I appreciate the simplicity of both proposals, I am worried about how they generalize to a case where we have a distributed database that handles coordination between registries. > 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. While I agree it is a possibility that a group of registries could contract out management of a coordination database to a third party, this arrangement certainly should not be codified as part of the sTLD protocol. It is true, even obvious, that it would require very little effort to implement a prototype shared registry that used a light-weight registry for coordination, I contend that unless we solve the distributed coordination problem we are not solving *the* problem. > In the case of contention over a domain name, operation of the domain > could be handled by a group of Rs where each of the Rs could pay a > fixed percentage of the cost of D's operation. D would be operated by > a neutral third party, preferably someone everybody trusts (sort of > like how the CIX is operating the CIX router -- I'm sure Vixie > Enterprises would be happy to help :-)). > > In both cases, the actual function of DNS registration as performed by > D becomes a complete no brainer. The Rs which are providing the > actual registration service and would likely need to compete on > something else to make any money at all, perhaps hand holding, > offering Internet services, etc. Note that in the second case, the > larger number of Rs, the smaller the amount of money each R would pay > for the operation of D. In the first case, the more Rs D gets, the > more money (at no additional work). What a deal... :-) Right -- it's essentially a cost-free monopoly, much worse than the InterNIC (the InterNIC at least has the excuse that it is doing the grunt work of dealing with human customers). Here's another scenario to consider: suppose 5 registries serve a particular TLD, and they use a centralized coordination database that they collectively own. However, all 5 of the registries are poorly run, so a sixth registry wants to enter the business. It applies to IANA and is granted a license to serve the TLD. The gang of 5 say "tough banans, guy. We're not going to let you use our coordination database unless you pay us $100000000." Perhaps, you think, the IANA could make it a condition of licensing that coordination data must be freely sharable. In that case, the 5 would have to allow "6" free access to their database, which would not be fair to them. 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. If, on the other hand, a protocol and reference implementation for a shared coordination database existed, then none of this is an issue. The IANA license would contain language that the registries must share coordination data via to the "sTLD protocol" with any other licensee, and that's the end of it. At a different level of abstraction, I believe that anywhere there is a centralization from a technical point of view there is a possibility for a monopoly from an economic point of view. Thus my constant carping on a fully distributed solution. - -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... kc@llnl.gov ---------------------------------------------------------------------- Date: 7 Aug 1996 18:24:59 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: business model for shared tlds >> I'm still trying to think of a workable solution other than a jointly owned >> per-TLD central database. > >For .com some fairly high powered solution would be necessary. Agreed, and this would lock all but the largest ISPs and the like out of registering people in .COM. I'd be happier if things came out a little more democratic. >...Using the same stupid algorithm for a much larger TLD, with an >aggregate transaction rate of 1000/day, with 100 registries handling >10 applications/day, there would be 100,000 coordination messages >(each of the 1000 applications requires a reservation being sent to >each of the 100 registries), and about 10,000 incremental zone >transfers/day. This is, in my opinion, too much traffic, and >something a little more clever than an n^2 algorithm would have to be >devised. But that's not a big deal -- slightly more intelligent >software could surely get this down to n*log(n), and perhaps maybe >even be linear. With a centralized server the traffic is linear. I think you might get N log N with a "notify your neighbors" scheme that ripples around, but I'm not up to analying the performance and reliability of a scheme like that. - -- 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: 7 Aug 1996 23:04:14 -0700 From: Kent Crispin Subject: Re: business model for shared tlds John R Levine allegedly said: > >For .com some fairly high powered solution would be necessary. > > Agreed, and this would lock all but the largest ISPs and the like out of > registering people in .COM. I'd be happier if things came out a little more > democratic. So would I, for sure. I hope we don't get down to a "fair, efficient, reliable, pick two" tradeoff. > > >...Using the same stupid algorithm for a much larger TLD, with an > >aggregate transaction rate of 1000/day, with 100 registries handling > >10 applications/day, there would be 100,000 coordination messages > >(each of the 1000 applications requires a reservation being sent to > >each of the 100 registries), and about 10,000 incremental zone > >transfers/day. This is, in my opinion, too much traffic, and > >something a little more clever than an n^2 algorithm would have to be > >devised. But that's not a big deal -- slightly more intelligent > >software could surely get this down to n*log(n), and perhaps maybe > >even be linear. > > With a centralized server the traffic is linear. Actually, its O(1) :-) -- each registration takes a small constant number of messages no matter how many registries there are...an Order 1 algorithm is hard to argue with... > I think you might get N > log N with a "notify your neighbors" scheme that ripples around, but I'm not > up to analying the performance and reliability of a scheme like that. There is no doubt in my mind that no distributed algorithm is going to compete with a centralized one for efficiency or reliability. The only problem is fairness. So what would really be nice is if we could work out some way of getting the efficiency and reliability of the light-weight registry, without sacrificing fairness. One way (not too good, but work with me here :-)) to get fairness would be to have the database rotate from registry to registry on a regular basis. Say once a day, or once a week. The minimum entry for the coordination database is the domainname and an index for which registry serves it. An incredibly successful TLD might have on the order of a million subdomains. Such a database should compress down to a few megabytes. At T1 speeds it would be practical to ship the entire database once a day. But this is soooooooooooo ugly. But of course, it would be nuts to ship the whole database around -- only updates would be necessary, if the database was replicated. If we assume a replicated database the problem gets a whole lot easier. Here's an algorithm, which I will dub the "rotating lightweight registry" algorithm: The registries are numbered 1 to N. Each registry keeps a copy of the registration database. Each day the "master" number is incremented mod N, so, for example, on day 5 registry number 5 is the coordination master. All coordination protocol messages go to the master, which functions as a light-weight registry. When the day ends the master sends a database update package to all the other registries, and then passes the torch to the next registry. Since the selection of master is just a function of the date, there is never any doubt who the master is. I think this scheme meets all the criteria of fairness, efficiency, and reliability. Of course, the registries could decide to let one of their members remain master indefinitely. The fairness requirement only comes in, I think, when a new registry appears on the scene: The new registry has to be prepared to be the lightweight master, and conversely, the old registries have to be prepared to at any time allow a new registry to act as a master. Assuming that the IANA licenses registries for particular TLDs, it was my earlier contention that the license should be constructed in such a way that it is as much a contract between the cohort registries as it is a contract with IANA -- when you sign it, you agree that you will deal with your cohort registries in particular ways, and that they can sue you for breach of contract if you fail to live up to the requirements. With such a legal framework the relationships between the registries become self-enforcing. The IANA never gets into enforcement at all - -- the registries compete against each other, or cooperate, as they see fit. They are required to deal with a newly licensed cohort in the manner prescribed by the license, but it is up to the new licensee to enforce those provisions of the license whatever legal methods seem appropriate. Well, I have certainly blathered on long enough...time to stop. - -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... kc@llnl.gov 5A 16 DA 04 31 33 40 1E 87 DA 29 02 97 A3 46 2F
