ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

[ga] the probable final solution: Jeff Field's wrong analogy


Dear Jeff,
your analogy is wrong (McDonnald should compare to .com, Burger King
to .biz, etc...) but let take your conclusion which is probably be the final
market/legal response to the issue. And let try to understand why knowing
it the iCANN god in three persons is acting as it does.

You cannot avoid that there are TLD managers (VeriSign for .com, ARNI
for .biz, IOD for .web etc...). These guies have the money (commercial) or
the users (cooperative ownership like mines).  But the users do not come
to them directly to resolve the addresses. They need disseminators (the
roots) because the DNS program on my PC asks its data to only one
source.

Now let assume we are a few weeks from now and multi-bind starts being
in use: the TLDs will only e-mail multi-bind users to have thel adding their
TLD in their include list.

Obviously the Linux users will be favored until MS includes the feature
into Windows or someone proposes a plug-in for doing the job.

When you think of it... there is already such a plug-in: New.net. The
New.plug-in started transforming xxx.shop into xxx.shop.netw.net. Many
others will do it. Starting with the rumored viruscom "porn.com" which
makes people who loaded it believing loading a New.net plug-in to have
their ".com" calls routed towards pornographic sites.

What does that mean? That we are living the last days of the iCANN if
there is not an alliance between RSCs (root service centers) to maintain
and protect the Internet DNS stability that iCANN endangered in different
ways with its TLD policy. iCANN believed it could politically (the actions
towards the GAC irt. ccTLDs and non-legacy TLDs) or technically ((M$
200 of R&D by VeriSign on DNS) ban them.

This is too late. Louis Touton and Joe Sims are not good enough in C
to know that Multi-Bind is not a big development (and that a multi sub-
root RSC Bind version is vey simple). And they had not enogh time and
no more technical support for a legal position.

Now only an alliance between the legacy and non legacy RSCs may be
technically and politically strong enough to warranty the stability of the
mail traffic (New.net does not support it) and to negotiate with the real
alternates RSCs like New.net and Name.Space an agreement on a stable
list of TLD and on a way to acknowledge and test new creations.

As multi-bind will show it we do not really need the iCANN (nor the other
RSCs). But they may help in providing some service and protecting the
net stability. One of these services is to provide a stable augmented root
(as Pacific Root, ORSC, CINICS and others already do). This only means
that iCANN machines are to use Bind 9.1.2 instead of 9.1.1 ...


Otherwise, the iCANN will disapear: as soon as 9.1.2. is validated? The
coinsusmens will have access to all the TLDs iCANN refused in MDR
and to all the non-legacy TLDs.

This is the time for the ccTLDs also to consider the situation and to put
some pressure on the iCANN otherwise they will lose their position as
many other national and regional TLDs will compete witgh them. We will
certainly reach the million TLD level, but IMHO we would be better off
in having it in cooperation and coordination that in disarray.

This must be discussed at the DNSO. Hence the subML on the
request for a WG-Inclusive Name Space Management I call for.

Jefsey


On 23:13 14/04/01, Jeff Field said:
>All this McDonalds/Burger King food talk got me thinking (a sometimes
>dangerous thing)...
>
>Today you have the ICANN root (McDonalds), the PacificRoot root (Burger
>King), and perhaps some other roots (Wendys, Jack In The Box, etc....but
>let's keep this simple).  Well, if I'm McDonalds, I don't sell Burger King
>food (unless I want to and have an agreement with Burger King that allows me
>to do so).  And, if I'm Burger King, I don't sell McDonalds food (unless I
>want to and have an agreement with McDonalds that allows me to do so).  On
>that, I think we can all agree.
>
>Applying the above well-accepted business practice to the ICANN root vs.
>alternative root situation, and the idea that the roots are for all intents
>and purposes in competition with each other...
>
>It would seem to me that PacificRoot has no right to include in their root
>the gTLDs (.com, .net, .org, etc.) or the ccTLDs (.uk, .au, .fr, etc.) that
>are contained in the ICANN root (hopefully, we can all agree that those TLDs
>were in the ICANN root first).  By the same logic, the ICANN root also has
>no right to include in their root the TLD's (.web, .biz, .scuba, etc.) that
>are contained in PacificRoot's root (hopefully, we can all agree that those
>TLDs were in PacificRoot's root first).
>
>If we can all agree on the statements above, then it would seem to me that
>the answer to the ICANN root vs. alternative root situation might be
>relatively simple...
>
>ICANN should request that PacificRoot immediately remove all ICANN TLDs from
>their systems.  If PacificRoot refuses to do so, ICANN should pursue all
>legal means to accomplish this goal (it's definitely a fair competition
>issue, after all, they're trying to drive traffic to their system and away
>from ICANN's system).  By the same token, ICANN should agree not to include
>in the ICANN root all the TLDs currently in PacificRoot's root (yes, that
>means giving up .biz...I'll deal with that below).
>
>Obviously, the practical effect of all this is that traffic to PacificRoot's
>root would dwindle to a trickle and the commercial value of .biz and .web
>and the other TLDs being in their root would quickly go to nil.  At that
>point, the .web and .biz registries (and the others) would have to make a
>decision; either stay with PacificRoot's root or try to get into ICANN's
>root.  If they want to stay in PacificRoot's root, fine.  If they want to
>get into ICANN's root, fine again...all they have to do is apply and be
>accepted.  Simple solution, huh?  But wait...
>
>I know, I know...I left out one little detail.  What to do with Melbourne IT
>and the fact that ICANN already awarded them .biz?  Well, assuming you could
>make all the above happen, I have to believe that both the .web and .biz
>registries would take a hard look at their business models and conclude that
>the ICANN root would be the only place to be.  Otherwise, having the rights
>to register .web and .biz domain names would be worth roughly zip.  And, if
>I were either, I would jump at the chance to cut a deal with Melbourne IT to
>get in on this first round of new TLDs.  And, if I were Melbourne IT, I just
>might jump at the chance to replace .biz with .web.  So, the solution to
>this problem just might be to...
>
>Get ICANN, Melbourne IT, Christopher Ambler (.web), and Leah Gallegos (.biz)
>all in the same vicinity and let them play, "Let's Make A Deal"!  The
>dynamics might be:
>
>- .web might see value in being included in the first round of new TLDs and
>want to cut a deal with Melbourne IT
>- .biz might see value in being included in the first round of new TLDs and
>want to cut a deal with Melbourne IT
>- .web and .biz might compete with each other to cut a deal with Melbourne
>IT
>- ICANN just wants to put this whole problem to bed with any kind of
>reasonable solution
>
>As a carrot to get a deal done, ICANN might/should consider making a rule
>for all future registry applications along the following lines, "the entity
>making application may not currently be operational in any other root system
>nor lay claim to any previously held or believed to be previously held IP
>(Intellectual Property) rights for the particular TLD for which it is
>applying".  IOW, the entity making a future application would be on equal
>footing with any other entity which submits an application for the same TLD.
>So, .web and .biz could stay in PacificRoot's root and never go anywhere or
>take the chance on a future application with ICANN...but not before they
>gave up their previous claims to the TLD and stood on equal footing with any
>other entity that wants the same TLD.  So, if I were Christopher or Leah, I
>think I'd want to cut a deal this time around.
>
>Anyway, I'm sure there can be some tweaking; I don't have all the
>answers...but just thought I'd send this along as "food for thought".
>
>Regards,
>
>Jeff
>--
>jeff field
>925-283-4083
>jfield@aaaq.com
>
> > -----Original Message-----
> > From: owner-ga@dnso.org [mailto:owner-ga@dnso.org]On Behalf Of
> > Christopher Ambler
> > Sent: Friday, April 13, 2001 7:06 PM
> > To: William X. Walsh
> > Cc: ga@dnso.org
> > Subject: Re: Re[4]: [ga] Call for a Working Group
> >
> >
> > > Which root server burger chain you go to decides which burgers you
> > > can buy.  Which root server network you go to decides which .com TLD
> > > you will be resolving.
> >
> > .com == Big Mac
> > .net == Whopper
> > .web = Hot and Juicy
> >
> > I don't care how many roots (burger chains) there are. There's only
> > one .com (Big Mac).
> >
> > Put another way - the first company to put up a serious .com in an
> > alternative root will find Verisign on them in a flash.
> >
> > > Just like McDonald's can't advertise that they are Burger King's.
> >
> > Nor can they call their burger a Whopper.
> >
> > > This is why you shouldn't use analogies like that, Chris  :)  No
> > > matter what analogy you use it can be twisted around on you to show
> > > the other side.  Some more so than others.
> >
> > Funny, that.
> >
> > Christopher
> >
> > --
> > 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
> >
> >
>
>--
>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

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



<<< Chronological Index >>>    <<< Thread Index >>>