<<<
Chronological Index
>>> <<<
Thread Index
>>>
Comments from ISPCP Constituency
- To: <draft-eoi-model@xxxxxxxxx>
- Subject: Comments from ISPCP Constituency
- From: "Tonyarholmes@xxxxxxxxxxxxxx" <tonyarholmes@xxxxxxxxxxxxxx>
- Date: Wed, 27 Jan 2010 22:43:21 -0000
The following comment represents the views of the Internet Service Provider
& Connectivity Providers Constituency.
Tony Holmes
ISPCP Chairman
ISP & Connectivity Providers Constituency
Constituency Comments on New gTLD Program - Draft expression of
Interest/Pre-Registrations Model
The ISPCP welcomes the opportunity to comment on the Draft expression of
Interest/Pre registration model.
The new gTLD program will have a strong impact on both ISPs and Network
Operators, and the ISPCP considers the stability and security of the DNS is
of prime importance to ISPs and the community that it serves.
The ISPCP is reviewing the Expression of Interest (EoI) concept with great
interest, and asks the board to consider the following issues in its
discussion of the EoI.
EoI may be a pragmatic approach and, as we go forward, and a more reliable
tool to measure the true level of demand for new gTLDS of different
categories. While many concerns remain regarding the EoI process and
circumvention of the DAG, the ISPCP is mindful of the beneficial impact of
the EoI.
The data collected will help clarify and address two of the overarching
issues:
- Economic demand and impacts
- Root scaling issues.
It will also provide to ISPs and Network operators useful information that
could assist in preparing for this fundamental change.
For the EoI data to be fully representative, and to minimize gaming, the EoI
should be mandatory for the first round of applications, and for the same
reason, a deposit should be required.
The ISPCP supports the principle that the deposit should be refundable if
the new gTLD program is not launched within a specific period of time that
would be known to all EoI candidates. But what is not clear is the timeline
in which this is expected to happen and what the conditions will look like
for launch of the EoI applicants.
We understand that there may be amendments to the Applicant Guidebook and
major changes to the RFP following the analysis of the results of the EoI.
It is indeed important to assess the interest of the community for this
process and amend the process accordingly to better serve it. However, if
such amendments are required and have a significant substantive impact on a
particular application because of its nature or characteristics (e.g. string
or category of application/applicant), the EoI could create false
expectations. We ask that ICANN elaborate on the contractual issues that
will arise if the Applicant Guidebook conflicts with the EoI process.
The EoI objectives are to clarify the impacts of the RFP related to the
overarching issues. In this respect, we do not see the value of making
public the participant and string information without the explicit consent
of the requestor. Knowing the character string and the requestor's identity
will not help evaluating the impacts for the above issues. Worse, in the
absence of mechanisms in place like appeals, contention/dispute resolution,
etc, such disclosure will result in confusion or legal actions without any
mechanism in place for the potential applicant and/or its contender(s) to
address them. This can only create confusion and uncertainty. A potential
applicant should therefore be granted confidentiality for the string
requested and/or on its identity if it so requests and public information
should be restricted to what is necessary for the community to address in an
efficient way the overarching issues.
The EoI should aim to help to solve or to have a better view on overarching
issues, not to create more confusion in the process, nor to further delay
the process for gTLDs expansion. The EoI is a useful tool to gauge impact of
the new TLD process, however there needs to be greater clarity and
consideration of the concerns raised by the community prior to its launch.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|