Wile E. Coyote, ACME, and TLDs

[lauren]

An example of how the Top Level Domain (TLD) structure has warped naming can be demonstrated by what I call the "Wile E. Coyote / ACME" problem.

When Wile E. needs to buy some new gadget in his never-ending quest to catch and eat the Road Runner, he has no apparent trouble reaching the correct firm, even though there are probably 1000s of ACMEs doing business around the country.

Somehow Wile E. manages to buy the needed rocket-propelled sled, and doesn't accidentally end up with a new toilet from any of the many firms that call themselves ACME Plumbing.

In fact, it's very common for enterprises to have the same name, and uniqueness in the brick-and-mortar world is usually restricted by regulations only to given counties and/or state jurisdictions, if at all.

But the existing TLD system has created a twisted sort of parallel universe, where in the one TLD that most people know best and trust the most -- .com -- there can only be one acme.com on the entire planet. Additional TLDs end up adding more confusion and vastly greater costs, only making the situation much worse.

Without getting into the complexities of trademarks, protective domain registrations, technical mumbo-jumbo, and all the rest right now, I believe a key aspect of IDONS should be to develop a naming system that includes the best attributes of the non-Internet world, where the many ACMEs are able to coexist, but where hungry coyotes are still able to place their equipment orders without undue confusion. Even if they still end up not actually eating the bird.


--Lauren--

[judic]

It's true that Mr. Coyote frequents a store with a common name (ACME), and once he knew the path to that establishment, Mr. Coyote would have no trouble re-establishing his path to said favorite.

But let's say that ACME goes out of business, or for some other unlikely reason is unavailable when Mr. C has a mission in mind. How does discovery happen for the replacement to ACME? How does one find the right place or make the right connection with so many Explosives4U-named sites available?

[lauren]

"Google is your friend." Search engines in general will clearly have a major "discovery" role to play in any naming environment.

[bug1]

(12-11-2010 05:04 PM)judic Wrote:  It's true that Mr. Coyote frequents a store with a common name (ACME), and once he knew the path to that establishment, Mr. Coyote would have no trouble re-establishing his path to said favorite.

But let's say that ACME goes out of business, or for some other unlikely reason is unavailable when Mr. C has a mission in mind. How does discovery happen for the replacement to ACME? How does one find the right place or make the right connection with so many Explosives4U-named sites available?

One day Mr. Coyote was following the path that he knew took him to the ACME store. This time however, there was some roadworks and he had to take a detour, having never been down the side-streets he quickly got lost. If only Mr Coyote had remembered the location of the store instead of the path, then he could have asked for directions.

Next time Mr Coyote had had the unique address for ACME, he found the store no problem. When he arrived the store was closed for lunch, he waited for the store to open again and managed to purchase one of his gadgets, but he couldn't purchase any birdseed, a vital component of any roadrunner trap.

When Mr Coyote got home he talked to some friends who advised him of the name of a specialist birdseed shop. He also found out its strangely named location, being hard to remember he just wrote it down incase he needed it later.

Things are much trickier for the roadrunner, all you want is a quick feed, but there are all these Coyotes trying to trick you and trap you; some of Mr Coyote favorites being;
- Putting a sign on the birdseed store advising all roadrunners of free birdseed at the coyote lair.
- Moving the lair to old abandoned birdseed shops, and waiting for slow-witted roadrunners to turn up.
- And of course, setting up roadblocks on the popular path to the popular shops.

[lauren]

Which of course is the source of the famous folk saying:

A bird in the LAN is worth two in the Root.

--Lauren--

[denim]

Even in reality, a company name has to be researched to be individual. "ACME" may be registered and well known, so a new company may have to name itself "ACME of MainStreet, USA" or some such.

[lauren]

Within the U.S. at least, as I said, this is limited by jurisdiction. For example, in California, a "fictitious name" DBA is county unique. Corporate names in California are state unique. U.S. trademarks are "unique" across the country, but (grossly simplifying the explanation for brevity here) only where there is likely confusion.

At least that's how it's supposed to work. But trademarks don't always trump other uses of the name. Think of the complicated entanglements that surrounded Apple (Beatles) vs. Apple (Steve Jobs) at various times, or even the way domain name disputes are handled today. A trademark does not by any means override all other factors when it comes to who gets a domain name, for example. But the whole situation is indeed a complex mess, and getting worse every day.

Let's go back to the Acme example. There are "Acme Plumbing" operations all over the country. Google gives about 58K hits globally. These firms may or may not officially have their location as part of their DBA or corporate names. But they will commonly say something like "Acme Plumbing of Bloomington" in their ads and such.

The point being, there can be signals beyond the name itself that help to pin down the particular enterprise you're looking for in such situations.

--Lauren--

[bug1]

We need to differentiate between unique in the real world and unique on the network.

Trademarks and business names help to differentiate between things in the real world, but that only works because of centralization, and centralization is not something we want.

We could have unique within our network without it being unique in the real world as multiple machines can hold the same data.

So i think if we can have something fairly general and memorable to humans (eg business or trademarked name) combined with a unique name within our network then we can have authoritative and decentralized.

[lauren]

And in fact, a key concept for IDONS (in my opinion, anyway) is what I call the "decoupling" of unique "identifiers" as used to communicate name/address mapping data per se, from "human-readable" names (e.g. aliases) that need not necessarily have meaning to humans except at specific end points. Identifiers would likely be "random" crypto-protected strings that not only are meaningless to people, but have no trademark meaning either.

More on this later.

--Lauren--

[ohir]

(12-11-2010 07:40 PM)lauren Wrote:  The point being, there can be signals beyond the name itself that help to pin
down the particular enterprise you're looking for in such situations.

There have to be such signals within the name and the whole name itself need to be
recognized as globally unique. Otherwise a Mr Coyote being told that ACME seeds
is the best shop for Birds will be able to setup his local ACME Seeds shop to lure
any local Roadrunner into.

Hashing name strings has this feature 'built in':
'ACME Plumbing of Bloomsberg' is sha1 25ab95b86fb8d9f507763fcdb1b52a7ce6f75a33
'ACME Plumbing of Cloogsberg' is sha1 09451fe20d2584fac6fdd94f0b31d1d4cd785b30

(12-11-2010 04:45 PM)lauren Wrote:  there can only be one acme.com on the entire planet.

Internet is global thing. In IDONS there have to be only one 'ACME Plumbing of Bloomsberg'
on the entire planet. If not, we may end with yet stronger censorship and disinformation
engine, so 'ACME Seeds' in U.S. will point to sesame seeds shop, in other country 'ACME seeds'
will point to oat seeds shop and yet other country will mandate that 'ACME seeds' points
to red melamine fake seeds.

I can imagine hierarchical resolving, that costs resolving servers storage and cpu but can
be enough precise to both preserve global uniqueness and give location hints.
Yet I do not know how to implement it reliable in distributed, least authority, mesh.

On the centralized/delegated tree it is trivial: we traverse first the locality then the
single words tree. Query for ACME should return all pointers to sites that registered
name with 'ACME'. Query for 'ACME Plumbing' yields pointers to names that contain both
words and so on. Client resolver should prefer longest path and fallback to parent
word with no children if user typed too much.

I think its not good approach, though. We may end dealing with mandatory names
like 'ACME Plumbing of Bloomsberg of Vancouver of CANADA of Earth of Milky Way'.
Ah, and at last with 'of Universe10980986898987' suffix.
Giving location its search engines' thing, not resolver's.

I'd like to stay with simple 'string' -> 'hash' -> ip(set) mappings. Its simple and its feasible.
It wont feed lawyers too much. It also is quite an obstacle for the censors: they may
got all f-words hashes, but they can not have all possible strings with f-words hashes.

Regards,

[lauren]

I am very uncomfortable with the idea of using names as identifiers under IDONS. Nor do I have any desire to reinvent X.500 methodologies. Hierarchical resolving (beyond the context of an individual enterprise's control) moves back towards the realm of traditional DNS problems.

An entirely new approach is needed.

--Lauren--

[ohir]

(12-11-2010 10:49 PM)lauren Wrote:  I am very uncomfortable with the idea of using names as identifiers under IDONS.

IDONS should not use 'names'. It should use crypto hashes of human readable strings. Machines do not store 'names', machines store hashes. Humans use 'names' and their local resolver library translates it locally to hash. That hash is being looking up, not 'name'.

'GCTIP Forums - Global Coalition for Transparent Internet Performance' ->
on your host resolver lib will translate this string to ->
2d203d29b104a6dfded68de4cfd34e4ea3f7e18a ->
and that hash will be looked up in IDONS and IDONS should return ->
67.119.61.43
as answer.

You likely would like to register mere 'GCTIP Forums' string.
'GCTIP Forums' -> a730719d44937088cababd55658a73c88c0490d8 -> 67.119.61.43

(12-11-2010 10:49 PM)lauren Wrote:  An entirely new approach is needed.

The very idea of name resolving is about translation from whatever human can write, read and memorize easily to something machine can understand and use directly.

http://anon793.penet.fi would fit for tiny minority of us. The same minority that already know how to use http://1.2.3.4 or even teredo http://2001::1:2:3:4.

Regards,

[lauren]

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

[ohir]

(12-11-2010 11:59 PM)lauren Wrote:  Identifiers need to be wholly separate from names, and to the greatest extent possible only coupled at end points under local control.

Coupled by whom?
I already can set up local nameserver serving in the name of all roots for
whole world. Just it will serve A's for my networks only.

(12-11-2010 11:59 PM)lauren Wrote:  claims that hashing and encryption were merely being used to try "mask" the use of names that conflicted with trademarks.

Any, even very convulsed way between something human can memorize and ip address will be regarded by courts as "mask".
"You type 'c-o-l-a' your browser opens that, you may try for yourself, your honor."

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

I see your point: you randomly assign 0xDEADBEEF to Alice registree. Have her sign on it. She now 'owns' 0xDEADBEEF random identifier. Then she locally (at end point) assigns 0xDEADBEEF to answer for distributed query for 'c-o-c-a-c-o-l-a'. As long as she points her random identifier to 216.64.210.28 nothing happens. If she points it to her counterfeits shop, big boys will act promptly with thick acta stick.
It might be worse yet: an average joe (who bought deer urine there) will not trust in IDONS anymore.

Name resolving is, um, about translating strings to numbers. Where are strings, there are owned, trademarked, registered or by other means forbidden strings.
System that will be ultimately 'dispute-resistant' equals to system where anyone can setup anything pointing anywhere. And thats good. As long as that anonymous one is not sole authoritative answerer for the rest of the world.

We want censor resistant, functional and trusted system for general use.
For niche uses there are already working distributed search'n'resolve systems built in TOR and gnutella.

[bug1]

(12-12-2010 12:46 AM)ohir Wrote:  We want censor resistant, functional and trusted system for general use.
For niche uses there are already working distributed search'n'resolve systems built in TOR and gnutella.

No point trying to make a censorship resistant resolver if it depends on censored information to be entered by the user.

* bug1 makes note to read up on how Tor and gnutella resolve things...