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

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

Jim and all,

  Interesting post here jim.  Finally something WORTHWILE to critique
and ponder with respect to legitimate ideas anyway.  (See below for
our comments).

Jim Dixon wrote:

> On Mon, 7 Dec 1998, Roeland M.J. Meyer wrote:
>
> > Exactly, which is why we are looking into it now. I might point out that
> > Jim Dixon is looking at a slightly different requirements set than that
> > which Karl, Kent, and myself are looking. I am also looking at Jim's
> > requirements for similar reasons Jim is; Redundancy of root.zone data to
> > enhance current Internet reliability and to insulate the ISPs better from
> > root-sers.net corruption in the future. This is related to, but entirely
> > different from, the instance that Karl, Kent, and I are considering in our
> > design discussions. I think that Karl is just begining to realize this. The
> > three of us had TLD.zone information distribution in mind. It is a
> > different class of problem.
> >
> > Jim's case is actually prohibited from using the DNS system becasue it is a
> > back up for that same DNS system. The assumption is that the root-servers
> > are either unreachable, or unreliable at the time, in Jim's requirements
> > case.
>
> Over the last year or two we have seen
>
> *       corrupt data in several of the root name servers
> *       inconsistent data in the root name servers
> *       at least one domain (.ES) accidentally dropped from the root name
>         servers
>
> The system I have been sketching out makes it possible for local system
> administrators to deal with each of these.
>
> It also addresses a more fundamental problem.  The DNS is designed as a
> hierarchy, with one central point of authority.  However the information
> being distributed has many sources, each of them authoritative for its
> own zone.  For example, the .ES TLD registry, is authoritative for .ES,
> but this is lost in the current scheme, which represents the InterNIC as
> authoritative for the entire root zone.  So in the current scheme the
> pointers to .ES can disappear or be changed at the InterNIC's discretion
> (well, because of an error at the InterNIC) but under the proposed scheme
> this would be immediately obvious and operators would be able to take
> corrective action.

  The DNS currently has a central authority only because it is under contract
to NSI from the USG.  The design of DNS is not bound to a central
authority to the root necessarily, which many have now, in our opinion
pointed out.  Such centralization of authority is not necessarily the best
scheme to continue to proceed with given that the Internet is being
privatized.  In fact there are obvious inherent weaknesses in continuing
a centralized model at this juncture.  One that is the most important,
is the high possibility for "Capture" or continuance of monopolistic
practice.  I doubt that the majority of Stakeholders prefer that potential
even being possible.

>
>
> There are of course two questions here which have been blurred together
> so far.  The first is the question of who is authoritative for a given
> TLD, that is, who has the right to say where the name servers for a given
> TLD are.

  This should reside as in accordance with the White Paper, in the hands
of the Stakeholders collectively through a management mechanism.  Policy
should be determined by those Stakeholders collectively through majority
VOTE.  Implementation on that policy will than be carried out by those
that represent the Stakeholders in the Director and Board positions
to which they were elected to.  In this way, you have full compliance
with the White Paper, and built in stability while still providing choice and
flexibility from the Stakeholde/user community.

  So , the importance of the Root becomes, as it is currently the important
point of control.  Name servers for particular TLD zones must than equate
to that Root if you are to continue with a central Root.

  Now if the design of DNS is changed to allow for multiple Roots, as
we and others would prefer, you would than provide for yet more
flexibility and more choice as to policies for Name Servers and their
respective TLD zones.

>
>
> The second question is where the name servers for a given TLD are.

  Why should this matter?  I assume when asking this question you
are referring to physical location.

>
>
> We have only been dealing with the second question.  That is, we have
> assumed that everyone knows, for example, who is authoritative for .ES,
> or more exactly we have assumed that everyone knows (or can easily find
> out) what the PGP public key for the .ES registry is.

  We should already know who is authoritative for the .ES registry.  That is
the Stakeholders are authoritative or should be.

>
>
> It would of course be possible for IANA, ICANN, or any other trusted party
> to publish a list of TLD registry public keys.
>
> >       On other words, there is no valid root-server to connect to and DNS
> > is otherwise considered "down" unless there is a local root.zone cache. In
> > this case, multi-cast may not be usable either. But I don't know enough
> > about multi-cast to say (Karl?).
>
> Multicast is just another way of distributing the data, so long as there
> isn't one central authority administering the multicast network -- in
> which case we would be back at the same problem.

  Yes, and as this is a circular argument/Discussion, we will never make
any progress until we change this.

>
>
> --
> Jim Dixon                                                 Managing Director
> VBCnet GB Ltd                http://www.vbc.net        tel +44 117 929 1316
> ---------------------------------------------------------------------------
> Member of Council                               Telecommunications Director
> Internet Services Providers Association                       EuroISPA EEIG
> http://www.ispa.org.uk                              http://www.euroispa.org
> tel +44 171 976 0679                                    tel +32 2 503 22 65
>
> __________________________________________________
> To receive the digest version instead, send a
> blank email to ifwp-digest@lists.interactivehq.org
>
> To SUBSCRIBE forward this message to:
> subscribe-IFWP@lists.interactivehq.org
>
> To UNSUBSCRIBE, forward this message to:
> unsubscribe-ifwp@lists.interactivehq.org
>
> Problems/suggestions regarding this list? Email andy@interactivehq.org.
> ___END____________________________________________

Regards,

--
Jeffrey A. Williams
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-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208