[council] informal batching discussion - summary and conclusions

[Thomas Rickert <rickert@xxxxxxxxxxx>]

Councillors,
this is a follow-up to the invitation that I sent to the list earlier. 

Please feel free to share the document with your respective groups.

Thomas


On Monday, June 25, an informal group of community members convened to exchange 
thoughts on potential answers to the questions of Batching and Digital Archery. 

The group did not neither craft nor agree on a common proposal to present to 
the ICANN Board since the time available did not allow for an attempt to do so. 
A huge number of ideas and suggestions were presented and commented on. 

With this document, I would like to briefly summarize those and more ideas that 
were brought to my attention in follow-up discussions and try to structure 
them. The conclusions I will draw do not represent the group's view, but my 
personal thoughts based on the cumulative input.

The main areas of discussion were

- Application Evaluation Batching and
- Delegation Batching.

However, the subjects of Digital Archery as well as the impact of the letter by 
the GAC to the ICANN Board on any proposal were also discussed and deemed 
necessary factors when defining what could be a superior solution to the 
current approach.

The group also felt that more data was needed to come up with a sound proposal 
in order to base calculations on facts rather than guesses. Apart from 
questions on parameters of the contracts with the firms that have been tasked 
to carry out the evaluation, the question of the maximum delegation rate per 
day or week was of interest to anticipate potential roll-out scenarios in the 
delegation phase. Kurt Pritz responded to this both in the informal meeting as 
well as during the public session. In summary, there does not seem to be a 
clear answer with unambiguous figures rather than the fact that the 1000 TLDs 
somewhat need to be distributed over the year i.e is a rate per year.

For the evaluation phase, there seemed to be a lot of support and little or no 
opposition to processing all applications in a single batch. That should be 
done as quickly as possible. While Kurt Pritz emphasized that quality is of 
highest priority and that it is not easy to add more evaluators since they have 
been trained for months, ICANN should try to deploy more resources. There is 
partially identical information in applications using the same Registry Service 
Provider and those of portfolio applicants. For these (and I am not suggesting 
that these should be processed in batches), only the the differences of the 
applications have to be identified, i.e. the evaluator would process one in 
total and then be able to concentrate on the variations of the applications and 
the impact of those on the assessment of the application. By doing so, it 
should be possible to expedite the evaluation process significantly. I 
understand that there are other proposals currently being drafted which focus 
exclusively on incasing process efficiency.

There did not seem to be an unanimous view on whether all results of initial 
evaluation should be published at the same time or whether they should be 
published as their evaluation is completed. A proposal was made to publish the 
results for individual applications as the initial evaluation is completed and 
then queue them for delegation as they are ready to go until the delegation 
rate limit of 1000 TLDs per year is reached. 

Numerous proposals have been made to establish a sequence of processing and 
then delegating TLDs. 

These can roughly be grouped into the following categories:

- Clustering

Several participants argued for different treatment for different types of 
applications, such as IDNs, geoTLDs, Community TLDs, grouping by competitors 
(applicants should tell who should not be delegated earlier than their 
application), grouping not only by contention sets, but also by synonyms (i.e. 
.music should be grouped with .hiphop).

- Financial 

Proposals were made to provide financial incentives to those who agree to be 
processed later or to give each applicant one point and that such points can be 
traded.

- Choice

Applicants should get the opportunity to opt-out and portfolio applicants could 
volunteer to prioritize their own applications. 

- Natural sequencing

Several attendees pointed to the fact that there will be a natural sequencing 
because of contention sets, objections, extended evaluations, GAC Advice, 
differences of time required for contract negotiation and execution.

In addition to that, withdrawals or rejections of applications will further 
reduce the number of TLDs that need to be delegated.

Another idea was to use the quality of the applications as a basis for 
sequencing them, eg. by scoring them or taking into account the requirement to 
get back to the applicant for additional information.

Conclusions:

It seems like creating groups of applications, such as IDNs, geoTLDs etc., is 
not an approach that gets broad community support. No matter how legitimate the 
reasons brought forward may be to either prioritize those or at least ensure 
that they are not processed at the end of the queue, it seems unrealistic to 
serve all these groups.

Thus, it will be difficult to establish a new methodology for clustering 
applications as the basis for creating an order for processing and delegating 
them.

A combination of various elements described above could be an eligible 
solution. These elements could be:

- Resources: ICANN should hire more resources to provide for an expedient 
evaluation taking into account the suggestions above.

- Choice: Applicants should say whether the earliest possible delegation is of 
high, medium or low priority for them. The applications will be processed in 
that order.

- Complexity: In terms of complexity, a distinction needs to be made between 
external and internal factors. 

Internal factors: Priority is given to applications with, i.e. where no 
additional information has to be requested and where no extended evaluation is 
required. This addresses the widely welcome idea that quality should be a 
factor.

External factors: Where contentions, objections or GAC advice are given, the 
applications are processed in the order these issues are resolved. 

The results of the initial evaluation of applications where no clarifying 
information had to be provided by the applicant was required, should be 
published at the same time. For the remaining applications, the results should 
be published whenever the evaluation is completed. 

The applications will then be processed whenever the respective next stage is 
reached. There will be a natural sequencing because of different time needed 
for contract negotiations and execution.

It should also be noted that the delegation process is not under ICANN's 
exclusive control, which will provide for additional sequencing.

Again, this document and the conclusion is an attempt to summarize and 
amalgamate proposals and feedback into what might be a possible approach. It is 
an effort in personal capacity which does not necessarily represent the view of 
the participants. 

Please circulate to those who are interested. I will collect feedback and make 
that available later this week.

Thomas Rickert


___________________________________________________________
Thomas Rickert, Attorney at Law
Director Names & Numbers

-------------------------------------
eco - Verband der deutschen Internetwirtschaft e.V.

Lichtstraße 43h
50825 Köln

Fon:    +49 (0) 221 - 70 00 48 - 0
Fax:    +49 (0) 221 - 70 00 48 - 111
E-Mail: thomas.rickert@xxxxxx
Web:    http://www.eco.de

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

eco - Verband der deutschen Internetwirtschaft e.V.
Geschäftsführer: Harald A. Summa
Vorstand: Prof. Michael Rotert (Vorsitzender), Oliver Süme (stv.
Vorsitzender), Klaus Landefeld, Thomas von Bülow, Felix Höger
Vereinsregister: Amtsgericht Köln, VR 14478
Sitz des Vereins: Köln