Vint Cerf Responds!
I always had a theory that the greatest sign of human intelligence is the ability to ask the right questions. I’ve now had that theory confirmed anecdotally by Dr. Vinton Grey “Vint” Cerf. If you don’t know who that is, please go study that name on Google right now, and finish reading this afterward.
Wikipedia article on Vint Cerf:
http://en.wikipedia.org/wiki/Vint_Cerf
The text below is taken directly from an email thread I exchanged with “Vint” (as he calls himself in his email salutation). I edited it down to eliminate parts of the conversation out of context with the main conversation, and to make this look more like an interview rather than an email thread. I honestly didn’t expect to be the main one talking in this interview! Really!
The Conversation
Jared: Hi Vint, I wanted to ask about your talk at the Speaker Series at Google LA in October, and your mention of Sergey Brin’s Challenge…
I have some ideas about geographic/co-orbital map numbering systems, with related applications for video game AI routing methods (like A* with convex culling). The DataRoads.org blog already has an old post about user-relative naming systems.
http://www.dataroads.org/blog/
Vint: I will read with interest! … This sounds a lot like the UUCP mail routing system – the serious problem this produces is exactly the inability to reference anything in such a way that someone else can find it using the same reference strings. We rapidly moved to the DNS design once it was clear that the alternative did not scale nor did it produce an ability to make common references. I may have read your proposal too quickly but this looked to me like a quagmire we escaped some time ago.
Jared: Behind the scenes (in protocol-space not user-space, let’s call it NNS), I think a structured namespace merger could occur at each name layer, to create a system much more like DNS than UUCP. Each merged namespace layer is determined democratically (i.e. majority name rule)
within the protocol space, rather than by any central administrator. Wherever the post says “we … agree” or “I can just simply use your name”, I mean that NNS can handle our namespace mergers for us in a consistent and predictable fashion. When the post says “[mine|your] name trumps”, I mean there’s a NNS merge conflict resolution default that maintains local settings at the cost of any complete merge. I also think we can find more clever merge conflict resolutions, and room for UUID overrides in non-merged NNS namespace translations, but that would be a whole different post and audience.
Ultimately, I think the last examples in the post could be resolved simultaneously in both DNS and NNS like this (using ‘.’ instead of ‘/’ separators):
30.1534.main.myville.ms.usa.
whitehouse.washington.dc.usa.
Here “.earth” is simultaneously a DNS gTLD and a final outer merged NNS namespace. That means ICANN would have to set aside a new gTLD like “.earth” for NNS compatibility purposes. In the worst case scenario of NNS-DNS compatibility, the DNS name for the Whitehouse FQDN example would be something like “whitehouse.washington.dc.usa.
The rest of the post is really just referring local default and host name overrides that already exist (i.e. in system “hosts” files), although those aliasing and override host naming methods are largely unknown to the public. Not everybody can be a Jon Postel fan like me. The core intent is local (per-user) determination of labels taking precedence over external (official/ICANN/government) settings. In practice, I think the end results will be very similar (especially in existing democracies), although “registrars” and government entities would have much less pricing or officiating power over NNS than they do with DNS.
Vint: How does “reply” work?
Jared: Mostly the same way they do now, except that writing out the names to the outer most merged namespace (the TLD, “.earth” in the prior examples) would not be necessary in every case. Each email can be seen as a 2-way communication. Even email lists are just a list of communication end points relative to the “From:” user. So each communicating name just has to be written to the closest agreed/merged namespace for each recipient. If it’s less work, the email header could also be written to the closest common merged namespace (CCMN) of all recipients collectively, which is contextually analogous to a FQDN in DNS.
In example, if we both worked for Google we could both address [username]@., and skip the “google.com” part, because our namespaces agree/merge at the “google” email server cluster. The “.com” part would never be a worthwhile factor in our internal-only communications. If other @[company].com users enter the conversation, then @google would be used. If other .tld users enter the conversation, then the FQDN @google.com would be used. The server can fill in the name blanks for us as necessary, so to speak, based on local knowledge of the merged user namespace per communication.
I know the “fill in the name blanks at the end” behaviors described above are possible now using DNS. The difference is the “fill” order and contextual necessity of any TLD. In DNS, everything eventually gets resolved to an administratively determined FQDN. In NNS, any CCMN in current use would be an evolving name string based on the outer most known namespace merges and latest primary-name
elections, as determined by the communication users involved. For example, if NASA opened a fully addressable network on Mars from Earth, the Whitehouse CCMN example would become something like:
whitehouse.washington.dc.usa.
Where the Curiosity rover’s CCMN on the Mars network would be something like:
curiosity.mars.solar
When these network node names address each other, they could leave the “.solar” part out as implied, because that’s where their namespaces merge. Unlike in DNS, the “.solar” TLD would not have to be set aside ahead of time, because that would automatically be created in the cross-planet namespace merge event in NNS.
Late last night I thought of an analogy between network names and English language usage, which might help to illuminate the primary differences and overlap between NNS and DNS. I think network name systems should be like Webster’s Dictionary — a convenient place to look up generally agreed words for things, with some indicators about semantic placement or hierarchy, and a list of common aliases. The problem is that English vocabulary usage does not strictly follow Webster’s Dictionary definitions, especially within niche dialects. Instead, Webster’s Dictionary observes and documents a huge subset of real-world English word use, and periodically integrates common dialect changes. While Webster’s Dictionary word selection is not completely democratic, it at least realizes that human naming systems are bottom-up, user-relative, and constantly evolving. The same cannot
be said for the top-down DNS. I want the same to be said for NNS (or whatever we call this new network naming system), using any available automation tricks in our current power. I also think this can be done in a DNS compatible way, with ICANN’s help, although DNS compatibility is not strictly necessary.
This Royal Society talk also helps me think about user-relative naming systems vs. hierarchical naming systems: