-> WG charter timeline by Michael Dillon -> Re: Lightweight vs. heavyweight registries by Michael Dillon -> Re: WG charter timeline by Kent Crispin -> Re: Lightweight vs. heavyweight registries by Kent Crispin -> Re: Lightweight vs. heavyweight registries by Kent Crispin -> Re: WG charter timeline by chris@kosh.punk.net (Christopher Ambler) -> Who is archiving the shared-tld list? by nreadwin@london.micrognosis.com (Neil Readwin) -> Re: WG charter timeline by Michael Dillon ---------------------------------------------------------------------- Date: 2 Aug 1996 00:36:47 -0700 From: Kent Crispin Subject: Re: Lightweight vs. heavyweight registries John R Levine allegedly said: > I've been pondering the ways that shared TLDs might work, and I see two > somewhat different ways that the responsibility might be parcelled out: > > The heavyweight registry model: > > There are a bunch of registries each of which holds a subset of the total > contents of the TLD. Via the magic of a distributed data base, these are > merged on the fly and loaded into the domain servers now and then. Each > registry is presumably a privately owned business. Unless there's been a > lot of progress in distributed databases that I haven't seen, this sounds > awfully tough to make work reliably. > > The lightweight registry model: > > There's one registry for the TLD, but it's a small and perhaps cooperatively > owned outfit, analogous to DSMI, the telco-owned registry that manages 800 > and 888 numbers. The registry has a moderate number of customers, each of > which can register domains for itself or third parties. Customers > communicate using a yet to be defined protocol (which need have nothing to do > with DNS protocols) to send updates to the registry's database, and have a > billing arrangement with the registry. The registry has all the info needed > to update the domain servers for the TLD. The customer-registry interactions > are quite formalized, with the idea that the customers are reasonably clueful > and can be expected to send in well-formed requests. > > Following the 800 model, third parties can switch from one customer to > another and take their domains with them. The financial arrangements are > between the third parties and the customers; all the registry does is to > accept a request from a new customer to take over an existing domain entry. > > Customers would typically be ISPs and various sorts of Net presence providers > who could offer domain registration by itself or more typically as part of > the package of services they provide. A single ISP or presence provider > would probably sign up as a customer of all of the shared TLDs so it could > provide one-stop service to its users. > > It seems to me that the existence of a lightweight registry solves all sorts > of data management problems, since it's a neutral party that can manage the > common database. There's still plenty of opportunity to make money here, > but it's moved one level out from the registry to the first level customers. > > One fairly critical assumption here is that anyone is allowed to grab any > available name, so the registry need only make a mechanical check for > duplication. This doesn't work so well for TLDs with some sort of > qualification (e.g., domains open only to registered trademark holders, for > people who believe in that) since it's not clear to me who the gatekeeper > would be. But I expect that in fact most domains will be open to anyone, so > this should work. You realize, of course, that the two alternatives you describe are just points in a design continuum, and not necessarily endpoints either. Also, the terminology you are using is different from what I have been using -- what you call the single "lightweight registry" for the domain I have been calling the "nameserver" for the domain. What you have been calling a "Customer" I have been calling a "registry". And what you call "third parties" I have been calling "Clients". However, "nameserver" is not a good term, IMO. I think we will be talking a great deal about these three roles, so good names will be handy. Let me propose that the role you call "light weight registry" be called a "coordinator"; that the entity you call a Customer we christian a "registry", and that we use the term "customer" or "client" to refer to members of the great unwashed multitude (or their legal surrogates) who seek to get their choice of domain name recognized by the internet. Your model, then, is that the "coordinator" is actually separate organizational entity that the registries contract with to keep things straight, and that the "coordination database" is actually not distributed, but rather centralized. Personally, I would prefer that the coordinator role be distributed. I don't think it will actually add any significant amount of "weight" to the operation of a shared registry, and it significantly simplifies the organizational situation if all the registries are indeed peers, and that peer relationship is enforced by the requirement to speak a certain database protocol. However, we can debate that as a separate issue -- I think that a large part of the operation of shared registries is really independent of that, and I would like to address the common part before we go off and debate :-) Consider: There are (at least) three databases involved, which may overlap. They are distinguished by their roles as much as by the data they contain: 1) The "nameserver database" -- the database that contains the (domainname,IP-addr) mapping. This database could actually be a DNS zone file, I guess, or some abstraction of it. In any case, this database contains the data that actually gets fed to the DNS nameservers. This database has weak time constraints -- it could be rebuilt or updated once a day, with the previous version serving as the source of DNS information until a fresh one was ready. Additions and deletions to DNS could be delayed by up to 24 hours, but that's no big deal. Thus there are no strong concurrency requirements on this database. 2) The "registry database" (which associates all the client/customer data with their domain). The registries maintain this as a partitioned database -- each registry only really cares about its own customers, after all. This database would also contain IP addresses. Maintenance of this database is a registry's local concern. There are no concurrency issues. 3) The "coordination database". In simplest form, this is just a database of all (subdomain_name,responsible_registry) pairs in use. This database could be maintained either as a centralized single database, with a client-server interface, or as a distribute replicated database, with a server at each registry. If it is distributed, then there are strong concurrency issues. However, it is an extremely simple and small database. Perhaps a hypothetical transaction will clarify my prose: Customer C walks into registry R, which services .com, and says "I have an IP address, and I want to register domain x.com". R collects C's data and a check, and reserves the name "x" in the coordination database (if the reservation fails, R tells C to pick another name, or refunds C's money). But thankfully for C, "x" is available. R spends some time trying to sell C their value-added services, and eventully C walks out, a slightly poorer but happy customer. That night R gets all the (domain,IPaddress) pairs out of his registry database that have changed, and mails them to all his cohort registries. The next morning he collects all the changes that his cohorts have sent to him, and generates an up-to-date nameserver database, which he loads into his nameserver. It is his turn to be the root nameserver for the domain, so he does a very careful job... Once a month all the cohorts do a full rebuild of the nameserver database by pooling the information from their registry databases. Notice that the only real use for the coordination database in this scenario is to act as a reservation system. The situation gets a little more complicated when you start worrying about things like a competitor cohort cheating by claiming a bunch of names, or how the IANA audits things to collect its fees ;-). Modulo that we will discuss at a later date how the coordination is done, is what I just wrote consistent with what you have been thinking? - -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... ---------------------------------------------------------------------- Date: 2 Aug 1996 01:09:39 -0700 From: shaw Subject: Re: .com Kent Crispin wrote: >Does anyone know more about the Harvard meeting, just out of >curiosity? > Here are the three key related conferences... 1. November 20, 1995 Conference: "Internet Names, Numbers, and Beyond: Issues in the Coordination, Privatization and Internationalization of the Internet" at: http://ksgwww.harvard.edu/iip/nsfforum.html 2. February 2, 1996 Conference: "Internet Administrative Infrastructure" at http://www.aldea.com:80/cix/agenda.html 3. Upcoming September 8-10, 1996 Conference: "Coordination and Administration of the Internet" at http://ksgwww.harvard.edu/iip/internet.html Robert ITU ---------------------------------------------------------------------- Date: 2 Aug 1996 07:27:34 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: Lightweight vs. heavyweight registries I said: >> It seems to me that the existence of a lightweight registry solves all sorts >> of data management problems, since it's a neutral party that can manage the >> common database. There's still plenty of opportunity to make money here, >> but it's moved one level out from the registry to the first level customers. [lots of sensible comments elided] > That night R gets all the (domain,IPaddress) pairs out of his > registry database that have changed, and mails them to all his > cohort registries. The next morning he collects all the changes > that his cohorts have sent to him, and generates an up-to-date > nameserver database, which he loads into his nameserver. It is > his turn to be the root nameserver for the domain, so he does a > very careful job... This is exactly the data management problem that I'm worried about. With all this mailing around, the changes for data skew are substantially higher than if there's one authoritative copy of the database. It may be wrong, but at least it's in one place so errors are easy to spot and correct. This also puts a considerably heavier responsibility on R than the lightweight registry model does. In the lightweight model, R needs only be able to communicate his updates to the lightweight registry/coordinator, while in this model R and all his peers have to be prepared to do a complete database merge. Given that the R's will be ISPs and the like, from what I've seen of the level of sophistication of most ISPs, this is a ticket to disaster. My ISP does an adequate job of providing bandwidth, but they can't even get their external routing right, and I cannot imagine them being up to the task of co-administering a registry. They have neither the expertise nor the time. The lightweight registry model does require that the centralized registry be trustworthy, but with an appropriate ownership model, that seems a lot easier to establish than to qualify all of the R's. ("Hey, all of the sites in .OINK disappeared!" "Yeah, it was Bogo-net's turn to do the update last night, they always screw it up. Try again tomorrow.") - -- 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: 2 Aug 1996 11:11:38 -0700 From: nreadwin@london.micrognosis.com (Neil Readwin) Subject: Re: Lightweight vs. heavyweight registries > The "coordination database". In simplest form, this is just a > database of all (subdomain_name,responsible_registry) pairs in use. It is not clear to me that this database has to exist. Let's consider an alternative transaction: Customer C walks into registry R and says "Here's some money, get foo.bar delegated to the host at IP address a.b.c.d" Registry R updates the "nameserver database" C and R part forever. This would move the concurrency problems to the registry and nameserver DBs (I'm not claiming that this is a good thing). An aside - if the coordination DB does exist then "whois" starts to look more like DNS itself - to find the contact info etc you would have to query the coordination DB to find the registry, just as you now query the root servers to find the NS for a second level domain. Is it desireable to have this data distributed? > Once a month all the cohorts do a full rebuild of the nameserver > database by pooling the information from their registry databases. I know this isn't fair, but this sounds a lot like "The incremental update scheme will obviously break, so here's a kludge to repair the damage from time to time." I think I have a better kludge :-) Since the DB will usually be small (a few megabytes or tens of megabytes) it shouldn't be that hard to generate a simple checksum of it and have the registries compare that after each incremental update (assuming they care whether they are right, that is). Neil. ---------------------------------------------------------------------- Date: 2 Aug 1996 11:28:07 -0700 From: nreadwin@london.micrognosis.com (Neil Readwin) Subject: Re: Charter > it is especially important that there be mechanisms in place to prevent > cheating, pre-claiming desirable names, and so on. Anyone else can still pre-claim names by paying the registries to do it for them, so why shouldn't the registries be allowed to do it too :-) The registries only have an advantage over random end-users at the moment the TLD is first opened, and my feeling is that it actually won't be that big a deal. Anyone know about precedents wrt phone numbers? The same problem should occur with any new area code (some numbers are better than others, right?), not just 888 etc. Neil. ---------------------------------------------------------------------- Date: 2 Aug 1996 15:39:55 -0700 From: Kent Crispin Subject: Re: Lightweight vs. heavyweight registries John R Levine allegedly said: > [snip] > > > That night R gets all the (domain,IPaddress) pairs out of his > > registry database that have changed, and mails them to all his > > cohort registries. The next morning he collects all the changes > > that his cohorts have sent to him, and generates an up-to-date > > nameserver database, which he loads into his nameserver. It is > > his turn to be the root nameserver for the domain, so he does a > > very careful job... > > This is exactly the data management problem that I'm worried about. With > all this mailing around, the changes for data skew are substantially higher > than if there's one authoritative copy of the database. It may be wrong, but > at least it's in one place so errors are easy to spot and correct. Hmm -- I actually have been thinking of this part of the problem as completely straightforward and rather simple, because there are no real time constraints. > This also puts a considerably heavier responsibility on R than the > lightweight registry model does. In the lightweight model, R needs only be > able to communicate his updates to the lightweight registry/coordinator, > while in this model R and all his peers have to be prepared to do a complete > database merge. Given that the R's will be ISPs and the like, from what > I've seen of the level of sophistication of most ISPs, this is a ticket to > disaster. My ISP does an adequate job of providing bandwidth, but they > can't even get their external routing right, and I cannot imagine them being > up to the task of co-administering a registry. They have neither the > expertise nor the time. Let's suppose, for discussion purposes, that responsibility for supplying an accurate zone file is rotated around the cohorts (say once a month), and that once a night all the cohorts mail their zone file updates to the designated maintainer of the month. They use a stylized format, of course, and it is in their best interest to both be very accurate, and to ensure that their updates reach the designee, perhaps requiring return receipt of some sort. The designee waits until all the update deadline has arrived, then runs a perl script to merge in the updates. This doesn't have to be a perl script written by them -- it would be part of the STLD package. The result of the run is a correct zone file. If an update file is damaged or incorrect in some way, the updates for that registry don't get done, a mail message is sent back to the registry, etc. This all seems extremely simple and low tech to me, and a turnaround time of 24 hours on getting a domain name installed would be a *lot* better than what we have now. Absolute consistency and so on doesn't seem critical here -- things can be fixed in the next days run, and all the competing registries will be able to check the results and verify that "bogo-net" didn't screw up. > The lightweight registry model does require that the centralized registry be > trustworthy, but with an appropriate ownership model, that seems a lot > easier to establish than to qualify all of the R's. ("Hey, all of the sites > in .OINK disappeared!" "Yeah, it was Bogo-net's turn to do the update last > night, they always screw it up. Try again tomorrow.") This is the good part about competition -- if Bogo-net was incompetent, then presumabley they won't remain in the business for long. :-) About the "centralized registry" vs other models -- any part of the operation of STLD registries could be subcontracted in various ways -- actual TLD DNS nameservers, for example could be totally separate from