[Gnso-newgtld-wg-wt1] Actions/Discussion Notes: Work Track 1 Sub Team Meeting 11 April 2017

[Julie Hedlund]

Dear Sub Team Members,

 

Please see below the action items and discussion notes captured by staff from the meeting on 11 April.  These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the recording.  Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+1+Meetings.

 

Please note also that the slides referenced below are attached and for ease of reference chat excerpts are included below.

 

Best,

Julie

 

Julie Hedlund, Policy Director

 

Actions/Discussion Notes:

 

1. Costing

 

Consider the following questions:

 a. Since the 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.

b. What are your fears if the floor is too low?

 

Costing: Big Picture (slide 3)

 

-- Started exploring evaluation of pricing -- holistically or over multiple rounds.

-- Example: systems could be a cost that could be shared over multiple rounds.  Did not have too many pros or cons.  Expand the thinking and add pros or cons.

-- Question: Would this be limited to fixed costs of developing the implementation and operationalization?  Answer: Two parts 1) fixed costs 2) variable portion associated with each operation, but that depends on the second part of the discussion on cost recovery or cost plus.

-- From a fixed cost point of view a spread over multiple rounds -- resolve 2 questions before tackling 3.

-- On question 2, we are seeing a conversation in other areas that there is some interest in having different fees for different types of applications.

-- In terms of 1 and 3 -- if something is being done on cost recovery and there are different open applications even if we were cost recovery we could be forced into a changing fee per cycle.

-- We've been talking that the actual recovery cost may be very low so do we want the fee to be as low as the cost recovery might be?  Also, we are likely to have to develop some new systems -- do we want to spread that across multiple rounds or write off in the first round?

-- It sounds like we need a huge system overhaul as a one-time cost.

-- It might be beneficial to do some outreach to Xavier and Christine Willet.  From an internal ICANN staff perspective -- I don't know how many of you are looking at the FY18 budget proposal it is bringing evaluation staff into GDD staff.  Is ICANN going to need to bring on more evaluation people?

-- On cost plus, we need to think about if there are monies that come out of these we need to consider what should be done with that.

 

>From the chat:

Vanda Scartezini: last year we did a survey in LAC region and price was not the problem justifying interested organization did not enter into the process. lack of information was the main issue

Ashley Roberts: May I suggest an alternate model: instead of spreading the application cost across different rounds, how about spreading it across the annual registry operator fees? So you could have a lower application fee, offset against slightly higher annual fees. It gets over the difficulty of predicting timing of further rounds.

Donna Austin, Neustar: The cost recovery is really difficult because there are too many unknown variables. If we knew the costs associated with developing systems and evaluating applications and how many applicants, it would be an easier proposition. 

Cheryl Langdon-Orr (CLO): yes @Avri the differential fees discussion is not yet finish at all... as seen in other WG's.

Cheryl Langdon-Orr (CLO): that's my assumption @Alan

Vanda Scartezini:  share cost as Ashley suggested looks interesting in my view

avri doria: in a cyclical application period, there will be steady state costs and it may be challenging to budget just per single application cycle.  I also assume the there would be efficinecies in terms of process that would drive costs down over time.

Alexander Schubert: Lets put it this way: There needs to be a substential "hurdle" to apply for a new gTLD. Otherwise we will have hobby gTLD makers entering the arena - without any intend and ability to actually really operate their TLD. A financial hurdle is the easiest to create!

Cheryl Langdon-Orr (CLO): good question re staffing / re staffing 

Jim Prendergast: Im also in agreement wth CLO that cost+ is not the way to go.  

Jim Prendergast: And agree with Alexander - there need to be some financial barrier here to demonstrate financial wherewithal.  

avri doria: are we suggesting high costs to keep people out?

Jim Prendergast: Good point donna.

Cheryl Langdon-Orr (CLO): yes indeed we should @Donna.

 

Reasons for a Cost Floor/Ceiling (slide 4)

 

-- This ties into the discussion point re: if we had different application costs for different types of applications then there could be a high-risk pool or some other type of subsidy.

-- Depending on the price if it is low then people will just register to speculate.

-- What we are currently doing is we are thinking of the reality of 2012.  There was a steep learning curve.  For the next round there will be providers that are not only RSPs but also consultancies.  They could say give us a lump sum and we will write an application for you.  Then you don't have to engage in all the work.  You just pay a new type of provider and he will set it up for you.  Not sure that this will be a viable outcome for ICANN.  You are not getting people to apply for a string to operate it, but for speculation.

-- Okay with having a price floor but no ceiling.

 

>From the chat:

Alexander Schubert: If the costs are low we need another hurdle: Say some proof that the applicant WILL manage their TLD and know what they walk into.

avri doria: I can just imagine the press that would great a price meant to keep people out of the market.

Alexander Schubert: I agree Avri.

Jim Prendergast: the $185 was just the beginning of the costs associated with TLD ownership. 

Cheryl Langdon-Orr (CLO): agreed 

Donna Austin, Neustar: @Jim, but some paid much more than $185k for the TLD, so how do we factor that into the value of a TLD.

Kurt Pritz: This is a pretty darned complex economics question. What is the effect of application cost on demand? What is the effect of application cost on developing area applications? What is the effect on gaming, I.e., how many applicants will enter the field to profit on private auctions? How will low cost increase the likelihood of applications that don’t have the financial wherewithal to sustain a viable registry? How will increased demand increase the number of contention sets? Different types of applications multiplies the complexity. I don’t see how anyone here can answer this question. One approach (that we very well likely to hate) is to get a competent economics analysis of these issues. I don’t think taking the time would interfere with a 2019 launch date. It would have to be carefully crafted and sophisticated.

Jim Prendergast: @Donna – that’s the market determining value, not ICANN.

Donna Austin, Neustar: @Alexander, i think the financial questions and the COI were intended to understand the applicants’ ability to manage the TLD into the longer term. 

Cheryl Langdon-Orr (CLO): I am ok with that 

Steve Coates: Hard to discuss a ceiling without discussing a floor.

Cheryl Langdon-Orr (CLO): yup

Jim Prendergast: ICANN cant go into debt on this so no celing

avri doria: personally (not as WG co-chair) I am uncomfortable with some of the assumption behind a floor.

Steve Coates: Apologies - I agree with Avri's point on the floor.  I think there need to be fundamentals behind a floor that do not take into account competitive hurdles (e.g. cost recovery, ensuring financial viability).

 

2. RSP Program 

 

See Donna Austin's proposal attached -- slide 2.  See also: ttps://community.icann.org/display/NGSPP/4.2.8+Accreditation+Programs.

 

Problems we're trying to solve (reading from slide 3)

 

Possible Solutions (reading from slide 4):

 

-- RSP accreditation

-- Other possible solutions: 1) ICANN Proven Providers 2) ICANN Pre-Certified Providers 3) ICANN Post-Application Certified Providers

 

ICANN Proven Providers (reading from slide 5)

 

ICANN Pre-Certified Providers (reading from slide 6) 

 

ICANN Post Application-Certified Providers (slide 7):

 

-- One of the realities from the 2012 rounds is that there were 10-12 RSPs that supported the applications for the 1900 applications.  The application had to go through PDT and it didn't matter the type of TLD.  If there is an assumption that the PDT should be customized to TLDs then we would have to do something differently.

 

How these solutions address the problems we are trying to solve? (slide 9):

 

-- Never really had the conversation on what the details of any program would look like.  For a Proven Provider the assumption is that they have been operating without any breech notices for 4-5 years so they are in pretty good shape.  What would a test look like on ability to scale?  Talked in the Registry SG that there could be an annual test that an RSP would undergo on how it is managing the loads it currently has.  Something akin to an annual retest.

-- We have avoided using the term "accreditation".  There is none as such.  Even an annual retest is just another test, not an ICANN seal of approval.

 

>From the chat:

Vanda Scartezini: back end list of certified companies was one of demands in our survey in LAC region.

Steve Chan: I would note that Ashley Roberts circulated a summary of Donna's proposed options. Provided Donna agrees with that summation, that might serve as a good high level reminder of what the three options/proposals are.

Donna Austin, Neustar: @Steve, no objection.

Laura Watkins: I'm not sure I follow the logic of removing PDT.  The RSP offering could differ depending on the type of TLD and TLD can be actually seen to reduce costs as it removes the obligation for the RSP to do their own testing and incur costs for that.  If one of the reasons that we're citing for having a fee level is to prevent failure - how can we justify delegation without testing? The Pre-certified providers concerns me that it creates tiers of RSPs and could stiffle compettion and ionnovation in the market.

Donna Austin, Neustar: @Laura, regardless of the type of TLD, the PDT was always the same.

Laura Watkins: I appreciate it was the same - I know our tech team actually found it quite useful!

Samantha Demetriou: My understanding is that PDT also didn't account for scalability, which could be an important factor if a single provider is running the back-end for large numbers of TLDs

Donna Austin, Neustar: @Laura, ours didn't after they'd been through it many, many times.

Donna Austin, Neustar: that's correct Sam.

Kurt Pritz: One problem that we are trying to solve is to ensure that proven providers continue to be successful. An RSP program might also include forward looking criteria in addition to past looking. Forward looking requirements for RSPs might include statistical process controls to determine whether an RSP is degrading in performance before they fall outside the performance limits. Another requirement might be that there be a threat identification process so that new security threats are identified as they arise and RSPs would be obligated to act in some ways. 

Jim Prendergast: What happens and brand X selects an ICANN accredited RSP and there is a technical failure that results in a breach.  Who does Brand X pursue?  the RSP, ICANN?  IS ICANN ready and wll to shoulder the burden/liabilty that comes with accrediting RSPs?

Jim Prendergast: We already have a situtation where RSPs are failing an ICANN is coaching them back into compliance

Samantha Demetriou: Thanks for confirming, Donna. So in that case, if applicants go with a "proven provider," then instead of just answering questions and going through a redundant PDT process, testing could focus on whether the RSP can scale appropriately - which in theory would be ensuring ongoing stability rather than just checking the box.  Basically, all of this is to say that I think having an RSP program presents an opportunity to improve the testing process.

Kurt Pritz: @ Jim: isn't that a reason that there be a direct relationship between ICANN and the RSP rather than creating stability through a thrid party?

Jim Prendergast: Sam - I think there are ways to solve testing program issues without going down the accrediation path

Ashley Roberts: JIm, Brand X would take it up with their RSP, as current 2012 registries would. They would have a contracual relationship with SLAs with the RSP.

Laura Watkins: Is a new process needed for this?  Could it be covered by the current material sub-contracting agreement fpr example?

Samantha Demetriou: @Jim, sure, I can see that. Just putting a thought out there about a potential added benefit if such a program was put in place.

Jim Prendergast: Ashley - But if ICANN accredits someone - there comes comes that ICANN seal of approval.  And if ICANN approved them, and that was the basis of my decision to go with RSP1 over RSP 2 - Im not going to be happy.

Laura Watkins: +1 Jim

Ashley Roberts: Jim, I don't think this proposal is talking about "accreditation" as such. I view is essentially doing exactly what was done in the 2012 round - ICANN is simply saying that an RSP meets the technial requirements set out in the AGB. The only difference between this proposal and the 2012 evaluations is that in this case ICANN only perform the evaluation and PDT once per RSP, rather than repeating the process over and over.

Kurt Pritz: I remember in the first round discussion that Chuck from Verisign came to the microphone and said that the technical criteria for a new TLD should be stringent. The Guidebook questions were written with that in mind. Now the marketplace has markedly changed where there are a few RSPs that are separated from direct obligation to the ICANN community. Wouldn’t a direct relationship between ICANN and RSPs (who control critical Internet infrastructure) comply with ICANN’s missions?

Jim Prendergast: So that’s a helpful clarification Donna - this is not an accreditation program - just problem solving the testing issues. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170411/30fb16ba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sub Pro Track 1 20170411 v2.pdf
Type: application/pdf
Size: 223674 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170411/30fb16ba/SubProTrack120170411v2-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSR Provision Of Back-end Registry Services.pdf
Type: application/pdf
Size: 129950 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170411/30fb16ba/NSRProvisionOfBack-endRegistryServices-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170411/30fb16ba/smime-0001.p7s>