-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FYI
Joy
- -------- Original Message --------
Subject: [council] ICANN Seeks Input on gTLD Batching
Date: Mon, 30 Jul 2012 01:17:41 +0000
From: Bruce Tonkin <[log in to unmask]>
To: Council GNSO <[log in to unmask]>
ICANN News Alert
http://www.icann.org/en/news/announcements/announcement-29jul12-en.htm
____________________________________
ICANN Seeks Input on gTLD Batching
29 July 2012
Opportunity for Community Input: Processing of New gTLD Applications
At the Prague ICANN meeting, the new gTLD Program Committee decided to
terminate Digital Archery, and instructed ICANN staff to proceed with
the initial evaluation of applications as quickly as possible. This
evaluation is in progress based on a tentative project plan that
foresees the processing of applications in a single batch, and
simultaneous release of results. ICANN believes this approach is
consistent with the constraints that various parts of the community
have in performing their respective roles in the evaluation process,
and with the feedback received from the community at the Prague meeting.
This comment opportunity seeks input on requirements for an evaluation
and delegation process consistent with previous root zone scaling
discussions of smooth delegations, adding no more than 1,000 new gTLDs
per year. This outcome can be achieved by the:
a. timing of the release of evaluation results to applicants,
b. timing of the release of applications into the pre-delegation
steps of contract execution and pre-delegation testing,
c. metering of delegations of new gTLDs into the root zone.
ICANN is committed to executing the evaluation and delegation process
in a way that is equitable and meets ICANN's commitment to ensuring
the security and stability of the DNS, consistent with previously
established root zone scaling goals.
Please write to [log in to unmask] with your input. Comments
received by 19 August 2012 (UTC 00:00) will be considered.
Background
The concept of batching has been a part of the Applicant Guidebook
since its first draft. Batching accomplishes three goals:
1. Better management of the evaluation process by placing an upper
bound on the number of evaluators necessary and the number of parallel
evaluations occurring at any one time.
2. Release of evaluation results to applicants according to a
predictable schedule.
3. Delegation of TLDs at a rate acceptable to the technical
community, consistent with the root zone scaling discussion.
Based on the definitive information that ICANN now has about the pool
of applications, and work on the evaluations to date, this comment
process seeks input to meet requirements for goals #2 and #3.
Leading up to and during ICANN's meeting in Prague, the applicant and
community positions on requirements for batching schemes that would
control the evaluation, communication and delegation of applications
were reported to be:
a. The batching solution has to be equitable.
b. The evaluation results have to be announced at the same time.
c. Successful applications should proceed to delegation phase without
undue delays.
d. Delegation to the root must be at a smooth rate and must not
exceed 1,000 per year.
e. The GAC is planning to issue early warnings shortly after the
Toronto ICANN meeting in October 2012.
f. Consideration by the GAC of issues concerning GAC advice on
contentious applications is not expected to be finalized before the
Beijing meeting in April 2013.
During the root scaling discussion, it was agreed that ICANN would not
delegate TLDs at a rate greater than 1,000 per year. This is because
the primary challenge with maintaining root zone stability is
controlling the rate of change to the root zone system and not the
size of the root zone itself, meaning delegation should not occur at a
rate of 1,000 delegations on a single day.
In Prague, the batching and prioritization method known as Digital
Archery was terminated and eliminated from further consideration.
Recent Developments
Initial evaluation of new gTLD applications is underway.
Applications are being distributed to evaluators in a way that enables
efficient processing.
ICANN has conducted pilot evaluations and had discussions with
evaluators to accelerate the evaluation schedule. As a result of these
discussions, the evaluation teams have committed to accelerate the
evaluations substantially, while processing them in a single batch.
In Prague, a methodology was discussed where the smooth delegation of
applications could occur by first releasing applications that passed
initial evaluation without the need for clarifying questions, then
releasing applications in order of the number of clarifying questions
required, from fewest to highest. After analysis, this methodology
proved unworkable because 80% to 90% of the total evaluation time is
required to form and ask clarifying questions, so little smoothing
would result.
The current plan indicates that initial evaluation of all
applications, processed in a "single batch", can be completed in 11-12
months, possibly less – resulting in publication of results in
June-July 2013.
Note: It is planned that regular updates to applicants during the
evaluation period will be provided. In addition to written reports,
ICANN is looking into the use of a webinar / conference call format to
deliver updates.
For applicants, releasing results in a single batch would mean that
the first delegations would occur in late third quarter of 2013, six
months later than originally expected.
Implications of GAC timing:
The GAC plans to "issue any Early Warnings shortly after the Toronto
ICANN meeting, in October 2012," meaning that Early Warnings would be
received within the currently planned single evaluation period.
Also, the GAC "is considering the implications of providing any GAC
advice on gTLD applications. These considerations are not expected to
be finalized before the Beijing meeting in April 2013." This is
shortly before the currently planned announcement of initial
evaluation results (i.e., the schedule without additional
accelerations beyond those stated above).
Statement of the Issue
While there will be some natural smoothing as applications take
different paths through objections and contention resolution
processes, there will still be a requirement for some method of
metering applications into the delegation process. This is due to the
relatively high number of applications that may reach pre-delegation
steps at essentially the same time. A metering method has not yet been
determined and will need to be developed.
Questions to be answered by comments
Submitted comments should specifically answer each of the following
questions:
1. Should the metering or smoothing consider releasing evaluation
results, and transitioning applications into the contract execution
and pre-delegation testing phases, at different times?
a. How can applications be allocated to particular release times in
a fair and equitable way?
b. Would this approach provide sufficient smoothing of the
delegation rate?
c. Provide reasoning for selecting this approach.
2. 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)?
a. How can applications be allocated to a particular timing in
contract execution, pre-delegation testing, or delegation in a fair
and equitable way?
b. Provide reasoning for selecting this approach.
3. Include a statement describing the level of importance that the
order of evaluation and delegation has for your application.
Please write to [log in to unmask] with your input. Comments
received by 19 August 2012 (UTC 00:00) will be considered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQFgQoAAoJEA9zUGgfM+bqghYH/A3gbgyxfg2xIqvYHb9knkMB
Z9IgHPnowDSZrGyYvw+FtdFFI0lwalM3eLNY08DjqLD1uZ00VwC418CG4BfrktB4
LZpxYngRqsZWr5ce9sz+Tr1URsewDWJB4bOZ7cIg8ZAnCP51YhSnZlFLoGfQDl0M
Je2NdQbN86aHgYPAnnXm1FMxw/eEDACMci6yYdj9s4rlFaMRebX4OJ/n5aGBLpWV
spVw7CpUY1sIHKXjbSuCbwsGGt1Wc+61Ah1lx07ng4P4lqclcVsWJ9fROn0Obz42
4r2jjJZSjkrQdpQRWCOFJzpZzMaE4ocoDdynDZmsF9TsdcFJ7b1KvXZsZAl0aoo=
=FE5z
-----END PGP SIGNATURE-----
|
