[Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

Alexander Schubert alexander at schubert.berlin
Wed Aug 9 20:57:35 UTC 2017 

Kurt,

 

You bring up a very valid point, and I try to rephrase it:

 

The ICANN fee structure set aside; in the 2012 round we had a NUMBER of clear entry hurdles for single string applicants; for example (but not limited to):

*        A relatively high base fee for the application (US $185k)

*        The COI (around US $20k often more)

*        Some paid the Data Escrow Service upfront – but it has to be paid at some point anyways (around US $25k annually)

*        Relatively high consulting fees for single string applicants (or years of ICANN participation)

*        Fees associated with the application writing

*        RSP upfront costs (e.g. setup fees)

*        Relatively high RSP fees (transaction related and annual) in most cases!

*        Outside of ICANN virtually NOBODY knew about the program (whatever publicity work ICANN did: it remained without ANY impact). So only the ICANN circles and those who were actively approached by consultancies considered to apply

*        And last not least quite some uncertainty whether the entire thing works out and will find any general acceptance

 

This all will change DRAMATICALLY in the 2020 round! 

*        All non-ICANN fees will shrink ENORMOUSLY! 

*        RSP related costs for example will be a tiny fraction from what single string applicants experienced in 2012. 

*        Brand managers around the globe are aware by now. 

*        Players specialized in geo names will BLANKET thousands of cities with requests for letters of non-objection (cheaper than buying a money printing machine, but as profitable).

*        “Success stories” of portfolio applicants lure in rich domain professionals as well as “investors”

*        “Turn Key” solutions at an annual fix price on 10 year basis (including all fees) will be offered; your grandma could apply for a string online in 3 easy steps!

 

We always act as if the 2020 round will unfold in an environment identical to that of the 2012 round; a mistake.

Long story short: Way higher demand will be met with WAY lower entry hurdles – even if the application fees would remain at the 2012 level. Kurt is right: We risk an inflationary DNS explosion when we further REDUCE hurdles. 

The most simple entry hurdle is obviously a financial one; through HIGHER application fees; which could decline then from round to round (and at higher price points the rounds would be much smaller and shorter). Can we think of OTHER hurdles, too? Or exceptions? E.g.: If the letter of non-objection for a geo clearly implies that there is only ONE supported applicant – we could lower the financial hurdle as another hurdle exists (the letter of non-objection) and there is no contention? Whereas brands and generic term based applicants will simply have to wait until in a future round the fees decline, or pay up (which shouldn’t be a problem for global brands). 

Preventing an onslaught of applications means by definition creation of hurdles and implies waiting for some prospective applicants. Just like in the real world. The alternative is chaos, long rounds, and a DNS that becomes very confusing very fast. I wonder what registrars would think about another 2,000 generic term based gTLDs they should carry. At some point they simply drop out one by one as the proceeds do not warrant the effort. Where shall the consumer then buy? This REDUCES competition and consumer choice in the end. 


Alexander




 

From: gnso-newgtld-wg-wt1-bounces at icann.org [mailto:gnso-newgtld-wg-wt1-bounces at icann.org] On Behalf Of Kurt Pritz
Sent: Mittwoch, 9. August 2017 18:45
To: Jim Prendergast <jim at GALWAYSG.COM>; gnso-newgtld-wg-wt1 at icann.org
Subject: Re: [Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

 

Jim, Jim, Jim: 

 

Only you could trash a number for being unsupported and in the very next sentence used the 27 terminations as a prognosticator of the future demand.  Well done!

 

[This is a small joke at Jim’s expense that I can only make because I respect him.]

 

My points to this string are: 

 

1) The current SSAC constraint on root zone delegation rate is 1000/year, a number arbitrarily selected and artificially low. If 5000 applications are received, that is a five-year processing time and at least that long until the next round. Whatever number of applications are lodged, it is highly likely that the processing will be delayed by this current constraint. While some might be pleased with this low rate, we should not design a process that is susceptible to such a shortcoming. 

 

We should address this issue now because, once the applications are filed, it will be too late to change this constraint. Any attempt to increase the number of root zone delegations per year later on, no matter how reasonable and safe, will be met with claims that the applicants are willing to sacrifice SSR in the name of expediting the process. (We saw that in the previous round.) Therefore, I think the issue should be addressed now. What is a maximum, safe delegation rate?

 

2) I don’t think ICANN processing time should be debated by us. It is a purely operational issue. Our policy should be that ICANN process the applications at a rate greater than or equal to the root zone constraint - or have a demonstrable reason for not doing so. In my opinion, ICANN, through outsourcing similar to that done in the last round, could multiply the output in the last round to the extent required. 

 

3) Application fee: the threshold question is - should the fee be cost recovery or something else? 

 

We seem to be debating how to implement cost recovery but we should take a minute to consider the implications of that. If the application fee is very low and we receive 25,000 or more applications, do we accept that? (I am not claiming we will have that number, I am just saying that everyone has some limit at which we think, “too much!”)  Taking the argument to a logical conclusion: should organizations able to raise, say $20K be able to apply for a new TLD? Using Donuts and a $20,000 fee as an example, is it acceptable for an equally-well funded company to apply for 2775 TLDs in the next round?

 

Does that make us think differently about cost recovery? It is very easy to default to cost recovery as a policy because all the other models seem difficult. To make headway, we could focus on policy and not implementation. We might limit our choices to:

1.	A cost-recovery fee?
2.	Something else, in case the costs drop to a certain level: 

1.	To limit demand in some way through the application price? 
2.	To charge a fee that keeps a level-playing fields with the previous round? 
3.	To charge a higher fee as a bar to those who are under-funded (with a robust applicant support process)?
4.	Some combination of these?

 

I don’t think we have to tell ICANN the application fee, just the policy to govern it. 

 

Finally, I apologize for the truncated email I sent earlier. My laptop evidently thought I had exhausted my ability to contribute when I was only three lines in. 

 

Best regards to everyone,

 

Kurt

 

 

 

 

 

On Aug 9, 2017, at 2:38 PM, Jim Prendergast <jim at GALWAYSG.COM <mailto:jim at GALWAYSG.COM> > wrote:

 

Until we have factual evidence of there being 25,000 potential applications, could we refrain from using that number?  I have yet to see any evidence of that many presented and it’s just not realistic to keep using it.  In Johannesburg there was some anecdotal references to demand in some regions but that was predicated on application fee assumptions that are not in place and it was unclear how widespread it was.

 

One possible indicator we have of future demand is that 27 .brands have gone through the process and decided to terminate.

 

Thanks

 

 

From: gnso-newgtld-wg-wt1-bounces at icann.org <mailto:gnso-newgtld-wg-wt1-bounces at icann.org>  [mailto:gnso-newgtld-wg-wt1-bounces at icann.org] On Behalf Of Trang Nguyen
Sent: Tuesday, August 08, 2017 10:23 AM
To: Alan Greenberg <alan.greenberg at mcgill.ca <mailto:alan.greenberg at mcgill.ca> >; Austin, Donna <Donna.Austin at team.neustar <mailto:Donna.Austin at team.neustar> >; Sara Bockey <sbockey at godaddy.com <mailto:sbockey at godaddy.com> >; Vanda Scartezini <vanda at scartezini.org <mailto:vanda at scartezini.org> >; Rubens Kuhl <rubensk at nic.br <mailto:rubensk at nic.br> >
Cc: gnso-newgtld-wg-wt1 at icann.org <mailto:gnso-newgtld-wg-wt1 at icann.org> 
Subject: Re: [Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

 

All,

 

As you may recall, application evaluation was done by priority number and not by portfolio of applications, RSP, or anything else. There was only one set of evaluation criteria that each application was evaluated against. Initial Evaluation results were then released in batches of 100 priority numbers each week. The actual number of results posted vary as some applications needed additional time for CQs, or had application change requests that required re-evaluation.

 

The batching comment that I made was in regards to the next procedures. If there will indeed be 25,000 applications, certain phases will need to be extended such as Application Comment, Objection Filing period and Dispute Resolution, or if extending certain phases is not desirable, then the applications would need to be batched in some form into smaller batches for processing.

 

Trang 

 

 

From: < <mailto:gnso-newgtld-wg-wt1-bounces at icann.org> gnso-newgtld-wg-wt1-bounces at icann.org> on behalf of Alan Greenberg < <mailto:alan.greenberg at mcgill.ca> alan.greenberg at mcgill.ca>
Date: Monday, August 7, 2017 at 4:35 PM
To: "Austin, Donna" < <mailto:Donna.Austin at team.neustar> Donna.Austin at team.neustar>, Sara Bockey < <mailto:sbockey at godaddy.com> sbockey at godaddy.com>, Vanda Scartezini < <mailto:vanda at scartezini.org> vanda at scartezini.org>, Rubens Kuhl < <mailto:rubensk at nic.br> rubensk at nic.br>
Cc: " <mailto:gnso-newgtld-wg-wt1 at icann.org> gnso-newgtld-wg-wt1 at icann.org" < <mailto:gnso-newgtld-wg-wt1 at icann.org> gnso-newgtld-wg-wt1 at icann.org>
Subject: Re: [Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

 

Yes, I know they were done in batches which is why I raised the question. If Trang made a comment regarding the cost-effectiveness of doing that, I must have missed that call.

Alan

At 07/08/2017 07:16 PM, Austin, Donna wrote:

Alan
 
I believe the applications from 2012 were done in batches and I think Trang made some comments in this regard on a recent call.
 
Donna
From: Alan Greenberg [ <mailto:alan.greenberg at mcgill.ca>  mailto:alan.greenberg at mcgill.ca] 
Sent: Monday, August 07, 2017 4:07 PM
To: Sara Bockey < <mailto:sbockey at godaddy.com> sbockey at godaddy.com>; Vanda Scartezini < <mailto:vanda at scartezini.org> vanda at scartezini.org>; Austin, Donna < <mailto:Donna.Austin at team.neustar> Donna.Austin at team.neustar>; Rubens Kuhl < <mailto:rubensk at nic.br> rubensk at nic.br>
Cc:  <mailto:gnso-newgtld-wg-wt1 at icann.org> gnso-newgtld-wg-wt1 at icann.org
Subject: Re: [Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC
 
As I read through these responses, a question came to mind. Is or was there an economy of scale in processing applications. That is, it is more expensive to process say 10 applications one by one than as a batch. If there is an economy of scale, the price that is set should work for the later staeady-state situation where the applications may be coming in slowly and will need to be processed one at a time.

Alan

At 07/08/2017 04:37 PM, Sara Bockey wrote:

Thank you, Donna, Vanda and Rubens for your feedback on this.  You̢۪ve all made some excellent points ts and suggestions.  We look forward to discussing this further and additional input during our next call in a few hours.

 

Best,

 

Sara

 

sara bockey

policy manager | GoDaddy™

 <mailto:sbockey at godaddy.comm> sbockey at godaddy.com  480-366-3616

skype: sbockey

 

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

 

From: Vanda Scartezini < <mailto:vanda at scartezini.org> vanda at scartezini.org>

Date: Monday, August 7, 2017 at 1:06 PM

To: "Austin, Donna" < <mailto:Donna.Austin at team.neustar>  Donna.Austin at team.neustar>, Rubens Kuhl < <mailto:rubensk at nic.br> rubensk at nic.br>

Cc: Sara Bockey < <mailto:sbockey at godaddy.com> sbockey at godaddy.com>, " <mailto:gnso-newgtld-wg-wt1 at icann.org>  gnso-newgtld-wg-wt1 at icann.org" < <mailto:gnso-newgtld-wg-wt1 at icann.org>  gnso-newgtld-wg-wt1 at icann.org>

Subject: Re: [Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

 

Thanks for your feedback Donna. I understand having string conflict will be difficult to postpone but I was thinking only for cities ( government) which can face some pontual difficulty depends on the election calendar of each region. In general I would follow the idea to stick with same price for this next round. May be will be some surplus with such value but we can use as reserve to face any litigation, as suggested by Rubens or well as to define some alternative for reimbursement. 

 

Vanda Scartezini

Polo Consultores Associados

Av. Paulista 1159, cj 1004

01311-200- Sao Paulo, SP, Brazil

Land Line: +55 11 3266.6253

Mobile: + 55 11 98181.1464 

Sorry for any typos. 

 

 

 

 

 

From: "Austin, Donna" < <mailto:Donna.Austin at team.neustar>  Donna.Austin at team.neustar>

Date: Monday, August 7, 2017 at 15:10

To: Rubens Kuhl < <mailto:rubensk at nic.br> rubensk at nic.br>, Vanda Scartezini < <mailto:vanda at scartezini.org> vanda at scartezini.org>

Cc: Sara Bockey < <mailto:sbockey at godaddy.com> sbockey at godaddy.com>, " <mailto:gnso-newgtld-wg-wt1 at icann.org>  gnso-newgtld-wg-wt1 at icann.org" < <mailto:gnso-newgtld-wg-wt1 at icann.org>  gnso-newgtld-wg-wt1 at icann.org>

Subject: RE: [Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

 

Hi Rubens and Vanda, comments inline below.

 

From: Rubens Kuhl [ <mailto:rubensk at nic.br> mailto:rubensk at nic.br]

Sent: Sunday, August 06, 2017 3:23 PM

To: Austin, Donna < <mailto:Donna.Austin at team.neustar>  Donna.Austin at team.neustar>

Cc: Sara Bockey < <mailto:sbockey at godaddy.com> sbockey at godaddy.com>;  <mailto:gnso-newgtld-wg-wt1 at icann.org> gnso-newgtld-wg-wt1 at icann.org

Subject: Re: [Gnso-newgtld-wg-wt1] [EXTERNAL] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

 

Donna,

 

I believe the data points you mentioned do exist, in the form of the actual expenses incurred by ICANN in the 2012-round. And considering the gains of scale foreseen by aggregating technical evaluation per back-end, with or without RSP program, the actual cost for further rounds is clearly expected to be lower.

DA: I agree that there is data available from 2012 that could be helpful to our discussion and to that end, we should ask Trang if she can provide an overview of the costs associated with the 2012 round, but we would need to define the cost parameters. I agree that an RSP program could reduce the costs associated with the technical evaluation, but current discussions suggest that the technical evaluation could still occur during the application process.

 

But we could adopt something in between specifying a new application fee and the reimbursement idea, like this:

- Application fee will be no less than 50% of the 2012-round fee, and designed to be of a cost-recovery target; in the event it generates more surplus than expected, the reimbursement will be available either as credit towards registry fees for successful applicants or reimbursement for non-approved or drop-out applicants.

DA: I have no objection to the concept, but 50% seems to be a large reduction in terms of fairness and competition for 2012 applicants, but I accept your note below that 2012 applicants will have a time-to-market advantage over future entrants. Any number we come up will largely be arbitrary at this point so the challenge is to come up with a reasoned rationale. We should also look for options to address Vanda’s„¢s point about not making the upfront fee too prohibitive, or finding a mechanism that would allow applicants from underserved regions to pay post-evaluation. This would become complicated where there is contention for the string, but if there was no competition for the string then perhaps this would be a little easier.

 

It̢۪s also important to decide whether the applicationion fee would change over time. I must admit that when I was thinking about this, it was only from the perspective of the next application window and not beyond that. It would be fair to assume that a lot of the setup costs for the next application window will not be repeated for processes beyond that, particularly as it relates to infrastructure or software development. The outcome of the rounds v first-come-first-serve discussion will be important to this one.

 

One issue to calculate the reimbursement is how much does the legal reserves need to be; the 2012-round proved that litigation either thru internal accountability or legal courts will happen, but how much ? If someone from the work track, or someone from ICANN Board risk committee, could provide an actuary's point of view would be interesting.

DA: Agree that a % of the application fee should be set aside for legal reserves, on the condition that the reserves are set aside for a designated period of time.

 

We should note that 2012-round applicants got a 4 to 6 years time-to-market advantage, and that could be worth much more than the application fee difference.

 

 

 

 

Rubens

 

 

On Aug 4, 2017, at 7:13 PM, Austin, Donna via Gnso-newgtld-wg-wt1 < <mailto:gnso-newgtld-wg-wt1 at icann.org>  gnso-newgtld-wg-wt1 at icann.org> wrote:

 

Hi Sara, all

 

I̢۪ve had a look at the responses to the CC2 responsenses as they relate to Application Fees and believe that the responses are largely consistent with the discussions we have already had within the working group on this topic. 

 

My rudimentary analysis of the comments suggest the following:

 

Based on the CC2 responses it would appear that most of the respondents support the principle of an application fee that is cost neutral or break even, which is consistent with the cost-recovery model that was developed for the 2012 round. However, many of the responses acknowledge that the assumptions of the 2012 round was off the mark because the number of applications exceeded expectations and resulted in a considerable surplus of funds (approximately $100M).

 

It would appear from the responses that there is little support for maintaining the $185,000 application fee into the future, with many responses suggesting a reduction, with the exception of John Poole who recommended that each applicant require a $1m deposit. However, there was support for the principle that the application fee should maintain a bar sufficient to ensure that applications are worth dedicating resources to evaluation and processing; and fees should not be too low as to be detrimental to security and stability and competition between rounds.

 

It would also appear that there is support for the WG providing direction on the use of excess funds, in the event that future rounds result in a surplus of funds.

 

Some suggested considerations for moving this conversation forward:

·        While it appears that there is consensus around the concept of an application that achieves the principle of cost-recovery, it is impossible for this group to come up with an actual number for any future round because we have no way to predict how many applications there will be.

·        The number of applications for a future application window will depend on a range of factors, including the amount of the application fee.

·        We could ask ICANN to provide estimates for costs associated with preparing for the next application window, but I don’t believe we are far along in deciding so some of the core issues to provide them with enough guidance on which to base any estimates or predictions.

·        What we do have from the 2012 application round is an application fee of $185,000 that resulted in 1930 applications—some 11400 more than was preddicted.

 

The policy for the WG could potentially be something along the lines of:

·        The application fee should be based on the principle of cost recovery.

·        Based on the principles of fairness and competition to 2012 new gTLD applications, $185,000 will be the application fee for any future application window.

·        In the event of surplus application fees, ICANN will provide all applicants (successful/unsuccessful?) with a reimbursement of an equal share of the surplus application fees; or

·        In the event of surplus applications fees, ICANN will provide all applicants a reimbursement up to an amount of $50,000/$80,000/$100,000 (successful applicants may choose this reimbursement as a contribution to ICANN’s annual fe fee); and

·        The remainder of the surplus application fees will be used to support ICANN’s efforts in Universal Awareareness and Universal Acceptance (or some other designated activity)

 

Some exemptions/exceptions:

·        Applications from underserved regions would/could (depending on the policy) have the application fee waived so that it is not considered a barrier to entry.

·        There may be other exclusions or exemptions from the application fee that could be developed to remove other possible barriers to entry perceived by some as being too high.

 

Rationale:

·        We have a principle of cost recovery, but rather than requiring complex economic modelling (or somebody’s besbest guess) to arrive at the amount of the application fee, we achieve the principle in an order of reverse by providing a reimbursement of a portion of the application fee equal to the distribution of excess funds.

 

I don̢۪t believe we can solve this problem absebsent a considerable amount of data that at this point in time simply doesn̢۪t exist, so I offer this as a possossible way to enable us to move forward and certainly to encourage discussion.

 

Donna

 

From:  <mailto:gnso-newgtld-wg-wt1-bounces at icann.org> gnso-newgtld-wg-wt1-bounces at icann.org [ <mailto:gnso-newgtld-wg-wt1-bounces at icann.org>   <mailto:gnso-newgtld-wg-wt1-bounces at icann.org> mailto:gnso-newgtld-wg-wt1-bounces at icann.org] On Behalf Of Sara Bockey

Sent: Thursday, August 03, 2017 9:31 AM

To:  <mailto:gnso-newgtld-wg-wt1 at icann.org> gnso-newgtld-wg-wt1 at icann.org

Subject: [EXTERNAL] [Gnso-newgtld-wg-wt1] Work Track 1 Agenda for 8 August 2017 @ 3:00 UTC

 

Dear All,

 

The next call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Suppport/Outreacch Issue will take place on Tuesday, 8 August 2017 at 3:00 UTC.

  

The proposed agenda is as follows:

  

Welcome & Agenda Overview 

SOIs 

Review of CC2 responses to WT1 questions

1.     Application Fees 

2.     Systems 

·  AOB   

The CC2 responses we will be covering may be review in the google document:   <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreadsheets_d_1427pgTCkguOj2NZZzMnz-5FH-5FlPe54dtvUErSJd9uhkZw_edit-23gid-3D1442059046&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=KxXpBeMo6gbRQ-BqdZ0TqFv_TRF2rGQiCdN-DB_qN84&s=4vy3M-5mmpfeBvqqyXWRPSI-t6ZrUwBiYzDw4G8yxqQ&e=> https://docs.google.com/spreadsheets/d/1427pgTCkguOj2NZZzMnz_H_lPe54dtvUErSJd9uhkZw/edit#gid=1442059046 .

 

Chat soon!

 

Sara

 

sara bockey

policy manager | GoDaddy™

 <x-msg://53/??> sbockey at godaddy.com  480-366-3616

skype: sbockey

 

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

_______________________________________________

Gnso-newgtld-wg-wt1 mailing list

 <mailto:Gnso-newgtld-wg-wt1 at icann.org> Gnso-newgtld-wg-wt1 at icann.org

 <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt1> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt1

 

Content-Type: text/plain; charset="us-ascii"

Content-Transfer-Encoding: 7bit

Content-Disposition: inline

X-Microsoft-Exchange-Diagnostics:

         1;DM5PR03MB2714;27:TSSrAIPoG+Dsfo4pjr5FI/gtSPSDzoQoN7Yydy0lx++MPVqKu8QqT/E0LAYoKKbtMwTWf7NmXPjyYQE9Tht88+bzyAcdWuvDfOpTk5rZhUBa1QOyr+MSeSAW+8MX+cGZ

X-Microsoft-Antispam-Mailbox-Delivery:

         ex:0;auth:0;dest:I;ENG:(400001000128)(400125000095)(20160514016)(750103)(520002050)(400001001223)(400125100095)(61617095)(400001002128)(400125200095);

_______________________________________________

Gnso-newgtld-wg-wt1 mailing list

 <mailto:Gnso-newgtld-wg-wt1 at icann.org> Gnso-newgtld-wg-wt1 at icann.org

 <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt1> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt1

_______________________________________________
Gnso-newgtld-wg-wt1 mailing list
Gnso-newgtld-wg-wt1 at icann.org <mailto:Gnso-newgtld-wg-wt1 at icann.org> 
https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt1

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170809/d34207aa/attachment-0001.html>

More information about the Gnso-newgtld-wg-wt1 mailing list