[Newgtld-input] Pharos Global's Batching/Metering Comments

[Michael D. Palage]

Dear ICANN,

 

I submit these comments in my individual capacity as President/CEO of Pharos
Global, and not on behalf of any current, previous or future client. In the
interest of openness and transparency Pharos Global was involved with over
150 new gTLD applications. While ICANN has asked commenters to respond to a
specific list of enumerated questions, I believe that ICANN staff's approach
toward this issue is systemic of a much larger problem which hinders ICANN's
operational effectiveness.  Specifically, this consultative process, either
by design or happenstance, is destined to fail.  Instead of this process
resulting in a bottom up consultative process based on facts and  taking
into account the full diversity of stakeholder views, the likely result will
be a top down staff authored proposal/solution prepared to meet the pending
deadline for briefing materials in connection with next month's ICANN Board
retreat.  Hopefully, this public comment will cause the ICANN Board and the
new CEO to pause and ask themselves the following question: are we taking
the time to make a decision based on facts and true community consultation,
or are we making a decision based on an artificial deadline, with limited
facts just to tick a box and claim that we are moving forward?

 

Before you answer that question please consider the following facts.

 

1.            Delay in initiating consultative process and deviation from
existing public comment protocol

 

Despite representations by ICANN in June during the Prague meeting that a
consultative process would be happening, it was not until the end of July
that a formal process was initiated.  However, when ICANN staff finally
launched this public comment forum, it did so by deviating from the existing
ICANN public comment protocol.  Specifically, this important consultation
was not listed on the global ICANN Public Comment portal webpage,
http://www.icann.org/en/news/public-comment. While it was posted in the
announcement sections of the ICANN main website and the new gTLD portal,
this deviation from existing protocol resulted in confusion within the ICANN
community as evidenced by a number of comments received through the public
comment forum.  It appears that the only reason ICANN staff deviated from
posting this important community consultation on the normal Public Comment
portal webpage was to break from existing public comment protocol which
allows for a 21 day response period.  Simply put, because of the delay in
launching the public consultation process, ICANN staff did not have
sufficient time to allow for a  21 day response period while still meeting
ICANN staff's  internal deadlines for briefing material in connection with
the upcoming ICANN Board retreat (September 12th -13th).

 

2.            Asking for proposals from the community without providing the
community the necessary metrics to make informed proposals

 

The first step in effective organizational management would have been to
identify potential bottlenecks in the delegation process and seek data
points of these potential rate limiting factors BEFORE proceeding with the
current consultative phase. It is respectfully submitted that ICANN's
current consultative process is premature and should not be undertaken until
the following questions are properly answered and the results shared with
the global stakeholder community.

 

A) In light of the new IANA contract which will require ICANN to provide
"specific documentation demonstrating how the process provided the
opportunity for input from relevant stakeholders and was supportive

of the global public interest" has ICANN obtained from the GAC any global
public interest concerns which it believes needs to be advanced/protected in
connection with any batching/metering proposal?  For example, the ICANN
Board had previously indicated a preference in Digital Archery for a
geographical distribution of applications from each of the five ICANN
geographical regions.  Does the GAC support this, does the ICANN Board still
support this.  Answers to this and other important public policy questions
are important drivers in any final implementation proposals.

 

B) How many delegations into the root can the United States Government (USG)
handle on a weekly basis. Although this is perhaps the last step in the
delegation process, has ICANN consulted/received a response from the USG
with regard to how many new delegations it can process in connection with
its existing workload. If so where/when will this response be posted.  While
the USG has not formally objected to the 1000 new gTLDs per year, does this
silence equate to the USG being able to process no more than 19 new gTLDs
per week, e.g. 1,000 new gTLDs divided by 52 weeks. It is difficult to
engage in a constructive dialog on batching/metering without this important
variable.

 

C) With regard to pre-delegation testing, will ICANN require every standard
application (e.g. no deviating from existing EPP or technical standards) to
undergo complete pre-delegation testing or will there be some type of
expedited testing for established backend providers which have already
satisfactorily completed this testing or will ICANN require certain
applicants and backend registry operators to undergo the same testing
hundreds of times?

 

D) How many delegations per week can the more popular backend registry
operators handle?  While most backend registry operators are unlikely to
disclose this information publicly for fear that it will be used against
them by a competitor, there is a finite number of gTLDs than even the
established and well-funded backend registry operators can handle.   While
some commenters have claimed that the contracting phase will result in a
natural throttling of applications being entered into the root, it is
respectfully submitted that these commenters are missing the fact that a
large portion of applicants that pass initial evaluation and are not
involved in contention sets will sign ICANN's standard registry contract
without amendments for the sole purpose of being first to market.  Therefore
there will  likely be large influx of applicants seeking immediate
delegation after passing the initial evaluation and being permitted to sign
a contract with ICANN.  

 


3.            ICANN's wiliness to consider proposals calling for increased
efficiencies in the application process

 

The New TLD Applicant Group (NTAG), an Interest Group of the Registry
Stakeholder Group, has proposed a number of constructive ideas to increase
the efficiencies of processing applications. Without commenting on the
merits of each recommendation, ICANN's decision to adopt some or all of
these proposals (e.g. pre-delegation testing,  pre-approval contractual
negotiations, etc.) would have a direct impact on the above discussed rate
limiting considerations.

 

Conclusion

 

Hopefully these data points will provide the ICANN Board with the necessary
information to engage in some thought leadership discussions during its
upcoming ICANN Board retreat instead of feeling pressured to rubber stamp
some ICANN staff generated proposal in which the community will be left
scratching our heads trying to decipher some highly redacted briefing
document circulated a month or more after the Board passes a resolution.
Hopefully the ICANN Board will not forget the lessons learned from Digital
Archery, that taking one step forward only to have to take three steps back
shortly thereafter is not the type of thought leadership that the community
and the 1900 plus applicants are looking for at this critical juncture.

 

Respectfully submitted,

 

Michael D. Palage