Return to New TLD Agreements Forum - Message Thread - FAQ

Username: jandl
Date/Time: Wed, April 18, 2001 at 10:56 PM GMT (Wed, April 18, 2001 at 6:56 PM EDT)
Browser: Microsoft Internet Explorer V5.5 using Windows 98
Subject: Email and privacy concerns with DoC duplication of a TLD


                "copyrighted by Warren Communications News (202-872-9200, and posted by permission."

E-Mail Disruption and Privacy Called Serious Concerns

Citing growing concern over ICANN’s intention to introduce a “.biz”
top-level domain name (TLD) in the face of an existing .biz TLD in another
root system, the newly elected chmn. of the Domain Name Supporting Or-ganization’s
General Assembly (GA) Thurs. called upon the Names Council
(NC) to form a working group to study the implications of colliding TLDs.
In his letter to NC Chmn. Philip Sheppard, Danny Younger said the flap over
.biz raised competition, Internet stability and possible consumer confusion
issues, and asked that the NC facilitate “the full and unfettered expression of
all views on this topic.” Sheppard couldn’t be reached by our deadline.

Younger’s move came just 2 days after his selection as GA chmn. was
approved by the NC. His top priority, he told us Tues., was to persuade the
NC to use working groups to focus on specific issues (WID April 10 p5).
Proponents of alternate root servers cheered Younger’s push for an air-ing
of the possible effects of colliding TLDs. “[Y]our letter...seems to point
out that you intend to redress the critically sensitive issues that threaten to
have far reaching consequences for the ‘average joe’ using the Internet,”
PacificRoot Chief Technology Officer Bradley Thornton wrote the GA
head. No one connected to an alternate root asked Younger to take on the
controversy, said Atlantic Root Network Inc. (ARNI) Pres. Leah Gallegos,
who operates a .biz TLD in a non-U.S. Govt. (USG) root: “Perhaps he sim-ply
has noticed that the issue is an important one.”

So far the debate over colliding TLDs has centered on the likelihood of
confusion on the Web. However, Thornton told Younger, “The real ‘hid-den’
nasties... aren’t that you might not know which ABC.TLD website you
will end up at (although this would occur on a regular basis), but things such
as mail transport and other peripheral forms of electronic communication
and protocols that depend upon [the Domain Name System (DNS)] as their
‘cable-car wire’ will be irrevocably and adversely affected.”

“Try this for a scenario caused by entering a duplicate .BIZ into the USG root,” Gallegos told us: Email sent to a domain -say, -“meant for someone who holds the domain in the ARNI registry, but sent by someone whose computer sees the [USG] root. Where does the mail go? It goes to the domain that the USG root sees.” 

Someone else then receives the mail, and vice versa, she said. All mail could be rerouted simply by pointing to a different root, Gallegos said. “You could send important mail to a company only to have it received by its direct competitor. Your medical provider could send mail to your company regarding an employee and have it go to someone else’s company with the same domain [in a different root server].”

Disruption to e-mail from colliding TLDs is a crucial issue, Gallegos said, but it’s just now hitting the Internet community’s radar screen because it’s more complicated than the problem of duplicate Web addresses. ICANN is “misleading the public terribly” when it says it’s responsible only for its own root, she said. ICANN is saying the USG root is the only one that counts, and that there are separate name spaces. But there’s no division of  name spaces within the DNS, she said.
- Dugie Standeford

My Own Additional comments:

[Please note that if there is no duplication by DoC, the email problem would not exist.  Mail would either reach its intended recipient or would bounce.  With the duplication, however, the above scenario applies and is a nightmare.  DoC can prevent it by either not entering a duplicate .BIZ (or any other duplicate) or by ICANN directing that the Neulevel registry choose an alternate non-duplicating TLD string such as "ebiz." 

There is a major FUD campaign being waged to make things appear as though existing businesses are creating the very problem that ICANN/DoC is promoting.  Had they simply paid attention and not attempted to isolate themselves from the rest of the world, we would not be facing this chaos.  Instead, this campaign will do nothing more than exacerbate the problem rather than solve it.  We have been trying to educate people for many months now regarding the consequences of DoC entering a duplicate into the USG root.  It has fallen on deaf ears. 

The political "opposition" has looked only at the politics of not recognizing existing TLDs and has ignored the real issue.  They have said there are separate name spaces and that those who work outside the ICANN framework are in a separate space and can operate in that space.  This is only partially true.  There are separate networks all over the world, but we all use THE SAME DNS.  It does not matter what "root" you point to.  Roots only point to TLD nameservers and one cannot duplicate a TLD in the DNS without causing serious problems, especially if that root is the one most widely used. 

That does not mean that DoC must include all existing operational TLDs in their root (although they should).  It does mean they must not duplicate them.  It is really simple. This has become a political football and is being pushed really hard by the special interests who want to control the Internet.  The information they have been feeding the public is misinformation (FUD) and the end result will be damaging to all users of the "net" when things go crazy.  The precedent they have set with their misinformation gives the go ahead to all roots to include duplicate TLDs. Wait until some entity out there decides to duplicate .com.

All I can say is, we tried.  I hope DoC listens. I hope the reasonable minds will also listen and understand the real issues.]



Link: Warren Communications News (202-872-9200

Message Thread:

Privacy Policy | Terms of Service | Cookies Policy