New gTLD Comments by Leap of Faith Financial Services Inc. (November 23, 2008)
- To: gtld-guide@xxxxxxxxx
- Subject: New gTLD Comments by Leap of Faith Financial Services Inc. (November 23, 2008)
- From: George Kirikos <gkirikos@xxxxxxxxx>
- Date: Sun, 23 Nov 2008 17:06:58 -0800 (PST)
Comments on New gTLD Applicant Guidebook
Submitted By: George Kirikos
Company: Leap of Faith Financial Services Inc.
Company URL: http://www.leap.com/
Date: November 23, 2008
If any other individuals or organizations wish to endorse or build upon
the comments below, please feel free to do so by referencing our
company name and the date of our comments that we've submitted to
We oppose the introduction of new gTLDs by ICANN, as the negative
externalities (e.g. phishing, consumer confusion, and defensive
registration costs, domain abuse) imposed upon others would outweigh
the benefits. They threaten the stability and security of the entire
internet. Given that ICANN has decided to go ahead with new gTLDs
despite these grave concerns by my company and many other companies and
stakeholders on the internet, in order to appease a small minority of
groups that wish to profiteer at the expense of others, it is our
position that any new gTLDs must be carefully introduced in such a
manner that the costs of those negative externalities are fully
internalized and borne by the applicants. Thus, the only applications
that should be accepted by ICANN are those few which will be a net
benefit to the broader internet.
Competition should have the effect of decreasing prices for
registrants. However, ICANN has accepted contracts with VeriSign and
other gTLD registries that have led to the exact opposite for
consumers. This represents a fundamental failure by ICANN that appears
to be exacerbated by the current draft guidebook. Modifications are
clearly required to repair these flaws before any final document,
otherwise it would behoove the Department of Commerce to discontinue
its Joint Project Agreement with ICANN
Throughout the draft document, ICANN refers to the policy development
work conducted by ICANN's GNSO. The GNSO does not properly reflect the
interests of internet stakeholders, as it has been captured and twisted
by the the registry and registrar constituencies ("the contracted
parties") who have been given undue voting power (double weighting)
compared to other constituencies. Thus, we dispute that there is any
consensus at all for new gTLDs. Instead, the policy development process
has been co-opted to favour a minority of special interest groups who
wish to profiteer from their introduction. That minority includes ICANN
itself, which presents itself to the public as a non-profit
organization, but whose own spending, as documented through the IRS
Form 990 disclosure statement (available through Guidestar.org for
free), demonstrate extravagant growth in spending to benefit insiders
and disregard for accountability. Until ICANN gets its own house in
order, to reflect prudent spending and a policy making body that
reflects more than just insiders, it should refrain from dramatic
policy changes such as the introduction of new gTLDs that threaten the
stability and security of the internet.
B. Module 1
1. Under 126.96.36.199, it is unclear what portions, if any, of the
applications will be made public, besides merely the list of
applications. Transparency and accountability demand that the entire
application be made available for public scrutiny. Organizations
applying for a new gTLD are consuming a valuable resource that belongs
to the public, not a private resource, and thus public disclosure
should be mandatory, just like broadcasting license applications, etc.
2. Under 188.8.131.52, it is not disclosed how the "panels of independent
evaluators" will be chosen or accredited. In particular, since these
evaluators are secret, there is a lack of transparency and
accountability into conflicts of interests that will undoubtedly occur
in the evaluation process. The panelists should be disclosed to the
public for scrutiny. The USPTO, for example, discloses fully the names
of staff that review US trademark applications, thus demonstrating that
full disclosure works.
3. Under 184.108.40.206, ICANN recognizes that proposed registry services will
play a part in new gTLD applications, thus opening up the potential for
Trojan Horses in new gTLD applications to threaten registrants in old
gTLDs like dot-com. Equal treatment clauses exist in current gTLD
agreements. For example, Section 3.2.b) of the .com registry agreement
"ICANN shall not apply standards, policies, procedures or practices
arbitrarily, unjustifiably, or inequitably and shall not single out
Registry Operator for disparate treatment unless justified by
substantial and reasonable cause."
Thus, it is imperative that ICANN not accept any new gTLDs that could
affect existing gTLDs. This can be accomplished by renegotiating
existing gTLD contracts to remove these equal treatment clauses.
Alternatively, ICANN can create a framework for standardized contracts
amongst all new gTLDs, so that these Trojan Horses are entirely
eliminated (i.e. there would need to be broad consultation amongst the
entire community before any changes are made to the universal
As another alternative, ICANN can create a new class of gTLDs called
"broad consumer gTLDs" (or "large gTLDs") that reach a cumulative
number of registrations equal to 100,000 or some other selected number
to be decided by the GNSO and ICANN. These broad consumer gTLDs (like
.com, .net, .org) would not be able to assert their equal treatment
clauses due to their size (or in other words, "small gTLDs" would have
more flexible contracts without affecting registrant rights in "large
gTLDs", as the size difference would be be a "substantial and
reasonable cause" under existing registry contract language).
If a large number of applications exist for small gTLDs, frankly the
public does not have the time or the inclination to review each one in
order to ascertain whether those applications will impact existing
registrants in large gTLDs through Trojan Horses. ICANN should
recognize this reality, and plan for it accordingly by putting in
safeguards from the start.
4. Under 1.1.5, the next application round should not begin until 1
year AFTER new gTLDs actually become operational, so that the community
can gauge their impact. It is an undeniable fact that previous
introductions of new gTLDs have been utter failures, imposing negative
externalities that far exceed their benefits in most cases (except
perhaps for the sponsored gTLDs). There is no reason to believe that
failure is not going to be the reality once again. Indeed, the only
difference this time appears to be that ICANN appears to be permitting
massive failure through disorderly and haphazard introduction of new
gTLDs, focusing more on volume rather than quality. Adding time before
a future round allows the gathering of empirical evidence to document
whether this time was any different. Benchmarks should be established
in advance to ensure that ICANN does not simply "declare success" (as
it usually does in its boiler-plate press releases) despite universal
evidence to the contrary. It is important that ICANN actually learn
from past mistakes and adjust its processes, rather than simply making
bigger mistakes at the expense of the security and stability of the
5. Under 1.2.1, the eligibility requirements appear to be overly broad.
ICANN has a history of allowing dubious applicants to become registrars
from companies associated with spam or fronts for criminal entities.
The standards for entry into the root, a more serious obligation than
that of a registrar, should be set much higher than that for
registrars, to take into account the potential damage that can take
place by allowing malevolent entities direct access to the root. These
standards should include at a minimum civil and criminal background
checks on its management and major shareholders.
6. Under 220.127.116.11, history has shown that open gTLDs (like .biz or
.info) have been failures. Open gTLDs should not be permitted at this
time, and should be deferred until future rounds.
7. Under 18.104.22.168, the "Contract Execution and Post-Delegation" language
must be made stronger. ICANN routinely approves all material changes to
community-based applications. This represents a reward for
"bait-and-switch" applications, whereby the applicants promise one
thing, but then after their applications are accepted, devolve into
something very different from what they initially promised. Severe
financial and other penalties (including mandatory redelegation or
tendering to other prospective registry operators) need to be in place
to ensure that applicants live up to their contractual obligations, and
not be rewarded for these kinds of games.
8. As per our concern under point B.5 above, the required documents
under 1.2.3 for "proof of good standing" are insufficient. Malevolent
entities will most assuredly create brand new shell corporate entities
that have no history in self-selected jurisdictions in order to mask
themselves. Given ICANN's history in certifying registrars that later
proved themselves to be shams, higher standards are demanded in order
to protect the public. Financial statements of newly formed
special-purpose companies will be insufficient to detect iffy
9. Under 22.214.171.124, the "documentary evidence of ability to fund ongoing
basic registry operations for then-existing registrants for a period of
three to five years in the event of registry failure" is obviously
insufficient, as the number of "then-existing registrants" is ZERO!
Reference needs to be made to the projected number of registrants
within the applications, and furthermore funds need to be held in
escrow by a recognized third party, or some other form of security bond
should be in place.
10. Also under 126.96.36.199 the bond or escrow of funds to "fund ongoing
basic registry operations" is far too small a bond given the negative
externalities that can be created by a malevolent registry operator
that supports phishing, spam, TM infringement and other cybercrime. The
bond or level of insurance needs to be much higher in order to act as a
deterrent to criminal organizations. Something on the order of USD $10
million would seem to be appropriate, either as insurance or a security
bond, to ensure that registry operators do not simply wash their hands
of ICANN and walk away from their gTLD obligations after abusing the
rest of the internet. The "documentation of outside funding
commitments" also needs to be strengthened beyond simply
"documentation" -- security bonds or insurance are stronger than simply
words that can be altered. ICANN has no real means to assess the
creditworthiness of these outside sources of funding, nor means of
enforcing their financial commitments.
Insurance is a market-based solution, given that high risk entities
(e.g. folks with dodgy histories) will face higher premiums from
insurers than safe entities (e.g. established companies or
communities). Good entities are rewarded, and bad entities are
punished. Insurers can place their own restrictions on their clients
(e.g. mandating certain procedures and safeguards) that act as an extra
layer of protection beyond what ICANN is able to police. Given ICANN's
poor history in policing registry operators (e.g. VeriSign's
SiteFinder) and registrars (too many to list!), it's clear that these
extra safeguards from insurance companies are essential.
If registry operators offer 10 year registrations, clearly 3 to 5 years
of funding or bonding are insufficient to meet their contractual
11. Under 1.2.5, we remain concerned that applicants will tweak their
agreements to favour themselves, as per our concern above in B.3,
thereby creating Trojan Horses that affect registrants in other gTLDs.
The need for universal standard agreements that cannot be altered
except through well publicized long processes with actual written
notice to all existing gTLD registrants, so that they can make informed
public input, is essential.
12. Under 1.3, we are very concerned that IDNs can and will be used for
phishing, TM infringement, consumer confusion and malevolent purposes.
Strong safeguards must be in place to prevent these activities. Indeed,
it was once talked about that existing gTLD registrants would see IDN
gTLDs bundled with their existing domains (either through NS-names or
DNAMEs). For instance, example.com would be able to resolve, at no
extra charge, example.kappa-omicron-mu, where ".kappa-omicron-mu"
represents a Greek IDN equivalent to .com. ICANN appears to instead
have disregarded what would have been beneficial to the public and
registrants, and even to registry operators in being able to add value
without extra costs. Instead, it will cause companies to face increased
costs through either explicit defensive registrations costs or other
negative externalities. Bundled IDNs, at no extra costs to existing
gTLD registrants, should be strongly encouraged, in order to promote an
international domain name system, and to also prevent a split-root,
thereby ensuring security and stability.
13. Under 1.3.1, there is no incentive to for applicants to be truthful
in documenting what the string translates to in English, thereby
informing their competitors and others. This incentive needs to be
countered by severe financial and other penalties (including removing
the gTLD entirely) at any time, including after any string contention
time has elapsed. It is more likely that any gTLDs that slip through
the cracks will be discovered after the gTLD has entered the root,
rather than during the application process, and procedures need to be
in place to remove these offending gTLDs for cause.
14. Under 1.5.1, the gTLD Evaluation Fee is far too small, as it does
not recognize the negative externalities imposed upon others, and the
degree of profiteering that will take place to abuse registrants of not
only its own gTLDs, but those of other gTLDs. In an age where
individual domain names in sunrise periods (e.g. .asia, .mobi, etc.)
routinely are 5 figures for just one domain, it is clear that an entire
gTLD should cost significantly more. This can either be reflected in a
higher gTLD Evaluation Fee (perhaps $1 million), or additional fees
once an application is accepted (i.e. before an accepted gTLD is
allowed to resolve by entering the root), or higher annual ongoing
fees, or a combination of all of the above. This ensures that frivolous
and malevolent gTLDs do not become the norm, as six-figures is hardly a
disincentive to criminals or profiteers in this day and age. Negative
externalities are certainly in the millions and tens of millions of
dollars per new gTLD, and these need to be internalized through direct
costs upon new gTLD operators, in order to protect the public.
15. Also under 1.5.1, the Registry Services Review Fee should be be
considerably higher, given the equal treatment clauses previously
discussed in B.3. A $50,000 fee would be willingly paid by the operator
of a Mickey Mouse gTLD that no one cares about (and thus is not
watching closely), in order to create a bad precedent that can be used
by a large gTLD such as .com, .net or .org. Until these linkages
between contracts which can encourage Trojan Horses are broken once and
for all, ICANN needs to proceed with caution. We've already seen twice
that registry operators have tried to introduce tiered-pricing into
their contracts (once 2 years ago, and once again through this draft
guidebook which eliminates price controls, see further below), despite
the huge outrage of the public. It's clear that they will not stop in
their attempts to abuse registrants and thus safeguards must be in
place to block their future attempts.
16. Under 1.5.2, it's ridiculous that ICANN would even consider
payments by credit cards to be acceptable, given the ability of people
to do chargebacks months after a transaction. Only irrevocable forms of
payments should be allowed, namely wire transfers. Any cheques (which
should be discouraged) should be certified, and any actions dependent
on payment should await funds having fully cleared (which in the case
of international cheques might be weeks or even months).
17. Under 1.5.5, refunds should not be available. Applications for a
new gTLD are a serious matter, and shouldn't be a game of trial and
error, with refunds if unsuccessful.
18. In general, the "Cost Considerations" accompany document should not
consider past sunk costs. Those are mostly irrelevant at this point.
What is far more significant is not the actual cost of reviewing an
application, but the negative externalities cost on the public. These
negative externalities are far higher than any application review
costs, and must be considered in the process. This is basic economics.
A bridge would not be approved in a certain area if the costs imposed
on a neighbourhood or the environment were too high. Similarly, all
these "new gTLDs to nowhere" similarly need to consider the negative
economic costs imposed upon others, besides simply the profiteering of
the applicants and other insiders.
C. Module 2
1. Under 188.8.131.52, ICANN explicitly recognizes that the introduction of
new gTLDs can and will cause user confusion and loss of confidence in
the DNS. Despite this, ICANN has trumpeted to the world that thousands
of new gTLDs are coming, which will cause chaos. The costs imposed upon
others by this chaos need to be imposed squarely upon prospective gTLD
registry applicants, and not society. Just as domain tasting, which
imposed huge externalities upon others, was mitigated through the
imposition of fees, similarly new gTLDs which bring externalities to a
much higher order of magnitude must have fees that will mitigate the
costs imposed upon others. Thus, we reiterate our comments in section
B. above, if ICANN goes ahead at all with new gTLDs despite the
widespread opposition to them.
We do not believe that an algorithmic approach alone is sufficient in
determining string similarly. It must be open to human review.
Algorithmic approaches have not stopped spam or other abuses, as
machines cannot perfectly account for all possible scenarios. Abusers
will adapt, and think of things that the original algorithm designers
had not considered. By its very nature, any algorithm will not be
perfect -- it's a case of garbage in, garbage out.
One can already notice an error in the algorithm designed for "visual
similarity." It's obvious the designers of this draft document are
imperfect, as they have not appeared to consider "aural similarity"
(i.e. strings which sound alike when spoken aloud). Given the
proliferation of voice interfaces to the internet, it is clear that
visual similarity alone is an insufficient standard.
Furthermore, other forms of similarity can exist that ICANN appears to
have not consider. Visually impaired people who read in Braille rely
upon touch, for example, and one should obviously consider how a new
gTLD might be confusingly similar to an existing gTLD based upon a
system of touch like Braille.
Other user interfaces besides touch and voice exist or might exist in
the future (e.g. neural interfaces; I'll leave it as an exercise for
staff and the community to enumerate others), and it is imperative that
string similarity criteria consider proactively all these new
interfaces, instead of rushing to introduce new gTLDs in a haphazard
manner and leave it to future society to deal with all the problems
that will ensue.
2. Under 184.108.40.206, ICANN's hypocrisy in regards to externalities imposed
upon others is revealed in all its glory, as it reserves all of its
trademarks and trade names from being registered by other applicants.
This goes to the heart of why new gTLDs are a bad thing, as they impose
costs upon others. ICANN seeks to lower its own policing costs by
ensuring that no one else can register names that it feels are
important to itself, yet denies that same right to all others. This
utter hypocrisy demonstrates to all that new gTLDs should not be
permitted, by ICANN's own behaviour in trying to protect itself. ICANN
might say in some forums or media or press releases how great new gTLDs
are, but one can see their true beliefs by the length of the reserved
names list in this section of the draft.
Because millions of other organizations do not get the same protection
that ICANN is receiving, it is clear that the case for new gTLDs is a
weak one. At a minimum, before new gTLD applications are considered,
ICANN should allow anyone to add to that reserved list, for a small fee
of say a one time blocking fee of $10 per name. That is $10 more than
ICANN is paying to block its most favoured terms. Any prospective
applicant that wishes to register a prospective new gTLD that is on
this expanded reserved list must then negotiate individually with the
organization(s) who have bought the $10 block. Until all the blocking
rights are purchased by the relevant applicant, the applicant shall be
barred from proceeding further with that new gTLD. Blocking rights
should be renewed annually without cost increase, and of course be
transferred by private agreement. Multiple blocking rights to the same
string should be permitted (e.g. if multiple companies don't wish .ABC
to be available, they can each pay $10 to block the name; if someone
desires the string, they need to negotiate with each holder separately,
each of which has the right to refuse to give up its blocking rights).
3. Under 220.127.116.11, ICANN recognized that new gTLDs might cause
instability of the DNS. Not only should reviews be undertaken during
the application process, but should continue even after a new gTLD is
approved. Mistakes made during the application process (and ICANN has
demonstrated a history of making mistakes) must be able to be
corrected later, instead of acting as precedents that institutionalize
and make standard bad prior decisions.
4. Under 18.104.22.168.2 , reference is made yet again to visual similarity.
We reiterate our comments in C.1 above that aural, Braille and other
emerging forms of similarity need also be considered. E.g. .calm would
be aurally similar to .com, and should not be permitted.
5. Under 2.1.2, we reiterate our previously stated concern from above
(B.3) of proposed registry services that might trigger the equal
treatment clauses of existing gTLDs, thereby creating Trojan Horse
stealth precedents that can be used to affect existing registrants in
large gTLDs such as .com, .net or .org.
6. Under 22.214.171.124, it is clear that ICANN is rushing forward with new
gTLDs despite concerns that applicants might not have deployed an
actual registry in the past, or have any operational experience of
expertise. Third-parties contractors should be certified as having the
technical background, and applicants should either have the technical
background themselves or have contracts in place with those certified
The financial capability questions need to be very carefully
constructed to ensure that malevolent entities face enormous obstacles
to securing a gTLD (they've already demonstrated they can operate a
registrar for years under ICANN's nose with no repercussions). This
would require performance bonds or insurance, as discussed earlier in
this document (B.10). Applicants and major shareholders should also
undergo thorough background checks, as previously discussed. Past
bankruptcies, frauds, criminal or civil judgements, and other negative
behaviour should weigh strongly against prospective applicants.
7. Under 2.1.3 and 2.2.3, we repeat our concerns from point C.5
regarding triggering of equal treatment clauses for new registry
8. Under 2.1.4, we reiterate our objection to refunds.
9. Under 2.3, there are no repercussions listed for violating conflicts
of interest, or having contacts with parties one is supposed to keep
away from. These repercussions need to be made explicit.
10. Under the Attachment to Module 2, page A1, we are concerned that
language like "Within that framework, applicant?s responses will be
evaluated against the criteria in light of the proposed model." leaves
the application process wide open for abuse and gaming. In particular,
incentives will exist for applicants to lie or pretend to be something
they are not when proposing a new gTLD, in order to get more relaxed
"subjective" treatment. For example, an applicant might pretend to be
in financial need or targeting a very small group of end users, in
order to get special treatment, but later on do a bait-and-switch, and
use the more relaxed review to its advantage. Saying that the "criteria
should be flexible" encourages false applications to take place.
11. Under the Attachment to Module 2, page A2, ICANN again talks about
safeguards for registrants. They talk the talk, but do not walk the
walk, given that this draft contract itself opens up the 2-year old
issue of tiered pricing for existing gTLD registrants, due to the lack
of pricing controls in these draft agreements. People without any
interest in new gTLDs will be negatively affected, despite flowery
language by ICANN that its showing balance and looking out for
registrants. This is an organization that has approved perpetual price
increases for monopolistic and oligopolistic registry operators in an
environment of declining technology costs. We put forward the position
that ICANN's demonstrated incompetence in creating safeguards for
registrants should preclude it from introducing new gTLDs, until such
time as it creates those safeguards. Indeed, if it does not create
those safeguards, the Department of Commerce should not renew the Joint
Project Agreement with ICANN.
12. Under the Attachment to Module 2, page A3, financial questions
should not be kept confidential. Criminal and other background checks
should also be authorized in these applications and conducted by the
reviewers or their agents.
13. Under the Attachment to Module 2, page A6, the contacts should
provide additional details such as passports, national ID or SSN
numbers, etc., to ascertain their identity and permit relevant
background checks. Major shareholders should also be disclosed and
reviewed (i.e. top of page A7) with sufficient details to allow for
background checks. Since there can be issues of direct vs. indirect
control (e.g. a shareholder might simply be another shell company, that
is eventually owned by another individual), the application must take
this into account. Furthermore, groups of individuals operating under a
common purpose can individually be less than 15%, but due to that
common purpose should still be disclosed, e.g. a legal partnership,
14. Under the Attachment to Module 2, page A9, we once again repeat our
objections to registry services that act as a Trojan Horse to trigger
the equal treatment clauses in existing gTLDs.
15. Under the Attachment to Module 2, page A11, the lifecycle of a
registration should require the redemption grace period, for the
protection of registrants. Furthermore, an applicant failing question
31 (abusive registrations) should not be allowed to proceed further.
The standard for "meets expectations" must be kept high.
16. Under the Attachment to Module 2, page A13, wildcarding of
nameservers (question 35) ala SiteFinder or any other scheme should not
17. In general, I expect that many prospective gTLD registry operators
will simply cut and paste answers provided by others in the relevant
sections, and thus many of the answers "demonstrating competence" will
be a sham, as they were simply copied from other applicants. Applicants
must substantiate their answers with evidence that they will actually
do what they propose, instead of promising the world in their
applications, and then delivering substantially less after they
actually get approval.
D. Module 3
1. As per our comment in C.3 above, we believe a Dispute Resolution
Procedure is insufficient, and that instead a blocking mechanism that
allows any organization to add to the list of reserved names, just as
ICANN protects its own favoured names (both trademarks and names that
it does not have trademarks rights), should be adopted before any new
gTLDs are introduced.
2. Alternatively, an Ascension Allocation Method, as previously
whereby applicants for .string must first demonstrate ownership and
control of string.com, string.net, string.org, and other existing gTLDs
first, before being allowed to ascend from the 2nd level to the top
level, should be adopted instead. This provides a market-based
allocation method, and allows successful owners of 2nd-level domains to
ascend accordingly, minimizing the impact upon others.
3. All objections and responses should be public in their entirety
(unlike the UDRP whereby only the decision of the panel is public).
4. Under 3.4.3, the language "The parties to a dispute resolution
proceeding are encouraged?but not required?to participate in a cooling
off period to determine whether the dispute can be resolved by the
parties." This should be added to the UDRP (i.e. non-mandatory
5. Under 3.4.4, the language "Neither the panelists, the DRSP, ICANN,
nor their respective employees, Board members, or consultants will be
liable to any party in any action for damages or injunctive relief for
any act or omission in connection with any proceeding under the dispute
resolution procedures." obviously in cases of fraud or negligence,
ICANN and the others should be held accountable in court, so the
language needs to reflect this reality. The dispute resolution process
is not the ultimate arbiter, as the courts can and will hold ICANN and
others accountable if there is a miscarriage of justice. Indeed, ICANN
should prepare a contingency fund for the massive potential litigation
that may occur for not having thought through properly the introduction
of new gTLDs.
E. Module 4
1. We repeat our prior concerns (see C.1) that visual similarity alone
is insufficient for determining string similarity.
2. Under 4.3, auctions alone are insufficient mechanisms for allocating
gTLDs, as they do not address the negative externalities imposed upon
others. ICANN cannot be trusted to use the auction proceeds in a
financially responsible manner, given what has been revealed in its IRS
Form 990 disclosures, whereby ICANN's budget and staff compensation has
been exploding to unreasonably high levels. Any proceeds should be used
on a dollar-for-dollar basis to reduce ICANN fees for existing gTLD
registrants, thereby refunding partially the externalities that ICANN
is imposing upon society. Debacles like the ICANN Fellowship Project,
whereby ICANN pays the travel expenses and provides stipends to people
around the world in order to have an audience for its meaningless
public meetings around the world (that would otherwise be poorly
attended, and could instead be provided through remote participation)
should not create new precedents for even grander debacles that ICANN
and its insiders hope to fund through auction proceeds. Financial
prudence in these tough economic times means not funding white
elephants, but instead rebating the fees back to domain registrants.
3. In the "Resolving String Contention" commentary document, once again
references are made to visual similarity alone, which are insufficient
(see C.1 above).
4. In the "Resolving String Contention", bidders during any auction
must place a bidding deposit of large enough size to ensure that no
fraudulent bids take place (in which case the auctions would be
replayed, but the deposit forfeited to the other bidders). It's unclear
that the current mechanism adequately addresses this, given the short
time frames discussed (bank letters of credit or other instruments
might be required before the auctions). We've seen spectrum auctions,
for example, where bidders defaulted, e.g.
F. Module 5
1. We reiterate our previously submitted comments in regards to tiered
pricing, as submitted at:
Due to the equal treatment clauses in existing gTLD contracts, and the
removal of price controls, the Base Agreement represents a Trojan Horse
that can be used by existing gTLD registry operators to engage in
ICANN staff who oversaw the drafting of this base agreement should be
fired, as they demonstrate either a) utter disregard for the protection
of registrants, ignoring the outcome of a debate from 2 years ago when
the same contractual flaws existed in the .biz/info/org draft
agreements, or b) incompetence for not understanding the
interconnectedness of existing gTLD contracts that would be impacted by
these new draft contracts, if adopted, or c) both. ICANN's Board should
investigate who was responsible, and hold them accountable, otherwise
what little credibility they have remaining will be eliminated, given
this shocking disregard for past Board decisions. This is the
equivalent of ICANN staff allowing SiteFinder or other past contentious
issues to be in the base agreement, and should be treated as such,
namely a grave breach of the public trust. I cannot overstate the level
of outrage that exists from people who have informed themselves of the
implications of this base agreement.
2. Under 5.1, the language "All successful applicants are expected to
enter into the agreement substantially as written" is another Trojan
Horse that permits variances to be introduced through stealth. The word
"substantially" should be stricken from the language, and instead there
should be focus on a universal standard contract. ICANN should not be a
make-work project for lawyers who need to review every single deviation
from a standard contract. Instead, there is contractual and economic
efficiency in ensuring that only one universal contract applies to
everyone. Think of the chaos if every registrar had a different
contract with ICANN, for example, and multiply that by orders of
magnitude in a world with many gTLDs. Some in ICANN appear to desire
that chaos, perhaps for job security in the equivalent of digging
holes, i.e. reviewing contract changes that are not desired by the
broad community. With a universal standard contract, the opportunities
to play games are reduced, as attempts to make changes will be noticed
by the broad community of stakeholders. It would be like trying to
modify the UDRP -- everyone would notice.
3. On page 5-2 (top), it states "If at any time during the evaluation
process information previously submitted by an applicant becomes untrue
or inaccurate, the applicant must promptly notify ICANN and submit
updated information. This includes applicant specific information such
as changes in financial position and changes in ownership or control of
the applicant." I would call this the ICANN "License to Lie" provision,
because there are no explicit negative repercussions for applicants. It
is clear that financial and other penalties must be part of the
process, explicitly in the applications and in all contracts.
Otherwise, we will have bait-and-switch applications that are
encouraged by ICANN due to the lack of penalties.
4. On page 5-2 (and elsewhere), self-certification is insufficient,
given that applicants will embellish their applications. This is
especially important in the area of registry continuity. It's human
nature to lie, and its certain that some applicants will do so,
especially when there's money involved.
5. Under 5.2.2, all bonds or other instruments must be irrevocable, so
that letters of credit that exist on Day 1 are not yanked on Day 2.
6. Section 2.9 of the Proposed Draft New gTLD Agreement, namely
"Transparency of Pricing for Registry Services," is ridiculous, and
does not protect registrants from price increases. As we previously
stated in F.1 and elsewhere, this would have the impact of introducing
tiered pricing like .tv into existing gTLD registries like .com, via
the equal treatment clauses. The entire base agreement needs to be
completely rethought in light of this type of interaction with existing
gTLD agreements. It's perfectly "transparent" to publish that
Hotels.com will cost $1 billion/yr to renew, Games.com will cost $50
million/yr, Yahoo.com $100 million, Google.com $3 billion/yr, and so
on. The level of protection to the registrants, though, is absolutely
zero, demonstrating once again ICANN staff's utter incompetence, and
its capture by registry operators who only have fantasies of the type
of language that ICANN put into these drafts. An inquiry by the ICANN
Board should be undertaken immediately.
7. Fees in Article 6 are far too low. In particular, minimum fees of
$75,000/yr do not begin to adequately reflect the negative
externalities imposed upon others by each of these new gTLDs. The bar
needs to be set high to discourage frivolous and even criminal use of
new gTLDs that would undermine the security and stability of the DNS.
The 5% registry level fees should also be replaced with a fixed dollar
value per domain, reflecting externalities, otherwise free domains
(e.g. used for tasting) would be encouraged. It is much easier to
account for costs given that a zone file can be downloaded and the
actual number of domains counted, rather than attempting to audit
actual revenues (which can be open to accounting manipulation.
Note that the language in Section 6.1 explicitly mentions "average
annual price", indicating that ICANN acknowledges and perhaps even
encourages tiered pricing in these new gTLDs, and through the equal
treatment clause, in existing gTLDs that might wish to copy these
contractual terms into their current contracts with ICANN.
8. Section 7.2 regarding notice of changes is a disaster waiting to
happen. If there are 500 new gTLDs, all attempting to modify their
contracts, it will be impossible for the public to adequately review
them all. Given the equal treatment clauses, all one needs is one
Mickey Mouse gTLD to have a term approved, and that can then be copied
into large gTLDs like .com affecting tens of millions of registrants.
The need for a single universal standard contract is clear.
9. Section 8.1 anticipates litigation against new gTLDs that could
affect the financial stability of ICANN. Obviously this should be a
factor arguing against massive expansion of the new gTLD arena,
especially if "weak" operators are approved who would not adequately
indemnify ICANN. ICANN has not adequately disclosed the size of the
potential legal liabilities that could be imposed upon it due to the
actions of its new gTLD operators, or its failure to properly manage
The explanation in the draft summary of changes document that "ICANN?s
indemnification rights in Section 8.1 were simplified and appropriately
scaled to reflect the nature of the revised agreement and the
expectation that new registry relationships will be cooperative and
flexible" is amusing to say the least, given its naivety. Given them an
inch and they'll take a mile. ICANN should be writing its draft
contracts based on reality, not on the basis of fantasy and false
hopes, especially given the historic behaviour of registry operators
(e.g. SiteFinder, attempts to bring in tiered pricing in the past,
10. Section 8.4 does not adequately take into account the contingency
that the Department of Commerce will not renew the JPA, in which case
it must assign its contracts to the DoC. The language should be altered
to reflect this reality. Indeed, the Department of Commerce should
proactively review the entire implications of these new agreements that
ICANN is undertaking, to ensure that there are no other problems.
11. Section 8.5 states "Irrespective of the provisions of Article 7,
ICANN and Registry Operator may at any time and from time to time enter
into bilateral amendments and modifications to this Agreement
negotiated solely between the two parties." This represents an affront
to ICANN's purported goals of transparency and accountability, when
they explicitly permit themselves to enter into contractual amendments
that are not reviewed by the public. This section obviously needs to be
12. Section 8.6 ("No Third-Party Beneficiaries") appears regularly in
ICANN's contracts, and represents a repudiation of any rights that
registrants have in ensuring just treatment, and should be reviewed.
Registrants have rights that need to be acknowledged and strengthened,
and once again ICANN has presented us with one-sided agreements that
protect only the registry operators at the expense of the registrants.
13. In the Consensus Policies document, section 1.4 does not permit the
price of registry services to be regulated in order to protect
registrants. This indicates once again that ICANN is not doing its job.
14. In the Registry Performance specs, the maximum renewal period of
ten (10) years is insufficient to protect registrants, in particular
given the lack of any pricing controls. Longer renewal periods need to
be adopted, and inserted into .com, .net and .org, in order to give
existing registrants price certainty now and into the future.
Registrants should not be subject to their domains being seized by
registries who unilaterally raise prices to exorbitant levels, in
effect allowing "eminent domain" of domain names by a private registry
operator for its own benefit. This naked abuse of power must be
15. Given the rampant abuse in prior new gTLDs, the "Rights protection
mechanisms requirements" are inadequate and appear to be an
afterthought, instead of being a high priority of ICANN. To deter
abuse, we suggest that there be a system of address verification by
registries in new gTLDs, similar to what exists in some current ccTLDs,
in order to stem the tide of domain name abuse. No domain would resolve
until a mailed PIN code was entered into a central system, so that the
registrant is verified. This would ensure a higher degree of registrant
WHOIS accuracy, reducing abuse from those who routinely use fake WHOIS.
This should eventually be adopted into existing gTLDs as a universal
standard, with financial penalties to registrars who permit fake
registrations above a certain level.
16. Section 4.1 of the Base Agreement creates 10 year terms, which
would allow VeriSign and other existing gTLD operators to attempt the
same under equal treatment clauses. The term should be reduced to what
VeriSign already gets, instead of reopening another can of worms.
17. The new Section 4.2 does not permit ICANN to raise registry fees.
Such protection is needed in the new language, lest it be inserted into
existing gTLD contracts through the equal treatment clauses.
18. Section 8.4 (Change of Control), should require ICANN approval,
particularly in regards to situations where a change of control will
lessen competition, thwarting ICANN's stated goals. Example, owners of
.shop and .store might decide to merge, and lessen competition between
themselves, thereby hurting registrants. Any change of control should
require public input, and should permit public tender for redelegation
to occur to other parties.
G. Module 6
1. Section 1 needs to discuss explicit financial and other penalties
for applicants to submit false and inaccurate applications. The slap on
the wrist that they "will reflect negatively on this application" is
obviously insufficient to deter people.
2. Section 3's refund policy is very unclear, and in particular seems
to leave the door open for full refunds in all cases of refusal. It
must be made clear that full refunds should not be the norm by tweaking
3. Section 6 demonstrates ICANN is concerned about protecting itself
from court challenges. It's unclear whether such language is able to be
enforced, though. If ICANN showed equal regard for the protection of
registrants, as is demonstrates protection of itself in this section,
it might have greater respect in the community.
4. Section 7 gives ICANN the right to not publish "confidential"
information. These are private actors attempting to usurp for
themselves public resources, namely gTLDs, and the level of disclosure
should be complete disclosure, including financials. Indeed, it is
often public scrutiny that catches falsehoods in financial documents
that incompetent staff routinely misses.
H. Final Thoughts
In conclusion, the draft new gTLD process leaves much to be desired. We
reserve the right to make additional comments on future drafts,
including in areas that we have not already commented (given the length
of the documents, it's possible we may have overlooked a few issues
that will come to light later).
ICANN should not proceed with new gTLDs. In the event they ignore the
views of the public and introduce them despite this opposition, much
greater safeguards are required to protect registrants, not only in the
new gTLDs, but in existing gTLDs that would be affected under the equal
treatment clauses. Furthermore, the negative externalities imposed upon
others by new gTLDs need to be internalized upon applicants through
much higher fees and standards of behaviour, in order to ensure that
only those new gTLDs that are operated as a net benefit to society,
instead of a drain on society, go forward.
We look forward to reviewing the next set of draft document which will
hopefully address the concerns of our company and those of other