-> Centralized or decentralized Whois server ? by huitema@bellcore.com (Christian Huitema) -> Re: New Non-Shared TLD's Create More Monopolies by johnl@iecc.com (John R Levine) -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: Mandated shared registries by Matthew James Marnell -> [ADMIN] Test by Simon Higgs -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: Centralized or decentralized Whois server ? by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Michael Dillon -> Re: New Non-Shared TLD's Create More Monopolies by Michael Dillon -> Re: Centralized or decentralized Whois server ? by Michael Dillon -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies by johnl@iecc.com (John R Levine) -> Re: New Non-Shared TLD's Create More Monopolies by Michael Dillon -> Re: New Non-Shared TLD's Create More Monopolies by Keith Winstein -> Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin -> Re: New Non-Shared TLD's Create More Monopolies by Kent Crispin ---------------------------------------------------------------------- Date: 20 Aug 1996 03:29:01 -0700 From: Alan Barrett Subject: Re: New Non-Shared TLD's Create More Monopolies Randy Conrad said: > Thanks for the clarification. I'm interested in getting up and > running as fast and reliably as possible, thus I was assuming that the > CDB (which is what I guess we're calling it) would not do any of the > checking to see if the nameservers were up. My previous message essentially argued for a separation between "reserve the name" and "register all the details" at the customer/registry interface. That in turn requires a similar separation at the registry/CDB interface. We probably do not want the CDB to do any checking to see if nameservers are up, but I would almost certainly want the registries to do such checking. > The scenario I envisioned was: > > 1) person chooses name > 2) person goes to registry to request name, providing registration data > 3) registry requests name > 4) if name exists, goto step 1 > 5) CDB allocates name with registration data at registry and builds zone file > 6) person pays registry > 7) person sets up DNS service > 8) zone file distributed to appropriate servers > > Is adding the state, timers, and server complexity valuable enough to > warrant the addition of the NS checking code (no opinion, just > asking)? I don't think we need NS checking code in the CDB. I do think we need the separation between "reserve" and "commit". I often see collisions where two or more parties try to register the same name nearly simultaneously. In too many such cases, the losers neglect to clean up the zones that they had set up prior to the registration attempt. We should design a new system that does not have that failure mode. - --apb (Alan Barrett) ---------------------------------------------------------------------- Date: 20 Aug 1996 05:55:40 -0700 From: perry@piermont.com Subject: Re: New Non-Shared TLD's Create More Monopolies Kent Crispin writes: > Nope. I'm suggesting a perl script that runs rwhois, gets the data, > and inserts all of it into a local whois database. Having built crap like that before, I'll tell you that one's life is always much, much happier when you have a real database. Perl hacks from text taken off the net are for when you have no choice. > I can accept (though grudgingly) that a centralized database for > synchronization is small enough and simple enough that it is unlikely > to become a serious problem. However, when this central database > also becomes the authoritative repository for all the contact > information I begin to worry. I don't understand this worry. It doesn't prevent you from storing the data elsewhere, nor does it give the central DB any advantage if it is under a contractual obligation about what it can and can't do. The central DB is NOT some mammoth organization. Its maybe Bill Manning's summer intern and a couple of donated machines sitting in a couple of machine rooms across the country from each other. Relax. Perry ---------------------------------------------------------------------- Date: 20 Aug 1996 06:12:02 -0700 From: perry@piermont.com Subject: Re: New Non-Shared TLD's Create More Monopolies Kent Crispin writes: > > > A 25 line perl script that takes about 30 minutes to write will > > > handle this quite easily. > > > > Not very well, I'd say. > > It doesn't have to be perfect. I'm afraid it does. The amount of time and effort involved when things fuck up is giant, and is what will end up costing everyone the most time and money. Doing it right is cheaper than doing a silly hack. > The only time this kind of interface would be used is when a user > changes registries. That is going to involve a certain amount of > human interaction and checking no matter what -- you wouldn't want > me calling up your registry and switching your domain to a registry > in Timbuktu. Thats what public keys are for. If you involve humans, the process will be *less* reliable, especially if the way you get contact information is over unauthenticated "whois" queries augmented by perl scripts. I don't want any humans involved in the central DB at all, if possible. The CDB gets called when one of the registries notices that there is a technical problem, or when someone wants to become a registry. Humans cost money, introduce error, and make you a better target for lawsuits. > Most important is the distribution of the *authority* for the data. > The registries should have (IMHO) the authoritative data for their > customers. The distributed character of the data follows from this > principle. What does 'authoritative' mean? The only 'authoritative' information is the information sitting in the DNS, since its the only stuff that matters in the last analysis. You can call anyone's copy of the database 'authoritative' for laughs, but that doesn't matter -- what matters is what gets cut to produce DNS entries. > Contracts can be developed that will avoid that, you're right. > > But then, contracts with whom? With the registries? With the IANA? Presumably both and more. > I can certainly see how contracts could be devised that would work > for a while. But NSI has a contract with NFS, does it not? A cooperative agreement, and nothing in it forbids the current behavior. > People need DNS to be reliable, but it is designed to work very well > with non instant updates. And the reliability constraints on > registries are of a totally different magnitude. A turnaround time of > a week is more than adequate. Nope, it isn't. Something fucks up your primary DNS entries, you need it fixed NOW. The InterNIC already takes too long on this. > > There is no reason not to have the CDB placed on a replicated database > > system such that even if one of the cities with one of the CDB > > machines was nuked the whole thing didn't continue just fine, but > > there is good reason not to operate without a centralized database. > > Hmm. Your last clause means "there is good reason to operate a > centralized database". The only good reason I've seen so far is to > support a reservation protocol on names, No. You need something to cut the masters that generate the DNS. You also want a central database containing authorization information on who can and can't switch a zone from one registry to another. Let me be blunt. I wouldn't run a company DNS with 500 entries without a real DBMS any longer. I certainly am not going to support some ad hoc crap to run the global DNS. We want a real DBMS. Its cheap, its efficient, and I don't see why we shouldn't take advantage of the technology. It is very different to run a pair of machines sitting in closets than it is to run an InterNIC. We aren't talking a big operation. I will not, however, support running stuff with perl scripts, masking tape and chewing gum, either. That takes more work, not less, and its more dangerous, not less dangerous. Perry ---------------------------------------------------------------------- Date: 20 Aug 1996 06:58:05 -0700 From: huitema@bellcore.com (Christian Huitema) Subject: Centralized or decentralized Whois server ? The whois service is very important -- how could we run any registration service if we did not have a way to find out precisely who registered what? Thus, I certainly understand why we should make sure that the information is available, and remains available even if one registry vanishes in a puff of smoke. Archiving everything in one mammoth database is one way to solve the problem. However, that solution has drawbacks. It creates a central focal point, which is arguably suboptimal in terms of performances, reliability and also distribution of control. However, there are alternatives, notably if we were to promote the "whois++" solution. Its use of centroids enables "navigation without hierarchy", so that requests will be automatically directed to whatever server holds the information. Then, we would have to solve the puff of smoke problem. What about an escrow database ? - -- Christian Huitema ---------------------------------------------------------------------- Date: 20 Aug 1996 07:59:32 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: New Non-Shared TLD's Create More Monopolies >If the CDB contains all the authoritative data, then it is a very >short step to a direct email interface, bypassing registries. >Contracts can be developed that will avoid that, you're right. No, wait, it's a very big step, because that step involves money. I'm working under the assumption that registries have a contract with the CDB, so they can use a straightforward billing scheme (so much per domain per month, so much per transaction, something like that.) One of the things that makes the Internic so unwieldy is that they have a million separate customers. Shared registries spread this out somewhat. >Hmm. Your last clause means "there is good reason to operate a >centralized database". The only good reason I've seen so far is to >support a reservation protocol on names, and for that you only need >the names. And even there, the "lazy propagation" character of DNS >makes me think that locking methods using DNS itself might be sufficient. Sigh. You'd almost think there wasn't a long exchange of messages on this topic only a week ago. The other reason to have a CDB is to force the data to be syntactically correct and consistent. (It may not all be semantically correct, but at least it'll be in one place so that corrections can be applied.) The only alternative I've seen proposed is some sort of big daily merge of all the registries' separate data, and I think at the time we agreed that it was unlikely that you'd be able to merge several hundred or thousand sets of data without running into some consistency errors, requiring in effect some central authority to sort it out anyway. - -- 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: 20 Aug 1996 08:30:12 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies David R. Conrad allegedly said: > > Alan, > > >Now, if several near-simultaneous attempts are made to reserve the name, > >only one will succeed, and the losers know that they have lost *before* they > >start setting up the nameservers. So the losers have no work that needs to > >be undone. > > Thanks for the clarification. I'm interested in getting up and > running as fast and reliably as possible, thus I was assuming that the > CDB (which is what I guess we're calling it) would not do any of the > checking to see if the nameservers were up. As such, the race > condition wouldn't exist. The scenario I envisioned was: All that is necessary to implement reservations is the following simple mods to your algorithm: > 1) person chooses name > 2) person goes to registry to request name, providing registration data > 3) registry requests name > 4) if name exists, 4a) and timestamp is current > , goto step 1 > 5) CDB allocates name with timestamp and registry id > 6) person pays registry 6a) registry sends confirm. if name is there with right regid build registration data at registry and build zone file else return "time expired" > 7) person sets up DNS service > 8) zone file distributed to appropriate servers > > Is adding the state, timers, and server complexity valuable enough to > warrant the addition of the NS checking code (no opinion, just > asking)? It really just rearranges the steps slightly, and adds a timestamp to the database. Very little extra work or code or state information is involved. A mere 10 more minutes of perl hacking :-) > Of course, the race condition can also be "avoided" by just saying, > "sorry, name taken, remove the gunk from the primaries and > secondaries", but I'd agree this would be annoying. - -- 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: 20 Aug 1996 08:45:50 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies David R. Conrad allegedly said: > > >In other words we define an HTML form that uses POST > >transactions and we define the behavior of the backend CGI script that > >handles it. > > There are many places in the world that could concievably want to be > registries under this scheme that have no hope of using the WWW (e.g., > they're on the end of a UUCP line). Yes -- the cannonical "registry on Pitcairn Island". Not being facetious, really, there are many parts of the world where the net infrastructure is very poor, but I don't want to name them for fear of offending anyone. Pitcairn Island just serves as a useful symbol. I certainly have no objection to defining an HTML interface. But (IMO) a direct protocol is necessary, whereas an HTML interface is a nice nicety. - -- 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: 20 Aug 1996 09:17:28 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Michael Dillon allegedly said: > > On Tue, 20 Aug 1996, David R. Conrad wrote: > > > >In other words we define an HTML form that uses POST > > >transactions and we define the behavior of the backend CGI script that > > >handles it. > > > > There are many places in the world that could concievably want to be > > registries under this scheme that have no hope of using the WWW (e.g., > > they're on the end of a UUCP line). > > Once we have defined the fields used for a CGI POST transaction there is > no reason why alternative interfaces cannot be devised. Cart before Horse. - -- 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: 20 Aug 1996 09:17:33 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Simon Higgs allegedly said: > > At 9:43 PM -0700 8/19/96, Kent Crispin wrote: > > >I can accept (though grudgingly) that a centralized database for > >synchronization is small enough and simple enough that it is unlikely > >to become a serious problem. However, when this central database > >also becomes the authoritative repository for all the contact > >information I begin to worry. > > > > This is an issue for later on (transaction scalability), but don't forget > Bob Frank's FOI request for the InterNIC database. There are numerous > third-party uses for the information outside the snail-mail spamming like > CRL and others do. Trademark searches are going to be done in any whois > created. That includes both the matches for addresses as well as domain and > organizational names. Several companies already tie up NSI's whois with > bulk searches. Should these searches tie up each registry's whois or be > assigned to a mirrored master whois database (or just be downloaded via > ftp)? Or should they be allowed at all? Privacy issues are another argument for distribution, as far as I am concerned. - -- 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: 20 Aug 1996 09:48:25 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Michael Dillon allegedly said: > > On Mon, 19 Aug 1996, Kent Crispin wrote: > > > > If you are suggesting that we build a pseudo-database interface on top of > > > a text interface then I strongly disagree. > > > > Nope. I'm suggesting a perl script that runs rwhois, gets the data, > > and inserts all of it into a local whois database. > > Yuck! You could write it in C++, or perhaps have a CGI interface, if you like :-) > > That would be nice, but I don't it is necessary for shared-tld to > > mandate that particular change. The whois format is the current > > standard, apparently moving to rwhois, and, as Perry says, we should > > only change one thing at a time. :-) > > Who says whois is a "standard"? RFC942, I think. > And who says that it is moving to rwhois? > One thing I know for sure is that Netscape and just about every other OS > and Internet tools vendor is adding support for LDAP queries into their > products so when that is available, LDAP will be far more standard than > rwhois. See RFC1714. I believe you mean "more widespread", not "more standard". > Not that I have anything against rwhois, just that the writing is > on the wall and we should encourage people to build a rational > architecture that will work with the directory service that 95% of the > Internet community will be using a year from now. Perhaps we should specify NT as the OS, as well? > > > One way to do this is to have a centralised database that anyone can > > > replicate at will and use to serve local requests when the central nature > > > of the database is not relevant. > > > > "Distributed" to me implies "distributed responsibility". > > You cannot distribute the responsibility to apply the first-come > first-served rule. Of course you can. [snip] > What is this monopolistic abuse problem? Hypothetical: IANA is charged with running the CDB. 5 years from now a contract is let to a company, Network Savants, Inc., to manage the CDB. NSI (no relation to the current NSI) decides that a subsidiary will go into the registry business... > > I can accept (though grudgingly) that a centralized database for > > synchronization is small enough and simple enough that it is unlikely > > to become a serious problem. However, when this central database > > also becomes the authoritative repository for all the contact > > information I begin to worry. > > Why? If a registry agent wants to maintain their own customer contact > database off to the side they are free to do so. Let me rephrase that: The agency maintaining the CDB can maintain their own, non-authoratitive contact database if they want to. > > of the advantage of moving as much responsibility as possible out to > > the registries is that they become the primary source of legal > > liability. And the more a local person can blame their local registry > > for screwups, the better. [argument deleted] I thought through this stuff a while back in my initial half-baked suggestions for a voting protocol with unforgable timestamps. I agree that it is simpler to have a centralized interlock mechanism. I don't agree that it is the only system that will work -- there are tradeoffs, that's all. > Might as well plan for the legal liabilities and have one single central > database run by an organization chartered under Swiss law in Geneva that > has some level of immunity from prosecution. I would really prefer a technical solution that results in such strong localized responsibility that any centralized part of the service is essentially immune from legal action, because it has no authority. To be more specific, a centralized mechanism (might not be anything other than a small addition to DNS) that merely prevents name choosing conflicts is vastly different in legal exposure than a centralized database that contains all contact information for all SLDs, that is searchable for trademark conflicts, and other clever social engineering schemes. - -- 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: 20 Aug 1996 10:32:55 -0700 From: Matthew James Marnell Subject: Re: Mandated shared registries :>I give away SLDs for a year for free, so that I'm the only player. I :>then start charging more for renewals, knowing that I've got :>market momentum that can carry me much farther than anyone else :>getting into the field anew. Additionally, I always have the :>threat that I can go back to doing it for free if anyone becomes :>a significant player. A) it won't work, and B) it won't work. I'm not saying that it won't work from the viewpoint of your company not having enough money to do it, I saying it won't work because, nobody would easily be able to handle the flood of new domain registrations. On a day to day basis, you may very well be able to handle it, but in the long run entropy creeps in. The first time something happens between you and your customer, like a section of sprint going down yesterday, or any other small thing, and you start getting the least bit behind, or loose a domain or 2, the "You get what you pay for." principle kicks in and people begin to see that that registry over there, that does registrations as a sideline of their main business, and charges $X actually gives you more for your money. The first post to USENET, inet-access and IAP about you and you've got a rep. The more posts, the worse the rep. Pretty soon, people who do registrations for clients, or as a sideline business are doing just fine, and you're getting all the freeloaders, who wouldn't normally pay if they had to. Even when you do start to charge, you're not likely to have cornered much of a "market" for yourself, neither have you done your business much good, nor the industry as a whole, but it'll bounce back. So, what you'll really get for your trouble, is more trouble. I may be misremembering the circumstances, but I think I remembered that you had external backers who may actually know a bit about business. Do you think their going to be happy about loosing more money? If I'm wrong and you're flying it yourself, how long and how much money can you afford to loose before the vultures come in to pick your bones. :>I'm doing nothing of the sort. Perry, you're quite adept at throwing :>around assumptive arguments and mudslinging, which only tarnishes :>your occasional valid point. Please stop putting words into my mouth. Can we see some words that actually reflect reality first. One registry charging nothing isn't a realistic arguement. Look at the current MSIE/NN wars and a million other examples. Toyotas? If ever there was an example of bad analogies, that was it. I could go on and on, but won't. Let us just quickly look at some quick and dirty examples of companies that were given an artificial monopoly over a certain area, RBOCs. I can't think of anyone that has been overly happy with their RBOC's performance, nor can I think of many people who are displeased with the opening up of competition in this area. So, what we're really looking at is the near impossible reversal of monopoly TLDs when it turns out that, for the most part, not necessarily true of you, that most people feel that it benefits nobody but the monopoly owner and asks for the overthrow of the TLDOCs for more open competition. Matt ---------------------------------------------------------------------- Date: 20 Aug 1996 11:05:24 -0700 From: Simon Higgs Subject: [ADMIN] Test _____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____ ... "I'm fine - it's the others" ......... President/CEO ................ _____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________ ... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ... ---------------------------------------------------------------------- Date: 20 Aug 1996 11:21:43 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Perry E. Metzger allegedly said: > > > Kent Crispin writes: > > Nope. I'm suggesting a perl script that runs rwhois, gets the data, > > and inserts all of it into a local whois database. > > Having built crap like that before, I'll tell you that one's life is > always much, much happier when you have a real database. Perl hacks > from text taken off the net are for when you have no choice. Or when you are doing a prototype. > > I can accept (though grudgingly) that a centralized database for > > synchronization is small enough and simple enough that it is unlikely > > to become a serious problem. However, when this central database