Subject: Re: [ifwp] Re: Interesting articles in Forbes and Chronicle of Higher Education

From: jeff Williams <[email-masked]>
Date: Sun, 06 Dec 1998 04:35:02 +0000

Roeland and all,

Roeland M.J. Meyer wrote:

> Frankly, I'm stunned. That's why I didn't answer your first note (that and
> working on Biz plans). One word, "Awesome". It's a very elegant solution.

  I personally agree with your analysis of Kents solution here, or a
potential
one anyway.  Good Job Kent!  >;)

>
>
> At 08:15 PM 12/5/98 -0800, Kent Crispin wrote:
> >On Sat, Dec 05, 1998 at 06:15:02PM -0800, Karl Auerbach wrote:
> >>
> >> > Here's another approach: Use DNS.  Instead of keeping lists and
> >> > emailing them around, or multicasting them around, just set up
> >> > alternate roots.  Thousands of them.
> >>
> >> Your approach does, in fact work best when we have one single root zone.
> >
> >It works with multiple root zones, as well.  The top is a forest, not
> >a single root.  There could be 20 or more trees with slightly
> >different information.  Down at the third or fourth level of the
> >structure you can do your grass roots stuff.  The TLD operators (and
> >new TLDs) would only advertise to the various roots.  Once you have
> >10000-100000 root servers, serving perhaps 20 or 30 different
> >versions of the root zone, it wouldn't take much software for
> >grass-roots operators to find the TLDs they wanted.
>
> I guess this means that one doesn't have a dot <grin>. Rather, dot would be
> "virtual". Do you have BIND4 or BIND8 in mind here? What about the UDP
> problem that Dave keeps hinting at, but never specifying? (Have you ever
> tried looking through someone else's code for a non-specific problem that
> *might* be there, or might not? It's basically trying to prove a negative.
> I've dropped it to a low-priority background task. Either Dave comes up
> with a specific failure mechanisim soon, or I'm dropping it as a waste of
> time altogether <sigh>, right next to Dave's credibility.)

  Exactly, "DOT" would be virtual.  This is what we do with SROOTS
in conjunction with BINDPlus.  This eliminates the need for a "DOT"
ROOT all together in actuality.  I am happy to see that Kent has come
around to this way of thinking from both a technical and philosophical
standpoint.  GRS also interfaces with this quite nicely from what I 
understand as well from others that are using this approach currently.

>
>
> >There is still a problem of how the 10-100 thousand root servers
> >become known to end users.  There is also a problem of load
> >balancing.  However, these are relatively minor -- several
> >straightforward approaches come to mind.
> >
> >Leaving us with what we all knew to begin with -- with proper social
> >acceptance, there are many possible solutions...
>
> In this thread, social acceptance isn't the issue. There is no point to
> measuring social acceptance in something that is infeasible. Anyway, we now
> have three distinctly different and independent means to support GRS
> servers. At least two of them will work with some degree of certainty. I
> would guess that we've adequately proven feasibility. Any more proof would
> require a working model, or a demonstration system.

 No problem with providing a working model Roeland.  Happy to comply.
Let me know, how you see this being done to YOUR satisfaction.  >;)

>
>
> >> The reason for the complexity of the other approachs is enable people to
> >> be grass-roots root operators and build their own root zone from
> >> advertisements that they receive from TLD operators.
> >>
> >> (We're not necessarily discussing the merits of whether that would be a
> >> good thing, but only the feasibility of having some sort of dynamic
> >> mechanism that didn't requre somebody to assemble all the information
> >> about the options [like who is running which version of which TLD and
> >> where the servers are this week] and keep it up to date.)
> >
> >There is a basic cross-bar problem -- each of the GRS operators has
> >to get information from each TLD registry.  If there are only about
> >10 reasonable combinations (3-4 conflicting TLDs), then several
> >schemes would work fine.  If there are hundreds of conflicting TLDs,
> >then the problem is intractable from a human perspective -- people
> >can't afford the time to keep track of all the conflicts.  This is a
> >fundamental issue of human information overload -- there is no
> >technical solution.  There are several possible outcomes: 1) a few
> >trusted humans will compile "good" root zones, and advertise them;
> >2) some mechanical criteria will win (use the TLDs with the most
> >entries, period); 3) people will just use the IANA roots.
> >
> >There might be other possibilites.  I'm betting on number 3, though
> >a screw up on the part of the USG could easily lead to number 1.
>
> Hmmm, he who gazes into crystal balls, often eats glass. An IANA/ICANN
> screw-up could also lead to either 1) or 2). The present root-servers would
> simply be one of the sources, as they are with current GRS and ORSC
> root.zone files.

   Actually, present Root servers are already in this position somewhat.
It is just that the IANA/ICANN/IETF do not wish to except this yet.  But
they
will.

> In fact, over the long-haul, the InterNet may gravitate to
> such a system. We simply do not know for sure. The internet, IMHO, will
> evolve into which ever is most flexible and open-ended. There will always
> be fringes, that's where the technical innovations come from. There is a
> certain amount of inertia which will always keep the core stable. It will
> incorporate useful innovations as they become vetted. IMHO, what the
> InterNet will not tolerate is stagnation, which is what we have now.

  Good point Roeland.  Exactly correct evaluation in our humble opinion.
No small collection of "Traditional" Internet organizations have the
ability
to "CONTROL" where and what direction the Internet will go, unless
they are open to any and all of the stakeholders/users.  Combine this
same thinking (Mode?) with alternative IP addressing protocols and
transport protocols that are needed now and to some extent used now,
you can without too much trouble see that Centralized control management
model without wide flexibility is doomed.

>
>
> >Kent Crispin, PAB Chair                        "Do good, and you'll be
> >[email-masked]                      lonesome." -- Mark Twain
> >
> >__________________________________________________
> >To receive the digest version instead, send a
> >blank email to [email-masked]
> >
> >To SUBSCRIBE forward this message to:
> >[email-masked]
> >
> >To UNSUBSCRIBE, forward this message to:
> >[email-masked]
> >
>
> >Problems/suggestions regarding this list? Email [email-masked].
> >___END____________________________________________
> >
>
> ___________________________________________________
> Roeland M.J. Meyer, ISOC (InterNIC RM993)
> e-mail: <mailto:[email-masked]>[email-masked]
> Internet phone: hawk.mhsc.com
> Personal web pages: staff<http://www.mhsc.com/~rmeyer>.mhsc.com/~rmeyer
> Company web-site: <http://www.mhsc.com/>www.mhsc.com
> ___________________________________________________
> Who is John Galt?
> "Atlas Shrugged" - Ayn Rand
>
> __________________________________________________
> To receive the digest version instead, send a
> blank email to [email-masked]
>
> To SUBSCRIBE forward this message to:
> [email-masked]
>
> To UNSUBSCRIBE, forward this message to:
> [email-masked]
>
> Problems/suggestions regarding this list? Email [email-masked].
> ___END____________________________________________

Regards,

Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: jeff Williams <[email-masked]>
Date: Sun, 06 Dec 1998 04:35:02 +0000

Roeland and all,

Regards,

Jeffrey A. Williams