ICANN ICANN Email List Archives

[gtld-dispute]


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

New gTLD Applicant Guidebook Public Comment

  • To: gtld-guide@xxxxxxxxx, gtld-evaluation@xxxxxxxxx, gtld-dispute@xxxxxxxxx, gtld-terms@xxxxxxxxx
  • Subject: New gTLD Applicant Guidebook Public Comment
  • From: "Dr. Neal Krawetz" <dr.krawetz@xxxxxxxxxxxxxxxx>
  • Date: Sun, 14 Dec 2008 14:55:56 -0700

                                                            Dr. Neal Krawetz
                                                     Hacker Factor Solutions
                                                             P.O. Box 270033
                                                      Fort Collins, CO 80527

ICANN
4676 Admiralty Way
Suite 330
Marina del Rey, CA 92092

                                                           December 14, 2008


Dear ICANN,

I applaud the intention to introduce additional top-level domain names
(TLDs). The current set of TLDs, including .com, .net, and .org, have lost
their meaning; they have become nothing more than a free-for-all land grab
for the best names. New TLDs, particularly ones with reasonable purposes,
have the potential to reintroduce usefulness into the domain naming system
(DNS).

In addition, I am relieved to see a formal and open proposal system
associated with the rules and guidelines behind this decision. The
documents posted at http://www.icann.org/en/topics/new-gtlds/comments-
en.htm provide a welcoming amount of insight into both the proposed process
as well as the rational behind these decisions. However, I believe there
are some unaddressed issues. These areas are limited to the proposal
requirements, review of domain allocations, and associated fees.


Proposal Requirements

The current proposal documents focus on the submission process, hosting
requirements, and naming conventions such as character sets and similar
name resolutions. However, the proposed document does not address the basic
purpose of the proposed TLDs.

ICANN has historically steered away from issues concerning the regulation
of domain names. This was most evident during the October 2007 rejection of
the proposed ".xxx" TLD.[1] As I understand it, the rational was that ICANN
has neither the authority nor the power to regulate who can or must
register with a particular TLD. It is this same reason that the ".net" and
".org" TLDs are currently associated with all kinds of registrants, and not
just network providers[2] and non-commercial organizations[3].

However, the required proposal system for TLDs forces ICANN to be a
regulatory body for the TLD allocations. ICANN is responsible for receiving
proposals, evaluating proposals, and resolving multiple requests for
identical proposed TLD names. This is a regulatory position. The current
process description offers no means to distinguish between requests. For
example, I - as an individual - can submit a proposal for ".cpa" that could
conflict with a proposal from an association of certified public
accountants. Assuming that I get my proposal submitted first and meet all
of the requirements (naming convention, hosting environment, etc.) then
there is no reason not to award the domain to me since I requested it
first.

I would like to suggest an addition to the proposal review process in order
to better resolve this issue. Each proposal should be accompanied by the
following information, which will be used to evaluate the proposal:

   1. TLD name. This is part of the current proposed evaluation process.
      However, the current proposed process only uses this to resolve naming
      issues. I am suggesting that the TLD name be meaningful with regards
      to the purpose (item #2). This requirement would continue the current
      level of organization, where each TLD name has meaning beyond a basic
      string. For example, .pro is not just three random letters, .pro is
      for professionals. Similarly, .com is for commercial, and the various
      ccTLDs represent specific countries.

   2. Purpose. This justifies why the submitted TLD name is necessary in the
      first place. This will remove proposed TLDs with a far too limited
      scope and prevent TLD name cyber-squatting.

      The defined purpose should include why the TLD is desired as well as
      expectations concerning who will use it - both domain registrants and
      domain users.

      For example, is ".cocacola" really necessary? The company is in a
      single market, offering a suite of similar products, and the TLD would
      only be usable by them. This is a sparse namespace that has no purpose
      beyond brand recognition.

      In contrast, ".microsoft" could serve a viable purpose: the company
      offers a variety of widely used products and services, and has working
      associations with a significant number of official vendors and
      partners. The ".microsoft" TLD could be used to distinguish legitimate
      partners and products from clones, copies, and unofficial products and
      services.

      As with item #1, this requirement follows the current TLD definitions.
      Each current TLD is associated with a general purpose - even if the
      purpose is not enforced.

   3. Appropriateness. A proposed TLD may have an understandable name and an
      acceptable purpose, but may not be submitted by an appropriate domain
      holder. For example, with an appropriate purpose and associated fee, I
      can register ".japan". But since I have no ties to either the country
      of Japan or any products related to Japan, I am not the best choice to
      manage this TLD.

      As another example, Toyota is an automobile manufacturer. As a
      manufacturer, they could propose the ".car" TLD. Considering that
      Toyota is a specific manufacturer, they would not necessarily be the
      best choice for managing a generic TLD for cars. A better manager
      would be an organization that represents many automobile
      manufacturers, or an organization that has the support of multiple
      manufacturers.

      ICANN must be willing to reject applications that contain a viable
      purpose but are submitted by an unauthoritative or limited entity.
      Without this requirement, the cyber-squatting problem currently seen
      with .com, .net, and .org will exist with TLD names.

   4. Organization. The original purpose of DNS was to provide a human level
      of organization; otherwise we would still be memorizing network
      addresses. Currently, few TLDs contain any organization. The .mil,
      .gov, and .name TLDs are excellent examples of well-organized domains.
      For example, divisions under the Department of the Navy are all within
      the "navy.mil" TLD, and the government of California uses ".ca.gov" -
      department dot California dot gov.

      In contrast, moderated TLDs, such as .aero and .museum, limit who can
      register but still remain unorganized. For example, the airport code
      for Denver is DEN and den.aero is the domain for the airport. However,
      while ATL is the airport code for Atlanta, atl.aero is a company
      called "Aviation Traders Limited". There is no organization within
      these domains; they are effectively a free-for-all that is limited to
      related services.

      At the far end of organization are the unmoderated TLDs. These include
      ".com", ".org", and ".net". These are essentially free-for-all TLDs.
      Non-technical users have no means to tell anything about a site from a
      given domain name.

      I am not suggesting that ICANN regulate the domain structures within a
      given TLD. However, I do suggest that ICANN require that proposed TLDs
      include a well-defined organizational definition. A TLD such as ".ffa"
      could define a "free for all", while TLDs that represent an organized
      subject should include an organizational structure.

   5. Dispute resolution. In 1999, ICANN adopted the Uniform Domain-Name
      Dispute-Resolution Policy (UDRP)[4]. While this applies to many TLDs,
      it has not been uniformly adopted by all gTLDs and ccTLDs. As a
      result, individual TLD managers may choose to use the UDRP, a
      variation of the UDRP, or their own dispute resolution policy. For
      example, ".com", ".net", and ".org" all use the UDRP. However, the
      ".name", ".pro", and ".aero" TLDs each include alternate dispute
      resolution procedures.[5],[6],[7]

      Unfortunately, the UDRP does not explicitly mention the legal
      jurisdiction. Instead, ICANN provides a list of approved UDRP
      resolution providers.[8] It is very conceivable for a single domain to
      be contested under multiple court systems located all over the world.
      In addition, even though the United States court system is not listed
      as an approved UDRP resolution provider, it has claimed jurisdiction
      over dozens of domain name disputes.[9]

      For clarity, ICANN should require that all TLD proposals include a
      well-defined dispute resolution policy. Frankly, legal remediation
      should be considered a last-option rather than the only option. As
      with item #4, I am not suggesting that ICANN mitigate disputes within
      a TLD. Instead, I am suggesting that ICANN require TLD proposals to
      include a defined method for resolving disputes. For example, a
      proposed ".japan" TLD could include a method for the TLD manager to
      evaluate claims, or require mitigation be handled by courts in Tokyo.


Review of Domain Allocations

I was unable to find any mention of a review process after a TLD has been
awarded. Simply speaking, TLDs should not be "forever" nor limited to one
manager for life. Otherwise, poor management decisions may result in very
poor long-range decisions.

This issue is analogous to the IPv4 allocations. For example, DEC was
allocated the Net16 Class-A range (16.x.x.x). Hewlett-Packard was allocated
Net15. DEC was eventually bought by Compaq, which was consumed by Hewlett-
Packard. As a result, one company now controls two Class-A subnets. This
perpetual allocation is a key cause behind the IPv4 address shortage.

I suggest ICANN adopt a policy for reviewing TLD allocations. For example:

    . Periodic. After a specified amount of time, such as five or ten years,
      the allocation proposal should be reviewed. If the TLD is found to
      serve no effective purpose, then it should be deallocated. For
      example, if less than 1% of airports and aerospace related services
      join .aero after 10 years, then perhaps .aero is unnecessary. The same
      argument could be made for .name, .museum, .tel, .travel, etc. In
      effect, this is removing TLDs that become ineffective and frees the
      namespace for future services that are potentially different from the
      original proposal.

      The periodic review is not intended to meet arbitrary metrics.
      Instead, it should be used to identify whether the TLD is still
      operating under their original proposal guidelines, provide an option
      to update guidelines or requirements, and address any unexpected
      concerns.

      The concept of re-evaluations is not new with regards to TLDs. RFC 920
      defined the original purpose. This was updated by RFC 1591, RFC 2606,
      RFC 3071, etc.

    . Violations. Along with the proposal for the TLD is a commitment to
      abide by the proposal. If a TLD manager fails to abide by the
      proposal, then the TLD should be re-evaluated. This could include
      addressing the violations, altering the proposal, changing the
      management, or deallocating the TLD.

      For example, let's say that the proposed TLD ".zoo" is intended for
      zoological organizations. If the TLD management begins to permit non-
      zoo companies, then the purpose of the TLD should be re-evaluated.
      Similarly, if ".news" is intended for news reporting agencies, but
      becomes closely tied to unsolicited or undesirable communications
      (e.g., spam or scams), then the TLD's purpose should be re-evaluated.

      Requiring re-evaluations in the event of blatant violations of the
      TLD's specified purpose simplifies the deregistration process. Had
      ICANN had a similar policy for existing registrars before October
      2008[10], organizations such as McColo, EstDomains, and Atrivo could
      have been removed without years of complaints and legal processing.
      The re-evaluations also address so-called "bulletproof hosting"[11],
      where some domain registrars remain overly lenient toward complaints.


Associated Fees

The fees associated with the proposed TLD submission process seem to be the
least coherent portion, yet this proposal section has the most
justification. The initial submission fee of $185,000 is one example of the
incoherency. The fee is intended to go toward ICANN's operational costs.
However, the proposal does not identify which operational costs are
currently covered. Are salaries, services, and base overhead currently not
being funded?

More irrational is the fee of $1,000 for dispute resolution filings. As I
understand it, I could have an extremely good reason why ".google" should
not be awarded. However, if I cannot afford the $1,000 dispute resolution
fee, then I will be unable to voice my challenge. Along this same argument,
if I can afford the $185,000 fee then I can be virtually assured to get
".krawetz" since I doubt anyone would pay $1,000 to contest my proposal.

There is also no mention of any kind of refund. If a TLD proposal is
rejected, is the $185,000 refunded? Similarly, if a $1,000 argument is
rejected, is the $1,000 returned to the submitter? Without any refund, I
can fully see ICANN facing lawsuits from submitters (both TLD and dispute
submitters) who feel that their concerns were not appropriately considered.

The current fees appear designed more to prohibit submissions than account
for appropriate costs. Perhaps a better breakdown would be something
similar to the following:

    . A large amount, such as $100,000, for the initial proposal. The high
      cost is to deter arbitrary submissions and cover processing overhead.

    . Each person or organization that desires to be a management candidate
      adds in a secondary amount, such as $30,000. Together, these two fees
      ensure that a single TLD proposal submitted by multiple managers is
      not double-billed by the large amount.

    . A change fee, such as $10,000, should be added for each significant
      change to the proposal after the initial submission. This is similar
      to a change-request process in normal business contracts.

    . There should be a fixed window for organizations to request to compete
      for the proposed TLD and to make changes based on their submissions.
      When the window is closed, no more candidates may vie for the TLD and
      no more changes may be made to proposals while they are evaluated.

The total sum of the fees should cover all forms of conflict resolution.
Individuals wishing to voice opposition to a TLD should not be required to
submit any fees. Together, a highly desirable but contested TLD, such as
".sex" or ".car", would generate the following fees along a timetable
similar to this. Please be aware that the entire process flows similar to
an open-faced poker game:

   1. An organization submits the initial proposal and pays $30,000 to be
      listed as a manager. This opens a window for other organizations to
      enter their names for the same TLD. Each subsequent submitter antes a
      non-refundable $30,000.

   2. For the $30,000 ante, each organization may specify why they are the
      best choice for managing the domain. These additional organizations
      may also submit addendums or changes to the initial proposal in order
      to strengthen their claims. For example, the second submitter may
      include a non-refundable $10,000 fee to alter the domain's proposed
      organization, potentially making their variation of the initial
      proposal better than the original proposal.

      Similarly, the original submitter may alter or update their variation
      of the original proposal in order to incorporate enhancements -
      including those from their competition - for bettering their version
      of the proposal. A non-refundable $10,000 fee accompanies each change.
      Using a poker analogy, this is essentially an open bidding war, with
      each group paying a fee to sweeten their proposal.

      During this time, all proposal variations are public. There may, and
      likely will, be parallel competing proposals for the same TLD.
      However, the initial proposal is treated as the baseline for all of
      the parallel variations.

      Throughout the open bidding and change window, some potential managers
      may drop out upon realizing that their proposal is not the best.
      Meanwhile, proposals are updated - providing ICANN with a set of
      optimal proposals to consider.

   3. At the close of the period for organizations to request management
      rights, the $100,000 fee is divided equally among contenders.

   4. The remaining proposals are then evaluated, along with any external
      feedback - positive or negative and directed toward the TLD or any
      particular management candidate.

   5. A consensus is made by ICANN. This may include required changes to the
      winning proposal. These changes are negotiated with the winning
      submission, but do require change request fees.

      . If the TLD is rejected, then the $100,000 fee is refunded but the
        other fees are retained by ICANN. Candidates must be aware that
        ICANN reserves the right to not award the TLD to anyone in cases
        where none of the proposals are strong.

      . If the TLD is awarded, then no moneys are refunded to any of the
        parties.

   6. After a specific period of time, such as ten years, the proposal is re-
      evaluated. The re-evaluation includes opening up the management
      proposal. However, a successful history of managing the TLD should be
      included in the review processes.

The total revenue generated by this approach is greater than the current
proposed system. However, the distribution appears fairer to all of the
participants.


I would like to thank ICANN for allowing me to voice these ideas and I
certainly hope that these suggestions, or alternate requirements that
address the same issues, are adopted. I would certainly hate to see the new
TLD system result in an unorganized free-for-all with unusable TLDs and
significant resources tied up in the courts.


Neal Krawetz, Ph.D.
Hacker Factor Solutions
http://www.hackerfactor.com/
Author of "Introduction to Network Security" (Charles River Media, 2006)
and "Hacking Ubuntu" (Wiley, 2007)


-----------------------
[1] http://www.icann.org/en/minutes/resolutions-30mar07.htm#_Toc36876524
[2] RFC 1591
[3] RFC 920
[4] http://www.icann.org/en/udrp/udrp-rules-24oct99.htm
[5] http://www.nic.name/policies.html
[6] http://registrypro.pro/nextphase/tou.htm
[7] http://www.nic.aero/registration/policies/dmp
[8] http://www.icann.org/en/dndr/udrp/approved-providers.htm
[9] http://www.internetlibrary.com/topics/domain_name.cfm
[10] 
http://www.icann.org/en/processes/registrars/de-accredited-registrar-transition-procedure-01oct08.pdf
[11] 
http://www.washingtonpost.com/wp-dyn/content/article/2008/11/12/AR2008111200658_2.html?sid=ST2008111801165&s_pos=

Attachment: icann-tld.pdf
Description: Adobe PDF document



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

Privacy Policy | Terms of Service | Cookies Policy