May 2017 - Gnso-newgtld-wg-wt1

Recording, Attendance, AC recording, AC Chat for New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue, 30 May 2017
by Terri Agnew May 30, 2017

May 30, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The AC recording and AC Chat are listed below for the New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue held on Tuesday, 30 May 2017 at 20:00 UTC. Adobe Connect recording (audio and visual): <https://participate.icann.org/p6rvj6gm2f7/?OWASP_CSRFTOKEN=1d0b66cd3929354d…> https://participate.icann.org/p6rvj6gm2f7/ 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/qgDfAw> https://community.icann.org/x/qgDfAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 30 May 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 30 May 2017 at 20:00 UTC. Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=wrVF8ge7Cw6yXiSc1fDGuOjdOqKlzyIW7ZXdtnrzx2w&s=Ru-D9a5MDlhCSpo1GRJN1gNQQYFCqdxDkNo-2ncCKy0&e= Cheryl Langdon-Orr (CLO):the call me says it is but it is not doing so... sorry Terri Agnew:@Cheryl, let me try again Emily Barabas:slides are currently not synced Emily Barabas:everyone can control slides for themselves avri doria:so us saying it goes away means we accept that which currenlty exists. Cheryl Langdon-Orr (CLO):indeed A Cheryl Langdon-Orr (CLO):Alan avri doria:there were applications Rubens Kuhl:The number was so small that any information can be traced to individual applicants. avri doria:an handful, i foeget the actual number Trang Nguyen:Yes, the eval report provides pass/fail by category (https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_… <https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_…> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=wrVF8ge7Cw6yXiSc1fDGuOjdOqKlzyIW7ZXdtnrzx2w&s=EUsIHqdB075ghYxryaMiV_3YvLCzdY9q1q1FrhMgtrA&e= ) avri doria:the APS starting early might make a difference. a lot of diffeence. avri doria:i mean ASP Alan Greenberg:Results of last Applicant Support Program: https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_… <https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_…> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=wrVF8ge7Cw6yXiSc1fDGuOjdOqKlzyIW7ZXdtnrzx2w&s=EUsIHqdB075ghYxryaMiV_3YvLCzdY9q1q1FrhMgtrA&e= Cheryl Langdon-Orr (CLO):agree Greg Rubens Kuhl:A possible program should not restrict itself to application fee, but also include planning and ongoing operations. Cheryl Langdon-Orr (CLO):too little too late Cheryl Langdon-Orr (CLO):full review needed on this Rubens Kuhl:Note that .IDN would have failed restricted strings criteria, being a 3-letter country code. Jim Prendergast:would it help to remind the larger WG that this issue is being discussed and we could use some help? Christa Taylor:Will do Jim! Rubens Kuhl:ASP gamed itself out. avri doria:Personal view: in the 2012 round the anti-gaming factions were the gamers who won. Cheryl Langdon-Orr (CLO):lots fell down on As effort Rubens Kuhl:On communications, Stakeholder Engagement capacity at ICANN grew a lot since 2012. So the same programs with the 2012 rules could have a different outcome this time. Cheryl Langdon-Orr (CLO):Applicant Support avri doria:Rubens, good point. Donna Austin, Neustar:I think the AGB was good. I don't know of any other mechanism that would be any great improvement. Kurt Pritz:On Applicant Support: I know this is late but you could stick it in the notes. I think this group could develop a set of policy principles guiding an applicant support implementation, e.g.,1. Applicant support should be more about coaching and mentoring than financial support2. Financial support could be awarded for the application fee and early registry fees but be focused on making the registry self sufficient3. The support program should be publicized as broadly as the program itself4. The program should take into account that applicants will be unsophisticated and evaluations should be conducted with that understandingWe could knock this out in a couple hours. After we have a simple set of principles, we can turn that over to ICANN to start implementation now for iteration and discussion with the community. Cheryl Langdon-Orr (CLO):thx Kurt... well worthwhile in my view Emily Barabas:@kurt - done! Sara Bockey:https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01… Jim Prendergast:if breach notices were issued, they would be on the compliance page and there are none. Unclear if compliance was involved in this Jeff Neuman:How do you analyze the financial/business case without knowing the costs of the RSP? Rubens Kuhl:ICANN staff mentioned that one of the reasons for not triggering EBERO was lack of registrants to be protected. If a TLD only has nic.TLD, it's really not that useful to do a transition. Phil Buckingham: Great points , Donna - it is a question of the cart before the horse for instance -. We wouldnt need the EBERO if the SLAs were raised. . Rubens Kuhl:Alan, there is currently an ongoing consensus call in WT4 proposing technical evaluation to be as aggregated as feasible. So even if that doesn't cover previous rounds like the 2012 one, it at least would already cover the next procedure. Jim Prendergast:the 27 times figure is one data point. Some others were presented by ICANN Technical staff at the DNS Symposium. Ive only seen the presentation (and not heard audio) but the stats on page 23 are broader than the 27 times figure. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste… <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=wrVF8ge7Cw6yXiSc1fDGuOjdOqKlzyIW7ZXdtnrzx2w&s=BQrQhehRQ8DDFpXqnWmOXKx6F70oHKbvT7na8XsHna4&e= Alan Greenberg:@Rubens, understood.. Jeff Neuman:For the record, I think we have established a need for the program. we just need to take Donna's comments into account when moving forward Jim Prendergast: I disagree with that Jeff Donna Austin, Neustar:@Jeff, I'm not sure we have. Jeff Neuman:Both in the Discussion Group, the Charter and previous discussions..... Karen Day:program or not we must remove barrier of having to choisecRSP before contention is resolved. Karen Day:*chosose* Karen Day:apologies for typos Jeff Neuman:Whether it is a "program" or just a pre-approval process, we have had a large number of calls on the benefits of this type of program/process/ or whatever we call it Cheryl Langdon-Orr (CLO):hold off for more information Donna Austin, Neustar:@Jeff, perhaps its the terminology that you are using that we're sensitive to. I think we agreed there would be benefit in enable new entrants undergo an approval process prior to the next application window. Rubens Kuhl:Trang, I believe we should allow before or during, but not after. Rubens Kuhl:This was the topic of some CC2 comments that we need to take into account. Cheryl Langdon-Orr (CLO):yup Rubens Kuhl:While this PDP WG charter does include some topics applicable to current gTLDs, I believe this issue is not in our charter, at least for now. Terri Agnew:New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 13 June 2017 at 03:00 UTC for 60 minutes. Cheryl Langdon-Orr (CLO):thanks everyone... bye for now then avri doria:bye Christopher Niemi:Thanks Rubens Kuhl:Bye @ll Trang Nguyen:Thanks, all! Bye! Katrin Ohlmer, DOTZON:thanks - and bye, everybody!

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - Track 1 - 30 May 2017
by Emily Barabas May 30, 2017

May 30, 2017

Dear Work Track members, Please find below the action items and discussion notes from today’s meeting. These high-level notes are designed to help Work Track members navigate through the content of the call and are not a substitute for the chat room or the recording. The meeting recording and chat transcripts will soon be available at: https://community.icann.org/x/qgDfAw. Slides from today’s call are attached for reference. Kind regards, Emily 2. SOIs - no updates 3. Topic Review and Progress - Today we will review topics where we don't yet have draft language. - CC2 is currently being reviewed and organized by staff, these comments will be available soon for the WTs to take into account. - Applicant Support - slide with overview of current status. Questions: How do we want to proceed, what information do we need? - We need a plan to address this topic, if not in this WT than in another form through the WG. - Question - for those who applied, do we know which elements they failed on? Were certain elements particularly difficult to meet? If so, maybe we can work on those. Were there enough applicants to evaluate this. - This is a topic that does need fixing. There is ample justification for making changes. We need to figure out to fix this or make a determination that is unfixable. - We may need to decide how we want to interface with the auction proceeds CCWG. Chat excerpt: avri doria: there were applications Rubens Kuhl: The number was so small that any information can be traced to individual applicants. avri doria: an handful, i foeget the actual number Trang Nguyen: Yes, the eval report provides pass/fail by category (https://newgtlds.icann.org/en/applicants/candidate-support/sarp-results-20m…<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_…>) avri doria: the ASP starting early might make a difference. a lot of diffeence. Alan Greenberg: Results of last Applicant Support Program: https://newgtlds.icann.org/en/applicants/candidate-support/sarp-results-20m…<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_…> Rubens Kuhl: A possible program should not restrict itself to application fee, but also include planning and ongoing operations. Cheryl Langdon-Orr (CLO): too little too late - There were three applicants in the 2012 round. One passed all criteria, one failed all four, one passed two and failed two. - All were "ICANN insiders." - We have to look at non-financial support. - There were a number of companies that signed up to offer logistical support. Did anyone use this list? It would be helpful to talk to anyone from ICANN staff who was involved with that to get more information. - We need to do more work on this. Leads will put it back on the schedule. - Hopefully we will get some useful input from the CCT Review report. - Applicant support program was put together late and there was strong concern about the system being gamed. Chat excerpt: Rubens Kuhl: Note that .IDN would have failed restricted strings criteria, being a 3-letter country code. Jim Prendergast: would it help to remind the larger WG that this issue is being discussed and we could use some help? Christa Taylor: Will do Jim! Rubens Kuhl: ASP gamed itself out. avri doria: Personal view: in the 2012 round the anti-gaming factions were the gamers who won. Cheryl Langdon-Orr (CLO): lots fell down on As effort Rubens Kuhl: On communications, Stakeholder Engagement capacity at ICANN grew a lot since 2012. So the same programs with the 2012 rules could have a different outcome this time. Cheryl Langdon-Orr (CLO): Applicant Support Kurt Pritz: On Applicant Support: I know this is late but you could stick it in the notes. I think this group could develop a set of policy principles guiding an applicant support implementation, e.g.,1. Applicant support should be more about coaching and mentoring than financial support2. Financial support could be awarded for the application fee and early registry fees but be focused on making the registry self sufficient3. The support program should be publicized as broadly as the program itself4. The program should take into account that applicants will be unsophisticated and evaluations should be conducted with that understandingWe could knock this out in a couple hours. After we have a simple set of principles, we can turn that over to ICANN to start implementation now for iteration and discussion with the community. - ICANN org verified information of volunteers for the pro bono assistance program, information was posted on a directory, but ICANN org did not play matchmaker in the last round. - Did the volunteers receive communication about the directory and role ICANN org plays? Additional communication may be helpful in the future. - Topic: Applicant Guidebook - status summary provided on slides. Chat excerpt: Donna Austin, Neustar: I think the AGB was good. I don't know of any other mechanism that would be any great improvement. - Topic: Clarity of Application Process - status summary provided on slides. - The 2012 round was difficult to implement because of the number of moving pieces. There will be lessons learned from the 2012 round, so the clarity of the process should be better going forward. - We need to be clear in the AGB about any policy changes. 4. RSP Program - Google Doc: https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWh…<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> - We haven't decided that there should be an RSP program and we don't know what it will look like. - Our goal is to create efficiencies in the application process, which seems to be focused on new entrants. - The stats we've received are over a 3.5 year period. We don't have the level of granularity in the stats on the SLAs to find the problem and why it occured and if there is anything we can do to mitigate observed problems. - RSP and applicants alike don't understand what the requirements are. - There is the application phase, delegation phase, and operations phase. The requirements are different in different phases. Do we need to solve all three elements in this exercise? Or does this only relate to the application phase? - We still don't full understand the problems that we are trying to solve with respect to each phase, to the extent they are relevant to the PDP WG. Chat excerpt: Jim Prendergast: if breach notices were issued, they would be on the compliance page and there are none. Unclear if compliance was involved in this Jeff Neuman: How do you analyze the financial/business case without knowing the costs of the RSP? Rubens Kuhl: ICANN staff mentioned that one of the reasons for not triggering EBERO was lack of registrants to be protected. If a TLD only has nic.TLD, it's really not that useful to do a transition. Phil Buckingham: Great points , Donna - it is a question of the cart before the horse for instance -. We wouldnt need the EBERO if the SLAs were raised. - From the application process, we've identified that we don't want service providers to go through the same process 30 times. This could be addressed without a RSP program, for example with a check box on the application, although such a solution would not address whether a provider could handle the overall volume, which is a different question. - It seems that an RSP program makes sense, but it may not be for the PDP to address. Chat excerpt: Rubens Kuhl: Alan, there is currently an ongoing consensus call in WT4 proposing technical evaluation to be as aggregated as feasible. So even if that doesn't cover previous rounds like the 2012 one, it at least would already cover the next procedure. Jim Prendergast: the 27 times figure is one data point. Some others were presented by ICANN Technical staff at the DNS Symposium. Ive only seen the presentation (and not heard audio) but the stats on page 23 are broader than the 27 times figure. https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pd…<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…> Jeff Neuman: For the record, I think we have established a need for the program. we just need to take Donna's comments into account when moving forward Jim Prendergast: I disagree with that Jeff Donna Austin, Neustar: @Jeff, I'm not sure we have. Jeff Neuman: Both in the Discussion Group, the Charter and previous discussions..... Karen Day: program or not we must remove barrier of having to choose RSP before contention is resolved. Jeff Neuman: Whether it is a "program" or just a pre-approval process, we have had a large number of calls on the benefits of this type of program/process/ or whatever we call it Donna Austin, Neustar: @Jeff, perhaps its the terminology that you are using that we're sensitive to. I think we agreed there would be benefit in enable new entrants undergo an approval process prior to the next application window. - Question - is it possible to clarify the timing of when these processes would occur with respect to the application window -- this would help with implementation. Chat excerpt: Rubens Kuhl: Trang, I believe we should allow before or during, but not after. Rubens Kuhl: This was the topic of some CC2 comments that we need to take into account. - Item 10 - this may not be a question for this group to address. 5. AOB - none

1 0

Re: [Gnso-newgtld-wg-wt1] Agenda - Work Track 1 for Tuesday, May 30, 2017 at 20:00 UTC
by Christa Taylor May 30, 2017

May 30, 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, 30 May 2017 at 20:00 UTC. The proposed agenda is as follows: 1. Welcome & Agenda Overview 2. SOIs 3. Topic Review and Progress 4. RSP Program 5. AOB Please feel free to add comments to the RSP document at: https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWho HNw/edit Cheers, Christa Christa Taylor, B. Tech, CPA, CMA, MBA Mobile: 604-961-9460 Skype: christat13 <mailto:christa@dottba.com> christa(a)dottba.com <http://www.dottba.com/> www.dottba.com

1 0

**2nd UPDATE attendance / Recording, Attendance, AC recording, AC Chat for New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue, 16 May 2017
by Julie Bisland May 16, 2017

May 16, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The AC recording and AC Chat are listed below for the New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue held on Tuesday, 16 May 2017 at 15:00 UTC. Adobe Connect recording (audio and visual): https://participate.icann.org/p6vf53hxy56/<https://participate.icann.org/p6vf53hxy56/?OWASP_CSRFTOKEN=2b0728a855708eb5…> The recordings of the calls are posted on the GNSO Master Calendar page: 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 Agenda Wiki page: https://community.icann.org/x/EtTRAw Thank you. Kind regards, Julie ------------------------------- Adobe Connect chat transcript for 16 May 2017 Julie Bisland:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue on Tuesday, 16 May 2017 at 15:00 UTC. Julie Bisland:Agenda Wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Sara Bockey:Much better! Ashley Roberts:for the record, I am on the call (I see I am listed as having sent apologies). Julie Bisland:I'll correct that, Ashley, thank you. Ashley Roberts:thanks VANDA SCARTEZINI:sorry to be little late Alan Greenberg:JOnathan fading... Jeff Neuman:Hard to hear Jonathan Jeff Neuman:Is there anyone that can present the RySG position on this call? Jonathan Robinson (Afilias):Correct. RySG group is scheduled to meet tomorrow Donna Austin, Neustar:@Jeff, I can more or less Cheryl Langdon-Orr (CLO):here now Jeff Neuman:@Donna, that would be great Donna Austin, Neustar:but as Sara said there is a call of the RySG group tomorrow Christa Taylor:last slide - May 30th Christa Taylor:20:00 UTC Julie Bisland:The next New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 30 May 2017 at 20:00 UTC Christa Taylor:https://participate.icann.org/newgtldsubteams/?launcher=false&discla… Cheryl Langdon-Orr (CLO):good point made by Jim Cheryl Langdon-Orr (CLO):indeed Donna we need more info here Jonathan Robinson (Afilias):@Crista - Julie Hedlund's notes on the RHS shoudl be a helpful aide memoir to updating the document after this meeting Jonathan Robinson (Afilias):Sorry Christa Christa Taylor:thanks Jonathan Steve Chan:WT2 had asked questions about the EBERO in relation to registrant protections. Here is the response from GDD. Steve Chan:Section 6 of Specification 10 of the Registry Agreement for new gTLDs provides emergency thresholds for the 5 critical registry functions. Per the Registry Agreement, reaching any one of these thresholds could trigger an EBERO event. Steve Chan:ICANN monitors registries’ performance of these critical registry functions, and regularly engages with Registry Operators and Registry Service Providers when service outages occur. Not all services outages reach emergency thresholds. If emergency thresholds are reached, ICANN evaluates each individual case and make decisions regarding whether to trigger an EBERO event based on the unique circumstances. Steve Chan:Since the launch of the New gTLD program, an SLA has reached or exceeded the emergency threshold 27 times. However, no EBERO events have been declared to date. In each of these 27 cases, ICANN technical teams were already working with the registry before the threshold was reached. In many of the cases, the TLD had no registrations. In the cases in which there were registrations, ICANN considered the EBERO option. However, ICANN determined that it would have less of a security and stability impact to assist the RSP through resolution rather than activating an EBERO event. Ashley Roberts:slides are here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste… Jessica Hooper (Verisign):Agree. This could lead to a race to the bottom by setting minimum standards rather than having providers strive for excellence in service. (third bullet point) Jeff Neuman:@Jessica - How is setting SLAs in the agreements now any different than setting them in a pre-approval process? Jeff Neuman:I am not sure why this would become a race to the bottom Jeff Neuman:Can someone clarify that Jeff Neuman:sorry, have a noisy printer going off now and cant speak :) Alan Greenberg:Given how many people on this call, pretty quiet group. VANDA SCARTEZINI:guess burden should be more clearly expressed. VANDA SCARTEZINI:@alan -I am in the airport, better be mute... quite a noise Kurt Pritz:@ Jeff. SLAs are sort of backward looking. Some registries will cut costs until there is a failure. Then it is too late. A pre-approved RSP might have forward-looking criteria that are intended to avoid failures such as statistical process controls and new threat identification and remediation. Jeff Neuman:@kurt - then this is a problem with existing registries and RSPs already. Its not something that is new. Nor is it something that would be worse with a Pre-approval process. Donna Austin, Neustar:@ Trang: we haven't decided anything yet. Jeff Neuman:@Donna - correct. No decisions yet, but the trend has been towards a "pre-approval" process prior to the applications being submitted for TLDs. It would be voluntary. VANDA SCARTEZINI:@kurt, looks you have a point - agree with you comment Jonathan Robinson (Afilias):Pre-approval to meet a minimum standard which seems to be demonstrably inadequate doesn't sound like it's moving in the direction of future security and stability VANDA SCARTEZINI:+ 1 Jonathan Trang Nguyen:@Jeff, there were 3 firms providing technical evaluation. Donna Austin, Neustar:@Trang, but PDT is done by the same provider? Sarah L Verisign:@Jeff I thought the RSP accreditation process was intended to make improvements to what we have today rather haan not make something that already exists without it "worse" - I dont see how that plays into security and stablity. Sorry for beeing late to the meeting I only just joinned. Trang Nguyen:@Donna, correct, PDT is performed by 1 vendor. Jeff Neuman:@sarah = Sure, standards can be approved for future as well and apply retroactively to all providers. If we think the standards are too low now (which I am not saying), then we can always through a policy that starts today amend the existing agreements to increase the SLAs for all.....and then apply that to the future applications Christa Taylor:Impro Jeff Neuman:I guess what I am saying is that there should not be additional barriers to entry in the future that do not exist today. Ashley Roberts:Jonathan, if we think the standards in the current RA are insufficient then that is a different conversation. I believe that topic comes under the remit of WT4 (please correcct me if I'm wrong).. All we are talking about is at what stage and how many times we evaluate whether the RSP meets the required standards (whether they be the current standards or some otherwise agreed standards) Cheryl Langdon-Orr (CLO):indeed it does not Jonathan, and an issue to be delt with, no doubt... but it's an issue not a new issue with any proposed pre approval, what is to me an opportunity is to possibly explore and enact mitigation or risk management of heading to a failure point, to be tethered to any such recommendations, and that also could help avoid the same risk in existing standards... Cheryl Langdon-Orr (CLO):yes Ashley far more clearly said... sorry ðŸ™ not fully operational atm Ashley Roberts::-) VANDA SCARTEZINI:Ok got it Ashley. tks Kurt Pritz:I think #4 is kind of irrelevant. If an RSP bears costs associated with its certification, those costs have to be passed on to registry operators somehow, either through a one-time charge or some rate. I think it is up to the RSP what they want to charge and then up to their customers if they want to pay that charge Jeff Neuman:Kurt - I disagree. This is costs to pay ICANN. Not costs paid by Registry to RSP Cheryl Langdon-Orr (CLO):Staff can we make sure we capture this standards issue, chat extracts etc., and send it to our WT4 Kurt Pritz:@ Jeff - lemme think about that. Maybe the Proposal should be edited a little Alan Greenberg:@Kurt, if testing is done ahead of time, there are no applicants at that point, only RSPs. If an RSP does not end up being used by any applicants, RSP is only entitty to bear costs. Jeff Neuman:ICANN collected approx $61,667 from each application (paid for by Registry Operators) to pay for evaluations. A substantial portion of that was paid for technical evaluation. That can be eliminated from the Registry Operator's application for the TLD with a pre-approval program Kurt Pritz:@Alan - but it passes those costs along at some point. If an RSP makes an initial investment, it has to recoup that investment Jeff Neuman:It can then charge RSPs to get "pre-approved" one time. Jeff Neuman:@Kurt - There is a big difference to pass through an evaluation cost incurred once divided by all its customers, then to be charged that evaluation costs 300 times (in the case of some RSPs) and pass those on to the ROs Emily Barabas:@Cheryl, notes, chat transcripts, and recordings for this call will be available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di… . Once all documents are posted, we can share this link with WT4. Jeff Neuman:For example, if RSP Approval costs $50,000 (hypothetically), then dividing that one time charge amongst 300 registry operators is much different than passing through $50,000 to each of its ROs to be evaluated 300 times. Cheryl Langdon-Orr (CLO):thanks Emily, I don't want any nexus points overlooked... VANDA SCARTEZINI:donna's points in the doc cover up the point Jeff Neuman:I have to drop. Thanks everyone Kurt Pritz:@Jeff : Won't the market deal with that? Donna Austin, Neustar:What is meant by 'functional areas' in Q7? Donna Austin, Neustar:thanks Julie Bisland:The next New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 30 May 2017 at 20:00 UTC Julie Hedlund:@Jim: Yes, staff will include the link to the document in the notes. Cheryl Langdon-Orr (CLO):thanks everyone good call, talk again soon... bye for now Jonathan Robinson (Afilias):@staff. PLease can I be added to this / relevant mailing list/s. Thank-you Alan Greenberg:Thanks all. Donna Austin, Neustar:thanks Christa Sara Bockey:Thanks all!!! Jonathan Robinson (Afilias):Thank-you Christa Ashley Roberts:thanks Katrin Ohlmer, DOTZON:thanks and bye, everybody. Trang Nguyen:Thanks, all! Bye! VANDA SCARTEZINI:thnaks to all Phil Buckingham:.thank you Christa Phil Buckingham:thank you Christa

1 0

**UPDATE attendance / Recording, Attendance, AC recording, AC Chat for New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue, 16 May 2017
by Julie Bisland May 16, 2017

May 16, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The AC recording and AC Chat are listed below for the New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue held on Tuesday, 16 May 2017 at 15:00 UTC. Adobe Connect recording (audio and visual): https://participate.icann.org/p6vf53hxy56/<https://participate.icann.org/p6vf53hxy56/?OWASP_CSRFTOKEN=2b0728a855708eb5…> The recordings of the calls are posted on the GNSO Master Calendar page: 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 Agenda Wiki page: https://community.icann.org/x/EtTRAw Thank you. Kind regards, Julie ------------------------------- Adobe Connect chat transcript for 16 May 2017 Julie Bisland:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue on Tuesday, 16 May 2017 at 15:00 UTC. Julie Bisland:Agenda Wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Sara Bockey:Much better! Ashley Roberts:for the record, I am on the call (I see I am listed as having sent apologies). Julie Bisland:I'll correct that, Ashley, thank you. Ashley Roberts:thanks VANDA SCARTEZINI:sorry to be little late Alan Greenberg:JOnathan fading... Jeff Neuman:Hard to hear Jonathan Jeff Neuman:Is there anyone that can present the RySG position on this call? Jonathan Robinson (Afilias):Correct. RySG group is scheduled to meet tomorrow Donna Austin, Neustar:@Jeff, I can more or less Cheryl Langdon-Orr (CLO):here now Jeff Neuman:@Donna, that would be great Donna Austin, Neustar:but as Sara said there is a call of the RySG group tomorrow Christa Taylor:last slide - May 30th Christa Taylor:20:00 UTC Julie Bisland:The next New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 30 May 2017 at 20:00 UTC Christa Taylor:https://participate.icann.org/newgtldsubteams/?launcher=false&discla… Cheryl Langdon-Orr (CLO):good point made by Jim Cheryl Langdon-Orr (CLO):indeed Donna we need more info here Jonathan Robinson (Afilias):@Crista - Julie Hedlund's notes on the RHS shoudl be a helpful aide memoir to updating the document after this meeting Jonathan Robinson (Afilias):Sorry Christa Christa Taylor:thanks Jonathan Steve Chan:WT2 had asked questions about the EBERO in relation to registrant protections. Here is the response from GDD. Steve Chan:Section 6 of Specification 10 of the Registry Agreement for new gTLDs provides emergency thresholds for the 5 critical registry functions. Per the Registry Agreement, reaching any one of these thresholds could trigger an EBERO event. Steve Chan:ICANN monitors registries’ performance of these critical registry functions, and regularly engages with Registry Operators and Registry Service Providers when service outages occur. Not all services outages reach emergency thresholds. If emergency thresholds are reached, ICANN evaluates each individual case and make decisions regarding whether to trigger an EBERO event based on the unique circumstances. Steve Chan:Since the launch of the New gTLD program, an SLA has reached or exceeded the emergency threshold 27 times. However, no EBERO events have been declared to date. In each of these 27 cases, ICANN technical teams were already working with the registry before the threshold was reached. In many of the cases, the TLD had no registrations. In the cases in which there were registrations, ICANN considered the EBERO option. However, ICANN determined that it would have less of a security and stability impact to assist the RSP through resolution rather than activating an EBERO event. Ashley Roberts:slides are here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste… Jessica Hooper (Verisign):Agree. This could lead to a race to the bottom by setting minimum standards rather than having providers strive for excellence in service. (third bullet point) Jeff Neuman:@Jessica - How is setting SLAs in the agreements now any different than setting them in a pre-approval process? Jeff Neuman:I am not sure why this would become a race to the bottom Jeff Neuman:Can someone clarify that Jeff Neuman:sorry, have a noisy printer going off now and cant speak :) Alan Greenberg:Given how many people on this call, pretty quiet group. VANDA SCARTEZINI:guess burden should be more clearly expressed. VANDA SCARTEZINI:@alan -I am in the airport, better be mute... quite a noise Kurt Pritz:@ Jeff. SLAs are sort of backward looking. Some registries will cut costs until there is a failure. Then it is too late. A pre-approved RSP might have forward-looking criteria that are intended to avoid failures such as statistical process controls and new threat identification and remediation. Jeff Neuman:@kurt - then this is a problem with existing registries and RSPs already. Its not something that is new. Nor is it something that would be worse with a Pre-approval process. Donna Austin, Neustar:@ Trang: we haven't decided anything yet. Jeff Neuman:@Donna - correct. No decisions yet, but the trend has been towards a "pre-approval" process prior to the applications being submitted for TLDs. It would be voluntary. VANDA SCARTEZINI:@kurt, looks you have a point - agree with you comment Jonathan Robinson (Afilias):Pre-approval to meet a minimum standard which seems to be demonstrably inadequate doesn't sound like it's moving in the direction of future security and stability VANDA SCARTEZINI:+ 1 Jonathan Trang Nguyen:@Jeff, there were 3 firms providing technical evaluation. Donna Austin, Neustar:@Trang, but PDT is done by the same provider? Sarah L Verisign:@Jeff I thought the RSP accreditation process was intended to make improvements to what we have today rather haan not make something that already exists without it "worse" - I dont see how that plays into security and stablity. Sorry for beeing late to the meeting I only just joinned. Trang Nguyen:@Donna, correct, PDT is performed by 1 vendor. Jeff Neuman:@sarah = Sure, standards can be approved for future as well and apply retroactively to all providers. If we think the standards are too low now (which I am not saying), then we can always through a policy that starts today amend the existing agreements to increase the SLAs for all.....and then apply that to the future applications Christa Taylor:Impro Jeff Neuman:I guess what I am saying is that there should not be additional barriers to entry in the future that do not exist today. Ashley Roberts:Jonathan, if we think the standards in the current RA are insufficient then that is a different conversation. I believe that topic comes under the remit of WT4 (please correcct me if I'm wrong).. All we are talking about is at what stage and how many times we evaluate whether the RSP meets the required standards (whether they be the current standards or some otherwise agreed standards) Cheryl Langdon-Orr (CLO):indeed it does not Jonathan, and an issue to be delt with, no doubt... but it's an issue not a new issue with any proposed pre approval, what is to me an opportunity is to possibly explore and enact mitigation or risk management of heading to a failure point, to be tethered to any such recommendations, and that also could help avoid the same risk in existing standards... Cheryl Langdon-Orr (CLO):yes Ashley far more clearly said... sorry ðŸ™ not fully operational atm Ashley Roberts::-) VANDA SCARTEZINI:Ok got it Ashley. tks Kurt Pritz:I think #4 is kind of irrelevant. If an RSP bears costs associated with its certification, those costs have to be passed on to registry operators somehow, either through a one-time charge or some rate. I think it is up to the RSP what they want to charge and then up to their customers if they want to pay that charge Jeff Neuman:Kurt - I disagree. This is costs to pay ICANN. Not costs paid by Registry to RSP Cheryl Langdon-Orr (CLO):Staff can we make sure we capture this standards issue, chat extracts etc., and send it to our WT4 Kurt Pritz:@ Jeff - lemme think about that. Maybe the Proposal should be edited a little Alan Greenberg:@Kurt, if testing is done ahead of time, there are no applicants at that point, only RSPs. If an RSP does not end up being used by any applicants, RSP is only entitty to bear costs. Jeff Neuman:ICANN collected approx $61,667 from each application (paid for by Registry Operators) to pay for evaluations. A substantial portion of that was paid for technical evaluation. That can be eliminated from the Registry Operator's application for the TLD with a pre-approval program Kurt Pritz:@Alan - but it passes those costs along at some point. If an RSP makes an initial investment, it has to recoup that investment Jeff Neuman:It can then charge RSPs to get "pre-approved" one time. Jeff Neuman:@Kurt - There is a big difference to pass through an evaluation cost incurred once divided by all its customers, then to be charged that evaluation costs 300 times (in the case of some RSPs) and pass those on to the ROs Emily Barabas:@Cheryl, notes, chat transcripts, and recordings for this call will be available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di… . Once all documents are posted, we can share this link with WT4. Jeff Neuman:For example, if RSP Approval costs $50,000 (hypothetically), then dividing that one time charge amongst 300 registry operators is much different than passing through $50,000 to each of its ROs to be evaluated 300 times. Cheryl Langdon-Orr (CLO):thanks Emily, I don't want any nexus points overlooked... VANDA SCARTEZINI:donna's points in the doc cover up the point Jeff Neuman:I have to drop. Thanks everyone Kurt Pritz:@Jeff : Won't the market deal with that? Donna Austin, Neustar:What is meant by 'functional areas' in Q7? Donna Austin, Neustar:thanks Julie Bisland:The next New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 30 May 2017 at 20:00 UTC Julie Hedlund:@Jim: Yes, staff will include the link to the document in the notes. Cheryl Langdon-Orr (CLO):thanks everyone good call, talk again soon... bye for now Jonathan Robinson (Afilias):@staff. PLease can I be added to this / relevant mailing list/s. Thank-you Alan Greenberg:Thanks all. Donna Austin, Neustar:thanks Christa Sara Bockey:Thanks all!!! Jonathan Robinson (Afilias):Thank-you Christa Ashley Roberts:thanks Katrin Ohlmer, DOTZON:thanks and bye, everybody. Trang Nguyen:Thanks, all! Bye! VANDA SCARTEZINI:thnaks to all Phil Buckingham:.thank you Christa Phil Buckingham:thank you Christa

1 0

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

May 16, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 16 May. 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. Please also see the link to the reference Google doc at: https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWh…. Best, Julie Julie Hedlund, Policy Director Actions/Discussion Notes: RSP Program See: https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWh… and the attached slides. -- General Comment: RSP work is going on in several places, such as Registry Stakeholder Group preparing a letter. The PDP WG should take into consideration other work. RySG is scheduled to meet on 17 May. Document Purpose: -- Include the question, "If not an RSP program are there other remedies that could address the problem?" -- Question: Was the repetitive resource intensive technical evaluation and pre-delegation testing an interpretation of the rules -- a form of application rather than the fault with the rules themselves? -- Perspective of a swap-out of an RSP discussion in RySG: Process developed by ICANN -- started a discussion on what could be done to improve the process. Realized early on that the process was repetitive, but wasn't anticipated. 1. Security and stability of gTLDs must not be negatively impacted and preferable, improved. -- There has been information released by ICANN that even existing registry providers are struggling. Shouldn't assume that anyone who met the 2012 threshold should be grandfathered or pre-approved. -- Helpful to understand why ICANN has not pulled the EBERO on those registries that haven't met SLAs. Need to understand the level of the problem that has been identifed. -- ICANN made a decision on its own that evoking EBERO may make more issues rather than less. The presentation this past weekend was from the OCTO in Madrid -- slides on how many incidents there have been -- 32 of 37 registry operators have had an SLA breach. See the slides at: https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf -- This does raise the prospect of setting a minimum threshold as part of a form of accreditation. Recommendations should seek to address the problems. What are the current problems and what is being solved? Is it performance issues? Also linked to item number 5. 5. RSPs must be able to innovate and differentiate themselves -- Speaks to the issue of a race to the bottom. -- Comment that the base agreement that applies sets the core standard. 2. Efficiency in evaluation and pre-delegation for ICANN, applicants, and RSPs must be improved. -- Re: "Coordination between ICANN and RSPs should be improved" assume this refers to communications? Would ICANN only communicate with RSPs? If RSP is not responding that would have an overall impact on the application and the applicant would be responsible. -- We are looking at this based on what happened in the past and how can we improve it in the future. RSPs would have an opportunity to become pre-approved prior to the opening of an application window -- something akin to addressing technical questions and pre-delegation testing. -- In terms of coordination between ICANN and RSPs being improved -- that is happening in the context of the current situation. ICANN had the relationship with the contracted party and the contracted had the relationship with the RSP. No formal mechanism for ICANN to reach out directly to an RSP. 3. Evaluation and pre-delegation testing must be consistent, predictable, and to the extent possible, objective. -- Understanding that there were three different technical advisers with JAS coordination with an attempt to ensure results were consistent. 4. 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 the RSP are not the same entity. -- Add comments about grandfathering registries from 2012. -- Standards are being discussed in Work Track 4. We don't want to create barriers to entry. Could have existing and new operators be held to a higher standard, but to not create additional barriers to entry that don't exist today. These are two different discussions -- how the process is conducted versus what are the standards (discussed in Work Track 4). -- Expressed in the original purpose. Mitigate the duplicative work at the outset. Important that we don't drift into a discussion of standards as these are being discussed in Work Track 4. 8. 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. -- Conversations about whether it's possible to do this -- the ability of a registry to scale without actually doing it. Whether it's possible to assess whether a registry could manage X number of names, or if there is a distinction between types of TLDs. Premise is that this may not be easy to do in a preparatory stage. There are various elements that could result in an answer to this question. -- Create some sort of formula or predicted number of names in the future, or methodology to consider that. Expand that idea. 6. An RSP Program should be designed in such a manner so it does not increase ICANN's liability. 7. Applicants must have access to a list of Registry Service Providers and a list of the functional areas they have been pre-approved for through the RSP Program. -- What do we mean by "functional areas" is that the different services registries provide? Yes. 9. Applicants must not be required to select a "pre-approved" RSP, but shall be able to either propose providing its own registry services or selection 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. 10. How do we solve the issues of changing from one service provider to another service provider? -- Need to add more to deal with this issue. -- That is something that the RySG is looking at now and will hopefully be able to provide some guidance. We are working with ICANN to understand how the process can be improved. 11. If an RSP Program is the agreed upon solution, do we have different categories of providers? >From the chat: Steve Chan: WT2 had asked questions about the EBERO in relation to registrant protections. Here is the response from GDD. Steve Chan: Section 6 of Specification 10 of the Registry Agreement for new gTLDs provides emergency thresholds for the 5 critical registry functions. Per the Registry Agreement, reaching any one of these thresholds could trigger an EBERO event. Steve Chan: ICANN monitors registries’ performance of these critical registry functions, and regularly engages with Registry Operators and Registry Service Providers when service outages occur. Not all services outages reach emergency thresholds. If emergency thresholds are reached, ICANN evaluates each individual case and make decisions regarding whether to trigger an EBERO event based on the unique circumstances. Ashley Roberts: slides are here: https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf Jessica Hooper (Verisign): Agree. This could lead to a race to the bottom by setting minimum standards rather than having providers strive for excellence in service. (third bullet point) Jeff Neuman: @Jessica - How is setting SLAs in the agreements now any different than setting them in a pre-approval process? I am not sure why this would become a race to the bottom. Can someone clarify that? Kurt Pritz: @ Jeff. SLAs are sort of backward looking. Some registries will cut costs until there is a failure. Then it is too late. A pre-approved RSP might have forward-looking criteria that are intended to avoid failures such as statistical process controls and new threat identification and remediation. Jeff Neuman: @kurt - then this is a problem with existing registries and RSPs already. Its not something that is new. Nor is it something that would be worse with a Pre-approval process. VANDA SCARTEZINI: @kurt, looks you have a point - agree with you comment Jonathan Robinson (Afilias): Pre-approval to meet a minimum standard which seems to be demonstrably inadequate doesn't sound like it's moving in the direction of future security and stability. VANDA SCARTEZINI: + 1 Jonathan Trang Nguyen: @Jeff, there were 3 firms providing technical evaluation. Donna Austin, Neustar: @Trang, but PDT is done by the same provider? Sarah L Verisign: @Jeff I thought the RSP accreditation process was intended to make improvements to what we have today rather haan not make something that already exists without it "worse" - I dont see how that plays into security and stablity. Sorry for beeing late to the meeting I only just joinned. Trang Nguyen: @Donna, correct, PDT is performed by 1 vendor. Jeff Neuman: @sarah = Sure, standards can be approved for future as well and apply retroactively to all providers. If we think the standards are too low now (which I am not saying), then we can always through a policy that starts today amend the existing agreements to increase the SLAs for all.....and then apply that to the future applications Jeff Neuman: I guess what I am saying is that there should not be additional barriers to entry in the future that do not exist today. Ashley Roberts: Jonathan, if we think the standards in the current RA are insufficient then that is a different conversation. I believe that topic comes under the remit of WT4 (please correcct me if I'm wrong).. All we are talking about is at what stage and how many times we evaluate whether the RSP meets the required standards (whether they be the current standards or some otherwise agreed standards). Cheryl Langdon-Orr (CLO): indeed it does not Jonathan, and an issue to be delt with, no doubt... but it's an issue not a new issue with any proposed pre approval, what is to me an opportunity is to possibly explore and enact mitigation or risk management of heading to a failure point, to be tethered to any such recommendations, and that also could help avoid the same risk in existing standards... Cheryl Langdon-Orr (CLO): yes Ashley far more clearly said... sorry 🙏 not fully operational atm VANDA SCARTEZINI: Ok got it Ashley. tks Kurt Pritz: I think #4 is kind of irrelevant. If an RSP bears costs associated with its certification, those costs have to be passed on to registry operators somehow, either through a one-time charge or some rate. I think it is up to the RSP what they want to charge and then up to their customers if they want to pay that charge Jeff Neuman: Kurt - I disagree. This is costs to pay ICANN. Not costs paid by Registry to RSP Cheryl Langdon-Orr (CLO): Staff can we make sure we capture this standards issue, chat extracts etc., and send it to our WT4 Kurt Pritz: @ Jeff - lemme think about that. Maybe the Proposal should be edited a little. Alan Greenberg: @Kurt, if testing is done ahead of time, there are no applicants at that point, only RSPs. If an RSP does not end up being used by any applicants, RSP is only entitty to bear costs. Jeff Neuman:ICANN collected approx $61,667 from each application (paid for by Registry Operators) to pay for evaluations. A substantial portion of that was paid for technical evaluation. That can be eliminated from the Registry Operator's application for the TLD with a pre-approval program Kurt Pritz:@Alan - but it passes those costs along at some point. If an RSP makes an initial investment, it has to recoup that investment Jeff Neuman:It can then charge RSPs to get "pre-approved" one time. Jeff Neuman:@Kurt - There is a big difference to pass through an evaluation cost incurred once divided by all its customers, then to be charged that evaluation costs 300 times (in the case of some RSPs) and pass those on to the ROs Emily Barabas:@Cheryl, notes, chat transcripts, and recordings for this call will be available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di… . Once all documents are posted, we can share this link with WT4. Jeff Neuman:For example, if RSP Approval costs $50,000 (hypothetically), then dividing that one time charge amongst 300 registry operators is much different than passing through $50,000 to each of its ROs to be evaluated 300 times. Cheryl Langdon-Orr (CLO):thanks Emily, I don't want any nexus points overlooked... VANDA SCARTEZINI:donna's points in the doc cover up the point Kurt Pritz:@Jeff : Won't the market deal with that?

1 0

Recording, Attendance, AC recording, AC Chat for New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue, 16 May 2017
by Julie Bisland May 16, 2017

May 16, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The AC recording and AC Chat are listed below for the New gTLD Subsequent Procedures Sub Team � Track 1 � Overall Process/Support/Outreach Issue held on Tuesday, 16 May 2017 at 15:00 UTC. Adobe Connect recording (audio and visual): https://participate.icann.org/p6vf53hxy56/<https://participate.icann.org/p6vf53hxy56/?OWASP_CSRFTOKEN=2b0728a855708eb5…> The recordings of the calls are posted on the GNSO Master Calendar page: 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 Agenda Wiki page: https://community.icann.org/x/EtTRAw Thank you. Kind regards, Julie ------------------------------- Adobe Connect chat transcript for 16 May 2017 Julie Bisland:Welcome to the New gTLD Subsequent Procedures Sub Team � Track 1 - Overall Process/Support/Outreach Issue on Tuesday, 16 May 2017 at 15:00 UTC. Julie Bisland:Agenda Wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Sara Bockey:Much better! Ashley Roberts:for the record, I am on the call (I see I am listed as having sent apologies). Julie Bisland:I'll correct that, Ashley, thank you. Ashley Roberts:thanks VANDA SCARTEZINI:sorry to be little late Alan Greenberg:JOnathan fading... Jeff Neuman:Hard to hear Jonathan Jeff Neuman:Is there anyone that can present the RySG position on this call? Jonathan Robinson (Afilias):Correct. RySG group is scheduled to meet tomorrow Donna Austin, Neustar:@Jeff, I can more or less Cheryl Langdon-Orr (CLO):here now Jeff Neuman:@Donna, that would be great Donna Austin, Neustar:but as Sara said there is a call of the RySG group tomorrow Christa Taylor:last slide - May 30th Christa Taylor:20:00 UTC Julie Bisland:The next New gTLD Subsequent Procedures Sub Team � Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 30 May 2017 at 20:00 UTC Christa Taylor:https://participate.icann.org/newgtldsubteams/?launcher=false&discla… Cheryl Langdon-Orr (CLO):good point made by Jim Cheryl Langdon-Orr (CLO):indeed Donna we need more info here Jonathan Robinson (Afilias):@Crista - Julie Hedlund's notes on the RHS shoudl be a helpful aide memoir to updating the document after this meeting Jonathan Robinson (Afilias):Sorry Christa Christa Taylor:thanks Jonathan Steve Chan:WT2 had asked questions about the EBERO in relation to registrant protections. Here is the response from GDD. Steve Chan:Section 6 of Specification 10 of the Registry Agreement for new gTLDs provides emergency thresholds for the 5 critical registry functions. Per the Registry Agreement, reaching any one of these thresholds could trigger an EBERO event. Steve Chan:ICANN monitors registries� performance of these critical registry functions, and regularly engages with Registry Operators and Registry Service Providers when service outages occur. Not all services outages reach emergency thresholds. If emergency thresholds are reached, ICANN evaluates each individual case and make decisions regarding whether to trigger an EBERO event based on the unique circumstances. Steve Chan:Since the launch of the New gTLD program, an SLA has reached or exceeded the emergency threshold 27 times. However, no EBERO events have been declared to date. In each of these 27 cases, ICANN technical teams were already working with the registry before the threshold was reached. In many of the cases, the TLD had no registrations. In the cases in which there were registrations, ICANN considered the EBERO option. However, ICANN determined that it would have less of a security and stability impact to assist the RSP through resolution rather than activating an EBERO event. Ashley Roberts:slides are here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste… Jessica Hooper (Verisign):Agree. This could lead to a race to the bottom by setting minimum standards rather than having providers strive for excellence in service. (third bullet point) Jeff Neuman:@Jessica - How is setting SLAs in the agreements now any different than setting them in a pre-approval process? Jeff Neuman:I am not sure why this would become a race to the bottom Jeff Neuman:Can someone clarify that Jeff Neuman:sorry, have a noisy printer going off now and cant speak :) Alan Greenberg:Given how many people on this call, pretty quiet group. VANDA SCARTEZINI:guess burden should be more clearly expressed. VANDA SCARTEZINI:@alan -I am in the airport, better be mute... quite a noise Kurt Pritz:@ Jeff. SLAs are sort of backward looking. Some registries will cut costs until there is a failure. Then it is too late. A pre-approved RSP might have forward-looking criteria that are intended to avoid failures such as statistical process controls and new threat identification and remediation. Jeff Neuman:@kurt - then this is a problem with existing registries and RSPs already. Its not something that is new. Nor is it something that would be worse with a Pre-approval process. Donna Austin, Neustar:@ Trang: we haven't decided anything yet. Jeff Neuman:@Donna - correct. No decisions yet, but the trend has been towards a "pre-approval" process prior to the applications being submitted for TLDs. It would be voluntary. VANDA SCARTEZINI:@kurt, looks you have a point - agree with you comment Jonathan Robinson (Afilias):Pre-approval to meet a minimum standard which seems to be demonstrably inadequate doesn't sound like it's moving in the direction of future security and stability VANDA SCARTEZINI:+ 1 Jonathan Trang Nguyen:@Jeff, there were 3 firms providing technical evaluation. Donna Austin, Neustar:@Trang, but PDT is done by the same provider? Sarah L Verisign:@Jeff I thought the RSP accreditation process was intended to make improvements to what we have today rather haan not make something that already exists without it "worse" - I dont see how that plays into security and stablity. Sorry for beeing late to the meeting I only just joinned. Trang Nguyen:@Donna, correct, PDT is performed by 1 vendor. Jeff Neuman:@sarah = Sure, standards can be approved for future as well and apply retroactively to all providers. If we think the standards are too low now (which I am not saying), then we can always through a policy that starts today amend the existing agreements to increase the SLAs for all.....and then apply that to the future applications Christa Taylor:Impro Jeff Neuman:I guess what I am saying is that there should not be additional barriers to entry in the future that do not exist today. Ashley Roberts:Jonathan, if we think the standards in the current RA are insufficient then that is a different conversation. I believe that topic comes under the remit of WT4 (please correcct me if I'm wrong).. All we are talking about is at what stage and how many times we evaluate whether the RSP meets the required standards (whether they be the current standards or some otherwise agreed standards) Cheryl Langdon-Orr (CLO):indeed it does not Jonathan, and an issue to be delt with, no doubt... but it's an issue not a new issue with any proposed pre approval, what is to me an opportunity is to possibly explore and enact mitigation or risk management of heading to a failure point, to be tethered to any such recommendations, and that also could help avoid the same risk in existing standards... Cheryl Langdon-Orr (CLO):yes Ashley far more clearly said... sorry 🙏 not fully operational atm Ashley Roberts::-) VANDA SCARTEZINI:Ok got it Ashley. tks Kurt Pritz:I think #4 is kind of irrelevant. If an RSP bears costs associated with its certification, those costs have to be passed on to registry operators somehow, either through a one-time charge or some rate. I think it is up to the RSP what they want to charge and then up to their customers if they want to pay that charge Jeff Neuman:Kurt - I disagree. This is costs to pay ICANN. Not costs paid by Registry to RSP Cheryl Langdon-Orr (CLO):Staff can we make sure we capture this standards issue, chat extracts etc., and send it to our WT4 Kurt Pritz:@ Jeff - lemme think about that. Maybe the Proposal should be edited a little Alan Greenberg:@Kurt, if testing is done ahead of time, there are no applicants at that point, only RSPs. If an RSP does not end up being used by any applicants, RSP is only entitty to bear costs. Jeff Neuman:ICANN collected approx $61,667 from each application (paid for by Registry Operators) to pay for evaluations. A substantial portion of that was paid for technical evaluation. That can be eliminated from the Registry Operator's application for the TLD with a pre-approval program Kurt Pritz:@Alan - but it passes those costs along at some point. If an RSP makes an initial investment, it has to recoup that investment Jeff Neuman:It can then charge RSPs to get "pre-approved" one time. Jeff Neuman:@Kurt - There is a big difference to pass through an evaluation cost incurred once divided by all its customers, then to be charged that evaluation costs 300 times (in the case of some RSPs) and pass those on to the ROs Emily Barabas:@Cheryl, notes, chat transcripts, and recordings for this call will be available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di… . Once all documents are posted, we can share this link with WT4. Jeff Neuman:For example, if RSP Approval costs $50,000 (hypothetically), then dividing that one time charge amongst 300 registry operators is much different than passing through $50,000 to each of its ROs to be evaluated 300 times. Cheryl Langdon-Orr (CLO):thanks Emily, I don't want any nexus points overlooked... VANDA SCARTEZINI:donna's points in the doc cover up the point Jeff Neuman:I have to drop. Thanks everyone Kurt Pritz:@Jeff : Won't the market deal with that? Donna Austin, Neustar:What is meant by 'functional areas' in Q7? Donna Austin, Neustar:thanks Julie Bisland:The next New gTLD Subsequent Procedures Sub Team � Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 30 May 2017 at 20:00 UTC Julie Hedlund:@Jim: Yes, staff will include the link to the document in the notes. Cheryl Langdon-Orr (CLO):thanks everyone good call, talk again soon... bye for now Jonathan Robinson (Afilias):@staff. PLease can I be added to this / relevant mailing list/s. Thank-you Alan Greenberg:Thanks all. Donna Austin, Neustar:thanks Christa Sara Bockey:Thanks all!!! Jonathan Robinson (Afilias):Thank-you Christa Ashley Roberts:thanks Katrin Ohlmer, DOTZON:thanks and bye, everybody. Trang Nguyen:Thanks, all! Bye! VANDA SCARTEZINI:thnaks to all Phil Buckingham:.thank you Christa Phil Buckingham:thank you Christa

1 0

Agenda - Work Track 1 for Tuesday, May 16, 2017
by Christa Taylor May 15, 2017

May 15, 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, 16 May 2017 at 15:00 UTC. The proposed agenda is as follows: 1. Welcome & Agenda Overview 2. SOIs 3. RSP Program 4. AOB The RSP document we'll be referencing can be viewed at https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWho HNw/edit Cheers, Christa Christa Taylor, B. Tech, CPA, CMA, MBA Mobile: 604-961-9460 Skype: christat13 <mailto:christa@dottba.com> christa(a)dottba.com <http://www.dottba.com/> www.dottba.com

1 0