[Newgtld-input] ICANN Seeks Input on gTLD Batching

[Asociación Puntogal]

Dear Sirs,

Please find below Asociación puntoGAL, new gTLD applicant, regarding how 
to process the applications.

Best regards, Manuel Vilas

/Should the metering or smoothing consider releasing evaluation results, 
and transitioning applications into the contract execution and 
pre-delegation testing phases, at different times? /

   1. / How can applications be allocated to particular release times in
      a fair and equitable way?/
   2. / Would this approach provide sufficient smoothing of the
      delegation rate?/
   3. / Provide reasoning for selecting this approach./

All the results of the Initial Evaluation should be published at the 
same time, as long as it is not beyond the period of June-July, 
announced by the ICANN three weeks after the meeting in Prague.

Bearing in mind the June-July deadline, publication of all the results 
at the same time minimizes potential damage to the candidates. It also 
helps to develop a more fair process, if the technical impossibility of 
incorporating all the candidates that pass the Initial Evaluation in the 
same year occurs.

Even if not all the candidates that pass the Initial Evaluation can be 
incorporated during the same year, the fact that everyone knows at the 
same time if they have passed the Initial Evaluation allows the 
candidates to be able to inform the communities that support them and/or 
investors that finance them also at the same time.

The other possible scenario, publishing results of the Initial 
Evaluation on different dates, is much more negative. If any candidates 
start the formalities to be added to the DNS while others still do not 
know if they have passed the Initial Evaluation, and if this happens 
without any objective criteria to classify the candidates, the 
communities that give support to relegated proposals will lose their 
confidence in ICANN’s ability to organize an equitable process. The 
damage to the process will be especially severe in the case of the 
community candidates, whose main resource it is the support of their 
respective communities, and these are communities that have been 
maintaining their support despite all the delays to the process.

In addition, bearing in mind that promoting cultural diversity is one of 
the goals of the process, ICANN must not relegate any of the following:

1- Applications that serve a public interest, that is, they have a 
letter of support from the competent public authority in the 
jurisdiction of the candidate. The 'public' proposals must have priority 
over those that only are fueled by private interests. It is logically 
more important to give support to candidates that will bring benefits to 
the whole of the society than those that will only benefit private 
investors. If not all the candidates can be added at the same time, 
those that benefit the community must not be the ones damaged for the 
benefit of 'dot brands', who are the majority amongst the candidates.

2.- Applications that are community candidates, that is, those who 
submitted their application on behalf of and with the support of a great 
number of bodies, institutions and/or people. These proposals have 
already been obliged to demonstrate that they have popular support, thus 
at the end of the day they will benefit more users that other applications.

3.- Applications that promote the cultural and linguistic diversity on 
the Internet. Promoting cultural and linguistic diversity on the 
internet is one of the basic objectives of the process. Therefore, the 
IDNs candidates and the proposals of linguistic communities must never 
be relegated, for they are those that will bring cultural diversity to 
the DNS. ICANN should ask itself "Which generic domain until today 
helped the linguistic diversity of the Net more?" and act accordingly.

4.- Applications that are not contested candidates; that is, there are 
no other candidates for the same string. ICANN will facilitate the 
agreement among contested candidates if these are allowed to have more 
time to negotiate.

All these criteria must be subordinated to the rapid and prompt 
publication of the evaluation. In any case, ICANN should organize the 
process in such a way tat the first delegations take place later tan in 
the final period of 2014. ICANN must take into account that the current 
calendar already has a six month delay regarding the initial calendar. 
New delays would put the businesses plans of many applications in 
danger, especially those which are counting on generating admissions 
from the next year, and this could be fatal for the process.

/
Should the metering or smoothing be accomplished by downstream metering 
of application processing (i.e., in the contract execution, 
pre-delegation testing or delegation phases)? /

   1. / How can applications be allocated to a particular timing in
      contract execution, pre-delegation testing, or delegation in a
      fair and equitable way?/
   2. / Provide reasoning for selecting this approach./

As the process advances after the Initial Evaluation, there will be more 
differences in the pace of the steps previous to the Delegation among 
different candidates. These different paces will not be caused by ICANN 
itself, but by the capacity of each candidate to pass each step of the 
process.

Therefore, once the batching is carried out, it is only logical to think 
that candidates should keep advancing in the process as soon as they 
meet the different requirements. This approach awards the administrative 
efficiency of each application makes the process fairer and more 
equitable, and limits ICANN's need to take decisions in favor of some 
candidates. Another two criteria that ICANN can implement without 
damaging anyone are:


·a mechanism to allow candidates to declare that they are not interested 
in being at the beginning of the queue.
·a mechanism to allow candidates to establish priority among its 
different proposals.

/ Include a statement describing the level of importance that the order 
of evaluation and delegation has for your application./


Being in the first groups both of evaluation and delegation is basic for 
this application. ICANN must take into account that this process was 
delayed several years before finally being started. Unlike other domain 
proposals, namely commercial ones, .gal is supported by a huge amount of 
citizens and entities. The frustration on this community (more than 110 
entities of every type and more than 13.000 people) has kept increasing 
as ICANN proved incapable of meeting its own deadlines. This year hope 
and excitement returned with the process being started, but if ICANN 
relegates .gal to the end of queue of the evaluation or of the 
delegation the community will not understand it, especially if other 
domains of similar type (for example for other linguistic and cultural 
communities or for geographical places) are evaluated and implemented on 
the DNS while .gal continues waiting for Initial Evaluation results.

There is no any other application for the Galician language and culture, 
so .gal does not have any direct competitor on its market. However, if 
.gal is approved years after other new similar domains are live on the 
net, this will mean that the Galician linguistic and cultural community 
will perceive ICANN as an entity that discriminates the Galician 
cultural community without objective reasons. In this sense, ICANN must 
take into account that one of the goals of the process is to promote the 
cultural diversity of the net, opening it up to new users and promoting 
contents on the net. Relegating cultural and linguistic domains would be 
a direct move against these goals.


-------- Original Message --------
Subject: 	ICANN News Alert -- ICANN Seeks Input on gTLD Batching
Date: 	Sun, 29 Jul 2012 19:45:06 -0400
From: 	ICANN News Alert <communications at icann.org>
To: 	<manuel.vilas at puntogal.org>



ICANN <http://www.icann.org/>


    News Alert

http://www.icann.org/en/news/announcements/announcement-29jul12-en.htm

------------------------------------------------------------------------


    ICANN Seeks Input on gTLD Batching

29 July 2012


      Opportunity for Community Input: Processing of New gTLD Applications

At the Prague ICANN meeting, the new gTLD Program Committee decided to 
terminate Digital Archery, and instructed ICANN staff to proceed with 
the initial evaluation of applications as quickly as possible. This 
evaluation is in progress based on a tentative project plan that 
foresees the processing of applications in a single batch, and 
simultaneous release of results. ICANN believes this approach is 
consistent with the constraints that various parts of the community have 
in performing their respective roles in the evaluation process, and with 
the feedback received from the community at the Prague meeting.

This comment opportunity seeks input on requirements for an evaluation 
and delegation process consistent with previous root zone scaling 
discussions of smooth delegations, adding no more than 1,000 new gTLDs 
per year. This outcome can be achieved by the:

   1.   timing of the release of evaluation results to applicants,
   2.   timing of the release of applications into the pre-delegation
      steps of contract execution and pre-delegation testing,
   3.   metering of delegations of new gTLDs into the root zone.

ICANN is committed to executing the evaluation and delegation process in 
a way that is equitable and meets ICANN's commitment to ensuring the 
security and stability of the DNS, consistent with previously 
established root zone scaling goals.

Please write to newgtld-input at icann.org <mailto:newgtld-input at icann.org> 
with your input. Comments received by 19 August 2012 (UTC 00:00) will be 
considered.


      Background

The concept of batching has been a part of the Applicant Guidebook since 
its first draft. Batching accomplishes three goals:

   1.   Better management of the evaluation process by placing an upper
      bound on the number of evaluators necessary and the number of
      parallel evaluations occurring at any one time.
   2.   Release of evaluation results to applicants according to a
      predictable schedule.
   3.   Delegation of TLDs at a rate acceptable to the technical
      community, consistent with the root zone scaling discussion.

Based on the definitive information that ICANN now has about the pool of 
applications, and work on the evaluations to date, this comment process 
seeks input to meet requirements for goals #2 and #3.

Leading up to and during ICANN's meeting in Prague, the applicant and 
community positions on requirements for batching schemes that would 
control the evaluation, communication and delegation of applications 
were reported to be:

   1.   The batching solution has to be equitable.
   2.   The evaluation results have to be announced at the same time.
   3.   Successful applications should proceed to delegation phase
      without undue delays.
   4.   Delegation to the root must be at a smooth rate and must not
      exceed 1,000 per year.
   5.   The GAC is planning to issue early warnings shortly after the
      Toronto ICANN meeting in October 2012.
   6.   Consideration by the GAC of issues concerning GAC advice on
      contentious applications is not expected to be finalized before
      the Beijing meeting in April 2013.

During the root scaling discussion, it was agreed that ICANN would not 
delegate TLDs at a rate greater than 1,000 per year. This is because the 
primary challenge with maintaining root zone stability is controlling 
the rate of change to the root zone system and not the size of the root 
zone itself, meaning delegation should not occur at a rate of 1,000 
delegations on a single day.

In Prague, the batching and prioritization method known as Digital 
Archery was terminated and eliminated from further consideration.


      Recent Developments

Initial evaluation of new gTLD applications is underway.

Applications are being distributed to evaluators in a way that enables 
efficient processing.

ICANN has conducted pilot evaluations and had discussions with 
evaluators to accelerate the evaluation schedule. As a result of these 
discussions, the evaluation teams have committed to accelerate the 
evaluations substantially, while processing them in a single batch.

In Prague, a methodology was discussed where the smooth delegation of 
applications could occur by first releasing applications that passed 
initial evaluation without the need for clarifying questions, then 
releasing applications in order of the number of clarifying questions 
required, from fewest to highest. After analysis, this methodology 
proved unworkable because 80% to 90% of the total evaluation time is 
required to form and ask clarifying questions, so little smoothing would 
result.

The current plan indicates that initial evaluation of all applications, 
processed in a "single batch", can be completed in 11-12 months, 
possibly less – resulting in publication of results in June-July 2013.

    /Note: It is planned that regular updates to applicants during the
    evaluation period will be provided. In addition to written reports,
    ICANN is looking into the use of a webinar / conference call format
    to deliver updates./

For applicants, releasing results in a single batch would mean that the 
first delegations would occur in late third quarter of 2013, six months 
later than originally expected.

Implications of GAC timing:

    The GAC plans to "issue any Early Warnings shortly after the Toronto
    ICANN meeting, in October 2012," meaning that Early Warnings would
    be received within the currently planned single evaluation period.

    Also, the GAC "is considering the implications of providing any GAC
    advice on gTLD applications. These considerations are not expected
    to be finalized before the Beijing meeting in April 2013." This is
    shortly before the currently planned announcement of initial
    evaluation results (i.e., the schedule without additional
    accelerations beyond those stated above).


      Statement of the Issue

While there will be some natural smoothing as applications take 
different paths through objections and contention resolution processes, 
there will still be a requirement for some method of metering 
applications into the delegation process. This is due to the relatively 
high number of applications that may reach pre-delegation steps at 
essentially the same time. A metering method has not yet been determined 
and will need to be developed.


      Questions to be answered by comments

Submitted comments should specifically answer each of the following 
questions:

   1.   Should the metering or smoothing consider releasing evaluation
      results, and transitioning applications into the contract
      execution and pre-delegation testing phases, at different times?
         1.   How can applications be allocated to particular release
            times in a fair and equitable way?
         2.   Would this approach provide sufficient smoothing of the
            delegation rate?
         3.   Provide reasoning for selecting this approach.
   2.   Should the metering or smoothing be accomplished by downstream
      metering of application processing (i.e., in the contract
      execution, pre-delegation testing or delegation phases)?
         1.   How can applications be allocated to a particular timing
            in contract execution, pre-delegation testing, or delegation
            in a fair and equitable way?
         2.   Provide reasoning for selecting this approach.
   3.   Include a statement describing the level of importance that the
      order of evaluation and delegation has for your application.

Please write to newgtld-input at icann.org <mailto:newgtld-input at icann.org> 
with your input. Comments received by 19 August 2012 (UTC 00:00) will be 
considered.



This message was sent to manuel.vilas at puntogal.org from:

ICANN | 4676 Admiralty Way Suite 330 | Marina del Rey, CA 90292-6601

	

Email Marketing by iContact - Try It Free! 
<http://www.icontact.com/a.pl/144186>

Manage Your Subscription 
<http://app.icontact.com/icp/mmail-mprofile.pl?r=17428745&l=6333&s=P42K&m=888980&c=165637>