Threaded Mode | Linear Mode

rev412 · 12-12-2010, 06:10 AM

Going to Human Name -> Identifier -> IP address seems like the right direction and follows the old aphorism that all problems in naming can be solved by adding another level of indirection. So here's a bit of what I see as the characteristics of these levels.

The Human Name is a free-form string. The primary characteristic is that it is not necessarily unique. This is probably going to look a lot like a search engine as it can return multiple results and leave it to the human user to determine the answer they want. One implication then is that there needs to be a system in place that allows for search engine spiders to do their thing. It may be that the easiest way to achieve this is by simply leveraging the existing web and web search engines. Just drop a few HTML tags on your contact page and Google, Bing, Altavista, and all of the other search engines soon have your information.

I'd expect there to be two kinds of Human Names, in fact. There would also be Local Context Human Names corresponding to your address book or named bookmarks. Once a user has established that they have found the destination they're looking for, they'll want to remember that result and perhaps give it a local name that's meaningful to them.

Identifiers, on the other hand, ARE unique. That's their main purpose in life. Both unique and long-lived. In fact, perhaps long-lived to the extent that any given Identifier is never reused, or is unlikely to be reused. Don't know about that. Anyway, Identifiers are not necessarily human friendly names. I'd say they're not assigned randomly, as such, but are assigned in a manner that makes life easier for the naming system. To the extent there's structure to the Identifiers, it is to help out the naming system.

While I said the Identifiers need not be human friendly, there is one gotcha known as the business card problem. Since Identifiers are what go in email addresses and URLs, they are exactly what you want to print on your business card or at the bottom of an advertisement in a magazine. It'd be nice to have a way to reduce errors in transcription. Using bar-codes or splats has been suggested in the past. There's also the approach of turning it into words sort of like the 4 Little Words proposal for IP addresses. Or maybe just some sort of forward error correction.

And finally a quick comment about security. It should be stated explicitly that no matter what crypto gunk you get back from the naming system, if an application cares about authenticating the entity it's talking to, it needs to handle that itself. With no hierarchy, there's no higher authority to appeal to who can sign this answer as authentic.

***lauren*** · 12-12-2010, 10:25 AM

The last two replies are really starting to home in on my views regarding identifiers. The key is that the coupling of identifiers to human-meaningful names is under control of individual users/organizations/sites, who can choose to use whatever naming context that they wish. Notably, identifiers, as random (or otherwise machine-oriented, not human-oriented) objects never enter into the realm of name disputes, trademark battles, and the like.

The methodology by which users couple locally chosen naming conventions to identifiers is an entirely different aspect. Issues of authority -- that is -- confirming to your own satisfaction that a name-identifier coupling is meaningful and valid for your own purposes, will likely involve not only local knowledge and so-called Webs of Trust, but also (for example) search engines and directories that are considered trustworthy and authoritative within various contexts.

The "business card" issue -- how to create a simple mechanism for human-based addressing, is a very interesting one. I would just note for now though that this is a problem that has been successfully dealt with, for individuals and local, national, and global firms, prior to the Internet age. I am confident that reasonable solutions can be developed under the IDONS model as well.

--Lauren--

bug1 · 12-12-2010, 03:22 PM

(12-12-2010 06:10 AM)rev412 Wrote: While I said the Identifiers need not be human friendly, there is one gotcha known as the business card problem. Since Identifiers are what go in email addresses and URLs, they are exactly what you want to print on your business card or at the bottom of an advertisement in a magazine. It'd be nice to have a way to reduce errors in transcription. Using bar-codes or splats has been suggested in the past. There's also the approach of turning it into words sort of like the 4 Little Words proposal for IP addresses. Or maybe just some sort of forward error correction.

I have seen identifiers transformed into an image so they can be compared as a picture rather than as language. (i cant remember where ive seen it)

Such a scheme is more useful for crosschecking a result as it doesnt give the user a foolproof way to get the correct result first time.

***lauren*** · 12-12-2010, 03:55 PM

The "business card problem" discussion is certainly worthy of a separate thread.

--Lauren--

stewart · 12-12-2010, 04:37 PM

I think it would be a useful discipline to unwind the functions of DNS and think about them separately. I'll probably miss some.

* Letting a human type "www.cnn.com" to reach a website

This is what search engines are for. And as Lauren points out, unless you have a beaurocracy, there will be conflicts over names.
Probably a search engine is the right place to encode all the nuances of "I want the ACME in my home town"

* Translating a permanent service identifier to a network address

Right now, DNS is using the same old human typeable string for this purpose, but channeling SDSI or similar schemes, permanent service identifiers ought to be public keys -- so that they cannot easily be forged.

* Locating a nearby representative of a service

So that http://www.cnn.com maps to a server in a data center near you.

I think it is likely that most of the politics are in the first section

ohir · 12-12-2010, 09:08 PM

(12-12-2010 04:37 PM)stewart Wrote: * Letting a human type "www.cnn.com" to reach a website
* Translating a permanent service identifier to a network address

These two are no bit different. Both actions need to be performed by software sometimes. Both need to be performed by human hand sometimes.
Irc client is not about to ask uncle google with ?any irc servers you know?

(12-11-2010 11:59 PM)lauren Wrote: I do not believe it would be wise to have names being used as identifiers whether cryptographically hashed or not. Identifiers need to be wholly separate from names, and to the greatest extent possible only coupled at end points under local control.

OK. Its certainly possible to chose this way. Looks like a work for Kademlia.

(12-11-2010 11:59 PM)lauren Wrote: Identifiers should be essentially randomly assigned, or at least unrelated intrinsically to human-meaningful names.

Still we ought to have that simple 'where is ip serving (a proto) for a name?' question answered.

Regards,

simon_brooke · 12-13-2010, 05:08 AM

(12-11-2010 11:59 PM)lauren Wrote: I do not believe it would be wise to have names being used as identifiers whether cryptographically hashed or not. Identifiers
need to be wholly separate from names, and to the greatest extent possible only coupled at end points under local control. This provides maximal flexibility in the definition of identifiers, and helps minimize the possibility of identifiers becoming enmeshed in trademark disputes (e.g. claims that hashing and encryption were merely being used to try "mask" the use of names that conflicted with trademarks).

Identifiers should be essentially randomly assigned, or at least unrelated intrinsically to human-meaningful names.

--Lauren--

We do need human-memorable and human-expressible tokens, whether you call those names or identifiers or whatever. Yes, search engines help. But search engines are not the whole story. For any given set of search terms a search engine will return a set of zero or many results. A replacement for DNS must have a way of returning zero or one result, with ambiguous searches being flagged as errors (and thus returning zero).

A replacement for DNS must reliably resolve the same token set to the same resource; it must allow a mail transport agent reliably to deliver my mail to my mail host and to no other. It must allow my banking application reliably to contact my bank and to no other.

And it needs me to be able to say to a chance-met person in the street, 'go to this address on the 'net to find the particular information you're seeking', and have them be able to follow that instruction and find the right place. Magic hashes that a person can't memorise and can't communicate verbally do not cut it.

***lauren*** · 12-13-2010, 08:57 AM

Simon, I believe you're confusing the concepts of "identifiers" per se with the human-useful associations and "labels" by which we would normally refer to them. The existing DNS conflated these two concepts within a centralized root structure, which is a major reason it has become such an expensive mess along so many vectors today, with so many collateral downsides that have become widely obvious very recently.

A major goal of IDONS (as I see it) it to keep these concepts distinct while avoiding all centralization.

--Lauren--

Morgan · 12-13-2010, 09:07 AM

(12-13-2010 05:08 AM)simon_brooke Wrote: We do need human-memorable and human-expressible tokens, whether you call those names or identifiers or whatever. Yes, search engines help. But search engines are not the whole story. For any given set of search terms a search engine will return a set of zero or many results. A replacement for DNS must have a way of returning zero or one result, with ambiguous searches being flagged as errors (and thus returning zero).

A replacement for DNS must reliably resolve the same token set to the same resource; it must allow a mail transport agent reliably to deliver my mail to my mail host and to no other. It must allow my banking application reliably to contact my bank and to no other.

And it needs me to be able to say to a chance-met person in the street, 'go to this address on the 'net to find the particular information you're seeking', and have them be able to follow that instruction and find the right place. Magic hashes that a person can't memorise and can't communicate verbally do not cut it.

I would have to agree with simon_brooke on this one. The concept of the current DNS solution is authoritative resolving of strings to unique addresses. A system that cannot uniquely identify google.com as the same google.com consistently will have significant issues.

Consider a few situations:

A user wants to search the web, there are now 13.5 google.com results, which one is correct?
An automated service runs and attempts to send critical data to a named resource (such as myservice.example.com), what if two addresses are the result? Which does this automated process use?
I goto mybank.com and am told there are three mybank's, now I don't know which is correct, or if any of them are!

I agree the ACME issue exists, however I'm uncertain of the best way to provide for this. Country specific tld's are always nice...but then there are at least thousands of ACME's within the United States so even country specific TLD's are enough to solve the problem. And even after that there are many in individual states, or regions so that may not be unique enough.

So my question is, where do we stop? In the conventional DNS solution we might opt that a reasonable solution to multiple acme's is to do delegation such that we get for a Hollywood based Acme:
acme.hollywood.losangelescounty.ca.us

That's just impossible to remember let alone further explain to my grandmother (not that DNS is a topic I bring up with my grandmother). At some point the solution needs to say enough is enough and we've made the absolute best compromise of usability and human readability. Certainly the above example would be perfect for the situation of thousands upon thousands of Acme's, but it certainly would be difficult for someone to remember exactly which Acme's website they went to.

An idea thats been floating around in my head for the past few minutes is that the proper TLD that we're hoping to use (the new .com equivalent) could simply redirect to a set of localized domains? Such that example.tld gives back example.us, example.ca, example.kr, example.jp, etc and as such the locality of the name server gives back the proper one for example.tld and as such uses with a properly configured name server get the proper version of the destination. It also still allows for another example.gb to created, but .com has been registered and is in use by the previous company.

I think I'll stop there and see what others think of that idea, if its worth discussing or not!

***lauren*** · 12-13-2010, 09:18 AM

(12-13-2010 09:07 AM)Morgan Wrote: I agree the ACME issue exists, however I'm uncertain of the best way to provide for this. Country specific tld's are always nice...but then there are at least thousands of ACME's within the United States so even country specific TLD's are enough to solve the problem. And even after that there are many in individual states, or regions so that may not be unique enough.

I assume you dropped a "not" there, in that you meant "even country specific TLD's are *not* enough to solve the problem."

And that's fundamental. Even with the plethora of expensive TLDs that ICANN has planned (though DOC has now sent them a new very strong letter accusing them of violating agreed process) there's no way for TLDs to solve the ACME and trademark problems. In fact, more TLDs only make the situation worse, due to protective registrations.

So we need to approach this from an entirely different angle.

--Lauren--

Morgan · (This post was last modified: 12-13-2010 10:19 AM by Morgan.)

(12-13-2010 09:18 AM)lauren Wrote:
(12-13-2010 09:07 AM)Morgan Wrote: I agree the ACME issue exists, however I'm uncertain of the best way to provide for this. Country specific tld's are always nice...but then there are at least thousands of ACME's within the United States so even country specific TLD's are enough to solve the problem. And even after that there are many in individual states, or regions so that may not be unique enough.

I assume you dropped a "not" there, in that you meant "even country specific TLD's are *not* enough to solve the problem."

And that's fundamental. Even with the plethora of expensive TLDs that ICANN has planned (though DOC has now sent them a new very strong letter accusing them of violating agreed process) there's no way for TLDs to solve the ACME and trademark problems. In fact, more TLDs only make the situation worse, due to protective registrations.

So we need to approach this from an entirely different angle.

--Lauren--

Yup, I sure did drop a "not"! Thanks for noticing (though I could not edit my original post due to a time limit). Also, agreed...I just wish this different angle was more obvious at the moment. Hopefully someone will have an epiphany on this!

bug1 · 12-13-2010, 01:51 PM

(12-13-2010 09:07 AM)Morgan Wrote: Consider a few situations:
[*]A user wants to search the web, there are now 13.5 google.com results, which one is correct?

If you type in a human identifier that isnt unique, then yea you would have to workout which result you want, same problem as human face when using a search engine.

When the user determines what from his perspective is the true "google.com" there should be some way to associate some trust with its unique identifier so the process is simpler in the future.

(12-13-2010 09:07 AM)Morgan Wrote: [*]An automated service runs and attempts to send critical data to a named resource (such as myservice.example.com), what if two addresses are the result? Which does this automated process use?

An automated process should use a unique identifier rather than a human friendly shorthand version.

(12-13-2010 09:07 AM)Morgan Wrote: [*]I goto mybank.com and am told there are three mybank's, now I don't know which is correct, or if any of them are!

There should be a way for people to check the unique identifier to be absolutely sure which one is correct, even if it means manually checking hash values.

Other ways might be having a visual representation of the unique identifier, or shortwords, which people might remember better than ascii strings.

Another method might be using feedback/trust metrics, like how we judge ebay sellers.

rev412 · 12-13-2010, 03:31 PM

(12-13-2010 01:51 PM)bug1 Wrote: There should be a way for people to check the unique identifier to be absolutely sure which one is correct, even if it means manually checking hash values.

I think if you think hard enough about this, you will realize it is simply not possible. There is never absolute assurance, there's only good enough. one way to get good enough is via a trusted third party. You let whoever controls the DNS root to assure that they're telling you true about .com. Then, because of that, you trust .com to tell you about amazon.com. You're now putting your trust in whoever signs the DNS root and so on down the chain.

Or you could put your trust in various SSL certificate authorities. Maybe you don't trust what you get back from the DNS but you connect to whoever they tell you and check out that SSL certificate. What this has turned into in practice is that you trust whoever came up with the list of CAs that come pre-installed in your browser.

Or you could take the effort upon yourself, essentially using the PGP trust model. You contact whoever it is over an authenticated link but don't trust them completely at first. Over time you either gain trust because they seem to be the right entity and you think that it's unlikely that your connection is being hijacked every time, or you use an out of band authentication method like verifying PGP fingerprints.

My opinion is that the first route is utter foolishness. The naming system should play little part in whether you trust that you have ended up communicating with the entity you wished. If that's important to you, you are best served by one of the two latter models.

bug1 · 12-13-2010, 04:10 PM

I was thinking that if you had say a business card (or other printed material) from a bank, they might have a unique identifier printed there (even if it is ugly) alongside the short human friendly name. In this case there is no third party.

I do think trust metrics are a very powerful tool as well.

rev412 · 12-13-2010, 04:30 PM

(12-13-2010 09:07 AM)Morgan Wrote: I would have to agree with simon_brooke on this one. The concept of the current DNS solution is authoritative resolving of strings to unique addresses. A system that cannot uniquely identify google.com as the same google.com consistently will have significant issues.

I agree, but... What I'm suggesting is that the function of the DNS name be split into two pieces. One is human friendly names, like Google, that may not be unique and may even change over time, and one is computer friendly names that are unique and permanent. More explanation below, as answers to your very well chosen examples.

(12-13-2010 09:07 AM)Morgan Wrote: Consider a few situations:

A user wants to search the web, there are now 13.5 google.com results, which one is correct?

Two possible answers. The first is: maybe it doesn't matter. If all thirteen and a half answers do the job of searching the web to your satisfaction, no problem.

However, that's usually not acceptable, of course. The real answer is that you have to figure that out. Somehow. You have to look at the sites and determine which one is the Google you want. For a different example, suppose you're looking up Apple and you get back both Apple Computers and Apple Records. Maybe also a whole slew of apple orchards and apple juice pressing houses. It's really not a problem in the real-world because of trademark law. The whole purpose of trademark law is to prevent consumer confusion over who's who. The network name service should stay out of that arena; more on that below.

(12-13-2010 09:07 AM)Morgan Wrote:

An automated service runs and attempts to send critical data to a named resource (such as myservice.example.com), what if two addresses are the result? Which does this automated process use?

Yes, excellent question. An automated service should not use the human friendly, possibly ephemeral and non-unique name. That's the purpose of the other name, the one that's guaranteed unique. Okay, it's computer friendly, not human friendly, but we're talking about an automated service here so computer friendly is okay. A human probably has to set up the automated service and that means going through the steps outlined above where they look up Google or Apple and choose which is the one they really mean, but then they store the computer friendly name for future use.

(12-13-2010 09:07 AM)Morgan Wrote:

I goto mybank.com and am told there are three mybank's, now I don't know which is correct, or if any of them are!

This may be the trickiest one of your examples. You can see the direction of my answer from what I wrote above but the problem here is that we're talking about a bank and your bank account. It really matters that you get it right. I've said before that I think it's important that the name system explicitly and loudly make no guarantees that who you end up talking to is who you think it is and that your communication is not being spied upon. If this matters to you, you should be using legitimate security technology which is well beyond the scope of a lowly name to network address translation system. You should be using encrypted communications to your bank with a solid authentication mechanism which has been pre-configured out-of-band so you know you got the right place. A fully general answer is really hard, perhaps impossible, but workable answers exist. You should not trust the name system one tiny little bit in this regard.

(12-13-2010 09:07 AM)Morgan Wrote: I agree the ACME issue exists, however I'm uncertain of the best way to provide for this. Country specific tld's are always nice...but then there are at least thousands of ACME's within the United States so even country specific TLD's are enough to solve the problem. And even after that there are many in individual states, or regions so that may not be unique enough.

Exactly so. The answer, in my opinion, does not lie in the network's naming system. This is the realm of trademark law and we should just stay out of the way. If we get involved with a dispute over who is allowed to have apple.com, it's designed wrong. Much better to say a web search on apple showed up both Apple Computers and Apple Records and if they have a dispute with each other, they can work it out in court the old-fashioned way, which they did.