ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    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
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    New layer, but little or no increase in latency
    by odonnell (michael_odonnell@acm.org) on Thursday August 01 2002, @04:16PM (#8286)
    User #3447 Info | http://people.cs.uchicago.edu/~odonnell/

    Thank you very much for introducing the terms handle (my "PUI"s are just handles) vs. name. I will use those terms from now on, as they seem to be widely used and understood.

    the handle could actually map to something non-IP

    To be fair, it seems that DNS could just as well map names to more than IP addresses. But a separation of handles from names probably reduces the baggage accompanying such a move. As we consider table entries other than IP addresses, we should avoid providing information that can just as well be obtained from the IP address, and also services (such as authentication) that are best handled end-to-end. But UDP style addresses (IP address plus port address), and even somewhat richer addresses that include parameters to pass to the application at the given port, are probably worthwhile, since they allow more separation of authority within an individual physical host. Hunt groups (lists of IP addresses to try) are probably worthwhile, since we need the later addresses precisely when we can't reach the first one. I'm sure that there are other possibilities, and there's no need to cut any of them off at the beginning.

    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,

    I don't think so. Handle resolution, by itself, should have essentially the same latency as DNS name resolution does now. Most name resolution services other than DNS now map to domain names (used, in this case, as handles). They can map to handles with no increase in latency. At first, the current DNS will work side-by-side with the new handle service---no lextra latency there. If the DNS switches to mapping names to handles, instead of names to IP addresses, most applications will store pointers to handles, rather than to names. The current cacheing of domain names is done mostly for their value as handles, not for their value as names. Handles will be very stable, and will be redirectable to different IP addresses over time. This reduces (dare I hope, nearly eliminates?) the need to refer repeatedly to the same name to find out whether it points to a new handle. Also, DNS tables can cache IP addresses to reduce and amortize the cost of refreshes from the handle-to-IP tables. They already know how to do this, since it's essentially the same thing as cacheing table entries in a local name server.

    I am personally building a naming system that is distributed (its called the Distributed Domain Name System) and which runs above peer to peerj

    Please post pointers to anything that you've written about this. So far, I haven't conceived of a peer-to-peer implementation of handle mapping. It seems that I need a central authority to avoid collisions at the top level. And lower levels are handled hierarchically just like DNS does it. But I definitely want to minimize the need for central authority, and if you know how to crank it even lower, please share.

    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

    I don't see why the table size squares. I think that handle tables are approximately the same size as name tables. So, the new handle system merely adds another set of tables equal in size to the current DNS tables. I am a bit worried that, because handles are so much cheaper than names, the demand goes up too fast for the administrators to deal with it by distributing subranges of the key space. But that's the sort of problem I'd love to deal with, since it means empowering lots of little guys with their own handles.

    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 , 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.

    Well, I do see the likelihood of mapping handles to more and more flexible types of values. The ability to give out handles so promiscuously probably increases the incentive to do this. But I don't see any reason to work this out up front. The handle-to-IP service seems very valuable by itself. Why not do it, then see what we think of next? We'll have the choice to add more functionality to the handle system, or to let other functions be implemented separately. An increase in the types of things that are handled (i.e., referred to by handles) in a uniform way usually looks attractive. But it's not hard to prove that, however many things have handles, we start manipulating some that don't.



    Mike O'Donnell
    [ Reply to This | Parent ]
    New layer, but little or no increase in latency by odonnell
    Working out details of decentralized handle servic
    by odonnell (michael_odonnell@acm.org) on Friday August 02 2002, @11:37AM (#8328)
    User #3447 Info | http://people.cs.uchicago.edu/~odonnell/

    This idea looks like it should be published somewhere. If it is, please post the citation.

    I'm aware of ideas of this sort, but I haven't followed any of them in detail. After I've studied the post carefully, and read whatever articles I can find, I'll post some evaluation. There are lots of details to be concerned about:

    • What are the detailed tradeoffs between key-size, security, and latency?

    • What do we do about a rare, but occasional, collision of hashed fingerprints?

    • Do we need a central repository to make sure that entries don't get completely lost? Part of the question here is whether the loss of an entry is considered harmful only to the handle owner (who can republish), or whether it could be harmful to the public.


    Mike O'Donnell
    [ Reply to This | Parent ]
  • 1 reply beneath your current threshold.

  • Search ICANNWatch.org:


    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