- Gnso-newgtld-wg - lists.icann.org

Recordings, attendance & chat / New gTLD Subsequent Procedures Working Group call / Monday, 03 June 2019 at 20:00 UTC
by Julie Bisland June 4, 2019

June 4, 2019

Dear All, Please find the attendance attached to this email, and links to the audio recording, Zoom recording (audio, visual, rough transcript) and Zoom chat below for the New gTLD Subsequent Procedures Working Group call held on Monday, 03 June 2019 at 20:00 UTC. Attendance of the call is posted on the wiki page: https://community.icann.org/x/qIijBg Audio recording: https://icann.zoom.us/recording/play/NeH6rA_fxkWD_xS1UhIM_OPAqFnY8PZ5ciLIRk… Zoom Recording: (includes visual and rough transcript. To access the rough transcript, selecte the Audio Transcript tab): https://icann.zoom.us/recording/play/weB9fvwV9EFmR1FbeVw6cBgI5PLnZY13x1CLnA… Zoom Chat: https://icann.zoom.us/recording/download/gb-KAWx2u4J7dAv5UwVsEGk1ePbIZeNBLQ… The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg/ Main wiki page for the working group: https://community.icann.org/x/RgV1Aw[community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> Thank you. Kind regards, Julie

1 0

Fwd: ICANN Board consideration of .amazon application
by lists＠christopherwilkinson.eu June 3, 2019

June 3, 2019

> > Subject : ICANN Board consideration of .amazon application. 15 May 2019, (published preliminary report 26 May 2019.) > https://www.icann.org/resources/board-material/prelim-report-2019-05-15-en <https://www.icann.org/resources/board-material/prelim-report-2019-05-15-en> > The .amazon point is addressed in pages 35-55 ; the relevant Resolution was adopted by 13 Board members with two abstentions. > > In my view, the unresolved impasse between Amazon Inc.·and ACTO derives in large measure from the failure in the 2012 AGB to adequately regulate applications for geographical names. > > In short, as widely reported already elsewhere, the ICANN Board has over-ridden the objections of the countries concerned (the ACTO members) to proceed with the processing of the .amazon application from Amazon Inc., in spite of the reported failure to reach agreement between Amazon Inc.·and ACTO. > > The purpose of this note is primarily to draw the attention of the new gTLD PDP and to WT5, that these issues will have to be addressed before the new gTLD programme can be successfully launched. For future reference, it is absolutely essential that the current PDP and WT5 agree on specific and globally applicable rules for applications for, and eventual delegations of, geographical names. Otherwise, issues arising over the <.amazon> application could very well be repeated across a wide range of future applications, world-wide. > > In the case in point, the Board and several recent comments (CircleID, The Register, Internet Governance Project) have attached weight to the outcome, in July 2017, of an Independent Review Process which supported Amazon Inc.'s application. Hoover, this IRP's proceedings and report were quite questionable in several respects, as I pointed out to the Co-Leads of the PDP and WT5 at the time. > > I attach my note of November 2017 to that effect. > > In conclusion, I must maintain most firmly that whatever conclusions are reached in the .amazon case, with or - apparently without - agreement between Amazon Inc.· and ACTO, this sad story can in no way be taken as a precedent for future applications for geographical names which are presently considered by GNSO to be unprotected and thus eligible for open applications for new gTLDs. > > It is quite essential for the success of the new gTLD programme that the currently very restrictive policy for prior authorisation or non-objection to geographical names be extended to all such applications. > > Regards, > > Christopher Wilkinson > Jávea, 2 June 2019 > > > Attachment: Note to PDP and WT5 Co-Leads of 7 November 2017. > > * * * > > From: cw(a)christopherwilkinson.eu <mailto:cw@christopherwilkinson.eu> [mailto:cw@christopherwilkinson.eu <mailto:cw@christopherwilkinson.eu>] > Sent: Tuesday, November 7, 2017 2:40 PM > To: Martin Sutton < martin(a)brandregistrygroup.org <mailto:martin@brandregistrygroup.org>>; Annebeth B. Lange <annebeth.lange(a)norid.no <mailto:annebeth.lange@norid.no> >; Olga Cavalli <olgacavalli(a)gmail.com <mailto:olgacavalli@gmail.com>>; Christopher Wilkinson < cw(a)christopherwilkinson.eu <mailto:cw@christopherwilkinson.eu>> > Cc: Emily Barabas <emily.barabas(a)icann.org <mailto:emily.barabas@icann.org> >; Julie Hedlund <julie.hedlund(a)icann.org <mailto:julie.hedlund@icann.org>>; Steve Chan <steve.chan(a)icann.org <mailto:steve.chan@icann.org>>; Cheryl Langdon-Orr <langdonorr(a)gmail.com <mailto:langdonorr@gmail.com>>; Jeff Neuman <jeff.neuman(a)comlaude.com <mailto:jeff.neuman@comlaude.com> > > > Subject: .amazon IRP > > Good evening: > > https://www.icann.org/en/system/files/files/irp-amazon-final-declaration-11… <https://www.icann.org/en/system/files/files/irp-amazon-final-declaration-11…> > > Having returned from Abu Dhabi, I have had the opportunity to read the Independent Review Panel Declaration on <dot.amazon> (pp 67). > > This turns out to have been a significant benchmark with respect to several aspects of our forthcoming work of WT5. For instance: > > - it is noticeable that the whole IRP procedure does not recognise, or even refer to, the fact that the Amazon name has been in the public domain for decades, if not centuries, and in any case long before ICANN or Trademark law existed. WT5 should recognise that geographical names are generally already in the public domain and are used to represent the places that people use them for. The very widespread sensitivities about the DNS and most geographical terms arise from the risks, some would say the threats, arising from the commercial monopolization of such names in the DNS. > > - the composition and location of the Panel in this case invites comment. It is hardly plausible for the ICDR and ICANN to accept that an issue, primarily beyond US jurisdiction, should be arbitrated by three US lawyers, based on hearings in Los Angeles. Whatever the principles and rules devised by the PDP and WT5, I doubt that they would enjoy widespread acceptance if eventual future disputes would be subject to such an IRP. > > . the IRP addresses, in exhaustive detail, the internal procure the ICANN Board and its NGPC. But it completely ignores the social, cultural and political dimensions of the issue. Outside the “ICANN bubble” this will appear rather curious, to the point of de-legitimising the underlying ADR policy. > > - The costs of this IRP have been exorbitant, amounting to some $480,000, not including attorneys fees. In the case in point, Amazon (Luxembourg) and ICANN could no doubt afford it, but more generally, if dispute resolution in the policy that PDP and WT5 intend to create is beyond the reach of most geographical communities, then I wonder what we are doing here? > > For most communities, the issue is not <.amazon>, per se, but the precedent. > > The DNS cannot override the historical interests of the general public in names that have been in the public domain, as long as most people can remember, without a clear mechanism whereby their acquired rights will be respected. > Just a few thoughts, that WT5 should be able to deal with in the months to come. > Regards Christopher. > >

2 1

Proposed Agenda - New gTLD Subsequent Procedures PDP WG meeting - Monday, 3 June 2019 at 20:00 UTC
by Steve Chan May 31, 2019

May 31, 2019

Dear WG members, Please find below the proposed agenda for the upcoming call on Monday, 3 June 2019 at 20:00 UTC for 90 minutes: Welcome/Review of the Agenda/Updates to Statements of Interest (SOIs) Review of Summary Documents 2.2.6 Accreditation Programs (e.g., RSP Pre-Approval) - (see - https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsX…) (time-permitting) - 2.3.2 Global Public Interest – (see - https://docs.google.com/document/d/15rwviHM6AYtqDqyB6_5Yij2dTL6iuou8z7A32yz…) AOB Note, in relation to agenda item 2, WG leadership and staff have tried to prepare summary documents for each topic that seeks to help you review some of the background material, consider a high-level summary of what we believe the WG is seeking to accomplish for the topic, a high-level summary of public comment received, and finally, a catch all at the end of each section (e.g., follow-up, parking lot, next steps). As requested, staff is also including a download of the two working documents. Please note that these represent a snapshot and will of course become out of sync as the working documents are updated. If you need a dial out or would like to send an apology for this call, please email gnso-secs(a)icann.org. Best, Steve Steven Chan  Policy Director, GNSO Support ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Mobile: +1.310.339.4410 Office Telephone: +1.310.301.5800 Office Fax: +1.310.823.8649 Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages. Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/

1 0

Source of the number of EBERO incidents as it relates to discussions around the pre-approved RSP program
by Jim Prendergast May 30, 2019

May 30, 2019

During the course of today’s call, Donna asked me for the source of the “close to 40 EBERO triggering incidents” that ICANN had detected in the earlier stages of the new gTLD program. Below are the stats and sources. Turns out it was 32 at the time but staff reported that since they started monitoring this, they had been seeing on average 2 incidents per quarter so the number is probably closer to 40 now. You need to pair this with the revelation from Christine Willett during the same session in Bangkok that during PDT, ICANN “regularly encountered registry operators with issues that had remediation, significant remediation to do.” “We’re not talking about a handful of incidents either.” “Pre-delegation testing, registry service testing continues to regularly find issues with basic registry service delivery that require remediation. And its not just about IDN tables.” As Steve suggested in chat and seconded by Anne and also asked for by Donna during a session on RSP Approval program during the GDD Summit in Bangkok, I too think it would be good to get an update on these statistics from GDD as well as more information on PDT issues mentioned. Would be helpful to inform not only the discussions on the RSP program but also the EBERO as a whole when we get to that part of the deliberations. Both of these combined demonstrate the need to continue a testing program as part of an RSP program. Note that this write up is taken from a document circulated to the RySG RSP working team members which included some of the registry participants in Sub Pro. ICANN Data on the Current Registry Operator’s Systems During the Madrid DNS Symposium / ICANN GDD Summit in May 2017 as well as the ICANN 59 meeting in Johannesburg in June 2017, ICANN provided information about potential SLA violations that took place from 2014 through 2016. On August 31, 2017, ICANN updated that data with the most current set of measurements. The data shared by ICANN shows that there have been 32 cases where a gTLD reached one of the emergency thresholds: * 16 out of 32 cases were triggered by perceived failures in the DNS/DNSSEC services, * 16 out of 32 cases were triggered by failures in the RDDS service. Of the 32 cases, 10 occurred prior to the TLD’s Sunrise period, 8 during Sunrise, 5 before general availability, and 9 during general availability. 11 RSPs, 26 gTLDs and a total of 211.7k active names, were involved in the 32 cases. The root cause, which ICANN began tracking in 2015, can be broken down as follows: RDDS: ▪ 3 were due to IPv6 transport failure; ▪ 1 was caused by a broken chain of trust in DNSSEC; and ▪ 1 was due to the web WHOIS service not responding. ▪ For 11 of these RDDS cases, ICANN does not know the root cause as the cases occurred before ICANN began documenting the causes of each incident. DNS/DNSSEC: ▪ 5 cases exhibited issues in which either the DNS servers were not responding or if they were responding, they were returning a malformed DNSSEC response where the NSEC3 records were not included; ▪ 2 cases were caused by expired signatures followed by breakage of the chain of trust in DNSSEC; ▪ 2 cases arose when there was no response from the DNS servers (apparently a routing issue); ▪ 1 case of expired DNSSEC signatures; ▪ 1 break in the chain of trust in DNSSEC; and ▪ 1 case where there were no DS records when requesting delegation from IANA. ▪ 4 of these cases occurred in 2014, for which ICANN does not know the root cause. Links Johannesburg discussion on RSP - https://icann59johannesburg2017.sched.com/event/B49H/gnso-registries-stakeh… Madrid – video of presentation - https://www.youtube.com/watch?v=VA_fCYHAQVo&list=PLQziMT9GXafWAdedvzQYmqvW3… Slides - https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf RSP discussion at GDD in Bangkok - https://icann.zoom.us/recording/play/1TfcynOARSGE5HPeicn5Bx36vZZsW2jXp5YTmT… Jim Prendergast The Galway Strategy Group +1 202 285 3699 @jimpren

2 1

Please register to get ready for ICANN65 Prep Week
by Julie Hedlund May 29, 2019

May 29, 2019

Dear SubPro PDP WG members, As per the announcement below, please register and submit your questions or comments regarding any of the subject matters covered by the 8 webinars taking place during Prep Week, by Friday 7 June 2019 via this form: https://docs.google.com/forms/d/18IzOJlVHNwXoViSKXZrjM-iW1BZqinyXYoV_R-1rGf… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_…> Tuesday, 11 June 16:00 UTC | ICANN Org Multistakeholder Strategy and Strategic Initiatives (MSSI) Update 23:00 UTC | ICANN65 Security Update Wednesday, 12 June 16:00 UTC | ICANN Org Global Domains Division (GDD) – Community Briefing on Raising Awareness about Registrant Issues and Challenges 23:00 UTC | Update on Evolving ICANN's Multistakeholder Model of Governance Thursday, 13 June 16:00 UTC | ICANN Org Policy Team: Policy Updates 23:00 UTC | Nominating Committee Review Implementation Working Group Update Monday, 17 June 16:00 UTC | ICANN Org FY21-25 Operating & Financial Plan and Open Data Program Updates 21:00 UTC | Generic Names Supporting Organization (GNSO) Policy Update Full announcement can be found here: https://www.icann.org/news/announcement-2019-05-23-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_ann…> Kind regards, Julie Julie Hedlund, Policy Director

1 0

Recordings, attendance & chat / New gTLD Subsequent Procedures Working Group call on Tuesday, 28 May 2019 at 15:00 UTC
by Michelle DeSmyter May 29, 2019

May 29, 2019

Dear All, Please find the attendance attached to this email, and links to the audio recording, Zoom recording (audio, visual, rough transcript) and Zoom chat below for the New gTLD Subsequent Procedures Working Group call held on Tuesday, 28 May 2019 at 15:00 UTC. Attendance of the call is posted on the wiki page: https://community.icann.org/x/-xVIBg Audio recording: https://gnso.icann.org/sites/default/files/policy/2019/audio/audio-new-gtld… Zoom Recording: (includes visual and rough transcript. To access the rough transcript, selecte the Audio Transcript tab) : https://icann.zoom.us/recording/share/IMBrkk03Da_52QwPKtpOGmhTq5bMgd4QZgcyY… Zoom Chat: https://icann.zoom.us/recording/download/Ax_oQUsxBAFv_pRpNRNgnJ3wWyuU8nSSNE… The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg/ Main wiki page for the working group: https://community.icann.org/x/RgV1Aw[community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> Thank you. Kind regards, Michelle

1 0

Fwd: [council] Root Zone Scaling Myths
by Rubens Kuhl May 28, 2019

May 28, 2019

Hi @ll. During the call today some old myths regarding root zone scaling have resurfaced; I'm resending here messages I've sent to WT4 and to the Council in 2017, containing research I did on why those myths started and what are the actual technical limitations. Rubens > > > From: <council-bounces(a)gnso.icann.org <mailto:council-bounces@gnso.icann.org>> on behalf of Rubens Kuhl <rubensk(a)nic.br <mailto:rubensk@nic.br>> > Date: Monday 26 June 2017 at 11:53 > To: "GNSO Council List (council(a)gnso.icann.org <mailto:council@gnso.icann.org>) (council(a)gnso.icann.org <mailto:council@gnso.icann.org>)" <council(a)gnso.icann.org <mailto:council@gnso.icann.org>> > Subject: [council] Fwd: Root Zone Scaling Myths > > >> > Just to answer a question from James Bladel during the part of the GNSO Working Session I couldn't attend due to conflicting schedule, it was determined at 2009 that the root server system could handle with the then in-use software codebase 100,000 TLDs without performance impacts. Even at that point, one of the DNS software codebases in use by root servers could go up to a million TLDs. Since then, DNS software has greatly improved, memory sizes are now much bigger, computers are much faster; there are TLD zone architectures that current handle 4 million entries and could easily scale up to 10 million without any significant architectural change, so the same evaluation done today would likely give 1 million with not that optimised software or 10+ million, all with open-source, readily-available solutions. > > I've recently sent to one the Subsequent Procedures work tracks an e-mail describing some "archeology" on this theme, please see below. > > > Rubens > > > >> >> From: Rubens Kuhl <rubensk(a)nic.br <mailto:rubensk@nic.br>> >> Subject: [Gnso-newgtld-wg-wt4] Root Zone Scaling Myths >> Date: June 18, 2017 at 4:40:49 AM GMT+2 >> To: gnso-newgtld-wg-wt4(a)icann.org <mailto:gnso-newgtld-wg-wt4@icann.org> >> >> >> While most current root zone scaling information is available in the CDAR report (https://www.icann.org/en/system/files/files/cdar-root-stability-final-08mar… <https://www.icann.org/en/system/files/files/cdar-root-stability-final-08mar…>), I did some research regarding root zone scaling, and found that the most comprehensive source to understand is this ICANN report of 2012: >> http://newgtlds.icann.org/en/about/historical-documentation/root-scaling-27… <http://newgtlds.icann.org/en/about/historical-documentation/root-scaling-27…> >> >> Besides all its interesting content, they compiled a list of previous root zone scaling studies that I reproduce here, changing only the link style and updating the links to their current publishing points: >> >> >> >> >> "Appendix A — Previous Studies and Analyses >> >> A number of studies and analyses have been compiled on the topic of scaling of the DNS Root Zone in the last three years: >> >> • Root Zone Augmentation and Impact Analysis(https://www.icann.org/en/system/files/files/root-zone-augementatio… <https://www.icann.org/en/system/files/files/root-zone-augementation-analysi…>) — This study, also known as the “L-Root Study,” examined the impacts of multifaceted growth of the size of the Root Zone on the performance of “l.root-servers.net <http://l.root-servers.net/>,” the root server that is managed by ICANN. This analysis considered the implications of IPv6 addresses, DNSSEC, as well as new TLDs in a laboratory simulation. The work was conducted by the independent DNS Operations and Research Center (DNS-OARC). This study was published in September 2009, and its conclusions include that root zone servers’ requirements for memory grow linearly with the number of top-level domains, that the then-deployed software was capable of handling at least 100,000 top-level domains before there was potential degradation in response times. Other software in use had higher thresholds (i.e. over a million TLDs) before the size of the root zone became a factor. >> >> • Report on the Impact on the DNS Root System of Increasing the Size and Volatility of the Root Zone(https://www.icann.org/en/system/files/files/root-scaling-study-report-… <https://www.icann.org/en/system/files/files/root-scaling-study-report-31aug…>) — This report was developed by a specially convened “Root Server Scaling Team” (RSST), comprised of experts from the RSSAC, SSAC as well as experts from outside the ICANN community. >> >> • Summary of the Impact of Root Zone Scaling(https://archive.icann.org/en/topics/new-gtlds/summary-of-impact-roo… <https://archive.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-s…>) — An analysis of issues relating to the impact of Root Zone Scaling was prepared by ICANN and published the document in October 2010. This document considers the findings of the DNS-OARC and RSST reports, and the various root scaling events to date. It identifies the impacts from IPv6 deployment, TLD growth, DNSSEC deployment and other factors, and concludes the maximum growth to the Root Zone caused by the New gTLD Program is unlikely to cause any disruption. >> >> • Report of the Security and Stability Advisory Committee on Root Scaling(https://www.icann.org/en/system/files/files/sac-046-en.pdf <https://www.icann.org/en/system/files/files/sac-046-en.pdf>) — ICANN’s Security and Stability Advisory Committee reviewed the original research questions relating to Root Zone Scaling, and provided recommendations relating to processes to handle the increase in the number of top-level domains. >> >> • Explanatory memorandum on Root Zone Scaling(https://archive.icann.org/en/topics/new-gtlds/root-zone-scaling-15a… <https://archive.icann.org/en/topics/new-gtlds/root-zone-scaling-15apr11-en.…>) — As part of a number of briefing papers associated with the New gTLD Program following dialogue between the ICANN Board and the Governmental Advisory Committee, ICANN published a memorandum concerning Root Scaling in April 2011. >> >> • Board response to the GAC on Root Zone Scaling(https://archive.icann.org/en/topics/new-gtlds/root-scaling-30may11-… <https://archive.icann.org/en/topics/new-gtlds/root-scaling-30may11-en.pdf>) — ICANN published an additional response to the issues raised on dialogue between the ICANN Board and the Governmental Advisory Committee, by providing further detail on how ICANN undertakes to address the ICANN community’s and the GAC’s concerns regarding root scaling. This response was published in May 2011." >> >> >> >> Besides those documents, the other interesting documents on this are: >> Anticipated delegation rate model: http://www.icann.org/en/topics/new-gtlds/anticipated-delegation-rate-model-… <http://www.icann.org/en/topics/new-gtlds/anticipated-delegation-rate-model-…> >> 2010 RSSAC e-mail to Board regarding scaling: https://www.icann.org/en/system/files/files/murai-to-board-25nov10-en.pdf <https://www.icann.org/en/system/files/files/murai-to-board-25nov10-en.pdf> >> SAC 042 (https://www.icann.org/en/system/files/files/sac-042-en.pdf <https://www.icann.org/en/system/files/files/sac-042-en.pdf>) (later superseded by SAC 046) >> >> In short, the anticipated delegation rate model estimated the maximum *evaluation* throughput to be near a 1000 per year, and other ACs responded that it wouldn't be a problem to be delegated. They have not said that the system had a 1000/year limit, a myth that started only when the number of applications (near 2000) exceeded the high estimate of applications (a thousand), that discussion went stray and landed at that being a limit. >> >> Since those studies, processing power, memory sizes, DNS software design and available bandwidth all greatly increased, so even figures that were determined at that point (like the 100,000 TLDs root zone size) are outdated, although still limited by latency of the global Internet (which is mainly determined by the speed of light in optical fiber). The root zone now features DNSSEC and IPv6 to most TLDs, so something that was an unknown at that time is now a baseline, the root zone management system has been completely rewritten, and root server monitoring instrumentation greatly improved (see RSSAC 002, https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06j… <https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06j…>) >> >> But, we didn't get an RSSAC response to our CC2 question on the CDAR report, nor they mentioned this in their comments to the CDAR report which were mostly clarifying questions. I believe we could ask them to clarify that and clear the fog in this topic. >> >> >> Rubens >> >> >> >> >> >> >> _______________________________________________ >> Gnso-newgtld-wg-wt4 mailing list >> Gnso-newgtld-wg-wt4(a)icann.org <mailto:Gnso-newgtld-wg-wt4@icann.org> >> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4 <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4> > >

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 28 May 2019
by Julie Hedlund May 28, 2019

May 28, 2019

Dear Working Group members, Please see below the notes from the meeting today, 28 May 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-05-28+New+gTLD+Subsequent+Pr…. Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsX…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to provide an update on EBERO-triggering events. ACTION ITEM 2: Develop a definition of an RSP especially in terms of RST. ACTION ITEM 3: Staff to circulate the meeting schedule for SubPro at ICANN65 once the schedule is published. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsX…) a. 2.2.5 Application Submission Limits Policy Goals / What the WG is Seeking to Accomplish * If limits are set, there must be a clear rationale for establishing these limits. * It must be operationally feasible to implement any policy that is developed. In this case, it must be feasible to enforce any limits that are set. * If any limits are imposed on the overall number of applications or the number of applications a particular entity may submit, the policy must be fair to all applicants. * Policy should support competition and consumer choice. Public comment summary High-level Agreements * Support from most commenters that no limits should be placed in the overall number of applications or the number of applications particular entity may submit. Outstanding Items - New Ideas/Concerns/Divergence * Public Interest Community/Christopher Wilkinson: Divergence - Place limits on the number of applications per company and in cooperation with other companies * Public Interest Community: New Idea - ICANN should allow no more than 2 dozen applications for each company, including its parent company, subsidiaries, and affiliates to increase fairness and allow for adequate oversight and public review. Discussion: -- Shouldn’t there be an additional policy goal of fairness? -- Question to OCTO/RSSAC/SSAC: Answer was that there was no upper limit on the number of TLDs that could be in the root. There is a scale for TLDs to be added to the root. Very high scale. The primary concern raised by the SSAC and RSSAC is more about rate of change rather than an upper limit. Rate of change to the root zone, to be more specific. -- Concerns about fairness to the Global South -- one of the policy goals should be application limits early on to enable applicants from the Global South to apply. -- Processing time and large numbers of applicants could prevent others from applying. -- Not allowing large applicants to dominate, what the community can process, protecting the Global South. -- Concerns about free speech rights if there are limits. -- Not all interests should be assumed to be conflicts of interest. -- How do we objectively get to a number? -- A limit of 24 multiplied by large applicants would give a large number. -- A limit should be based on facts. -- Difficult to have this conversation in isolation. If we have one more round then it is difficult to have a limit. If we have 5 or more rounds then it might make sense if they open on a schedule (say after 6 or so months). -- Go on the assumption that there will be multiple rounds and some type of formula for determining when to open the next round. -- Global South applications and/or Middle applicants and/or applications which intend to benefit under-served communities are better supported through prioritization, Applicant Support, partnerships, rather than limiting application numbers. -- Applicant freedom of expression is a guiding principle for the program. There is an overarching concern about the public interest. Could there be a dedicated unit in ICANN for a different type of application so that these types of applications get processed more quickly? This would fall into the topic of prioritization. -- There is a policy recommendation from this WG that applications would be prioritized. -- ICANN Org: there is a rate of delegation limit of 1000 a year. So that also limits processing. But the SSAC now says this is a sliding scale. b. 2.2.6 Accreditation Programs (e.g., RSP Pre-Approval) Policy Goals / What the WG is Seeking to Accomplish * Where operationally feasible and appropriate, efficiencies should be realized in the technical evaluation of registry services without compromising the goals of the program, such as diversity, competition, and security of the DNS. * Where a single RSP provides registry services for multiple TLD applications, duplicative evaluation and testing should be reduced. * To the extent that there is testing as part of the Pre-Approval Program, Testing must be consistent, objective and to the extent possible, predictable. * Program should avoid processes and structures that show undue preference to incumbent RSPs versus prospective RSPs and should be equally available to both. Note from Jeff: This was a comment from Google, and supported in comments by Mark Monitor and Lemarit, but seems like one that had support when discussed previously. Should this be here? Discussion: -- Comments from Valideus would support the 4th bullet -- equal treatment of all. -- If this is a pre-approval program, then both incumbents and new entrants would have to go through the program and treated equally. -- Seemed to be general support that this would be a voluntary program. -- Don’t want an RSP that is not currently an incumbent to complain that they are disadvantaged because incumbent RSPs are already following ICANN’s procedures. We don’t want to cater to the lowest common denominator. There needs to be a strong basis in security and stability. -- Seems to be agreement that our structures and processes should treat all RSPs equitably (4th bullet in Policy Goals). -- Note on referrals to other sections: “To the extent that the Working Group adopts the notion that all RSPs are evaluated in the same manner using the same processes (except the Pre-approval process happens earlier in time, then all evaluation requirements should be referred to applicable sections (eg., 2.7.6 Security & Stability and 2.7.7 Applicant Reviews)” High-Level Agreements: -- Support for use of the term “Pre-Approval Program”. -- Support for process having technical requirements. -- Some commenters also supported the consideration of anbut will also consider the RSP’s overall breadth of registry operator support, while others believed that the measurement of overall breadth of registry operator support would be difficult to assess. -- Support expressed for the idea that the RSP pre-approval process should be a voluntary program and the existence of the process will not preclude an applicant from providing its own registry services or providing registry services to other New gTLD Registry Operators. The Business Constituency was the only one to recommend that the program be mandatory. -- Support for self-funding on a cost-recovery basis. -- Some support for the idea that if required, the requirement should be extended to RSPs that are not Pre-Approved as well. -- ICANN Org Seeks confirmation that only difference between a pre-approved RSP and one that is approved during application evaluation is the timing of when the approval takes place; All criteria for evaluation and Registry Services Testing (RST) are the same. Comment from Jeff: Does this have high level agreement? If so, keep here. 3. ICANN65: -- Sessions scheduled on Day 1 (Monday) -- 2 sessions scheduled for WT5 in the morning. Then for the WG there are sessions split between Day 1 and Day 2. -- Staff will circulate the schedule of SubPro meetings at ICANN65 once the schedule is published.

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG meeting - Tuesday, 28 May 2019 at 15:00 UTC
by Julie Hedlund May 28, 2019

May 28, 2019

Dear WG members, Please find below the proposed agenda for the upcoming call TODAY, Tuesday, 28 May 2019 at 15:00 UTC for 90 minutes: 1. Welcome/Review of the Agenda/Updates to Statements of Interest (SOIs) 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsX…) * 2.2.5 Application Submission Limits * 2.2.6 Accreditation Programs (e.g., RSP Pre-Approval) 3. AOB Note, in relation to agenda item 2, WG leadership and staff have tried to prepare summary documents for each topic that seeks to help you review some of the background material, consider a high-level summary of what we believe the WG is seeking to accomplish for the topic, a high-level summary of public comment received, and finally, a catch all at the end of each section (e.g., follow-up, parking lot, next steps). If you need a dial out or would like to send an apology for this call, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Julie Julie Hedlund, Policy Director

1 0

Re: [Gnso-newgtld-wg] [Ext] RE: Proposed Agenda - New gTLD Subsequent Procedures PDP WG meeting - Monday, 21 May 2019 at 03:00 UTC
by Steve Chan May 21, 2019

May 21, 2019

Dear Anne, All, Apologies, meant to respond on Friday and it slipped my mind. Responses inline. Best, Steve From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Friday, May 17, 2019 at 2:49 PM To: Steve Chan <steve.chan(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: Proposed Agenda - New gTLD Subsequent Procedures PDP WG meeting - Monday, 21 May 2019 at 03:00 UTC Thanks Steve – It would be extremely helpful going forward if Staff could provide links to the appropriate Subgroup A, B, and C chart sections as applicable to the matters being discussed at this time by the full Working Group. In other words, in the “Background Documentation” section, could we please have the links to the relevant Subgroup A, B, and C work in addition to the Community Comment 1 and the Initial Report? (We do not want to lose the benefit of all the work done by the Subgroups in this regard.) SC: Staff has added the link to the Sub Group A public comment review document for each of the sections where a summary has been produced and we will carry this practice forward. In connection with 2.2.5 Application Limits (and based on the Subgroup Chart), I believe we need to include in the Summary the fact that two comments reflected DIVERGENCE. Those would be the comments of Christopher Wilkinson noted in the SubGroup document and the comments of the Public Interest Community. The underlying Subgroup document for this issue shows two Divergent commenters. The first is Christopher Wilkinson. The second is the Public Interest Community as correctly noted in the current Summary Document. Comments of the “Public Interest Community” commenter that appear in our SubGroup chart are more properly characterized as Divergence than “Concerns”. As you have noted, this commenter is in fact arguing for strict limits of no more than “2 dozen applications for each company, including its parent company, subsidiaries, and affiliates”. Christopher’s comments are properly noted in the Subgroup Document as “Divergence”. SC: Staff has added a separate line to capture the Divergence from the Public Interest Community and Christopher Wilkinson. The additional element from the Public Interest Community, with a numerical example supporting the strict limit, is still captured as a New Idea, which should be consistent with the public comment analysis performed by Sub Group A. Separately, I see that the Summary Document has stricken the Predictability Framework section and summary public comments in favor of a new “Working Document”. Is that the document that we, as a smaller group convened on the Predictability Framework, will be working from? Can you please give the full WG a general summary as to how this new document differs from the Summary previously provided to the full Working Group? I am pasting the link to the “New Working Document” for the Predictability Framework below. SC: If you will recall, PDP leadership introduced the repackaged document on the 6 May WG meeting that you linked to below, to try and better support the discussions around the Predictability Framework. As Jeff pointed out at that time, substantively, the document does not contain new information, but is simply organized in a different manner. In order to not have duplicative documentation for the Predictability Framework, this newer version is intended to serve as a replacement. As for whether that will serve as the document the small group works from, I would imagine that would at least serve as the basis to begin discussions, but it is ultimately up to PDP leadership and the small team to determine what documentation it will use, as well as eventually produce for review by the full WG. https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecG… [docs.google.com] Thank you, Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Steve Chan Sent: Friday, May 17, 2019 10:55 AM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG meeting - Monday, 21 May 2019 at 03:00 UTC Dear WG members, Please find below the proposed agenda for the upcoming call on Tuesday, 21 May 2019 at 03:00 UTC for 90 minutes: Welcome/Review of the Agenda/Updates to Statements of Interest (SOIs) Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsX… [docs.google.com] 2.2.4 TLD Types 2.2.5 Application Submission Limits (time permitting) AOB -- ICANN 65 Planning Note, in relation to agenda item 2, WG leadership and staff have tried to prepare summary documents for each topic that seeks to help you review some of the background material, consider a high-level summary of what we believe the WG is seeking to accomplish for the topic, a high-level summary of public comment received, and finally, a catch all at the end of each section (e.g., follow-up, parking lot, next steps). If you need a dial out or would like to send an apology for this call, please email gnso-secs(a)icann.org. Best, Steve Steven Chan  Policy Director, GNSO Support ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Mobile: +1.310.339.4410 Office Telephone: +1.310.301.5800 Office Fax: +1.310.823.8649 Find out more about the GNSO by taking our interactive courses [learn.icann.org] and visiting the GNSO Newcomer pages [gnso.icann.org] Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO [twitter.com] Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ [facebook.com] http://gnso.icann.org/en/ [gnso.icann.org] This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.

2 1