Comments to GNSO PDP June 2006 by dotBERLIN

[edit] Community TLDs need to have special attention

Today there are only a few organisations visible that express the wish to get their own Top-Level-Domain (TLD). The identified organisations mostly represent natural communities with a cultural, linguistic or regional background. These include the following community TLDs:

• .SCO – The Scots culture and language community Website | Wikipedia
• .CYM – The Welsh culture and language community Website | Wikipedia
• .BZH – The Brittany culture and language community Website | Wikipedia
• .GAL – The Galician Community Website | Wikipedia
• .LAC – The Latin American Community Website | Wikipedia
• .NYC – New York City community Website | Wikipedia
• .BERLIN – Berlin community Website | Wikipedia

Community strings are strings which show an intrinsic relation between the string and a clearly defined community, address the needs and interests of the people making up the community and also have a clear meaning to the community. These strings are abbreviations for cultural and linguistic communities mentioned in the available ISO lists, strings for cities, regions and countries, as well as strings for religious communities. Strings include full names and common abbreviations.

Since these natural communities will play an important role among future TLD applications it is reasonable to spend some thoughts about their needs in the Policy Development Process (PDP) for new TLDs.

One important point is the protection of community strings against misuse.

We think, the GNSO should address the context of community TLDs with particular attention since free-riders or copycats might have the idea to misuse published strings of community TLDs for own commercial and hostile activities. Especially community TLDs have the problem that their activities before and during filing the application cannot be treated confidentially, as the community needs to participate and the sponsoring organisation has to fund sufficient support and resources in the public.

Therefore a community TLD applicant should be able to answer the following questions with a well-founded “Yes”:

1. Does the proposed TLD string meet the definition of a natural community TLD?
   • Is the TLD string obviously a relevant and by internet users recognisable name, abbreviation, or signification of a natural community?
   • Is the intended community clearly definable and clearly defined by the TLD applicant?
   • Does the TLD applicant demonstrate a reasonable and adequate support of the community for the TLD string, for the sponsoring organisation and for the policy-making process?
   • Does the TLD applicant represent a wide range and major members of the community?
   • Does the proposed TLD string address the needs and interests of the people making up the community?
   • Is a significant portion of the community aware of the TLD application?
2. Does the TLD applicant show to act in good faith/bona fide in the interest of the community?
3. Has the TLD applicant established a reasonable policy-making body with outreach in the respective community?
4. Is there a sound business plan which has been positively evaluated by an independent auditor?

[edit] Avoidance of speculative TLD applications

The approval of a TLD string by ICANN and the subsequent registration of domains under this string potentially generate significant revenues for the sponsoring organisation, the TLD applicant, or the registry of that TLD. For this reason we would expect that organisations try to get multiple TLD strings approved in the next RFP only for profit. Especially natural communities with a cultural, linguistic, religious or regional background could be victim of such undesirable actions.

To avoid speculative TLD applications or the blocking or hampering of competition, mechanisms should be established that minimize these foreseeable manipulations attempts. An adequate mechanism could be a pre-evaluation of applications by a standing/ad-hoc pre-evaluation committee, for instance by designated ICANN directors/staff or a GNSO sub-group. Pre-evaluation is nothing new, it is widely used in some industries, for instance frequently in the pharmaceutical industry, where pre-evaluation hearings take place before authorities recommend the filing of the application for a new pharmaceutical drug. The TLD process could copy and leverage these well established mechanisms.

The pre-evaluation should be scheduled 90 days before the application deadline at each ICANN meeting ends (see timeline below)

Purpose of the pre-evaluation is

• to increase the quality of the final application
• to give serious TLD applicants consulting for the application
• to prevent fancy applicants to file an un-mature application
• to prevent misuse and speculative TLD applications
• to bring applicants for the same TLD string or TLD purpose together
• to give ICANN more certainty in planning resources for the next TLD evaluation round

The pre-evaluation is not a pre-approval, but it is valuable consulting for the TLD applicant and reveals potential problems before the final application is filed. The pre-evaluation should be voluntary for applicants but ICANN should recommend to applicants to participate in the pre-evaluation since it provides planning reliability and also optimizes the outcome of the invested resources of the TLD applicants.

If the application does not conflict with the following simple and short exclusion list the pre-evaluation committee should give a positive recommendation to the applicant to file its application.

In the following cases a TLD applicant should not be recommended to file its application:

• If the TLD technically harms the DNS in any way
• If the TLD potentially confuses users, e.g. TLDs with mixed IDNs, numbers, punctuations
• If the TLD is too close to existing TLDs, e.g. .com and .comm
• If the TLD reflects an internationally known famous and generic brand
• If the TLD obviously offends third parties
• If the TLD is obviously designed for bad faith or illegal use
• If the TLD is part of a potentially speculative mass application
• If the TLD has a very limited support of the respective community
• If the TLD has not a business plan approved by an independent auditor

[edit] Application modus

We think that new TLD applications should be accepted only at the three annual ICANN meetings. And there should be two options for the TLD applicant to get a first-come, first served time stamp for its TLD string: Either the TLD applicant goes through the pre-evaluation process (as described below) and gets a first class priority or he applies without pre-evaluation directly on the ICANN meeting and gets a second class priority. If a TLD applicant doesn’t apply with its priority at the next meeting, the priority is lost.

If the TLD applicant chooses the pre-evaluation the timeline for the TLD applicant could be the following:

90 days before ICANN meeting – Filing of TLD executive summary

The pre-evaluation process starts with a deadline for TLD applicants to file a five page executive summary about their application. No format for this summary is required, but it would good if the summary highlights the most important points of the application. The TLD applicant gets the first-come, first served bonus, if he’s the only one for this string or purpose. The pre-evaluation committee has now 30 days to evaluate the application document and has the option to request further information from the applicant. The TLD applicant can require confidentiality for the TLD string at this stage.

60 days before ICANN meeting – Hearing in front of pre-evaluation committee

The TLD applicant should present the TLD proposal in front of pre-evaluation committee and discuss the proposal with the committee. Location for this hearing could be one of the ICANN offices (Marina del Rey or Brussels). A 2 hours timeframe for presentation and discussion should be sufficient. The confidentiality for the TLD string and applicant at this stage is limited. At the hearing the pre-evaluation committee is for instance allowed give to the applicant the recommendation, that there’s another applicant for the same string and that a joint application might have better success. The pre-evaluation committee has now 30 days to evaluate the application.

30 days before ICANN meeting – Publication of recommendations

The pre-evaluation committee publishes a one page summary about its opinion on the application and finalizes the review with a recommendation for the TLD applicant. The recommendation should be either a positive or a negative opinion. Positive means that the TLD string is likely to be approved. Negative means that there are major concerns and the TLD string might has limited chances to get an approval. Positive opinion also means that the applicant gets a presentation slot at the next ICANN meeting. The fee for the pre-evaluation should be US$ 10,000 and is refunded if the applicant applies at the next ICANN meeting.

TLD applicants who not want to run through the pre-evaluation should be able to request a presentation slot for the next ICANN meeting confidentially. The time slot should be granted with seven days. For this kind of applicants there are only 5 presentation slots available (wildcards), they are granted on a first-come, first-served modus.

ICANN meeting – Presentation and hand over of application to ICANN board

At the three annual ICANN meetings there should be a half day session where TLD applicants present their proposals to the public and officially hand over the application document to the ICANN board. The new TLD presentation agenda for this meeting lists names of TLD applicants and TLD strings, except of those which have confidentiality.

The TLD applicant must present its proposal by representatives live on stage in a 30 min time slot (15 min presentation 15 min QAs). To plan the half day session, the time slots for the presentation are automatically granted to those who have gone through pre-evaluation. Other have to request the slot in advance at ICANN (see above). This public presentation procedure guaranties high awareness of the TLD string, purpose and applicant and is a good possibility for the internet community to get in contact with the applicant representatives.

[edit] More than one applicant for a TLD string

If two or more applicants for the same string or purpose get a positive opinion for filing the application, all of them should be given the equal possibility to file their application. A comparative evaluation of the applications will then find out which application meets the criteria best.

If there is only one applicant for a certain TLD string the TLD string is blocked until ICANN has made a decision to approve or not to approve the application. If ICANN denies the application new applicants might try to apply for the same TLD string at the next following ICANN meeting or go through the next following pre-evaluation process.

[edit] Statement

We fully support the tremendous work the GNSO has done so far and endorse the GNSO efforts to complete the new TLD PDP as soon as possible. We see this document not as comment to the current PDP documents but as a proposal illustrating how some of the current consensus items can be shaped into a process.

By Dirk Krischenowski

CEO dotBERLIN GmbH