[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heirarchical DNS ?!?!?!



Dave and all,

Dave Crocker wrote:

> >>> What is going to change is the environment in which we are operating.
> >> POC
> >>> and CORE will find that they have a very simple choice.  they will either
> >>> join a DNS conferation which is now being formed, or if they do not join
>
> Actually, the nature of the challenge is exactly the opposite.  The
> question is whether those who have been choosing to operate outside of
> IANA's sphere of influence will choose to change and, instead, cooperate
> with it.

  First of all to characterize those that there is only one true Root has been
debated before.  And determined that the current Legacy root has the largest
exposure by far than any other.  It is also true whoever, that sharing
of that Root does not mean that new gTLD's or TLD's must be added
to that root considering a Shared Root configuration.  In fact we would
prefer this approach in many respects

> POC/CORE are now, and have always been, agents of IANA.  As such,
> there is no question about POC/CORE continuing to be subject to IANA's
> authority.

  Yeah, we know Dave.

>
>
> In contrast to this is the collection of rogue alternate-root efforts which
> attempted to supplant IANA and failed.  Will THEY choose to mend their ways
> and become cooperative?

  Now you are saying that those whom wish to go their own ways do not or
should not have the right to do so.  As I remember some months back you stated
that they can do so if they wish.  Now you say the opposite.  Curious change
of opinion.

  To characterize alternatives a "Rogue" is inflammatory and incorrect.
Different
yes, but Rogue, no.  You seek yet again from this statement to smear these
efforts in order to further your own desires.  That is unfortunate indeed.
It says volumes about your position and your character.

>
>
> >>fact is that the DNS is a hierarchical system and therefore it has only
> >>one root and therefore one set of true top level domains. Someone has to
>
> This is an entirely correct assessment of the nature of the DNS.

 Under the current configuration this is correct.  This does not have to remain
tobe so however.  We have choices.  The "Shared Root" configuration that I
have outlined many times is just one of those options/choices.

>
>
> >this fallacy being propogated. BIND is NOT, in and of itself, heirarchical.
>
> This is an entirely correct assessment of the nature of BIND.



> The problem is in thinking that flexibility in the latter makes for
> flexibility in the former.

  Actually it does.

> What it validly allows is selection of THE root
> by individual participants, rather than requiring that there be only one
> candidate for root.

  Not technically correct Dave.  One can have any number of Root selections
as secondary, and multilevels down from there.

> That is, if the current root is unacceptable, the
> community can choose to move to another.

  They most certainly can.  I do now.

>
>
> The view that each user of bind can configure its own collection of root
> components and that, somehow, this will be viable on a large scale in the
> Internet, is a failure to understand both the nature of the DNS naming
> scheme and the effects of scaling.

  Scaling data is at best incomplete to date.  So you statement here has not
basis in fact.

>
>
> It is important to distinguish between configuration flexibility by a piece
> of software, versus global operation of an infrastructure naming service.

  This is a nice operations statement, that is not only not founded but can and
has been proven untrue.

>
>
> >In fact, one has to take some pains to NOT make it root-less. The fact that
>
> The fact that a piece of software has the ability to reference replicas of
> the root does not make the SERVICE rootless.

True.

>
>
> >Operating the DNS system in heirarchical fashion is running it at reduced
> >specification.
>
> That statement is technically and formally incorrect.  The DNS is a
> strictly hierarchical -- i.e., tree-structure -- system.

  True.  BUt it needs not remain so, nor should it.

>
>
> >>that nothing breaks. That's why no new gTLDs have been added during the
> >>three years that many have been demanding them. And, in fact, after three
>
> Well, no.  We'd have had new gTLD's added almost a year ago, had it not
> been for distractions caused by the US government.  On the other hand, yes,
> IANA has been diligent in taking the conservative approach to DNS
> operations that is appropriate for an infrastructure service.

  Conservative approach is one thing.  Doing nothing is yet another.  Hence the
need for change.

>
>
> >>long years of discussion and compromise, the gTLD/POC/CORE folks will only
> >>be allowed 7 new gTLDs. They then have to show that they can operate the
>
> This phrasing misrepresents the basis by which the number 7 was selected.
> The IAHC, itself, hammered out that compromise.  It was not imposed by IANA
> or any outside source.  So it is a matter of the POC/CORE community,
> itself, choosing to move carefully.

  Carefully?  Hell I haven't seen a single TLD added yet, nor any of your own
schedules met yet either.  False promises that the MoU process put forth
is much like the little boy crying wolf.

>
>
> >>IMHO this is a much safer approach to the problem than the "anything goes"
> >>solutions that have been promoted by the Alternic,
>
> yup.
>
> >>Your comments have made it seem that the US government was about to throw
> >>a wrench in the works that would stop the CORE registry from coming
> >>online. In fact, your comments above continue that impression. And yet in
>
> No.  It appears that the goal was to force things to go more slowly,
> apparently to satisfy the extreme "right wing" of the trademark community
> (in spite of support for POC/CORE by substantial, formal portions of the
> global trademark community) and by NSI, which was understandably lobbying
> hard to retain their impressive monopoly.
>
> d/
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Dave Crocker                Brandenburg Consulting        +1 408 246 8253
> dcrocker@brandenburg.com      675 Spruce Drive        (f) +1 408 273 6464
> www.brandenburg.com        Sunnyvale, CA 94086  USA
>
>

Regards,

--
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com