[ALAC] Fwd: informal batching discussion - summary and conclusions

[Alan Greenberg]

>From: Thomas Rickert <rickert at anwaelte.de>
>Date: Tue, 26 Jun 2012 13:10:59 +0200
>Subject: [council] informal batching discussion - summary and conclusions
>To: GNSO Council List <council at gnso.icann.org>
>
>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