| | At Large Membership and Civil Society Participation in ICANN |
|
| |
|
|
|
|
This discussion has been archived.
No new comments can be posted.
|
|
Building the alternative to DNS
|
Log in/Create an Account
| Top
| 26 comments
|
Search Discussion
|
|
|
|
The Fine Print:
The following comments are owned by whoever posted them.
We are not responsible for them in any way.
|
|
 |
|
I am working out my thoughts in more detail on my good old Web page. So far, I have a very preliminary draft of definitions and requirements, probably missing a lot of points. Warning: this is real detailed and pedantic stuff, for those interested in technicalities. I will write stuff that's intended to be widely readable later, and I may or may not succeed.
Mike O'Donnell
|
|
|
|
[ Reply to This | Parent
]
|
|
|
|
Give me the telephone numbers for those same businesses, please. From memory.
You're making a rather irrelevant argument.
Domain names are valuable because they provide an easy way to remember something that you wish to remember, or that the advertiser wants you to remember.
Saying and remembering numberoneautorepair.com is easier than 18003862548, believe it or not.
++Peter
|
|
|
|
[ Reply to This | Parent
]
|
| |
|
|
|
DC says,
However, the value of domain names as " ... locaters and identifiers ..." is NOT "overrated".
I don't think that the value of "locators, identifiers, and navigation aids" is at all overrated. Rather, I think that the value of domain names for these purposes is overrated. Independent directory services, such as Google, Yahoo, RealNames (yes, I know they went under), have a good chance to become much better. For most of my purposes, Google is already better, but it doesn't satisfy all possible needs for directory lookup. Jon posted an interesting brief comparison of DNS with search engines earlier.
Leave the DNS alone. It remains a viable option for consumers and businesses.
This is precisely what I propose to do. Let the DNS alone, and let it compete freely with other directory lookup services. I expect that it will survive and be useful for the foreseeable future, but that it will cease to be the dominant directory lookup service.
While leaving DNS, and particularly its directory lookup function, totally alone, I propose to offer a separate implementation of its portable unique identifier function, divorced from meaningful directory lookup. If my reasoning is correct, the value of the domain name x.com will go down a lot in the new regime, and people will fight over it a lot less, but I don't see any reason for it to go away entirely, unless and until a new service is so much more attractive that DNS is not worth maintaining.
Mike O'Donnell
|
|
|
|
[ Reply to This | Parent
]
|
|
|
|
Folks, this doesn't necessarily replace the DNS. It is an _intermediate_ layer of indirection between IP and DNS. It seperates somethings _name_ from its _handle_. A handle could be thought of as a unique GUID, a number. CORBA has something similar, as does DCOM. The name is then mapped to a handle, which is then mapped to a service endpoint.
There are some very good reasons to have such a system, and some concerns as well. The good reasons is that it adds another layer above IP. This means that you can now have a unique, long-lived handle that refers to services, devices, and sites that are independent of whether the underlying IP address changes or even if the underlying user even has an IP address (if they are NATed or firewalled). Even deeper, the handle could actually map to something non-IP, such as a SOAP endpoint running at the end of an HTTP URL or something else wierd. It also means that several competing directory services could be instituted that map to the given handle. For example, let's say I have a website with the handle 234234234 (some random GUID); I could have a DNS like system that maps the website name www.acme.company or www.sieraclub.environment to this handle, or I could have an LDAP like naming service that maps ldap://o=Siera Club,c=US that maps to the same GUID. The point is that innovators are now free to implement their own directory service, but they don't have to start over in terms of the objects they point to.
My concerns are twofold: performance and the "everything as a URI" argument of Tim Berners-Lee.
First, performance. With indirection you always impose a whammy, both in terms of storage space and performance. To dereference the domain name www.bradneuberg.love, for example, you would first need to contact the Naming Service and get the handle, such as 23423423. Then you would need to contact the Handle Service and get the actual IP address or service endpoint. Latency latency latency, which already plagues DNS, would get you as well, so even if the servers are hierarchical you still get the inherent latency. I am personally building a naming system that is distributed (its called the Distributed Domain Name System) and which runs above peer to peer, which already is going to be tough to get to run at DNS speeds, so imposing another layer of indirection might not be feasible. You also have the problem of maintaining the storage space for these two sets of tables, Name to Handle and Handle to Service Endpoint. That would mean squaring the size of the existing DNS system; big stuff.
The other issue is more abstract. TBL (Tim Berners Lee) has the dream of everything being addressable through URIs, because if something has an address, "we can talk about it." So when I create a tag library in XML for my newspaper, lets say the Newspaper Markup Language, and have the tag <Article>, this tag actually derefences to the full URI http://mynewspaper.org/NewspaperMarkupLanguage/Article.
How would this scheme of everything as a URI tie into a Handle scheme? Would that URI above actually be some handle, 213423423? It seems messy.
Hope all is well,
Brad Neuberg
codinginparadise.org
|
|
|
|
[ Reply to This | Parent
]
|
| | | 1 reply beneath your current threshold. |
Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their
respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com
|
