April 2017 - Gnso-newgtld-wg-wt1

Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 1 - 25 April 2017
by Emily Barabas April 25, 2017

April 25, 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+Pr… 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(a)icann.org | Phone: +31 (0)6 84507976

1 0

Recording, Attendance & AC Chat from New gTLD Subsequent Procedures Sub Team Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 25 April 2017
by Terri Agnew April 25, 2017

April 25, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue held on Tuesday, 25 April 2017 at 03:00 UTC. Adobe Connect Recording: <https://participate.icann.org/p12my6zhdo8/?OWASP_CSRFTOKEN=270a392f7eacd741 b08abf3f2654f84519ad6e8cf34f5cf5e6c5e8497ddb0bc4> https://participate.icann.org/p12my6zhdo8/ The recordings of the calls are posted on the GNSO Master Calendar page: <http://gnso.icann.org/en/group-activities/calendar> http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1> http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1 Agenda wiki page: <https://community.icann.org/x/_7DRAw> https://community.icann.org/x/_7DRAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 25 April 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 25 April 2017 at 3:00 UTC. Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_- 5F7DRAw <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ -5F7DRAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSF pCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jZkO63PoGHEjIFn6twujY6w4nJ6RxaHeiFDpCX7u ejQ&s=pExutxgVaNeM6YYGfUVwmsTIP6n2IHVdhdScfVJ8ClA&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=jZkO63PoGHEjIFn6twujY6w4nJ6RxaHeiFDpCX7uejQ&s=pE xutxgVaNeM6YYGfUVwmsTIP6n2IHVdhdScfVJ8ClA&e= avri doria:i am on adobe and don't hear Jeff Neuman:I am on Adobe and I can hear Terri Agnew:Checking audio, can I be heard at this time? Steve Chan:I can't hear you Terri Terri Agnew:If having audio issue on adobe , try logging in using a different browser Terri Agnew:or ping me with your telephone number and I can dial out to you Jeff Neuman:I can hear Terri now Steve Chan:I can hear as well and I'm on phone. (Jeff is on AC) Jeff Neuman:Avri has left the building Terri Agnew:@Avri, can you hear me at this time? avri doria:nope and tried to call in, but that did not work either avri doria:even rebooted Terri Agnew:I will send you a private chat Jim Prendergast:same here. I'd probably need some tie to review it, especially not at this hour. Jim Prendergast:on point 2 - is that implying that someone other than the front end registry aka applicant should bear the costs? I don't thnk you are suggesting technical service providers actually pay for it are you? Jeff Neuman:Can we post the link Jeff Neuman:And make suggestions Steve Chan:Available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen t_d_1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWhoHNw_edit <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume nt_d_1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWhoHNw_edit&d=DwIFaQ&c=FmY1u3PJp6 wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2 EBk&m=jZkO63PoGHEjIFn6twujY6w4nJ6RxaHeiFDpCX7uejQ&s=f7HazjgaVR1hFdjtZicPZVrI U_yxsvmGQ1KJfetsRA4&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=jZkO63PoGHEjIFn6twujY6w4nJ6RxaHeiFDpCX7uejQ&s=f7 HazjgaVR1hFdjtZicPZVrIU_yxsvmGQ1KJfetsRA4&e= Jeff Neuman:If there are specific questions, please ask....but yes, this is a starting poin Jeff Neuman:point Donna Austin, Neustar:appreciate that Sara, and I hope my comments aren't being taken as being critical, just some general observations at this point. 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 o 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. Jim Prendergast:that probably warrants to clarification to it Jeff Neuman:I think that is right Donna. Its 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 Jeff Neuman:Agree- All, please make suggestions in the google Doc. Lets get the wording to a point where it is clear and we can all agree Jim Prendergast:will do. I'm better at 11am as opposed to 11pm Jeff Neuman:Funny Jim...i am better at 11 pm :) Steve Chan 2:Sorry, missed those. Reloaded with the two points Jeff is discussing now. 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. Donna Austin, Neustar:@Jim, we really need ICANN to provide that information before we go down that track. Justine Chew:So we need to address scalability, Jeff? Jeff Neuman:that could be one item Jeff Neuman:again it is for discussion avri doria:I find the issue of granfathering somewhat problematic. i think there are possibly too many conditions that may vary. i do not see the harm of everyone starting afresh. Justine Chew:@Donna: Yes, agree with your response. Jeff Neuman:Thanks Donna - I dont think your comments and mine are inconsistent. Cheryl Langdon-Orr (CLO):had to drop audio to get into my next ICANN call 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) Cheryl Langdon-Orr (CLO):sigh 6,5 has of these today from 0300 2 oh of course it's a National public holiday so I shouldn't complain should I Donna Austin, Neustar:No Cheryl, you should be off playing two-up and leaving the phone at home avri doria:wee are trng to eliminate multipel testings, i do not see the requiremnt to eliminate all testing for some. Cheryl Langdon-Orr (CLO):poor audio for me Cheryl Langdon-Orr (CLO):improved Terri Agnew:let me know if audio goes to poor again Cheryl Langdon-Orr (CLO):off again a bit Jim Prendergast:did the community determine the pricing in the previous rounds or was that dictated by ICANN? Jeff Neuman:@Jim - Dictated by ICANN Terri Agnew:I reported Avri's AC audio issue earlier. I will add additional poor audio quality to the ticket Jeff Neuman:Based on some vague formulas and SWAGs on expected volumes Jim Prendergast:that's what I thought. 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 Terri Agnew:next call: New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 16 May 2017 at 15:00 UTC. Jeff Neuman:so, that is the key part we (WT 4) may need to discuss Donna Austin, Neustar:@Jeff, do you know who signs off on that report, ie, is it the Board? Cheryl Langdon-Orr (CLO):bye for now then lots more to divvying all this from today Cheryl Langdon-Orr (CLO):discuss Edmon:bye Jeff Neuman:Not sure as it was just outsourced

1 0

Agenda - Work Track 1
by Sara Bockey April 24, 2017

April 24, 2017

Dear All, The next call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 25 April 2017 at 3:00 UTC. The proposed agenda is as follows: 1. Welcome & Agenda Overview 2. SOIs 3. RSP Program 1. Costing 2. AOB Thanks, sara bockey policy manager | GoDaddy™ sbockey(a)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.

1 0

Recording, Attendance & AC Chat from New gTLD Subsequent Procedures Sub Team Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 11 April 2017
by Terri Agnew April 11, 2017

April 11, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue held on Tuesday, 11 April 2017 at 20:00 UTC. Adobe Connect Recording: <https://participate.icann.org/p2sbco0i6ib/?OWASP_CSRFTOKEN=436763efcaabf56f d0227f108d44d3c705d81ed2dd669eac5ee8f7b29a7d3189> https://participate.icann.org/p2sbco0i6ib/ The recordings of the calls are posted on the GNSO Master Calendar page: <http://gnso.icann.org/en/group-activities/calendar> http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1> http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1 Agenda wiki page: <https://community.icann.org/x/_bDRAw> https://community.icann.org/x/_bDRAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 11 April 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue on Tuesday, 11 April 2017 at 20:00 UTC Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_- 5FbDRAw <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ -5FbDRAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSF pCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=I5Bnfz4eCTwQIZg0cmhHrPnjsMOBgW56GDRTDUa6 VYs&s=CKFrLDO4Z-gpbMKhYP32mEYbFHmfgBc369GCb9AkPX0&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=I5Bnfz4eCTwQIZg0cmhHrPnjsMOBgW56GDRTDUa6VYs&s=CK FrLDO4Z-gpbMKhYP32mEYbFHmfgBc369GCb9AkPX0&e= Vanda Scartezini:hi everyone Christa Taylor:Hello Vanda Vanda Scartezini:listen mode since I am in a road with traffic and high noise Terri Agnew:thank you for this information Vanda Emily Barabas:we can advance the slides Donna Austin, Neustar:Is the audio choppy or is it just me? Steve Chan:@Donna, I'm on phone and it's clear for me. Donna Austin, Neustar:thanks Steve, must just be me. Terri Agnew:@Donna, if needed I can always dial out on the telephone. Terri Agnew:sometimes rejoining on the adobe connect using a differernt browser helps as well Donna Austin, Neustar:@Terri, that's what you told me last night :-) Christa Taylor:can you hear me? Julie Hedlund:@Christa: We can't hear you. Christa Taylor:one sec Christa Taylor:one sec Christa Taylor:can you let me know Christa Taylor:can you let me in the room Terri Agnew:@Christa , we are still unable to hear you Terri Agnew:We are not seeing you join on a second connection via adobe connect Terri Agnew:@Christa, second Adobe Connect has joined for you Cheryl Langdon-Orr (CLO):yeah! Cheryl Langdon-Orr (CLO):Darn gremlins Alan Greenberg:Sorry, that was me. Forgot to mute. Cheryl Langdon-Orr (CLO):yes Steve that needs clarification Jim Prendergast:ill call in 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. Terri Agnew:@Jim, if assistance is needed dialing in, please let me know 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 Jim Prendergast:im dialed in 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 demonstarte financlial wherwithal. 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 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. Alexander Schubert:But I can tell you Domainers all over the world are already licking their fingers - they think they spend US $200k and then lean back and cash in.... "Hobby-TLDlers" 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 - thats 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 Cheryl Langdon-Orr (CLO):yup Vanda Scartezini:I agree with Jim about no celing avri doria:personally (not as WG co-chair) I am uncomfortable with some of the assumption behind a floor. Jim Prendergast:it might help avri doria:i think it is a good idea to do so Christa Taylor 2:It was sent with the agenda in case it helps in viewing the document Vanda Scartezini:back end list of certified companies was one of demands in our survey in LAC region Katrin Ohlmer, DOTZON:Could the PDF docs be made downloadable, please? Thanks in advance. Katrin Ohlmer, DOTZON:ah, ok. Katrin Ohlmer, DOTZON:thanks. Emily Barabas:The slides are also available on the wiki here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_dis play_NGSPP_4.2.8-2BAccreditation-2BPrograms <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di splay_NGSPP_4.2.8-2BAccreditation-2BPrograms&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mS VzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=I5Bn fz4eCTwQIZg0cmhHrPnjsMOBgW56GDRTDUa6VYs&s=ZhXiqecCREatHc2UvDIUADfUHxp9tSIzlt sfBjg7P0Y&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=I5Bnfz4eCTwQIZg0cmhHrPnjsMOBgW56GDRTDUa6VYs&s=Zh XiqecCREatHc2UvDIUADfUHxp9tSIzltsfBjg7P0Y&e= 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). 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 accreditng RSPs? Jim Prendergast:We already have a situtation where RSPs are failing an ICANN is coachng 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 Samantha Demetriou: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 thats a helpful clarificaitonDonna - this is not an accrediation program - just problem solving the testing issues.\ Terri Agnew:Next call: New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 25 April 2017 at 3:00 UTC Cheryl Langdon-Orr (CLO):bye for now then... thanks everyone good progress today more to come of course Vanda Scartezini:nice meeting tks to all good ideas. Katrin Ohlmer, DOTZON:thanks & bye, everybody. Vanda Scartezini:happy Easter and Pesach to everyone

1 0

Actions/Discussion Notes: Work Track 1 Sub Team Meeting 11 April 2017
by Julie Hedlund April 11, 2017

April 11, 2017

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.

1 0

WT1 Agenda
by Sara Bockey April 10, 2017

April 10, 2017

Dear All, The next call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 11 April 2017 at 20:00 UTC. The proposed agenda is as follows: 1. Welcome & Agenda Overview 2. SOIs 3. Costing - COME PREPARED! Consider the following questions: * 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. * What are your fears if the floor is too low? 4. RSP Program * Attached is a copy of Donna’s previous proposal to refresh memories. 5. AOB Thanks, sara bockey policy manager | GoDaddy™ sbockey(a)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.

1 0

RSP Program
by Ashley Roberts April 10, 2017

April 10, 2017

Hi all, In anticipation of our discussion of the RSP Program on tomorrow's WT1 call I'd like to re-circulate the proposal<https://community.icann.org/display/NGSPP/4.2.8+Accreditation+Programs?prev…> Donna put together a while back, as I think it contains the basics of some good, relatively straightforward solutions for the problems we are trying to resolve around RSP certification (or whatever you prefer to call it) and will thus, hopefully act as a good starting point for some debate. In a nutshell, the proposal puts forward three options for RSPs (Donna, please correct me if I have misinterpreted any of your ideas): - RSPs providing back-end services to current 2012-round TLDs (and have thus already passed evaluation and PDT) would be considered "proven providers" and therefore would not need to go through further evaluation (including submission of technical answers) or PDT in a subsequent round (AR caveat: evaluation and/or PDT may be required if there are substantive changes to the technical requirements in the AGB); - Any non-2012 round RSPs could - prior to a subsequent application round commencing - apply to ICANN to go through evaluation and PDT and become pre-certified, meaning that they also would not need to go through further evaluation or PDT per application; - The status quo: for any RSPs which do not fall into the above two categories, they can elect to submit answers to the technical questions in the application and go through evaluation and PDT as part of the normal (2012) process. It'd be good to hear any thoughts you have on these suggestions. Thanks, Ashley Ashley Roberts Senior Manager | Valideus Ltd 28-30 Little Russell Street London, WC1A 2HN, United Kingdom E: ashley.roberts(a)valideus.com<mailto:ashley.roberts@valideus.com> T: +44 20 7421 8299 D: +44 20 7421 8264 F: +44 87 0011 8187 www.valideus.com<http://www.valideus.com/> Liability cannot be accepted for statements made which are clearly the sender's own and not made on behalf of Valideus. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Valideus Ltd is registered in England and Wales with company number 06181291 and VAT number 987 7551 49. Our registered office is at 28-30 Little Russell Street, London, WC1A 2HN.

1 0