All, you may recall I asked for feedback on the summary and conclusions I circulated earlier this week. In addition to oral responses mainly supporting the general approach I displayed, I have also received two written statements, which I have included in this e-mail. Please note that, as I had mentioned during the session on Monday as well as in my last e-mail, this is an effort in personal capacity. Thanks, Thomas Rickert Anfang der weitergeleiteten E-Mail:
Thomas,
Thank you for your summary regarding the batching discussions that took place on 25 June in Prague. My colleague who participated in the meeting, Jim Stoltzfus, and I have discussed and below, please find CSC’s feedback:
· Overall Timing: CSC is in agreement that it is in everyone’s interest (ICANN/applicants/providers/Internet users) to facilitate the first launch asap because everybody loses if it takes 18 months to launch due to the dynamic nature of the industry and Internet itself. Further, CSC also agrees that it would be unfair and counterproductive to allow incomplete or contested applications to slow down the evaluation and delegation of uncontested, quality applications. · Digital Archery: CSC recommends ICANN abandon Digital Archery as a method of ranking applications within geographic regions as it is technically flawed, provides an unfair advantage to those who have significant technical and financial resources and is reliant on a single action whose outcome is too heavily influenced by conditions (system latency, network traffic volume/throttling/routing, etc,) that can neither be predicted nor mitigated by diligent applicants. · Batching: CSC recommends that ICANN conduct initial evaluation of applications in 2 batches and that ICANN require applicants to self-select which batch they would like to be processed in. Contentious strings in the total application pool should be grouped with the application in the earliest batch. · Order of Application Review within Each Batch: CSC recommends ICANN order applications within a batch for evaluation in the following manner: o Non-contentious strings 1st in the following order of priority - community TLDs, “closed” .BRAND TLDs, IDNs, geo TLDs, remaining “open” TLDs/generics o Contentious strings 2nd in the following order of priority- community TLDs, “closed” .BRAND TLDs, IDNs, geo TLDs, remaining “open” TLDs/generics · Initial Evaluation of Applications: CSC urges ICANN to streamline initial evaluation of applications by utilizing the efficiencies suggested by the community, such as single review of answer sets used across multiple applications, evaluation by same evaluator of multiple similar applications by a single applicant, expedited review of closed .brand TLDs which utilize vetted gTLD registries, etc. · Publication of Initial Evaluation Results: CSC recommends that Initial Evaluation Results/Reports be released as evaluators complete evaluations. · Sequencing of the Delegation of Approved Strings: CSC recommends that delegation sequencing be based on the date that all pre-requisites for delegation are completed (queue based on date of completion). Where there are multiple applicants that complete all pre-requisites on the same day and ICANN believes it is not possible to delegate all strings in the same day, priority of delegation would be based on the following factors: application score, batch number, date of contract with ICANN, time-stamp of submission of acceptable pre-delegation testing results to ICANN.
We welcome the opportunity to continue to be part of the dialogue to craft a solution to these issues. Please continue to keep us apprised on any further discussions or proposals on this matter.
Thanks and best regards, Gretchen
Gretchen M. Olive Director, Policy & Industry Affairs
[snip]
www.cscglobal.com
From: Thomas Rickert [mailto:rickert@anwaelte.de] Sent: Tuesday, June 26, 2012 7:09 AM To: rickert@eco.de Subject: informal batching discussion - summary and conclusions
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@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
NOTICE: This e-mail and any attachments is intended only for use by the addressee(s) named herein and may contain legally privileged, proprietary or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me via reply email or at (800) 927-9800 and permanently delete the original copy and any copy of any e-mail, and any printout.
web: www.anwaelte.de