RE: [ga] Question No. 1

[Roeland Meyer <rmeyer@mhsc.com>]

> From: Eric Dierker [mailto:ERIC@hi-tek.com]
> Sent: Wednesday, April 11, 2001 10:18 AM
> 
> Certainly the Countries that I have had the great pleasure of working
> with consider their ccTLD a public resource.  It seems that the U.S.A.
> considers .us a public resource.

> If the space is not considered a public resource then the contract
> between ICANN and the DoC is null and void.

There is a serious disconnect here. When dealing with finite physical
resources, these distinctions make sense. OTOH, when dealing with abstract
resources these distinctions make absolutely no sense. I am sorry to see
that some have managed to rat-hole the discussion into "argument by
analogy". There are no definitive analogies that matter. We need to grasp
the concepts directly and deal with them ... directly.

The facts are that names are simply labels. I may label a spherical rubber
object a "ball" and you may label a square steel cube a "ball". Both are
equally valid within their context. A third-party would have to deal with
each of us, within our own context, and use the labels appropriately, when
discussing those things within the given context.

The fundimental problem here is that labels are not resources at all. They
are a meta-object, a means for organizing a universe of entities such that
we can distinguish one from another. They are a reusable tag. We can change
the object that we place the label on. We can also place the label on
another object ... at the same time. The problem here is that the contexts
that the labels are valid within ... can also be labeled, which is valid
within a meta-context. This is a recursive phenomenon. I submit that, the
only other place we have this problem is in object-oriented design and
analysis (OOD and OOA). Analogies don't work, for defining the problem,
there either. Further, OOD and OOA technologies weren't available when the
DNS system was designed.

This is the fundimental theoretical problem that the original designers of
the DNS system ran into. Thair answer was that, they drew the line in the
sand, at the root-zone level, and said "we'll stop here, for now". The line,
while occuring at a natural demarcation point, is still arbitrary. This
reduced the problem to managable proportions, such that they could build the
initial DNS system (the decendent of which is ISC BIND 8.2.3). 

What we have here, as a direct result, is a system which is, intentionally,
context-limited. However, for labeling hosts on the Terabit project, it
worked. The problems we are dealing with today are a direct resultant of
applying the DNS system, out of its contextual referent, to problems that
really have their own context rules. Refering to my previous example, my
definition of "ball" differs from yours and unless we make an effort to
define the context of "ball" we will never understand each other. In the DNS
context, the label "ball" is a name space collision unless the relevant
context is defined. The key is that, understanding the context matters and
we'll never resolve this until we start dealing with context and
acknowleging that there are other contexts.

The practical application is that;

ICANN cannot ignore the contextual referents of the other root-zone
publishers. 
Trademark and IP interests cannot apply thier restrictions without also
understanding the contextual references.
The software needs to apply to a larger contextual scope than it has ever
had to heretofore (the MultiBIND project has been announced).
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html