This is a scratchpad for drafting the June 2010 Announcement

Introduction

Responding to a Board resolution in Nairobi, the GNSO Council initiated the launch of a Joint SO/AC Working Group on New gTLD Applicant Support, or JAS WG for short, launched in April 2010. The JAS WG wishes to report on its current status and findings to date, with a view to solicit public comments to guide further work. The WG decided early on to work in two parallel Working Teams; Working Team 1 focusing on application fee aspects and Working Team 2 addressing issues regarding which applicants would be entitled to special support and of what nature the support could be. Below are the current findings of the two Working Teams.

Working Team 1

Background

Working Team 1 is tasked with meeting the Working Group's Charter Objective 2: To identify how the application fee can be reduced and/or subsidized to accommodate applicants that fulfill appropriate criteria to qualify for this benefit, in keeping with the principle of full cost recovery of the application process costs.

Process

WT1 examined how the application fee has been constructed and explained/justified in the cost consideration documents #(1) and the DAG4 in order to determine if there is any potential for requesting the fees be revisited for applicants that meet the established criteria. The WT suggests several options for financial support of applicants. The first two proposals appear to have consensus; the remaining proposals are still under discussion.

The fee for applying for a new gTLD is $185,000. The fee structure is divided as:
1. New gTLD Program Development Costs $ 26,000
2. Fixed and variable Application evaluation costs - Predictable $100,000
3. Risk/Contingency costs $60,000

Proposals

The following suggestions have been formulated by WT1.

1. Waive the cost of Program Development ($26K) for selected entities qualifying for financial assistance. The document New gTLD Program Explanatory Memorandum New gTLD Budget #(2) indicates an expected Net profit of $184,600 for the new gTLD program. This profit could fully or partially offset the loss of waiving the $26k program development costs for several applicants. We expect very few applicants (relative to the total number applying) to meet the criteria for assistance, so the financial burden of waiving these fees should be minimal.

2. Staggered Fees. Instead of paying the entire fee upon acceptance of the applications, applicants meeting the criteria established for support could pay the fees incrementally (perhaps following the refund schedule in reverse). Allowing an applicant to have a staggered fee payment schedule gives the applicant more time to raise money, and investors will be more likely to back an application that passes the initial evaluation. Staggered fees enable an applicant to compete for strings that might otherwise have gone to the first and/or only group with enough money to apply. If the applicant does not proceed through the entire process, they are not "costing" ICANN the full projected amount, therefore cost recovery remains intact.

3. Auction Proceeds. Qualified applicants receive a partial refund from any auction proceeds #(3 ) —for which they can repay any loans or invest into their registry, or the auction proceeds could be used to refill the disadvantaged applicant’s foundation fund for subsequent rounds.

4. Lower the Registry fixed fees due to ICANN. In lieu of the Registry-Level fixed fee of US$25,000 per calendar year #(4 ), instead only charge the Registry-Level Transaction Fee of US$0.25 per initial or renewal domain name registration. An annual fee of $25k to ICANN is a barrier to sustainability for an applicant representing a small community. Many TLDs pay much less to ICANN (if anything). If a minimum is absolutely required, then consider lowering this fee by 50% for qualified applicants.

5. Reconsider the Risk/Contingency cost per applicant ($60k). The WT questions if ICANN really expects a total of $30,000,000 ($60k x 500 applications) in unknown costs to surface. This fee could be reduced/excused for the applicants that meet the criteria established by the WG.

6. The Fixed/Variable cost of $100,000 is based on the total cost of the previous round of applications, which the cost considerations document quantifies as $1.8MM for all ten applications. This fee most probably includes costs associated with the conflict that arose from the rejection of the ".XXX" application, which remains unresolved. The fee of $180,000 may have been significantly skewed by the long-term work required for .XXX. The actual evaluation and administrative costs for the other nine applications may have been considerably less than $180,000 per piece. If this is the case, the $100,000 fixed cost fee could be reduced for the applicants that meet the criteria established by the WG.

WT1 is working with WT2 on identifying sources of funding for subsidizing the fees for qualified applicants. The WG suggests that an independent foundation be established, outside of ICANN structures, to assist applicants with funding.

Working Team 2

The who and what of offering assistance: Working Team 2 findings

1. Who should receive support?

Key to making a support program work is the choice of initial support recipients. With this in mind Working Team 2 considered a number of possible applicants, but agreed that the initial focus should be on finding a relatively limited and easily identifiable set of potential applicants which would be non-controversial to support. Based on these criteria, the Working Team recommended the following:

a. At least in the initial/pilot phase, target support to ethnic and linguistic communities (e.g. the Hausa community, Quechua speakers, Tamil speakers). These potential applicants have the benefits of being relatively well defined as groups, and pass the test of being generally non-controversial. Such communities already have a history of recognition at ICANN and facilitating community on the web is one of ICANN’s core values.

b. Address support for other groups, especially NGOs and civil society organizations at a future point as the idea of who constitutes a “community” in this space is less clear and the tests for which groups might need/merit support would be trickier. Moreover, the number of applicants could be very large.

c. Overall, the Working Team recommended giving some preference to applicants geographically located in Emerging Markets/Developing countries and in languages whose presence on the web is limited.

d. A series of groups are not recommended for support based on our work, specifically :

  • Applicants that don’t need the support/have ample financing
  • Applicants that are brands/groups that should be self-supporting companies
  • Applicants that are geographic names (such as .Paris and others)
  • Purely Government/parastatal applicants (though applicants with some Government support might be eligible)
  • Applicants whose business model doesn’t demonstrate sustainability

2. What kinds of support might be offered?

The group recommended a number of different kinds of support that could be valuable for potential applicants, support which falls relatively neatly into three categories:

a. Logistical, outreach and fee Support in the Application Process

  • Translation of relevant documents – a major concern noted by non-English speaking group members, who noted the extra time and effort needed to work in English
  • Logistical and technical help with the application process – including legal and filing support that are expensive and in short supply in most Emerging Markets nations
  • Awareness/outreach efforts – to make more people in underserved markets are aware of the gTLD process and what they can do to participate in the gTLD process
  • Fee reduction/subsidization and/or some sort of phased-in payment for deserving applicants – this discussion builds off of the work of Working Team 1, and includes two key ideas:
    • That deserving applicants might receive some reduced pricing in general
    • That some sort of phasing for payment might be appropriate, enabling selected applicants to effectively “pay as they go” for the application process rather than having all funds assembled up front

b. Technical Support for Applicants in operating or qualifying to operate a gTLD

  • Infrastructure – providing IPv6 compatible hardware and networks as needed
  • Education/consulting – to help with DNSSEC implementation
  • Possible technical waivers or “step ups” – allowing applicants to build their capabilities rather than needing to demonstrate full capacity before applying (as appropriate)
  • Grouping and/or lower cost registry service/CoCCA-type back end service

c. Support for Build-out in Underserved Languages and IDNs for new gTLDs

  • Price discounts to incentivize build-out in scripts with a limited presence on the web
  • Bundled pricing to promote build out in multiple scripts – incentivizing an expansion of IDN content as new gTLDs are launched by encouraging applicants to build out in numerous scripts at once
  • Clear tests to prevent gaming and ensure that support reaches its targets

3. Other recommendations?

The Working Team also agreed on a series of “principles” that are recommend to guide the community as the support process is finalized, namely:

a. Self-Financing responsibility – ICANN/community support should comprise not more than 50% of the total cost of an application. The WG saw this as a good way to encourage accountability and sustainability.

b. Sunset period – Support should have an agreed cut-off/sunset point, perhaps 5 years, after which no further support would be offered. This was recommended as another measure to promote sustainability and as a way to help limited resources reach more applicants.

c. Transparency – Support requests and levels should be made public to encourage transparency.

d. Applicant form is not limited – While many groups receiving support would be NGOs, applicants would need to be non-profits. Some might start as non-profits but morph into hybrids or for-profits and others might be appropriate for-profit or hybrid applicants.

e. Limited Government support – The receipt of some support from government(s) should not disqualify a community applicant from receiving gTLD support. However, the process is not designed to subsidize government-led initiatives.

f. Repayment in success cases – In cases where supported gTLDs make money significantly above and beyond the level support received through this process, recipients would agree to re-pay/rebate application subsidies into a revolving fund to support future applications.

Additional Questions and Possible Responses:

  • Q: Can we offer standardized plans of support? A: This will become clear over time, but standardizing packages of support should help reduce support costs.
  • Q: Is there a minimum number of people in a community needed to create “critical mass” for viability? A: There was extensive discussion around this, but no consensus. It is hoped that new business models will emerge specifically for work with smaller communities.

Notes

1. http://www.icann.org/en/topics/new-gtlds/cost-considerations-04oct09-en.pdf

2. http://www.icann.org/en/topics/new-gtlds/new-gtld-budget-28may10-en.pdf

3. http://www.icann.org/en/topics/new-gtlds/Draft-rfp-clean-28may10-en.pdf page 4-18

4. Draft-rfp-clean-28may10-en.pdf Registry Agreement 6.1

—
To select possible applicants to be subsidized, aren’t we doing one part of the selection process?

Can someone explain to me WT2 #3d?

If the draft letter requesting providers is not yet send (I know I am late) I would like to suggest to add
Are you aware of any other providers (including yourself) that IS OR would support disadvantaged applicants?

SeB

contributed by sebastien@bachollet.com on 2010-06-15 09:15:55 GMT

  • No labels