[Gnso-newgtld-wg-wt1] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 1 - 25 April 2017

Tue Apr 25 11:58:42 UTC 2017

Dear all,

Please see below the action items and discussion notes captured by staff from the meeting on 25 April.  These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the recording.  Call recording and chat transcript are available on the wiki: https://community.icann.org/display/NGSPP/2017-04-25+New+gTLD+Subsequent+Procedures+PDP+Work+Track+1

Kind regards,
Emily

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Agenda

  1.  Welcome & Agenda Overview
  2.  SOIs
  3.  RSP Program
  4.  Costing
  5.  AOB

2. SOIs
- No update

3. RSP Program
- To discuss today: draft requirements or principles that might apply to an RSP program if one was created
- Problem statements (From the Google Doc)
1.  The New gTLD technical evaluation and pre-delegation testing processes were repetitive, resource intensive, unnecessarily expensive and inefficient.
2.  The costs of the technical evaluations were borne by new gTLD applicants (front-end registry operators) as opposed to the actual technical registry service providers.
3.  Applicants were required to select (and in some cases pay for) back-end registry service providers prior to knowing whether those providers would pass the ICANN technical evaluation.
4.  Multiple evaluations of the same registry service provider by different evaluators led to inconsistent evaluation results despite presenting the exact same technical registry solution

- Draft Requirements/Principles:

From the Google Doc: Security and stability of gTLDs must not be negatively impacted, and preferably, improved
o    Applicants’ (or applicant’s provider) must be able to demonstrate technical capability equal to or greater than the 2012 round of the New gTLD Program
o    The evaluation of a Registry Services Provider should account for the number of TLDs it supports with respect to the five critical services it provides (DNS, SRS, Whois, DNSSEC and Data Escrow)
o    Service Levels for Registry Service Providers must be equal to or greater than the 2012 round of the New gTLD Program
- In relation to Security and Stability, what is the different to the two bullets above?
- Some of the technical requirements may not translate into specific service levels. One of the requirements in the technical questions was backup plan or registry failure capabilities that are not necessarily measured by service levels. There are differences between making sure someone meets service levels and actual technical capabilities.
- Context for the document: last week we were looking at proposals. It might be helpful to agree on some principles for a program, which might help to evaluate potential solutions.

From the Google Doc: Efficiency in evaluation and pre-delegation for ICANN, applicants, and RSPs must be improved

     *   Coordination between ICANN and RSPs should be improved
     *   Burden on RSPs and applicants must be reduced
     *   Overall costs for ICANN evaluations and pre-delegation testing should be reduced
- We need to be specific in these problem statements and principles. Some of these requirements listed in the Google Doc may actually be problem statements. It will take some time to digest this document and provide feedback.
- This is an early to draft to be used as a springboard for conversation. There will time to provide feedback and revise.

From the Google Doc:
- Evaluation and pre-delegation testing must be consistent, predictable, and to the extent possible, objective
- The costs associated with the evaluation and testing of an RSP should be borne by the RSP as opposed to the Applicant where the Applicant and RSP are not the same entity.
- RSPs must be able to innovate and differentiate themselves
- Applicants must not be prohibited from serving as its own Registry Services Provider.
- An RSP Program should be designed in such a manner as to not adversely impact ICANN’s liability
- Applicants must have access to a list of Registry Service Providers that have been pre-approved through the RSP Program.
- Pre-approval of RSPs could be done in such a way as to take into account the capacity of such RSPs, the type of TLDs they support and the services they provide.
- Applicants must not be required to select a “pre-approved” RSP, but shall be able to either propose providing its own registry services or selecting a new RSP.  if that occurs, such new RSP must be evaluated prior to the ultimate selection of the Applicant to manage one or more specific TLDs.

From the chat:
Jeff Neuman: That last bullet is a long way of saying it is a voluntary program :)
Jim Prendergast: the costs point is something that going to need more discussion. I don't think this group should dictate that.  if two parties want to negotiate it or an RSP wants to offer that, that's a differentiator in the marketplace. buts it's not the role of this group to dictate that.

- We heard that applicants were not in a position to negotiate with RSPs due to a lack of knowledge. Applicants were not certain that the RSPs they selected would pass the initial evaluation or would have to go into extended evaluation. The Brand Registry Group said that they would prefer if providers were pre-approved so they would not have to bear the cost of another evaluation. Maybe we should label this item “for discussion.”
- On the cost issue, we may be talking about two separate issues. If we assume pre-approval, costs associated with testing should probably be taken on by the RSP. But any relationship that the RSP enters into with an applicant and a registry operator is separate issue that ICANN does not enter into. There may conflation between the costs associated with these two sets of costs.

From the chat:
Jim Prendergast: that probably warrants to clarification to it
Jeff Neuman: I think that is right Donna.  It's not to govern the relationship between the RSP and RO, but rather who pays for the cost of technical evaluation if there is a preapproval process

- We need to be specific in these potential requirements which parties we’re talking about in each bullet.

From the chat:
Jeff Neuman: Agree-  All, please make suggestions in the google Doc.  Let's get the wording to a point where it is clear and we can all agree

- There were some additional points in for discussion (from the Google Doc):

- FOR DISCUSSION:  RSPs [should or should not] be subject to additional contractual terms and conditions with ICANN.
- FOR DISCUSSION:  RSPs that provide back-end registry services for then-currently delegated TLDs should be deemed to be pre-approved for subsequent procedures for similarly situated new TLDs.

- For the second item above – it is a difficult sentence to understand. Donna’s proposal broke this down into categories. If the last bullet is about grandfathering, can we state that? If so, let’s put that in the document.
From the chat:
Jim Prendergast: I'll elaborate more in google docs on the last point but the fact that icann has had instances of a few operators failing SLAs and having to coach them into compliance makes it difficult to automatically grandfather them. In
Justine Chew: Agree with Donna. Also subject to any changes in technical requirements for operating as RSP.
- The reason the phrasing may seem a little odd is that we were trying to get at the requirement and not speak to a specific solution.
- It wasn’t just an issue of grandfathering. You may have some existing RSPs that have the capacity to handle what they currently have, but may not be able to handle additional TLDs or additional types of TLDs. If there is a better way to phrase, please suggest wording.
From the chat:
Justine Chew: So we need to address scalability, Jeff?
- If one of the principles is that evaluation and PDT must be consistent, predicable, and objective you are going to run into this problem for those who go through any future testing. It’s very difficult to assess the ability of the RSP to scale based on assessment of technical capabilities. The scalability question has to be answered after the fact. Perhaps another test needs to be done to address this point. To the extent we can identify what processes are required to approve and RSP vs. the scalability question, that would be helpful.
- As we’re evolving, we are starting to get different types of TLDs. While conceiving of a process that an RSP goes through, that can actually be done with scalability in mind. We haven’t thought through the process that needs to happen. The problem with grandfathering is that those providers would not be subject the same processes as other providers in the new round/procedures. For gTLD applicants, they don’t have an equal view of all RSPs they are considering in terms of predictability. Perhaps the issue of grandfathering should be considered on its own.
Donna Austin, Neustar: @ Avri, as I see it and how i read this document, we are really only discussing a pre-approval process and if that doesn't change substantively from what was undertaken in 2012 i don't see why 2012 RSPs could not be grandfathered in.
Jeff Neuman: Perhaps the grandfathering applies to what is the same with perhaps some lesser amount of evaluation on only those new requirements (if any)
avri doria: wee are trng to eliminate multipel testings, i do not see the requiremnt to eliminate all testing for some.
4. Costing
- (Reading from the slide) – review of previous discussion on costing
- holistic costing models: basis for determining model – rounds, applications, others
- possible cost floor: floor is a minimum price, but if’s below a threshold change the costing model
- what should be done with excess costs
- still to flesh out – fees by application type
- If we have something that looks like a rolling process and a policy that the system is self-funding, and a principle that costing be revisited periodically, any excess funds would feed back into the system, the problem could take care of itself.
- Question – how would we work out the allocation to different systems.
- Jim Prendergast: did the community determine the pricing in the previous rounds or was that dictated by ICANN?
Jeff Neuman: @Jim - Dictated by ICANN
Jeff Neuman: Based on some vague formulas and SWAGs on expected volumes
Jim Prendergast: that's what I thought.
- There are a number of dependencies on the costing issue. One thing we haven’t discussed is the CDAR report. One of the recommendations is that you maintain the controlled rate of delegation, similar to the 2012 round. The 2012 round is based on an arbitrary number. If that rate of delegation stays in place for no more than a 12 month period, how does that impact costing? That puts pressure on who gets delegation first and may also drive the costs up. This is difficult because it’s based on so many other conversations we haven’t had yet.
From the chat:
Jeff Neuman: Applicant support programs need to get funding from somewhere
Jeff Neuman: (if we have them)
Cheryl Langdon-Orr (CLO): indeed they do!!!
Cheryl Langdon-Orr (CLO): and we should IMO
avri doria: Jeff the cost of those should be calcualted into the total cost.
Jeff Neuman: WE do need to revisit that report.  If as people believe there will be 25000 applications, then under the current rates, it would take 25 years to complete delegating those TLDs
Jeff Neuman: So we need to push those boudaries of that recommendation
Jim Prendergast: 25 years....wow
Jeff Neuman: That report found no issues with the current rate of delegations and said it could handle much more

Emily Barabas | Policy Specialist
ICANN | Internet Corporation for Assigned Names and Numbers
Email: emily.barabas at icann.org | Phone: +31 (0)6 84507976

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