Globality vs. Locality: a matter of context
What's Global?
Bcn: we can have multiple global namespaces for different kinds of names.
IP#s and DNS hostnames are both global
Dll: there's always a local context we talk about within
Public vs. private is just one kind of context (mm)
Mm: all names are local to a context already
Gb: all names should be dynamically assigned, based on context of use. Humans are very good at using names like "that" and "this"
BM: how many people participate in the namespace is a good metric
e.g. IP# is global to all of us outside of NATs
bcn: maybe it's a question of how explicitly one specifies the namespace one's in. The API, say, tells you what's in the domain and range. A filesystem -- what happens in a 'cd'? in Prospero, you explicitly spec the root of the ns
Gb: there's no good automated way to close the context -- implementation constructs in place of social ones?
RK: two aspects: globality (large scope) in the domain, range, or both; and breadth of adoption (global "trust")
MM: a global namespace is anything you can resolve completely with itself; without any external type/context/... bits.
CME: in a global namespaces, everyone uses the same symbols to refer to the same objects
BCN: "at a given time/place/observer, the same name will resolve to the same object for any time/place/observer" -- so globality is a measure of invariance
MG: a namespace is really a pair of things (references, resolver)... could be the identity function and still be useful. Globality is where people implictly understand the resolver.. no wait, logic has lots of examples of resolvers which do not exist. Namespaces can exist indepently, even with multiple competing resolvers
MM: consider XML tag namespaces, which have no resolver (identity)
LM: I don't think the resolver has anything to do with it: Merriam-Webster does not define the English language -- globality is the community of users. URLs continue to have meaning even after their resolvers are long gone (Internet Archive, Google).
Nico: the resolution service is just part of the context.
Dll: what's the meaning of a name? All possible ways of resolving it?
Recap: who's on first?
LM: a typical problem is multiple contending resolvers
ED: I'll resolve "mother" differently from you, "dog" probably the same, but there's still a lot of slack: I could be imagining a different kind of dog
EJW: Category fault! Category fault! The difficulty may indicate a false dichotomy between them
OK, so what's locality?
MG: Locality is just the intersection of namespaces, an algebraic operation
I want to send all my email addresses to all the people in this room, and we get this local TWIST99 namespace...
BCN: Reasons to localize 1) simplification, mental model 2) customization/personalization 3) deferred binding (e.g. "the local printer" when time comes to print)
HR: Localize for learning advantage: familiarity, frequency of use
SH: In fact, "domain name" is a really abstract term -- and it varies whether you're fetching an MX record, SOA, etc, etc.
DLL: Location itself is a distinction from local to global
What are some practical examples of context delimiters?
MM: Geographic, Temporal, Demographic...
EJW: Task (Domain) based -- RK objects to ask what's the namespace of the context itself!
MG: Organizational (employer-designated hierarchy). Social (self-defined: everyone who's my friend and yours)
RK: Resources: result depends on the resources of the machine you ask (caching, completeness of index, etc -- different answers on desk and lap)
Dll: any Attribute of the result space or its metadata (e.g. retreiving car registrations, and finding that make, model, color are additional keys...
EJW: which of these are more or less global?
LM: Context-delimiters are used to 1) change the set of bindings (not any McDonalds, but the closest one) and 2) base relative resolution ('Mom')
EJW: Is globality vs locality a property of the 1) namespace or 2) the resolver
Nico: "Pepe LaPew" : do I want a person, movie, fragrance...?
BobM: Locality is a property of use -- how do I intend to use it?
EJW: Is it possible to design a global namespace -- or does it just emerge from popular acclaim of local namespace.
MG: is GPS a global service? Arguably, but not indoors, not in deep space
RK: Again, distinction between global domain/range: intended to address the entire universe of some thing; and widely used/adopted
HR: 911 is a global number, but resolves to a local emergency number in a local switching system. GB: that scales very gracefully...
Dll: global iff it has a 'killer app' -- every namespace is born local....
RK: Advertising is a good metric of globality HG: it's a way to buy your way into someone's personal namespace.
IS HIERARCHY EVEN NECCESSARY?
Nico: resolving a flat name in some context (england), isn't that hierarchy by another name?
ED: you can have something locally hierarchical; heterogenous; not all flat. RK: e.g. .com, which is a flat second level, but hierarchical within each company?
Bob: intersection of multiple contexts: english, airline, green
Nico: partition IS possible without hierarchy
SH: you can always impose a hierarchy (ordering) on a set. That's mechanically scalable, but maybe not socially.
BCN: two perspectives: 1) user's experience: "English things" 2) system's experience: as mapped onto servers, say, a resolver in England.
DLL: the 1) identifier being structured or the 2) context being structured
Bill: Human Language is nonexhaustible, but nonhierarchical
Sami: hierarchy sacrifices network bandwidth (more rtts)
EJW: I sense the room thinks "hierarchy" is bad -- as a quality of a namespace or a resolver?
LM: there are 3 mechanisms at least 1) name assignment 2) name maintenance 3) name resolution. Over time, 2) diverges from 1) as individuals move and organizations change. And 3) may be completely separate. The Problem is that the design of many namespaces ties these three together.
RK: PGP is an exception
HFN: Delegation: who owns the namespace ; how can I find the namespace. Stability in ownership; dynamism in lookup.
DLL: Internet philosophy -- anarchy -- argues against hierarchy
ED: freedom is a better word than anarchy
CME: it's a better express of real-life: I establish relationships without consulting a central authority. Introducers, maybe, but no prior restraint.
Central authority does not imply hierarchy. Authority and Power are not synonymous
EJW: fear that over time, name-support institutions will gain power over time as 1) single point of failure and 2) divergence from users' interests.
ED: The power that ICANN has derives from contracts with registrars and registries -- all we can do is cut them off. Those say NOTHING about privacy, IPR, whatever; no one can petition us to shut someone else down.
RK: what are the engineering obstacles to multiple roots? Multiple GTLDs?
MarkK: dnssec, for example, moves to TCP to establish security, but also breaks the single-packet barrier to publish far more root server IP addrs. As yet, new roots are operated in an amorphous fashion.
RK: what are the performance implications?
MarkK: We're already up from 1 to 2 updates a day (12 hr cycle). IXFR, incremental zone update is not operational yet, but on the horizon.
SH: some things come down to deployed software: BIND is outgrowing its origins as grad student code. But an ns built on an Oracle database can update .com in 15 minutes. Multiple registries, multiple roots -- what kind of scaling are you asking about?
MM: conflict-resolution on the client side; IP hijacking -- lots of consequences of multiple roots
SH: the nice thing about a common root is that Ford doesn't have to track down a dozen spaces to add itself.
DLL: can you even have a non-hierarchical space if it's not resolved hierarchically.
CME: you may want it just for assignment, uniqueness. I have a strictly local algorithm for delivering packets over the early net
DLL: the early UUCP days -- what were the real obstacles?
MG: I had to keep a map in my head! (SoCal UUCP hubs). It was a lot of wizards passing along personal namespaces of routes... that could even be automated. It also worked like 6DOS, because there were a few highly-connected "celebrity" machines...
SH: a routing hub system (IS-IS routing). Hierarchy emerged socially, self-organizing, based on economic capacity, too. See Mike Schwatz's "dispersity routing" -- just throw out info to your neighbors, and it forms an ever-expanding breadth-first search.
BCN: Cheriton's V system did that too, with a fallback directory between regions.
SH: Check if Bill Manning is doing research at ISI on topology-informed domain search
EJW: what about, with enough disk, doing satellite-based global ARP, a billion roots on every watch?
A full zone transfer is 600Mb, uncompressed at this point.
Problem is thinner international links. Roots with poor connectivity have to be able to complete a zone transfer before beginning the next one.
HR: can we do without roots and hierarchy? Well, what will be do if the roots go off the air in two weeks, and everyone has to run their own root, and will market anarchy prevail? I bet hierarchy will redevelop quickly.
BCN: UUCP routes were propagated this way...
SH: I've heard that 5-10% of domain name traffic (by packets) is DNS queries -- been consistent since NSFnet days. Suppose we go to a decentralized system, 5x more transactions, 2x size with digital signatures, you could saturate the network...
EJW: what are other Iscale architectures for doing something like DNS?
July 1999 56,218,00 hosts advertising DNS.
ED: open or closed gTLDs?
GB: I would personally love to be able to set up a server and see who uses it. There's plenty of marketing opportunities...
ED: but what happens when .pepsi shows up in Japan and means something else... what if someone else starts up another .pepsi?
LM: I don't see that adding TLDs solves anything. It creates a lot of confusing noise. It's like adding all this landfill to the .com beachfront in a vain effort to create more waterfront property.
RK: Usenet analogy: private, directly-connected nntp news servers now outnumber the public commons. So what if anyone could set up a dns: server and boostrap off of the current DNS.
Stef: if a few are good, why not many?
GB: separation of concerns: if you want to make a new tldspace for a business-to-business ecommerce connection, then ihit seems legitimate to group that aspect in one TLD
MarkK: to counter a technical objection, we certainly can have a very, very large number of TLDs, just as well as we run second-level domains today.
BCN: leads to an epidemic of either 1) re-registration or 2) searching in many TLDs.