Re: [ga] Question No. 1

[Jeff Williams <jwkckid1@ix.netcom.com>]

Roeland and all remaining assembly members,

Roeland Meyer wrote:

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

  Exactly right.  However I have some personal doubts that this will be done
all that soon.  It is obvious that some would be content if directly addressing
this issue/issues is not their preferred approach....

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

  This is the most significant point...

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

  Well they actually can.  BUt they do so at the peril of what can be achieved
and stand the great chance of causing confusion and perceived instability
of the Name Space.

>
> Trademark and IP interests cannot apply thier restrictions without also
> understanding the contextual references.

  Well again they can, but the degree of difficulty would be tremendous.

>
> The software needs to apply to a larger contextual scope than it has ever
> had to heretofore (the MultiBIND project has been announced)

Yes I was ask to participate in the "MultiBIND" project.  However
I declined as we already have BindPlus and SROOTS which has a
different although similar technical philosophy....  And our approach
is working now and is proven....

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 118k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1800 x1894 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html