[Newgtld-input] New gTLD metering input from NIC.br

[Rubens Kuhl]

"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?"

Different types of applications can be grouped so when every application in that group finishes initial evaluation, their results can be published. These types should be the ones defined in the guidebook:  Community Applications, Geographic Applications, Standard Applications, not market-based determinations like brand/open/closed/single-registrant. 

Community applications will only be given such status if they elect to have a Community Priority Evaluation and pass it. Because of this possibility, community applications will be asked to elect to go or not go through Community Priority Evaluation even if they are not part of a contention set. If the application elects not to go thru Community Priority Evaluation or fails it, it will be considered standard application for the purposes of metering, although keeping the community restrictions on its contract. 

Geographic applications without government support would be either rejected or moved to the standard status through the metering process, depending on panel determination. 

However, grouping of evaluation results wouldn't be a factor on determining which applications to send to evaluators. Order of evaluation should still target maximum efficiency measured as the time it takes for the last application to finish evaluation. 

As GAC Advice is the likely throttle of applications, all successful applications that are not part of a contention set and have not received GAC Early Warning should proceed to pre-delegation testing before publishing of results. It's not assumed that no GAC EW means no GAC Advice, just that it's less likely. Early pre-delegation testing activities cannot be disclosed by applicants as ICANN approval or endorsement as applications are still subject of GAC and ICANN board determinations. Pre-delegation testing should be done for each back-end provider, defined by the same criteria used to optimize technical part evaluations. 

"	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)?"

At every processing stage, these guidelines should be observed, in this order:
1) First-In-First-Out : Until every application that entered a stage at the same date starts being processed, no other applications that have since arrived should enter processing. 
2) Geographic diversity: From every set of applications that enter a processing stage at the same date containing more than one ICANN region, one from each region should be picked from the queue, the same mechanism that would be in place with secondary timestamps.
3) Community priority: From every set of applications that enter a processing stage at the same date, community applications and geographic applications (both community-oriented, each in their own sense) would go first. 


For contract executions, besides those 3 base guidelines(FIFO, Geographic diversity, Community priority ), these guidelines should be observed:

4-Contract) Applications that have completed early pre-delegation testing should be picked first for contract execution than applications that will still need to go thru pre-delegation testing
5-Contract) Applicants with more than one application in this phase should wait until all applicants with a single application have contracts in place. For each stage, applicants would provide ICANN with a prioritized list of what strings they prefer to prioritize. For this guideline companies that are part of the same group would be treated as a single applicant.

For pre-delegation testing, we think the base guidelines are enough, as early pre-delegation testing as suggested in part 1 would leave few applications to this stage at this time. 

For delegations, besides those 3 base guidelines(FIFO, Geographic diversity, Community priority), these guidelines should be observed:

4-Delegation) IDNs: From every set of TLDs that are ready to be delegated at the same date, IDN TLDs (regardless of being an IDN new gTLD or an IDN ccTLD) should be picked first. 
5-Delegation) For TLDs entering delegation stage at the same date, they should be ordered by the A-Label (excluding "xn--" from IDNs) . To achieve  fairness, for each set of TLDs being metered, the criteria would be reversed, and the first set would have one criteria or another based on the week number being odd or even. After ordering they would be batched considering the at that time in effect delegation rate (assumed to be of 20 per week approximately). Uppercase or lowercase (IDNs) would be treated equally. 

This approach would provide priority for important topics (Community applications, IDNs), metering and a process that has variability without being random. The alternating criteria provides fairness (for instance, a string beginning with Z can be either the best thing or the worst thing at a single step, but on average all strings are alike). Smoothing would be by design achieved. 

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

We and our clients are not sensitive to the order of evaluation and delegation, so regardless of other TLDs being delegated earlier or later than ours, what we value is delegation at the earliest point in time. To clarify, between a scenario where other TLDs are delegated in February and ours in July, and a scenario where ours are delegated in October and others in December, we prefer the former.


Rubens Kuhl
NIC.br