Page History
...
Application Submission Period Section 4.2.13
Dial out: Cheryl Langdon-Orr, Seun Ojedeji
Apologies: Seun Ojedeji
On audio only: none
Action Items/Discussion Notes:
1. Work Track Progress Status [reading from slide 3]
-- Good progress on all of the topics
-- Adjusting the work plan a bit
-- Focus to see if we can close a few topics
-- Accreditation -- had hoped to close by mid-December but still discussing
-- Still on track for applicant support
-- Need more discussion on clarity of application process, application fees, and variable fees
-- application queuing and submission period will fall under clarity of application process
2. Clarity of application process [reading from slide 4]
Accreditation -- new working group and carving out policies for WT1 to focus on for the next meeting
Clarify of application process [reading from slide 5]
-- Any additions to what is on the slide?
-- Will put forward what we have to the list for consideration
Application Queuing [reading from slide 6]
-- Need feedback on whether we still believe that first come, first served is relevant, or if another mechanism is more appropriate
-- If it is a round is first come, first served relevant? Could be some other method after that.
-- This just the order that the application is reviewed.
-- Not sure how this would play out in an application period. Two options -- wait for the last one in the contention set or everyone gets the benefit of the first one selected -- all applications for the same TLD would be evaluated.
-- To be clear we are talking about the substantive processing, which could potentially go all the way through to delegation. Processing on contention sets has to be done on all of the applications.
-- First what would happen is ICANN woudl time stamp the applications as received, wait until the end of the period, determine the contention sets, they would do the review application 1, 2, etc. Use the priority numbers to release the intial results, but that wouldn't be processing everything, just the priority number for initial processing.
-- The question we are trying to address is whether first come, first served is still relevant.
-- First come, first served: Yes/No; lottery system: yes/no -- lottery system 9 approvals and no objections.
-- Went away from first come, first served to the lottery. We are seeing a preference for a lottery and not seeing why we should go back to first come, first served.
-- Could hold multiple lotteries within categories (as with IDNs).
-- Should not use the term "lottery". Cannot get a license for that process.
Action Items:
1. Put forward lottery system to the list.
2. Ask staff what they would need to do to keep their lottery license to continue to do lotteries
From the chat:
Rubens Kuhl: As long as we are doing rounds, it is not relevant.
Rubens Kuhl: Changes are required at least to reflect what has already been done.
Alexander Schubert: 1stcome1stserve would only benefit the portfolio guys with their unlimited rescources!
Alexander Schubert: In a gTLD round!
Jeff Neuman: So, is everyone comfortable with the randomization/lottery that ICANN held
Steve Chan: The current guidance should be viewed in contrast with the prioritization.
Jeff Neuman: (assuming ICANN can maintain the license to run lotteries)?
Michael Flemming: Firstly in rounds, then yes as long as we have objections of course :)
Jeff Neuman: If we do rounds, I would not be comfortable with first come first served. I think the lottery was the only fair way to go.
Michael Flemming: once again are we talking about rounds?
Jeff Neuman: I think a question needs to go to staff (legal) to see whether they can maintain their license to run the lottery
Alexander Schubert: +1 Jeff - two scenarios: Round and ongoing application period
Michael Flemming: secondly, if a long term period, then first come first serve as long as we have objections of course :)
Ashley Roberts: Agree some kind of randomised assignment of priority numbers is preferable to FCFS
Laura Watkins (Nominet): +1 Ashley
Alexander Schubert: How about prioritizing GEo's - as they are usually clear cut cases with no contention (as they usually require the OK of the Government)
Rubens Kuhl: FCFS is an invitation to dropcatch-like practices where people will bomb the application system to hell so their TLDs go first in application processing.
Michael Flemming: I'm with Jeff
Trang Nguyen: In the current round, the priority numbers were used to release IE results.
Alexander Schubert: Another idea: Have 10% of slots being prioritized by the Internet Community! So the 10% strings the Internet Users in the world value as potentially most impacting would be awarded the top 10% slots? Negative: Potential gaming.
Rubens Kuhl: We can let every applicant point one other string as their main competitor, and the process would honor those requests so the results would be released in the same time.
Steve Chan: The priority numbers were also used for contracting, PDT, and transition to delegation, if I'm not mistaken.
Jeff Neuman: So again, we need to ask ICANN legal whether they could maintain the license to run the "lotteries" and what they need to do to maintain that license.
Rubens Kuhl: But if not in the policy, it should be written that processing would always favor and only be based on process efficiencies. Queueing would be only applied, if applied, to release of results.
Alexander Schubert: +1 Rubens: We should NOT honor drop-catchers!
Trang Nguyen: Perhaps one question that the group could consider is what was the intent behing the GNSO policy recommendation of first come first served, and given objections/string contention, whether the intent could be achieved.
Jeff Neuman: @Steve - that was the theory, but not sure how much that was honored given all of the interruptions in the application processing
Trang Nguyen: There is a negative aspect to using priority numbers... the ability to normalize priori to releasing IE results.
Alexander Schubert: Lottery and some system whereby e.g. GEO applications (with no contention) get prioirity as they serve communities?
Michael Flemming: I'd prefer the lottery
Laura Watkins (Nominet): Agree Alexander. It makes sense that applications less likely to have contention gets priority
Justine Chew: If FCFS caused issues, then keeping the lottery system makes sense
3. Application Submission Period [reading from slide 7]
Assuming that the next round is for a fixed period of time, is three months sufficient?
-- Suggestion: 3 months is long enough for the first of the application windows as long as there is a long enough communication period prior to the start. Each subsequent window could be shorter, such as 30 or 60 days.
-- In writing the Issue Report for this topic we didn't see that there was guidance for the exact length of time for the application period, but guidance of when to start after the request for proposal. This was not a policy issue identified in the Issue Report, but the WT could draft some language if it wishes.
-- In considering the example of applicant support in order to apply, would 3 months be relevant in considering those parties? Or do we want to address that in the applicant support area?
-- Think it would be in the applicant support area.
-- For approval: Initial period is 3 months, subsequent period is 2 months -- 7 approvals.
-- Approved assuming we are talking about rounds and a delay before the next round, and in no other areas, such as applicant support.
From the chat:
Jeff Neuman: So again my proposal would be a three month submission period for the first application window, but to have a shorter 60 day application window for subsequent application windows
Rubens Kuhl: Preparing can be done before application window. If the community needs time, postpone the begining of the application period
Rubens Kuhl: Until we know how Applicant Support would play out, it's premature to determine something to support it.
Steve Chan: Policy recommendations could potentially be less specific than an actual number of months.
Laura Watkins (Nominet): If applications are to be batched anyway should the submission period(s) relate to number of applications received rather tha running for a set time?
Justine Chew: I abstain. Not comfortable with questions surrounding the AGB.
Jeff Neuman: @Alan - Agree we need to sync with other recommendations
4. Application Fees [reading from slide 8]
-- Methodology was cost recovery.
-- Are we requiring more substance to understand the methodology? "It may be useful to evaluate how well costing estimates compared to actual costs incurred by ICANN...consider providing implementation guidance to be taken into account when ICAN works with the community to develop the costing methodology for subsequent procedures."
-- Need to determine how we address overages.
-- Should we implement cost floors/ceilings? Seems like we might be more concerned about a floor. What are the implications if we choose a methodology other than cost recovery? Look at comments on the list.
From the chat:
Alexander Schubert: The fees should NOT be lowered in the next round. We are inviting speculators otherwise. A good .com is much more expensive than the gTLD application fee.
Rubens Kuhl: If we are arbitrating fees, than it's not cost-recovery.
Phil Buckingham: + 1 Alan . should Applicant support applications to go through a separate process channel
Alexander Schubert: Actually 500k USD would be more appropriate.
Michael Flemming: I disagree. I think costs need to be lowered to a more realistic cost. More substance would help to determine a realistic fee.
Jeff Neuman: existing plicy is cost recovery at this point.
Phil Buckingham: Should be free . Fund it from auction funds and Round 1 "profit excess ",.
Michael Flemming: I think you need to set a cost analysis per TLD category.
Rubens Kuhl: Arbitrating fees to market value could put ICANN non-profit status in jeopardy.
Trang Nguyen: One thing to note is that we have much more information based on this round than we did when we estimated the cost of the program (from a cost recovery perspective). The learnings from this round can be used to better estimate the actual cost for next round.
Alexander Schubert: ICANN could do it at a cost of $US 15k probably - we would have 25,000 applications then......
Michael Flemming: Some TLD types require much less check and the process can. e much more streamlined to be cost effective.
Justine Chew: Having a surplus is a good problem to have. For starters can use some of this to fund application support, no?
Phil Buckingham: Dont need a legal contingency fund (1/3 ) anymore for a Round 2 ??
Rubens Kuhl: Phil, .africa and .merck are showing that legal contingencies could be needed... and we don't yet if .amazon will turn into another legal battle.
Jeff Neuman: I agree with Trang. I also believe that having such a large contingency fund (legal fund) for future rounds would be unnecessary.
Rubens Kuhl: Size of the fund can be argued, though.
Variable fees: Seemed to be consensus that there should be one fee. Is that still the case or do we want to revisit this? May need to revisit.
From the chat:
Laura Watkins (Nominet): Agree fixed fee - except in the situation of applicant support - those fees could effectively be discounted in some way maybe
Cheryl Langdon-Orr (CLO): indeed Alan good points
Trang Nguyen: There was no difference in application processing costs for applications this round.