Thecall for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 28 March 2017 at 15:00 UTC.
08:00 PDT, 11:00 EDT, 16:00 London, 17:00 CEST
For other times:
Agenda:
- Welcome & Agenda Overview
- SOIs
- Recap & Discussion from ICANN 58
- Costing
- Clarity of Application Process
- RSP Program
Dial out: none
Apologies: Ashley Roberts, Cheryl Langdon-Orr, Seun Ojedeji
On audio only: none
Action Items/Discussion Notes:
1. Recap & Discussion from ICANN58
a. Holistic Costing Approach to Multiple Rounds (Slide 3)
-- Good feedback from ICANN58 (as follows).
-- Would cost recovery in the next round be in isolation. Question: is anyone looking at this holistically or only in isolation.
-- Consider a first-come, first-served process.
-- We have already brought up concerns about surplus and application fees.
-- We don't know the number of rounds. Need more information to make it work.
-- Recollection from the start of the process: original intent was that the original round would be cost recovery. After the price was set the development took longer than planned and development costs went up radically. Address by spreading development costs over future rounds, presumed not enough money from $185,000.
-- Correct that was the original intent: 1) recover historical costs and the development; 2) evaluations; 3) litigation/contingency fund. Because of the surplus and because we've baked in historical costs and no ramp up to begin a new round -- doesn't seem that historical costs need to be built into the round going forward. Leaves the notion that if we want to do a cost-recovery type model need to build in what the costs should and should not be, assuming not a huge ramp up.
-- Should be some resusable elements of the system, but need to hear from ICANN staff re: development costs.
-- Have the flexibility to decide if new rounds should be isolated or not.
-- Development costs were approximately $27,000 per application (part of hte $185,000). So, the question is: should costs be in isolation or not?
-- Concern that cost recovery was a pricing ceiling rather than floor. Talking about setting a floor price, which would be a change in policy.
-- Unclear economically if we are talking about cross-collateralizing rounds -- assume that there was a net profit from the first round. One could say that if cost recovery is the concept, consider the fact that ICANN dug into its reserves to fund the transition. ICANN has to look at getting its reserves back up. Talking about this in the abstract is a little rough; but mere cost recovery and ignoring other potential costs is narrow minded and needs to be looked at in a much bigger picture.
-- Take a few minutes now: existing policy is cost recovery -- do we think there should be a change to that policy, such as a floor. Put down all the reasons to have a floor/to change the policy.
-- Why is "Cost" to "society" -- IP community an issue?
-- Need to consider why to keep current policy.
-- If we do set a price above what it would cost what do we do with the surplus?
-- Not sure that dropping the price would result in a large increase. Not sure that an increase in price would lower the number of applications. Price elasticity isn't clear.
-- What about having different fees for different types of applications?
Action Item: Helpful for WT1 members to share thoughts re questions below with Sara and Christa.
1. Why to have a floor/what happens if price is too low?
-- Funding for reserve funds
-- Piece of Internet real estate
-- If price is too low too easy -- cost for IP community of so many TLDs, many which may fail
2. What if price is too high?
-- Anti-competitive
3. Why keep the current policy?
From the chat:
Alexander Schubert: Why "cost recovery" in the first place? What if the cost goes down to 5k USD? We face hundreds of thousands of gTLDs? There must be a SUBSTENTIAL hurdle to overcome for applying for a gTLD. The easiest hurdle is a monitary one. If there is no entry barrier we will be FLOODED with applications by "hobby-gTLD-makers".
Trang Nguyen: One big development cost for the next round is the system development cost.
Steve Chan: I would imagine the development cost would be dependent upon the recommendations from this group.
Trang Nguyen: TAS has been retired so we would need to do new system development. Now much work depends on how many changes from the 2012 round there will be.
Jeff Neuman: @Steve - of course to some extent.
Donna Austin, Neustar: @Alexander, we did have some discussion about the challenges associates with setting a low application fee.
Jeff Neuman: But to be honest some of that "development cost" was not wisely spent....especially in trying to develop a home grown customized one time solution.
Steve Chan: @Alexander, there is a question related to a pricing floor in CC2.
Alexander Schubert: TNX
Jeff Neuman: I would really like for us to set forth all of the reasons for which we believe that a floor should be set (as that would be a change in policy).
Alexander Schubert: There is also a "cost" to "society", brands, the Intellectual Property community! If 100,000 gTLDs are being applied for because they "cost" only 10k USD - then the "cost" to the wider community is BIG!
Donna Austin, Neustar: @Greg, agree about getting the reserves back up, but ICANN shouldn't be using excess fees from a future round to do that. I know that's not what you were suggesting, but I just wanted to put that on the record.
Greg Shatan: Donna, I wouldn't consider those to be "excess fees." It's simply revenue. And I don't see why revenue should not be used to bolster reserves. On this point, since the first round fees were so significant, a floor was irrelevant. How far short is ICANN's reserves from best practices amounts of 110-120% of annual revenue? How does that compare to the $90 million of "excess" fees?
Michael Flemming: I agree with keeping the cost higher. Cost recovery is the right idea as long as that costs come back. My firm and I feel that for our customers, the value of a gTLD can be seen in its price. Brands in the first round paid a high price for a resource and that becomes minimized if the price of that resource goes down too much for future application windows.
Jeff Neuman: @Alexander - To sum up your concerns: (i) IF too low, we may have unsophisticated Buyers of TLDs - threat to security/stability; (ii) If too low, we may hae squatting activities, abuse
Donna Austin, Neustar: @Greg, they wouldn't be excess fees if the cost-recovery model was not applied, but my point was more that I don't believe it is appropriate to raise funds to bolster the reserve fund by opening up another round of TLDs.
Alexander Schubert: I suggest to ask whether we RAISE the amount to US $500,000.
Michael Flemming: Could we just see a list of hands to see who is for the cost-recovery model and who is against?
Jeff Neuman: @Michael - I think it is too soon for such a poll
Michael Flemming: Just an idea
Jeff Neuman: I think we should focus on the pros and cons of each method.
Michael Flemming: To grab the storm, because I am curious about who we are trying to convince to change it?
Greg Shatan: ICANN does plenty of things that cost money -- that's where the "excess"" of revenues from any income-producing activity goes, as a generic point. Non-profit does not mean non-revenue-generating...I am not suggesting ICANN turn gTLD applications into a "cash cow" but there's a big range between the lowest non-money-losing price and a massive cash cow.
Trang Nguyen: Does the concept of floor mean a floor above the cost recovery of processing applications, or some arbitrary floor? It's not clear to me.
Michael Flemming: Clarification to cost coming back: Meaning that the excess is used for an agreed upon benefit or that it is returned to applicants/registries.
Jeff Neuman: @Michael - but those brands that bought now have a huge first movers advantage (up to 7 years in theory). That is worth a higher price
Carlton Samuels: Given what we now know of the market situation, Is there a sense that a new gTLD program should be demand-driven? And, iff we agree with that in principle, it would be a dead easy step to agree in principle the administrative costs to ICANN - the corporation - should be on a cost recovery basis.
Michael Flemming: Yes, but those same brands don't agree to loweing the price.
Jeff Neuman: Trang - the floor means that essentially we would look at cost recovery, but if cost recovery is not as high as the arbitrary price floor, then the price becomes the floor
Trang Nguyen: Thanks, Jeff!
Jeff Neuman: @Michael - is this really a decision that should be made by existing registries (that may be viewed as a competition concern)
Greg Shatan: Maybe we turn every new gTLD application into a potential auction, i.e., applications are public and others can offer a higher price. Not suggesting this is a good idea, but it is an alternative to the current model.
Michael Flemming: When those same registries consider applying in subpro, yes it is a high concern.
b. Clarity of Application Process (Slide 4)
-- Feedback from ICANN58: Make application process more clear/predictable.
-- Question re: If AGB went with no changes would clarifying questions change? Applicants will be smarter about it; help them understand the nature of the questions -- so clarifying questions could be reduced. Also, be smarter in designing the question form.
From the chat:
Donna Austin, Neustar: @Trang, I think if we went forward with the current AGB, ICANN could also provide some kind of 'how to' guide based on the experience from 2012.
Trang Nguyen: @Donna, yes, absolutely.
Phil Buckingham: Surely the goal for Round 2 should be to minimise clarifying questions as much as possible . A huge number were re the Q50 question to which a solution will be found for Round 2.
c. RSP Program (Slides 5 and 6)
-- At call on 11 April will discuss the proposal from Donna Austin.
-- Helpful to have a discussion on the interpretation of the rules concerning testing -- implementation and policy issue.
From the chat:
Jeff Neuman: This subject will be a primary topic for the next WT 1 call in 2 weeks.
Donna Austin, Neustar: Christa, I think its an implementation issue.
