Dear Working Group members, Please see below the notes from the meeting on 18 November 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-11-18+New+gTLD+Subsequent+Pro.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: Contractual Compliance: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66X... ACTION ITEM 1: Continue discussion on the list of the following question: Is there evidence of “arbitrary and abusive pricing for premium domains targeting trademarks; use of reserved names to circumvent Sunrise; and operating launch programs that differed materially from what was approved by ICANN.” If yes, how should these issues be addressed? Notes: 1. Welcome and Updates to Statements of Interest: -- Re SOI, Anne Aikman-Scalese has been appointed as CSG voting rep to the Auction Proceeds CCWG. 2. Review of summary documents: a. Registry System Testing: https://docs.google.com/document/d/1RGB1DYMZAb62izAV0Uxo9pmEskYzZ4SGSa4JqWQq... (page 2) Policy Goals: * The following recommendations from 2007 remain applicable: * Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out.” * Recommendation 8: “Applicants must be able to demonstrate their financial and organisational operational capability.” High-level Agreements: -- Remove a better part or all self-certification assessments. Outstanding Items: Remove a better part or all self-certification assessments. -- ICANN Org: New Idea - It should be noted that some self-certifications, such as those related to load testing, should be retained as operational testing of load would be disruptive and not favorable, and it is important to do load testing to ensure that the infrastructure can handle expected traffic. -- At least one RySG member: New Idea - Recommendation should stipulate that removal of the self-certification assessment applies to established RO's who exhibit the exact same business rules across TLDs. There is opposition within RySG for that viewpoint, believing it to be anti-competitive. Registry System Testing (RST) should be split between overall registry service provider (RSP) matters and specific application/TLD testing. -- BRG: Agreement. -- Consider whether this rises to the level of a preliminary recommendation. Rely on Service Level Agreement (SLA) monitoring for most if not all overall registry service provider testing. -- BRG/At least one RySG member: Agreement. -- Some RySG: Concerns/New Idea. -- ICANN Org: Concern - The Initial Report indicates that this preliminary recommendation was based on ICANN Org’s response to a PDP Working Group request. ICANN org would like to clarify that our recommendation was that some tests could be removed from Registry System Testing in favor of ongoing monitoring of TLD operations against a broader set of existing contractual technical requirements. -- SSAC: Divergence - In general, it is preferable to discover major failures before delegation instead of after the TLD is in operation. Past performance is not a guarantee of future performance. Discussion: -- How can we merge/reconcile this views? We need to drill down on the ones ICANN Org said could be eliminated. There isn’t a consensus to remove those other aspects, but we should talk about whether pre-delegation testing needs to be done on every top-level domain. -- What would be the utility of testing pre-approved RSPs? Do different TLDs react in different ways to the sane system?
 Same system (although hoping the system is sane). -- If the only difference between pre-approval and regular approval is the timing, then it shouldn’t be an issue. -- I don’t think we want to eliminate any parts of PDT that discovered these issues prior to delegation -- But as to the point of timing, earlier testing can then be a boon. -- Wouldn't the pre-approval process essentially involve the pre-delegation testing? So it wouldn't need to be done time after time
. -- There would still be a need for pre-delegation testing lite—to make sure the name servers are correctly configured. But it would be so much less burdensome than the complete PDT from last time. -- Drill down into the elements that ICANN Org thought could be removed and get agreement on those. -- If we are moving toward removing pieces from the previous round make sure we aren’t removing anything that may have caught deficiencies. Limit Internationalized Domain Name (IDN) testing to specific TLD policies; do not perform an IDN table review in Registry System Testing. -- BRG/Neustar: Agreement -- RySG: Agreement/Concerns. -- ICANN Org: Concern - The Initial Report indicates that this preliminary recommendation was based on ICANN Org’s response to the PDP Working Group request. The ICANN Org recommendation suggests removing IDN table review from PDT if using tables pre-vetted by the community, or if using tables not pre-vetted that they be reviewed prior to Registry System Testing. Discussion: -- One of the main challenges with the IDN tables is that the testing provider changes the requirements often without notification. Include additional operational tests to assess readiness for Domain Name System Security Extensions (DNSSEC) contingencies (key roll-over, zone re-signing). -- RySG: Concerns from some members & New Idea from some members. Possible language: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, either by submitting it to evaluation at application time or agreeing to use a previously approved* technical infrastructure.” * Could mean in the same procedure or previous procedures if an RSP program exists. -- BRG/Neustar: Agreement. -- RySG: At least one RySG member suggests that if an applicant is choosing to use a previously approved technical infrastructure, then the applicant should be required to identify that service provider at application. This is opposed by at least one RySG member, stating that this would only serve the interest of registry service providers, while leaving approved registry operators to later choose a registry service provider increase competitiveness in that field. -- Consider whether this rises to the level of a preliminary recommendation. Feedback on recommendations ICANN’s Technical Services group provided to WT4 -- RySG: Agreement/Concerns/New Idea/Divergence. b. TLD Rollout: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66X... (page 2) Policy Goals: The following Implementation Guideline from the 2007 recommendations remains appropriate: * Implementation Guideline I: “An applicant granted a TLD string must use it within a fixed timeframe which will be specified in the application process.” High-level Agreements: * The ICANN organization should be responsible for meeting specific deadlines in the contracting and delegation processes. * Maintain the timeframes set forth in the Applicant Guidebook and the base Registry Agreement; namely (i) that successful applicants continue to have nine (9) months following the date of being notified that it successfully completed the evaluation process to enter into a Registry Agreement, and (ii) that Registry Operators must complete all testing procedures for delegation of the TLD into the root zone within twelve (12) months of the Effective Date of the Registry Agreement. In addition, extensions to those timeframes should continue to be available according to the same terms and conditions as they were allowed during the 2012 round. -- RySG states in its support for this recommendation that any specific proposal should be flexible enough to permit ICANN to extend the contracting and delegation process for security and stability and public interest reasons subject to SSAC advice and / or GAC consensus with board approval. Outstanding Items: Maintain the timeframes set forth in the Applicant Guidebook and the base Registry Agreement * ICANN Org: Concerns - Extensions in the 2012 round caused extensive delays and consumed significant program resources (see the ICANN Program Review Report for discussion on extensions for contracting and Registry System Testing). Additionally, the lack of a time limit for launch of a gTLD created significant burden and costs on ICANN operations to support a number of activities that take place between delegation launch (i.e., processing sub-contractor changes and RSEP requests). This impacts program financials, and has a potential impact on the timing of closure of a round depending on the criteria used to close a round. Discussion: -- How can this WG help to address ICANN Org’s concerns? Hard to see what we could do without affecting different TLD models. Is prevention of squatting/warehousing still a relevant reason to have a delegation deadline? Are other measures needed? -- BRG: Agreement. -- RySG: Agreement/Divergence. -- MarkMonitor: Agreement. Is the definition of use of a TLD from the 2012 round still appropriate or are adjustments needed? -- BRG/RySG: Support use requirement in the 2012 AGB. No adjustments are necessary. -- RrSG: Does not support requiring a TLD to have registrations within 12 months for the Registry Operator to retain the license to the TLD. Suggests increasing the time-to-first-registration (other than NIC.TLD and WHOIS.NIC.TLD) to 5 years for non-exempt TLDs. Additional comments: -- Christopher Wilkinson: 1. Rollout: It would be helpful to have information about how many new TLDs have still not been implemented and why. The Initial Report appears to indicate that the WG would in practice accept squatting and warehousing of new TLDs. The WG should pursue a more proactive approach to discouraging such behavior in the future. Discussion: -- There is a huge problem with warehousing. -- Particularly concerned about the political repercussions of warehousing of geo-names outside the corresponding jurisdiction. -- There was never anything in the AGB that had a requirement of use and doesn’t seem to be much support for adding a use requirement. -- To be clear, I think prevention of squatting/warehousing is still relevant reason to have a delegation deadline. I just think .brand TLDs not launching is a lesser concern than others TLDs. -- Pushing all TLDs to start selling names within a certain period encourages multiple launches all at the same time - surely a RO ought to be able to roll out at the time they believe they will lead to the best business outcome. -- There are many factors that impact launch and use of TLDs, especially those that are not purely for commercial purposes. The last round was also hindered by many delays, which had a detrimental impact for many. -- Didn’t all applications have to state their intended use? If that was to change, or not occur because roll out does not happen, is there not a procedure or penalty to address this? -- If you don't make available domains to the community - then others should be granted the opportunity to steward that string. At the very latest once the first 10 years went by without measurable use (a few registered domains aren't sufficient). So no use = contract cancelation. -- What contractual obligations do the registry operators have in this regard? -- Public comment did not sway this towards any changes being required. -- To address ICANN's concerns, minimum payments could be required for TLDs not yet launched within years after delegation and signed contract. This would have to be based on average costs. -- To answer the question of whether TLDs are not in use we need to define what we mean by “use”. -- What is the problem we are trying to resolve here? We’ve already collected public comments on this question. -- Prevention of squatting/warehousing is still relevant reason to have a delegation deadline. -- Is it worth pointing to the previous calls on the public comments on this topic. -- It seems the record should reflect that there is deep concern from many in Non-Registry Community on this call. -- Struggling with what the problem is and possible ramifications on defining/requiring use. Lacking the evidence and issue base to come up with a way forward on this. -- Without clear definition of "squatting" or "use", I would suggest looking at reasonable timeline to launch for registration. Especially if the RO had prevailed in a contention set or objection. Timeline to be proposed by RO themselves. This is my personal opinion. c. Contractual Compliance: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66X... (page 6) Policy Goals: The following existing recommendation from the 2007 policy remains appropriate: * Recommendation 17: “A clear compliance and sanctions process must be set out in the base contract which could lead to contract termination.” High-level Agreements: * ICANN’s Contractual Compliance Department should publish more detailed data on the activities of the department and the nature of the complaints handled. -- While generally supporting this recommendation, the following additional points were raised -- RySG and Neustar indicated that ICANN should not publish or reporting that identifies any specific party(ies) subject to compliance action. IPC asked that the WG's recommendation include additional detail so that it can be more fully considered. Should applicant statements, such as representations and/or commitments, be included in the Registry Operator’s Agreements? Why or why not? -- INTA, IPC, ALAC: Agreement. -- IPC: Agree especially in relation to rights protection mechanisms. -- BRG, RySG: Agree if inclusion is optional. -- INTA: New Idea. -- Neustar: Divergence. -- Christopher Wilkinson: The statement in the Initial Report that 'There was no agreement … in support of this proposal' is a rather weak conclusion which might be queried at a later stage. Is there evidence of “arbitrary and abusive pricing for premium domains targeting trademarks; use of reserved names to circumvent Sunrise; and operating launch programs that differed materially from what was approved by ICANN.” If yes, how should these issues be addressed? -- INTA: Agreement/New Idea/Concerns. -- IPC: Agreement. -- LeMarit: Agreement/New Idea. -- Neustar: Is not aware of any evidence that would support the assertion that these operational practices are being implemented. -- RySG: Has no empirical evidence of these types of activities and generally believe these allegations are unsupported. If these activities are occurring, existing mechanisms are sufficient to address them. Discussion: -- Is it within this group's scope to consider or review the thresholds used for meeting compliance and triggering sanctions? If not, then whose job would that be? -- Continue discussion on the list. -- What can be done about it would not be a question of regulating pricing - need a different remedy because the RA prohibits ICANN from regulating pricing - as far as I know.