Support for other Comments and proposal for corrections

[Amadeu Abril I Abril <Amadeu.Abril@xxxxxxxxxxx>]

CORE Internet Council of Registrars thanks ICANN for this new opportunity to 
comment on the processing TLD applications.

In order to make everybody’s tasks simpler, here is the summary of our position:

The Draw is an improvement over the Digital Archery proposal. While still 
causing a number of undesirable and unnecessary unfair side effects, these can 
be easily corrected with minor corrections to the proposal.

CORE wants to explicitly support the comments sent by the New TLD Applicants 
Group (NTAG; except in its partial implication that only IDNs should enjoy some 
gurantess against de-prioritization), the Community-based TLD Applicants Group 
(CTAG), the Geographic-names TLD Applicants Group (GeoTAG), as well as other 
comments such as those sent by ECLID , puntoGAL and others proposing 
improvements on the Draw Proposal, including those from the GAC as epressed in 
the Toronto Communiqué (partially as the position of several members and not 
GAC’s itself).

While these comments touch on different aspects, they are mostly complementary. 
The amendments we propose and support can be summed up in three principles:

Preventing the relegation of applications with special public interest relevance
Multiple-track draw (in order to prevent the excessive de-prioritization of 
applications not fulfilling the criteria in A) above) and
Technical corrections to prevent unnecessary detrimental effects of the Draw.

Here is the list of supported amendments:

Preventing the relegation of applications with special public interest 
relevance.

CORE supports that a mechanism (some sort of prioritization; in reality, a 
guarantee of non-de-prioritization given the “natural” play of the numbers 
involved) of applications meeting the following criteria:

IDN applications
Community-based applications
Geographic and other applications expressly supported by the relevant public 
authorities
Applications coming from underreresented areas (Africa, Latin America)

Arguments for these choices have been made been made by the commenters 
mentioned above, and many others. We don’t have a specific view on 
prioritization among these types of applications. It is not that any of them 
has a “right to be first”, it is that the whole ICANN community has an interest 
in them “not being last”. 

All those groups account for slightly above 200 applications. Once contested 
applications (cntention; objection; GAC advice) discounted, as they will be 
indeed throttled back to sovle those different types of disputes, there will be 
less than 200. That is, 10 weeks of delegation time. This is close to 
irrelevant, but we propose under B) a simple mechanism (also proposed by NTAG) 
to further reduce the slight, but certain, impact on the rest of applications.

One important technical correction regarding many comments is regarding the use 
of geograhic names as a group. ICANN has set some specific rules regarding 
eligibility of such applications, but it is not the “category” that brings them 
here, but the fact that (due to the eligibility requirement) they must provide 
express support of by the relevant public authorities. This is what brings them 
the “public interest” angle, as exlicitly expressed by the public authority 
which has the sole responsibility for interpreting such public interest. Hence, 
we recomemnt ICANN to:

not include in the group the so-called geoTLDs which have not pased the 
Geographic Nmes Review at the time of the Draw (as the condition of support 
will still be missing) and
Include those that have the explicit support, but are not strictly geographic 
names in the sense of the Applicant Guidebook (a ahndful of them exist; often 
in the grey area of what is a gographic name; but as they have that explciit 
expression of support from the relevant authority, in terms of interpret of 
that “local” public interest, they should deserve the same treatment).

Applying a double track in the Draw: Round-robin between prioritized and the 
rest

In the current proposal, only IDNs can be effectively delegated during the 
first 5 weeks (some 100+ applications). In our proposal (and the proposals of a 
large proportion of the community) this figure could double, up to 10 weeks. 
Two months and a half. 

This is not dramatic, but, as said above, it is not that those categories have 
a right to be first above anyone else; only a need not to be sent at the end. 
Our proposal therefore (as NTAG and others also support) is to have a dobule 
track. with a round-robin mechanism between those 200 prioritized applications 
and the rest. This would effectively mean that all those applications falling 
under A) would have a chance to be delegated during the first five months (20 
weeks) of elegations (unless they fail frther behind in any of the successive 
steps, indeed: but they have the chance, and this is what counts). But other 
applciations of any other type would also have chances to be at the very 
beginning, even the very first one (something absent in the current proposal).

The non-deprioritization measures under A) above are intended to counter the 
natural effects of the big number of applications, and the fact that some 
applicants have large numbers of applications, with the sytem playing logically 
in their favour. But those other applicants, including large portfolio 
applicants, should not be deprived of the chance to alos be at the very 
beginning.

Technical corrections to prevent undesirable side effects

CORE would also like proposing the following simple mechanisms to prevent some 
of the unwanted effects to sizable groups of applciants:

Allow multiple-application applicants to order their applications before the 
Draw.

This one seems simple. Nobody would be harmed by allowing applicants to express 
their desiered order for processing their applications. This would not alter 
their chances in the Draw, only provide for a more rational prioritization. Not 
only applicants, but likely users and intended applicants would greatly benefit 
from such simple correction.

The combined effect of this correction and the proposal round-robin mean that 
so-called protfolio applicants are in fact much better off under this proposal 
than the original one, despite the fact of the increase of “prioritized” 
applications: they have a much higher statistical likelihood of having their 
top 1, top 10 and even top 20 applications in the first half of the delegation 
process, compared to the current proposal.

Consider s sub-track for single-application applicants.

The other group for which the statistical odds are adverse in the Draw is the 
non-prioritized single-application applicants. We propose that they go in 
round-robin with the rest of de-prioritized (in that case, multiple application 
applicants) ones. This would mean 1-in-4 slots during the first 5 months, 
1-in-2 after the 200 “prioritized” applications are dealt with.

Allow voluntary grouping.

For many TLDs, specially for many exclusive-use applicants (aka, brand TLDs) 
the msot imprtant factor is “not being too far behind my main competitors”. 
Granted many don’t care, but many others have this competitive advantage angle 
as their top priority, clearly over timeline. The current proposal does not 
address this (only solution is to delay one self, but not to be tied with 
somebody who was luckier in the Draw).

CORE proposes that applicants so within be able to “tie” themselves with other 
appications. That is, Application A decides that they want to be immediately 
after Application B. Instead of having their own ticket in he Draw, their are 
grouped with the other applciations.

Again, nobody is worse off: If application B does not care, its chances are not 
at all affected by who is after them, not before. The rest of the pool is also 
unaffected as thoe two (or three or ten) applications would in fact have a 
single ticket, and a single chance, inthe Draw (but once their number drawn, 
they would take two, three or ten places at that precise point). Contrary to 
the Digital Archery proposal, where contentions sets were favored by the 
multiple-ticket, all-go-with-first approach, here the rest of the applications 
are not negatively affected in their chances “be early”.

In order to prevent gaming or unintended effects, the size of such groupings 
could be limited to 20 applications (one week of delegations) or even half 
that. Applicants would have one week to establish those groupings or links 
before the Draw, in the TAS.

*****

CORE sincerely believes that these corrections would greatly improve the 
current proposal, as their net added affect would be to have most applicants 
better off than they are now (community, geo and underrrepsented applicants 
gaining some prioritization; large portfolios gaining their ability to 
prioritize their preferred applications and also gaining access to the very 
first slots through the round-robin; single applicants gaining a part on the 
round-robin, and hence the top slots; many exclusive-use TLDs, but not only, 
gaining the chance to prevent unfair anticompetitive effects of the Draw..). 
While nobody really losing compared to the current proposal, except for the 
mostly marginal case of IDNs (which would move from having a guaranteed slot in 
the first 10 weeks to the first 20 weeks). But this effect, even if it amounts 
to doubling the timeline, is really marginal (we are still talking about the 
first five months, or less). 
We believe that this simple corrections deserve therefore the attention of 
ICANN’s staff and Board, as they produce big benefits to large number of 
applicants, with negligible, if any, unwanted effect, without adding too much 
complications to the system as proposed, and without requiring ICANN to make 
any individual or subjective decision (ordering of applications for multiple 
applicants, or self-grouping would be dealt with by applicants themselves, not 
ICANN).

Disclosure: CORE has applied for 3 TLDs, all of them IDN, precisely the group 
that loses something in our propsoal, but a negligible something. We also 
provide registry back end services, and in some cases, front end services, to a 
number of other applications: community-bawed; geoprphical names TLDs, and 
exclusive-use TLDs.

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