You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Work Track 1 Questions - Overall Process, Support, and Outreach

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 

 


FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

 


FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.

Please reference the "Work Track 1 Questions" document above for detailed questions asked

Work Track 1 Question #
Joint Comment from Bastiaan Goslings & Evan Leibovitch 
1.1 Registry Service Provider Accreditation Programs

 

1.1.1

The At-Large Community is generally dubious of the value of ongoing expension in gTLDs, given that the benefit from the previous round is yet to be proven. Documentation provided to the CCT-RT suggests that gTLD expansion actually exerts a negative effect on Internet users (that is, suppliers of Internet-based services and the end-users who partake of these services).

As such, the internal relationships between contracted parties and their service providers is of relatively little import to Internet users.

1.1.2

See response to 1.1.1

1.1.3See response to 1.1.1
1.1.4

The onus of compliance with the RAA is on the registry. At-Large is of no opinion on the benefits or drawbacks of separate regulation of service providers.

1.1.5

No. The onus of RAA compliance – and contact with ICANN – should remain with the Registry.

1.1.6See response to 1.1.1
1.1.7See response to 1.1.1
1.1.8See response to 1.1.1
1.1.9See response to 1.1.1
1.1.10See response to 1.1.4
1.1.11See response to 1.1.4
1.2 Applicant Support 
1.2.1

The origins of the AS program were always intended to include IDN support. This is not readily evident to be a problem that needs fixing. 

Considering that there were zero successful applicants from underserved or under-developed economies, attention should be focused to learning from that and making criteria less stringent for applicants from these areas. This involves potential expansion of the traditional definition of community applications, as well as the enabling of for-profit entities in underserved and underdeveloped economies to participate in the program.

Expanding a too-restrictive program to operate in richer economies will not, we believe, result in benefits consistent with the original aims of the program.

Rather than expanded to other regions, the AS program must be modified so it can be more-readily exploited in the regions it was originally intended to serve. Expansion to richer economies should not proceed until the AS is evidenced to be functional in the originally targeted regions. 

1.2.2

The primary focus of any changes to the Applicant Support program should be in the eligibility criteria. Addressing the benefits in other areas is premature unless the rate of successful applications to rejections is dramatically improved.

1.2.3

The Applicant Support program was barely mentioned in the original ICANN promotion of the 2012 gTLD round, so any new communications will be an improvement. Inclusion of the Applicant Support program in all promotional activities related to new TLD applications is merely sensible.

1.2.4

ICANN must be sensitive of the dire lack of resources related to Internet connectivity in least-developed economies. Where basic infrastructure and reliable access continues to be a challenge, ICANN must accept that existing availability of TLDs (ccTLDs and existing gTLDs) may be sufficient in regions where resources may be more effectively applied to critical local Internet infrastructure. ICANN would display poor global citizenship - and weaken public trust - if it promotes the investment of rare resources to new gTLDs in preference to core infrastructure.

1.2.5

See response to 1.2.2. Improvement starts at changing the eligibility criteria to enable more potential applicants, in relevant regions, to succeed.

Specifically, the rule that prevented a failed 2012 Applicant Support effort from re-submitting as a conventional gTLD (without support) must be eliminated. This rule was believed to be a significant barrier to entry for many would-be applicants.

1.3 Clarity of Application Process 
1.3

See response to 1.1.1

Such operational issues are of little concern to the general public.

1.4 Application Fees 
1.4.1

See response to 1.1.1

Such operational issues are of little concern to the general public.

1.4.2

Hindsight is always 20-20.

ICANN made its calculations based on what it believed would be break-even, with absolutely no precedent.

Obviously a new calculation needs to be derived that may be able to, for instance, eliminate the historical-cost component if that has been fully recovered by the last round.

1.4.3

ICANN’s responsibility is to price the program based on cost recovery. Any other philosophical approach indicates needless bias towards either established players or would-be entrants - any such stance would be seen as political and a potential source of public mistrust.

1.4.4 
1.4.5 
1.5 Variable Fees 
1.5.1

“One fee fits all” is a reasonable standard, else applicants will work to game the system to achieve best advantage. There may be cause to reduce the fees for eligible community applications, and the Applicant Support program addresses those potentially unable to pay for identifiable reasons.

1.5.2

See response to 1.5.1. We do not believe that there should be differential pricing, except perhaps for community applications for which evaluation criteria already exists (and maybe worthy of revisiting)

1.5.3

No. The fee should not be changed based on the volume. There should be a level playing field for all. There should especially be no consideration for applicants for whom projections are not matched by market realities.

1.6 Application Submission Period 
1.6.1

See response to 1.1.1

Regardless if done in rounds or in “first come first served” continual application processes, At-Large is skeptical of the public benefit of ongoing gTLD proliferation. Moe information, such as the data being collected by the CCT-RT, needs to be collected in order to make an informed judgment regarding the benefit or harm caused to Internet user by further gTLD expansion.

1.6.2

See response to 1.6.1. The choice of hard rounds or a continuous application process is less relevant to Internet users than the general concerns regarding potential harm to Internet users caused by gTLD proliferation.

1.6.3

See response to 1.2.1 The choice of hard rounds of continuous applications should not affect the Applicant Support program provided that the program (and specifically its evaluation criteria) is appropriately updated.

1.7 Application Queuing 
1.7.1No preference
1.7.2

Applicants asking for Applicant Support and community evaluation be given priority.

1.8 Systems  
1.8.1No comments as this is mainly operational
1.8.2No comments as this is mainly operational
1.9 Communications 
1.9.1No comments as this is mainly operational and aimed at applicants
1.9.2No comments as this is mainly operational and aimed at applicants
1.10 Applicant Guidebook 
1.10.1We see no need to fragment the Guidebook, as it may create confusion (especially when versions written for different audiences are perceived to conflict)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 


  • No labels