[Newgtld-input] Melbourne IT response to call for Input on gTLD Batching

[Tony Smith]

Melbourne IT response to call for Input on gTLD Batching



============================================



Melbourne IT welcomes the opportunity to provide a response to ICANN's call for input on gTLD batching, posted on 29 July 2012.



(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.





In response to question 1:

====================



Please refer to the attached diagram of the evaluation process.



Melbourne IT believes that ICANN will be creating an artificial bunching of applications by attempting to release all Initial Reports at the same time, which in turn will lead to bottlenecks in the delegation process.  Melbourne IT recommends that initial evaluation reports be released as soon as possible after the evaluations are complete for each application.   This allows applicants and the general public to take these initial evaluation reports into account when planning whether to object to an application, as well as planning the allocation of resources to launch a new gTLD.



As Melbourne IT previously noted in its letters of 30 May 2012 and 25 June 2012 (http://www.icann.org/en/news/correspondence/hnarakis-to-chalaby-25jun12-en.pdf), there is a high degree of correlation amongst the applications.   72% of the applications are supported by 5 registry operators, while the 5 largest single applicants account for a third of the total applications submitted.   By taking advantage of these correlations, it should be possible to complete some initial evaluations either by the end of the year in 2012, or before the ICANN meeting in Beijing in April 2012.        Note that the Initial evaluation reports can be released prior to either GAC early warning or GAC advice, as GAC advice ultimately is taken into account by the ICANN staff and Board rather than the external evaluators, which are only evaluating applications against the criteria in the guidebook.   If the Initial reports are available at least one month prior to the Beijing meeting (7-12 April 2013), the GAC will be able to take the reports into account when finalizing their advice.



Given that some applications have no need for clarifying questions, some will have a few clarifying questions, and others may have many clarifying questions, there should be a natural spread over time for how these questions are dealt with.   Given the correlation between applications, there will also be a correlation in receiving and responding to clarifying questions.  For example if there is a clarifying question related to the technical operations of an application with a particular registry back-end operator, the same question and response would be required for other applicants using the same registry operator.





In response to question 1(a):   How can applications be allocated to particular release times in a fair and equitable way?

===========================================================================================





With reference to the diagram attached, a fair method of scheduling release times for initial reports would be to consider releasing results in proportion to the number of clarifying questions and the speed to which the responses are provided.



For example:



- release initial reports for those applications where there were no need for clarifying questions (e.g. 10% of applications as estimated by ICANN)



- release initial reports for those applications where there are less than 5 clarifying questions, where answers that have satisfied the evaluators are provided within 14 days



- release initial reports for those applications where there are more than 5 clarifying questions, where answers that have satisfied the evaluators are provided within 14 days



- release initial reports for those applications where there are less than 5 clarifying questions,  where further clarifying questions were required



- release initial reports for those  applications where there are more than 5 clarifying questions, where further clarifying questions were required



The exact sequencing will be determined by the actual spread of clarifying questions and the degree to which the responses have satisfied the examiners.   ICANN may choose to use different numbers of clarifying questions to break up the release of initial reports  - e.g. less than 2 clarifying questions, less than 3 clarifying questions etc.



The sequencing method is fair because those that have provided the most complete answers should have their initial evaluation reports released first.





In response to question 1(b):   Would this approach provide sufficient smoothing of the delegation rate?

================================================================================



As discussed in response to question 1(a) above, using the amount of clarifying questions, and the degree to which responses have satisfied the evaluators, is one method of smoothing the rate at which initial evaluation reports are released.



There are other areas where there will also be a natural smoothing effect.   With reference to the attached diagram of the evaluation process:



- some applications will receive a GAC Early Warning soon after the Toronto meeting in October 2012, and applicants will want to address the concerns raised by the GAC to avoid getting GAC advice in the transition to delegation phase.



- some applications will be subject to one or more formal objection processes - including string confusion objection, legal rights objection, limited public interest objection, or community objection.   These applications will not be able to proceed to the delegation phase until the objection process is completed.   The timing for when these objection processes complete will also vary, providing more spread over time for when applications are ready to enter the transition to delegation phase.



- some applications will fail initial evaluation, and go into extended evaluation.  Extended evaluation itself could go through cycles of additional clarifying questions as shown in the attached diagram.



- once applications have passed all evaluation and objection processes, there may still be situations where string contention still exists.   Applicants have the option to work to resolve string contention while initial evaluation and objection processes are underway.   Where string contention still exists, applicants can be given additional time to reach a resolution amongst themselves.      Where applicants cannot resolve contention amongst themselves then either community evaluations or an auction process will necessary.   The process of resolving string contention will also provide more spread over time for when applications are ready to enter the transition to delegation phase.



- once applications enter the transition to delegation phase there are several steps within that phase that may introduce a further spread in timing.    Some applications will be able to sign the standard gTLD registry agreement, and others may require changes to conform with their local laws, or to take into account any agreements reached with Governments in response to GAC early warning.   Changes will need to be posted for public comment before they could be approved by ICANN.   Once an applicant signs a registry agreement, the date and time of receiving the signed application should be noted for use in final scheduling of delegation.



- once a gTLD registry agreement has been agreed, a final check will need to be made to see if any GAC advice has been received.    The applicant may have the option of resolving the issue for which GAC advice is received .     Once the staff prepare a report for the Board, the Board could decide to send an application back for further changes in response to GAC advice, reject the application, or approve the application following the bylaws process for rejecting GAC advice.   Each of these steps has its own level of time variation.



- once a gTLD agreement has been approved by the Board and sent to IANA for processing, IANA will need to run pre-delegation technical tests.   It is likely that the time taken to satisfy the technical tests will vary by applicant, although there will be correlation amongst registry back-end operators that will be able to streamline their processes.



As described above, Melbourne IT believes that the combination of spreading the release of initial reports, along with the significant level of variation in the evaluation process as described above, and shown in the attached diagram, should introduce a significant smoothing of the rate at which new gTLDs are ready to be delegated into the root.   Should that level of smoothing not be sufficient, Melbourne IT proposes some additional techniques below to meter the flow of new gTLDs into the root.





In response to question 1(c):   Provide reasoning for selecting this approach.

=========================================================



Melbourne IT recommends that ICANN take advantage of the natural smoothing available in the full evaluation process as shown in the attached diagram.  A key part of the smoothing available is to avoid artificially bunching applications up at the end of the initial evaluation phase.   The fairest approach to evaluation is to take into account the number of clarifying questions, and publish initial reports early for those with no or few clarifying questions.   This rewards those applicants that have provided sufficient answers to the questions in the application.    Delegation of applications that have passed initial evaluation in the least time, with no objections and no contention, should also naturally proceed to delegation first.



=========================================================================================



=========================================================================================





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.





Response to question 2:

===================



Melbourne IT believes that the chances are low that more than 1000 applications will be ready to delegate in a given year.   However there may need to be a method to ensure that applications are gradually released into the top level zone.   For example it may be desirable not to release more than 100 gTLDs in a given week, or it may be desirable to start with a smaller number in the first few weeks and months, and ramp up to higher numbers as system stability is demonstrated  e.g. starting with 10 names a week, and then gradually increasing.



Melbourne IT assumes that the ICANN Board is likely to approve gTLDs on a monthly basis once the gTLD registry agreements are signed, and any GAC advice is resolved.   The Board can take advantage of the natural variability of the process described in the responses to questions 1 (a) and 1 (b) above, to approve gTLDs in batches.



After the Board has approved a batch of applications to be delegated, the staff could schedule the technical testing and delegation of the approved applications on a weekly basis, as described in response to question 2 (a) below.





Response to question 2(a):    How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way?



=====================================================



Once the Board has approved a batch of gTLDs for delegation, the IANA staff could assign gTLDs to weekly delegation slots by using the following prioritisation approach:



- allow applicants to request a later slot in the delegation process (or put delegation on hold for up to a year).    Depending on the degree to which the applicant choses to delay delegation, ICANN could provide an exemption for the Registry Fees (US$6,250 per quarter) for one or more calendar quarters.



- date of receiving a signed gTLD registry agreement



- geographic region of the applicant - allocate gTLDs in a weekly slot fairly across the five  ICANN geographic regions: North America, Latin America/Caribbean Islands, Asia/Australia/Pacific, Europe and Africa



- applications with the highest score in the evaluation process



- gTLDs based on IDNs



- alphabetical   (as a last resort)





Response to question 2 (b):   Provide reasoning for selecting this approach.

=========================================================



It is likely that some metering of applications will be needed to ensure the smooth delegation of gTLDs that have been approved in a batch by the ICANN Board.



Applicants should be given the chance to decide themselves whether they are ready for immediate delegation, or whether they would like more time to plan the launch of their gTLD.   ICANN could provide exemption from the Registry Fee on a quarterly basis as an incentive for applications to spread their delegations over time.



If Applicants don't volunteer for a later delegation slot, ICANN should attempt to even out the delegation rate by taking into account the date of signing of the gTLD agreement and the  ICANN Geographic region to ensure an even spread of gTLDs globally.   This is likely to ensure that those from regions such as Africa and South America are likely to be able to be delegated when they are ready, as these regions have fewer applications in comparison with USA and Europe.



Within a particular geographic region, ICANN should reward those applications that have the highest evaluation score by allowing them to be delegated first.



Finally if the above method doesn't result in a sufficient spread of gTLDs across weekly delegation slots, then ICANN could use a last resort method like alphabetical assignment.   IDNs would be treated as at the beginning of any alphabetic order.    ICANN could alternate between "a" to "z" or "z" to "a" order for each batch approved by the ICANN Board.







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

===============================================================================================



Melbourne IT is not an applicant for a new gTLD, but has provided consulting advice for 146 applications.    The level of importance of evaluation order and delegation varies by customer.



Some customers wish to gain a competitive advantage in the market by launching their new gTLDs as early as possible, while other customers may be happy to take their time to prepare their launch plans by evaluating the approaches successfully used by other gTLD operators and their level of commercial success.



A priority for most customers will be certainty that their application has been accepted, but there is likely to be more variability with respect to when customers want to go live with their new gTLD.   Thus customers will want to secure a signed registry agreement with ICANN as soon as possible.

-----

Tony Smith | General Manager - Corporate Communications | Melbourne IT | Brisbane, Australia | ph +61 7 3230 7525 | fax +61 7 3249 2533 | mob +61 412 879 360 |  www.melbourneit.info<http://www.melbourneit.info/>

Melbourne IT Group (ASX: MLB)
The information contained in this email message may be confidential. If you are not the intended recipient any use, distribution, disclosure or copying of this information is prohibited. If you receive this email in error, please tell us by return email and delete it and any attachments from your system.

P Please consider the environment before printing this e-mail

-------------- next part --------------
A non-text attachment was scrubbed...
Name: evaluation-process.pdf
Type: application/pdf
Size: 117576 bytes
Desc: evaluation-process.pdf
Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/a60546b0/evaluation-process.pdf