ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [soac-newgtldapsup-wg] charter language

  • To: <soac-newgtldapsup-wg@xxxxxxxxx>, "Alan Greenberg" <alan.greenberg@xxxxxxxxx>
  • Subject: Re: [soac-newgtldapsup-wg] charter language
  • From: "Anthony Harris" <harris@xxxxxxxxxxxxx>
  • Date: Wed, 12 May 2010 11:49:22 -0300


Alan has made some interesting points.

My comments in blue below.

  ----- Original Message ----- 
  From: Alan Greenberg 
  To: soac-newgtldapsup-wg@xxxxxxxxx 
  Sent: Wednesday, May 12, 2010 1:23 AM
  Subject: Re: [soac-newgtldapsup-wg] charter language

  At 11/05/2010 10:19 PM, Andrew Mack wrote:


    I think we're making two assumptions here if I'm understanding correctly:

    1) That the $185k is a good number -- i.e. what it needs to be for cost 
recovery.  We've already asked whether cost recovery should include past costs 
but that issue doesn't seem to have been addressed.  I think there is a 
legitimate argument that these costs are sunk costs, which -- if we were to 
write them off -- should lead to lower application fees across the board.  
Please tell me if I'm getting that wrong, but that's the way it seems to me.

  The rationale was that the gTLD process development costs reduced ICANN's 
ability to build its reserve, and that when received for new applications, 
would go into the reserve. There was a strong negative reaction to this at the 
time it was first introduced, and no change was made. I am not optimistic that 
at this point, where the projected FY11 budget is rather constrained and the 
contribution to the reserve has been reduced, that this is a productive path to 
  Obviously any proposal we come up with may well be rejected, nonetheless as 
far as budgets go I have difficulty in feeling concerned about them, when on 
page 3 of the ICANN explanation document we are told that if 500 applications 
are presented, this will mean a total intake of U$S 92.5 million !!!  

  One possibility is that we do not argue against recovering these sunk costs 
in general, but that we do recommend that they be waived for whatever group of 
applicants meets the criteria developed under Objective 1. That will be a 
moderately small percentage of the overall applicant group and may be palatable.
  A very good suggestion. But what about the U$S 60.000 "just in case" risk 
contribution that is part of the application fee?

  There is one more consideration. You may have noticed that this entire new 
gTLD process has gone on for far longer than originally expected. The costs to 
be recovered have no doubt FAR exceed the amounts that were used in the $185k 
calculation. I do have some fear that if we try to get the overall pricing 
re-considered, it could push the application fee even higher.
  Very true, do we then lower our voice and hope this does'nt happen?

    2) We're making the assumption that everyone should pay the same fees -- 
which is what is implied in the idea of a "subsidy" versus a two-tier pricing 
structure.  I recognize the gaming risk in a two tier system but am a bit 
concerned that if we argue for subsidies we may be effectively saying to groups 
that need help (that we agree deserve it)  "once we raise some money we'll get 
back to you".  This seems a bit outside of the spirit of the Nairobi meeting. 

  The issue of some sort of subsidy or preferential pricing has been on the 
table for years now. The staff answer has always been that we need to wait for 
the second round. That put off the need to consider the gaming issues, and to 
consider differential pricing. It also allowed some of us to dream that the 
windfall revenue from auctions might be available then. For reasons that have 
never been clear to me, the staff proposals always presumes a single fee for 
all. The description of how the fee was determined ( 
http://www.icann.org/en/topics/new-gtlds/cost-considerations-23oct08-en.pdf ) 
makes it clear that to the extent that one could forecast the number of 
applications in the various categories (that is, a "category" corresponding to 
a different path through the decision tree on page 9 of the document), the 
total costs were summed and divided by the number of projected applications. 

  So, if you accept the arithmetic (which is veiled in calculations and 
simulations we are not privy to, and so have no basis on which to argue) and 
the principle of one-fee-fits all, we don't have a lot of room to play here.
  Perhaps if we consider the various parts of the application fee, as they are 
explained in the document, we might conceivably come to the conclusion that 
they may be overstacked in some cases. 

  Arguing the one-fee-fits all principle has not been successful in the past. 
Perhaps with the Board resolution, it can be raised again. But I think that it 
does imply that if some fees go down, others will go up.
  This is true, and must be avoided by all means.

  One way to approach a solution might be to not request a reduction in the 
"application" fee, but, for our Objective 1 group, have part of the fee 
deferred coupled with a reduced ongoing fee once the TLD is operational. This 
would have the net effect of a reduced fee but without actually lowered it on 
  A good alternative.

    Should we assume that everyone pays the same fees?  I'm not sure.  As 
Baudouin and others noted, non-English speakers (who need translation) and 
Emerging Markets applicants and NGOs (who may have less access to/budget for 
legal fees) are already at a disadvantage, as these challenges function to some 
extent as a tax on them.

  I think that if we want have ICANN revisit the issue of differential fees, it 
must be done on a basis of fairness - that is, why should those who take a 
simple path through the decision tree subsidize those who take other paths. But 
I fear that this was not the intent of the Board resolution, and it may not be 
the best use of our time. More creative approaches such as the ones above may 
be more effective.


    Just want us to be mindful of our assumptions.

    Cheers, Andrew
    Andrew A. Mack 
    AMGlobal Consulting

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy