[Newgtld-input] COMMENTS FROM CORE Internet Council of Registrars

[Amadeu Abril I Abril]

PLease find hereby attached both as text and PDf format our comments and proposals. We also attache an erleir version on "Amedning Digital Archery" in PDF, prepared and circulated prior to the Prague meeting, as it contains some background for our poposal.

Amadeu Abril i Abril
Cief Policy Advisor
CORE Internet Council of Registrars
http.//corenic.org

Amadeu.Abril at corenic.org / Amadeu at abril.cat

*****************

1Comments from CORE Internet Council of Registrars

We thank ICANN for the opportunity provided by this Public Comment Forum. We already provided a proposal last June, forwarded to staff, Board Committee and GAC, on how to handle this issues, as a reaction to the now abandoned “Digital Archery” mechanism. We attach that proposal to this comment, as the logic and reasons for some priority criteria are the same, but we will answer the questions as made by the new gTLDs Committee for the benefit of structure as well (and, indeed, most the reasoning in that document specifically related to Digital Archery is no longer relevant).

As a summary of our proposal, the following points can be made:

A) The intermediate steps (Initial Evaluation; Contract Execution; Pee-Delegation Test) should not be used for throttling, but instead should focus on efficiency and speed (and quality of evaluation, indeed).

B) Artificial bottlenecks should be avoided, though, as they would result in unnecessary delays for the whole process. In this regard, delaying the move into the next step for all applications until them all have completed the previous one is both inefficient and unfair.

C) We provide some hierarchical criteria for prioritization in order to solve those bottlenecks according to principles of the global public interest which includes fairness and competitive considerations among applicants, but also the global interests of the Internet community. These includes some groups with specific reasons for priority (IDNs; GeoTLDs and other TLDs backed by public authorities; community-based TLDs; TLDs located and aimed at underrepresented areas) plus equally objective and non-discriminatory rules for the rest of applicants (percentages, for portfolio applicants, based on their stated order of preference; Exclusive Use TLDs grouped by industry or competitive concerns as expressed by the applicants themselves; etc).

D) These criteria, applied at each stage if necessary (but perhaps only needed for the delegation step, if all goes well) coupled with the natural throttling of applications will most likely solve the question ICANN faces (by natural throttling we mean delays suffered by applications subject to objections; contention resolution; GAC Advice; failing Initial Evaluation or suffering delays in the contractual execution or pre-delegation test phases).

Responses to enumerated questions:


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

The evaluation itself should not be used for throttling as a goal in itself. In this regard, CORE would have no objections (we rather believe it would be beneficial) to ICANN publishing the Initial Evaluation Reports as they get completed.

At very least, the GOAL for these phase should be to publish the Initial Evaluations as soon as GAC provides its Advice to the Board. The roadmap as published by ICANN staff seems to be close to that goal. We propose below some additional measures to foster efficiency to attain that goal.

But no delays should artificially arise from these phase. As not all and every TLD can be added to the root the very same day, nor can CIANN perform all Pre-Delegation Tests, or sign all contracts, in the very same date, it would be unacceptable to artificially add delays by forcing each and every application to wait until the very last Initial evaluation has been completed.

Below we provide some ideas on a) how to further increase efficiency in order to meet the goal (publishing *all* initial evaluation reports immediately after GAC advice, ie, without causing any delay for the following step) and b) criteria as to how to prioritize applications if ICANN staff sees at any point that the said goal is not attainable and a delay will occur (more complete under answer to question 2 below).

1.1 Measures to Increase Evaluation Efficiency

1.1.1 Evaluation Productivity

In order to achieve evaluation productivity, ICANN must analyze the applications globally by similar content. For any given question, many TLDs have absolutely identical responses (after allowing for changes in TLD string and Applicant name). ICANN must use available technology to identify similarity and identical content. The data shown on http://gtld-similarity.info demonstrates that the number of response models per question field is so low that all content can comfortably be reviewed in a few months on a per-question-per-model basis. A second pass can then take into account relationships between model responses as used in a given application. ICANN should use similarity testing for the non-public responses and publish statistics. ICANN could also ask the applicants (and though them, to the providers helping them in drafting the applications) to identify both the similarly-drafted portions in other applications and the differences in the models.

1.1.2 Simplified Evaluation of Exclusive-Use TLDs

Furthermore, evaluators should avoid losing time with responses that have no practical bearing. That is especially true for exclusive-use TLD applications. There are at least 600 of them. Most applicants for brand TLDs will never allow third parties to register in their TLD. They will therefore apply for exemption of Specification 9 (Registry Code of Conduct) of the Registry Agreement, declaring that the TLD is for exclusive use by the registry operator. This means that the bulk of the evaluation questions for those TLDs are devoid of any practical significance. It would be a huge waste of time for ICANN to evaluate the financial stability or business plan of an exclusive-use TLD applicant. The same is true for the technical plan and most policy-related questions in these TLDs.

It would be far more efficient for the Evaluators, these concrete applicants, the rest of aplicants and the users that those applicants committing to this model (and committing to apply for the exception ex Specification 9 of the Draft Agreement) undergo a simplified evaluation at this point, and, at the time they decide to open their TLD to third-party use and/or registration (for which they will necessarily need to go back to ICANN and modify some minor points of the TLD Agreement, such as giving up the Exemption ex Specification 9; provide a Code of Conduct and a RRA, etc...) at that time, not now, the complete evaluation should be performed. For most of them,this will never occur. For all of the applicants, this would mean a significant improvement of evaluation productivity; and for the registries changing their mind as to the exclusive use, and for the DnS users in general, the evaluation would be more meaningful at that moment, not years before this occurs. And it would be faster s ICANN would not be overloaded as it is now with 1927 complete applications

 ICANN must therefore allow applicants to use TAS to declare that they apply for exemption under Specification 9. For the applications flagged as exclusive-use, the evaluation is reduced to the aspects that matter. Furthermore, if a TLD application is flagged as exclusive-use in TAS by the applicant, then the applicant should be allowed to use TAS to identify same-industry competitor applications which should not enjoy a time advantage over the declaring applicant. This is an additional incentive for an early declaration of exclusive-use.

1.1.3 Allowing Objections to Be Handled Early

While the objection period ends now prior to the Evaluation Period, ICANN has not clarified if the objections will be handled early, or only after publication of the Initial Evaluation. We strongly encourage the former. Early resolution means less applications, more clarity, and less work overall.

1.1.4  Allowing Joint Conditional Withdrawals as a Way to Early Reduce the Number of Applications in Contention

We know that some 200+ strings count for some 750 applications. ICANN explicitly encourages private and early resolution of those contentions sets. 

Unfortunately, this is not practical in most cases. As the rules are set, resolution, wherever it implies, must result in all but one application in the contention set being withdrawn. But this is difficult to manage for contention sets with more than 2 applications, where multiple applicants must withdraw.

The problem is that no matter how or why, multiple applicant in a contention set reach an agreement, it is difficult to enforce. As the system is now, each individual applicant should sent the withdrawal request to ICAN  who would individually very each one with the applicant. Fair enough.

But what happens if, say, five applicants agree to withdraw a given TLD application each, for the benefit a sixth one, and all sign the relevant documents and send the withdrawal request to ICANN, but one of them changes its mind and does not confirm it to ICANN? As it is now, ICANN will proceed to withdraw four of those applications, and leave both the one that has not send any request, and the one who started the process but changed mind. Bringing all participants in the contention-resolution process facing a new, unsolvable situation. Irreparable damage has been caused to all parties, and no remedy is available (sure, contracts can provide for all kind of penalties and guarantees, but in a scenario where applicants are in disparate jurisdictions this become unrealistic, and prohibitively expensive at best). ICANN cannot be forced to comply with a private agreement among third-parties. Nobody (short of a out-of-this-process timing Court) can force the non-complying applicant.

We certainly don’t propose ICANN to enforce such private Agreements. But to publicly explain that it would accept Joint Conditional Withdrawals. In this scenario, when multiple parties jointly withdraw, ICANN would proceed with the usual and necessary checks. But if one or more of the withdrawals are not confirmed, then it would notify the other parts in the Joint Withdrawal and allow them to choose between moving forward or staying in the process, as the intended resolution has failed.

If this is allowed we foresee a fair number of those 100+ contention sets with more than two applications (accounting for some 500 applications in total) with a real chance of early resolution, and hence, providing for a significant reduction of the names subject to Evaluation and subsequent steps.

1.2 Global Public Interest Priority Evaluation

As stated above, CORE firmly believes that the goal of completing and publishing all Initial Evaluations immediately after the GAC advice is perfectly attainable, and we have provided some further ideas under 1.1 in order to make that goal even more realistic.

But let’s imagine that at a certain point ICANN staff and the Evaluators are convinced that this goal is t risk. In this case (and only in this case) ICANN should make extra resources available for applications where public interest plays a special role.

In a nutshell, ICANN should make sure that by the time of GAC Advice being published, at very least the following applications are ready to be immediately published and move into the next step (contractual execution): “uncontested IDN, public-authority backed applications, applications coming from underrepresented areas and community-based TLDs”. 

We explain what each of these categories means in more detail in our response to Question 2 below, where we also provide for a methodology to handle metering or smoothing for the whole set of applications.

-----------
2. How can applications be allocated to particular release times in a fair and equitable way?

Given the structure and language of the other questions, we are not completely sure if “release” here means release of Initial Evaluation Reports, or release of TLDs in the rot (delegation), i.e., the final step. Just in case, we answer both.

As for Initial Evaluation Reports, we have already said that:

a) they could be released as soon as possible, as they get completed
b) In any case, they should all be released immediately after the publication of the GAC Advice;
c) In the worst case scenario in which c) is not possible, at least a series of public-interest qualified groups of applications should be published at that time, so as not to delay the process
d) In this particular scenario those categories should move immediately into the next step, even if not all Initial Evaluation reports are complete and published.
e) No step should be used to create artificial delays by preventing the start of the next steo until each and every application has completed the previous one.

As it regards how to move forward from Initial Evaluation to Delegation, we submit the following criteria, based on public interest considerations.

2.1 Global Public Interest Considerations
 
A lot has been said about *fairness* in handling the applications. But farness reduced to its over-simplistic concept of “treating everything in the same way, as if it was all the same”. And also in the sole perspective of fairness towards the applicants: why this or that application should go or not before that other one, from the perspective of the itnerests of the applicants. These interests, our (CORE’s) own interests, are indeed very relevant. But not the only one. Interests of potential users, and the global community as such are also very relevant, if not more so. Shouldn’t we also ask what ‘s important for the users? And, also, for certain users, comparatively underserved and underrepresented in the current DNS landscape?

Take the case of IDNs. No such IDN gTLD was allowed in the prior two rounds of 2000 and 2004. No IDN gTLD exists today. For those users unfamiliar, or uncomfortable, with English/Western writing systems this is not a minor point (even not for those actually able to handle those “foreign” systems, in fact). And we are not talking about any small number of individuals, by the way.

In general, we encourage (and ask) ICANN to prioritize applications aimed at population and areas where wide cultural and linguistic differences exist between the environment of the applicant (and intended users) and the mainstream Western/English-speaking environment. Failure to do so would be an implicit discrimination against applicants whose language is not English and not similar to English. ICANN must take into account that the difficulty of writing an application increases exponentially with cultural and linguistic differences. It is easy for an American company to write an application and be understood by ICANN evaluators. It is a bit more difficult for French or German-speaking applicants, and it is much more difficult for Chinese-speaking ones. The Chinese-speaking applicant already had to bridge a considerable cultural spectrum. Imagine what it would be like if Western applicants had to send their gTLD applications in Chinese. The cultural differences cause misunderstandings which must be corrected.

Beyond this point, ICANN has as a mandate to encourage diversity in the DNS, including cultural diversity and global reach of services. In this regard, we also propose that under-represented areas, such as Africa, Latin America or most of Asia (outside the Pacific Rim and Oceania, probably) should also benefit from some sort of priority. 

Ina different level, public interest is a guiding principle in how ICANN must manage the DNS. And we have long agreed that the different, local incarnations of public interest are defined by the relevant, local, authorities. In this regard we propose that those applications submitted by public authorities or backed by explicit endorsements of public authorities expressing that such TLDs would benefit the public interest they are competent to represent, would also benefit from a priority. This includes all geographic names as defined by ICANN, but not only those.

We also believe that community-based applications, when submitted by representative entities providing for an adequate accountability framework with regard to the community itself, should also benefit from a high level of priority.

Finally we propose some methods to handle the rest of applications.

2.2 Priority Criteria

2.2.1 Negative Priority: Contested Applications
For any of the categories below, we mean “uncontested” applications within such group. There are a series of facts that contribute to the natural throttling of applications, and this should be taken into account, We use this term broadly, covering applications affected by:

- Contention sets
- Objection Procedures
- GAC Early Warnings and GAC Advice

While those issues are unresolved, those applications should not be prioritized, as they would be affected by a delaying factor. We certainly don’t mean the they should be penalized, or even put lst in the queue for each step. we only claim that if, for instance, ICANN foresees at a given time that not all Initial Evaluations will be ready at the expected time, these ones should **not** concentrate the efforts, as they would in any case be unable to move to the next step yet. As soon as the delaying factor disappears, they should reintegrate their priority group. 

This also applies in later stages to applications:

being sent into Extended Evaluation
experiencing delays in contractual execution
failing or facing delays in pre-delegation test

 2.2.2 Priority for reasons of Public Interest
Overall, ICANN should give priority to

a) 	IDN applications
b) 	Geographic TLDs with the explicit support (or letter of non-objection) of the relevant public authorities, as well as any other TLD application with that explicit suport even if not geographic in the Guidebook terms.
c) 	Community-based TLDs for communities with clear community accountability and support. 
d) TLDs from under-represented areas, such as Africa, Latin America and most of Asia (Middle East; Central Asia; Southern Asia; Southeast Asia; excluding Oceania and the most developed economies of the Pacific area).


2.2.3 Priority by Applicant Choice (Voluntary Application Groups)

Ideally, the timing of TLD delegation should match the wishes of the applicants. Some applicants may actually prefer their application to be added to the DNS root at a later stage. Applicants with multiple applications will naturally have preferences as to which of their applications they want to go first.

Applicants should be allowed jointly set the preferred order of priority within a group of applications. For this purpose, TAS should allow each application to propose a group, to join a proposed group or not to join any group. For processing purposes, this process can be conducted over a period of 3-4 months. Those who joined a group can give their application and intra-group priority score agreed upon with the group’s proposer. The priority score can be updated and an application can leave a group and join another until the end of the grouping period.



2.2.4 Competition safeguards for exclusive-use TLDs

In the current environment, a brand owner having applied for a one or several exclusive-use TLDs is unlikely to be under time pressure. The only time-sensitive aspect is competition between brand TLDs in the same industry sector. So long all TLD applicants in the same sector transition to delegation at the same time, a typical brand applicant has no problems waiting 2 or three years, let alone some extra months (while we know this dos not apply to all applications, a significant number of those we consulted expressed that “not being clearly later than a competitor” was much more important than “when” their TLD would be delegated).

In other words, ICANN must be able to reassure them if their direct competitors will not be favoured. For instance, one can reasonably assume that a bank will not like its TLD to be introduced much later than another local bank, and that German car manufacturer will not like it if rival French, Japanese or US car manufacturers get their TLDs  introduced one year before.

That can easily be addressed. As pointed out under the responses to Question 1 above, there is a lot of value in formalizing the question of exclusive-use (Exemption from Specification 9) as early as possible. Applicant must be allowed to use TAS to declare they will use the TLD exclusively and therefore request exemption from Specification 9. If they do so, they should also be allowed to identify any gTLD application that they think is a same-industry competitor. Under normal circumstances, it should be easy to check plausibility: real competitors with exclusive-use TLD applications will symmetrically identify one another as competitors. From a processing standpoint, it is easiest is if TAS allows exclusive-use TLD applications to add a “same-industry-competitor” pointer towards any other application, whether or not that application already carries the exclusive-use pointer. The result must be published online. ICANN can then make delegation batches of exclusive use TLDs that are naturally linked as competitors.

-------------- 
Would this approach provide sufficient smoothing of the delegation rate?

Yes if applied according to its two basic principles:

The process should not create artificial bottlenecks at each stage by stopping everyone from moving to the next phase until everyone has completed the previous one; and,
If at any given moment, but most notably at the delegation step, there is a need for throttling, metering or smoothing into the next phase, the same public-policy oriented criteria should be used in order to establish priority.

In general terms, all the categories granted priority for public-interest reasons in this model amount to less than 300 applications, given the overlaps. This fails short of the intended batch size in the previous proposal, and represents just above a quarter of root delegation capabilities, if we understand that part correctly. Which means that there is still room for handling in early stages a fair number of applications from portfolio applicants, groups of competitive exclusive-use TLDs, and applications from other single-TLD applicants not in any other category.

------------------
4. 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)?

Yes. As explained above, the process should focus on efficiency, and whenever the number of available applications for a given phase or step is bigger than the available resources for parallel handling, the criteria should apply as explained.

--------------- 
5. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way?

ICANN staff is in a better position to establish the available bandwidth for each given phase. We all know of the published apparent constraints in the delegation phase, but the applicants know very little of how ICANN wants to manage both contractual execution and pre-delegation testing, so precise estimates are impossible.

We urge ICANN to use an idea similar to the airport’s “takeoff window”. Allocate a time window for each applicant (or groups or applicants) for both contractual execution and pre-delegation tests (we guess that for the latter, ICANN should establish concrete dates, though). The takeoff windows should not be necessarily the same. We might imagine that, for instance, community-based TLDs and Exclusive-Use TLDs might need a longer window, as they have to negotiate, on top of the standard contract, the policy commitments registrations restrictions, on one side, and the exception contained in Specification 9 (which includes some public-interest evaluation on ICANN’s side) on the other. If an applicant misses its window, or allocated date, it jumps its turn into the next allocation group.

However, we all need to keep in mind that the only really relevant step is “delegation”. This is “it”. And here we have the annual constraints (1000 per year, apparently, even this is more a target figure than an absolute figure set in tone). Plus the daily, weekly, monthly rates that have never been clarified. But we all assume that it is certainly not “let’s add all those 1000 for this year in a single morning”. Again, ICANN staff is in a better position to get and provide further clarification on workable weekly or monthly rates.

At this critical stage, it is where the application of the priority criteria expressed above takes most importance. 

------------
6. Provide reasoning for selecting this approach.

Our main goal in drafting this proposal is to prevent unnecessary delays though artificial bottlenecks at each of the four steps (Initial Evaluation; Contract Execution; Pre-Delegation Test, and Delegation). 

An over-simplistic view of “fairness” could lead to a solution that forces everyone to to everything at the same time. In other words, everybody should wait for the last applicant to pass Step 1 before everybody moves to Step 2. This is not fair, it is simply inefficient, and unfair to the whole group.

Let’s imagine ICANN invites 1927 people to a lunch. There is a self-service buffet. Nobody would pretend that the 1927 guests have the bread and the butter before anyone moves to the salad. And then nobody can start serving entrées until the 1927 have all got their serve of salads, and so on. The result of such process would be that everybody would start eating much later than with a “normal” self-service line. Being fair in the line but unfair in the lunch is not fairness, is inefficient unfairness to every guest.

What we really need is a fast moving line that gets everybody, including the last guests as soon as possible to the table. What counts is not when you get the meal, but when you can eat it, so the *fairness* principle must be applied precisely then: when people can start eating. Which in our situation means: when TLDs get delegated. As, contrary to a normal lunch, we know that not everybody can be delegated at the exact same time, it is better to organize the line from the beginning in a way that, logically, would lead to some groups of TLDs getting to the table (into delegation phase) not later than others.

As for the logic of applying priority in the context of processing constraints, the overall principle is the use priority of effort rather than priority of result as long as possible. This minimizes knock-on effects of delays.

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

CORE is not submitting these comments only on its own behalf, but after consultation and discussions with both its customers and other unrelated applicants. As general comments we would like stating that the order of evaluation, and, most notably, the prior decision to publish the evaluations in randomly-selected “batches” affected mostly *fairness among applicants* more than any other financial, operational or other long-term consideration. Evaluation is just one step on the process of becoming operational, and it is the point at which the TLD can start operations what counts. That is, the delegation point is the critical one. 

On the Initial Evaluation side, we consider that a) ICANN should proceed as quickly as possible; b) should avoid artificial delays, such as holding for too long evaluated applications for too long and c) if the preceding point advises early publication of a part of the Evaluation Reports, follow the criteria explained above.

On the contrary, the moment at which delegation happens is relevant to all applicants. With some distinctions. For a number, but not certainly not all, so-called Exclusive Use TLDs (or Brand TLDs or any other term referring to TLDs not open to third party registrations) the critical point seems to be fairness, in competitive terms: most of the applicants falling within this category we have consulted firmly express that not being significantly delayed with regard to other TLDs in the same industry, sector, area etc., is much more relevant than the concrete moment. On the contrary, for most open-to-third-party-registrations TLDs time is of the essence. And while we acknowledge that this is the for most (perhaps with the partial exception of portfolio applicants), it is specially relevant to community-based TLDs. Most of them have been relying for years upon the work of volunteers, and due to its structure cannot have access to external funding. Both clarity and celerity as to when they will be able to start the registry operations is critical for this subgroup.

But not adding further delays, after all these years, is of the utmost importance to most of the applicants.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CORE-Comments-Batching-2012-08-18.pdf
Type: application/pdf
Size: 110856 bytes
Desc: not available
Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/12e1b2e1/CORE-Comments-Batching-2012-08-18.pdf 
-------------- next part --------------