[council] informal batching discussion - summary and conclusions

Tue Jun 26 11:10:59 UTC 2012

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 at eco.de
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20120626/d051cb7e/attachment.html>