ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAHAIAJAKALAMANAOAPAQARASATAUAVAWAXAYAZBABBBCBDBEBFBGBHBIBJBKBLBMBNBOBPBQBRBSBTBUBVBWBXBYBZCACBCCCDCECFCGCHCICJCKCLCMCNCOCPCQCRCSCTCUCV
1
TimestampEmail Address RedactedPlease provide your name:Please provide your affiliation Are you providing input on behalf of another group (e.g., organization, company, government)? If yes, please explain:Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:Enter your response here:If you have a response to the question please enter your response here:If you choose one of the following responses there is no need to submit comments:If you choose the following response, please indicate in the text box below what should change and why:Enter your response here:If you choose the following response, please indicate in the text box below the new information or interests that the Working Group has not considered:
2
Topic 1: Continuing Subsequent Procedures.Topic 1: Continuing Subsequent Procedures.Topic 1: Continuing Subsequent Procedures.Topic 1: Continuing Subsequent Procedures.Topic 1: Continuing Subsequent Procedures.Topic 2: PredictabilityTopic 2: PredictabilityTopic 2: PredictabilityTopic 2: PredictabilityTopic 2: PredictabilityTopic 3: Applications Assessed in Rounds (Application Submission Periods)Topic 3: Applications Assessed in Rounds (Application Submission Periods)Topic 3: Applications Assessed in Rounds (Application Submission Periods)Topic 3: Applications Assessed in Rounds (Application Submission Periods)Topic 3: Applications Assessed in Rounds (Application Submission Periods)Topic 4: Different TLD TypesTopic 4: Different TLD TypesTopic 4: Different TLD TypesTopic 4: Different TLD TypesTopic 4: Different TLD TypesTopic 5: Application Submission LimitsTopic 5: Application Submission LimitsTopic 5: Application Submission LimitsTopic 5: Application Submission LimitsTopic 5: Application Submission LimitsTopic 6: Registry Service Provider Pre-EvaluationTopic 6: Registry Service Provider Pre-EvaluationTopic 6: Registry Service Provider Pre-EvaluationTopic 6: Registry Service Provider Pre-EvaluationTopic 6: Registry Service Provider Pre-EvaluationTopic 7: Metrics and MonitoringTopic 7: Metrics and MonitoringTopic 7: Metrics and MonitoringTopic 7: Metrics and MonitoringTopic 7: Metrics and MonitoringTopic 8: Conflicts of InterestTopic 8: Conflicts of InterestTopic 8: Conflicts of InterestTopic 8: Conflicts of InterestTopic 8: Conflicts of InterestTopic 9: Registry Voluntary Commitments/Public Interest CommitmentsTopic 9: Registry Voluntary Commitments/Public Interest CommitmentsTopic 9: Registry Voluntary Commitments/Public Interest CommitmentsTopic 9: Registry Voluntary Commitments/Public Interest CommitmentsTopic 9: Registry Voluntary Commitments/Public Interest CommitmentsTopic 10: Applicant Freedom of ExpressionTopic 10: Applicant Freedom of ExpressionTopic 10: Applicant Freedom of ExpressionTopic 10: Applicant Freedom of ExpressionTopic 10: Applicant Freedom of ExpressionTopic 11: Universal AcceptanceTopic 11: Universal AcceptanceTopic 11: Universal AcceptanceTopic 11: Universal AcceptanceTopic 11: Universal AcceptanceTopic 12: Applicant GuidebookTopic 12: Applicant GuidebookTopic 12: Applicant GuidebookTopic 12: Applicant GuidebookTopic 12: Applicant GuidebookTopic 13: CommunicationsTopic 13: CommunicationsTopic 13: CommunicationsTopic 13: CommunicationsTopic 13: CommunicationsTopic 14: SystemsTopic 14: SystemsTopic 14: SystemsTopic 14: SystemsTopic 14: SystemsTopic 15: Application FeesTopic 15: Application FeesTopic 15: Application FeesTopic 15: Application FeesTopic 15: Application FeesTopic 16: Application Submission PeriodTopic 16: Application Submission PeriodTopic 16: Application Submission PeriodTopic 16: Application Submission PeriodTopic 16: Application Submission PeriodTopic 17: Applicant SupportTopic 17: Applicant SupportTopic 17: Applicant SupportTopic 17: Applicant SupportTopic 17: Applicant SupportTopic 17: Applicant SupportTopic 18: Terms and ConditionsTopic 18: Terms and ConditionsTopic 18: Terms and ConditionsTopic 18: Terms and Conditions
3
8/21/2020 8:09:31Alexander Schubertnew gTLD management companyNoYes
4
8/26/2020 4:31:35Annebeth B. LangeNORID AS (The Norwegian ccTLD .no)YesI am answering on behalf of NORID ASNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenYes
5
8/27/2020 10:47:15Annebeth B. LangeNORID AS (the Norwegian ccTLD)YesI am answering on behalf of NORID ASNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenYes
6
8/27/2020 22:53:49RamtinNoticed NoNo, I would like to continue to the next sectionSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)New information or interests that the Working Group has not consideredSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)Support Output(s) as writtenSupport Output(s) as writtenNew information or interests that the Working Group has not consideredSupport Output(s) as writtenNew information or interests that the Working Group has not consideredNo, I would like to continue to the next sectionSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)Support Output(s) as writtenDo not support certain aspects or all of the Output(s)Support Output(s) as writtenNo OpinionDo not support certain aspects or all of the Output(s)No OpinionNew information or interests that the Working Group has not considered
7
9/4/2020 7:27:23afandee33347897YesYes
8
9/5/2020 12:11:57ashraful alambusiness companyNoNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo, I would like to continue to the next sectionNo OpinionNo OpinionNo Opinion
9
9/8/2020 15:12:55Naeem Uddin HadiNextGen@ICANNNoYes
10
9/9/2020 4:24:11Peter Van RosteCENTRYesThis response is a CENTR Board commentNo, I would like to continue to the next section
11
9/11/2020 6:44:49Clement GentyArts & Metiers ParisTechNoNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo Opinion
12
9/17/2020 12:13:34Annebeth B. LangeNORID AS (The Norwegian ccTLD)YesI am answering on behalf of NORID ASNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as written
13
9/20/2020 22:13:39Anthony LeeTWNICNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as written
14
9/18/2020 9:35:25Jamie BaxterIndividualYesA Community Applicant from the 2012 RoundNo, I would like to continue to the next sectionSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo OpinionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as written
15
9/20/2020 19:03:41thomas barrettEnCirca, IncNoYes
16
9/20/2020 21:09:18thomas barrettEnCirca, IncNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)I would clarify recommendation 6.9 to make it clear that: if applicants elect to use a pre-evaluated RSP, then responding to the application topics handled by the pre-evaluated RSP are OPTIONAL and can be responded to with "handled by pre-evaluated RSP".

Ideally, there would be a global check-box to cover the entire section of topics handled by a pre-evaluated RSP.

Further, the guidebook should make it clear that if applicants are electing to use a pre-evaluated RSP, then it is OPTIONAL for applicants to disclose its choice for a pre-evaluated RSP in its application to ICANN.

Support Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)I believe it is overly broad to provide exemptions/waivers for single-registrant TLDs from the requirements in Specification 11 3(a) and 3(b) as it assumes USE of the delegated strings to a single legal entity, since it is possible that such domains are distributed to affiliates that are distinct from the registry operator.Not ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)Please clarify how applications in the first round would have received different treatment under this version of the guidebook.No, I would like to continue to the next sectionNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as written
17
10/5/2020 16:37:14Kathy Kleiman/Bruna Martins dos Santos/Raphael Beauregard-LacroixNCSGNoNo, I would like to continue to the next sectionSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)A lot of work has gone into the “Predictability Framework,” but it remains something new in the ICANN process - a standing Implementation Review Team. It will continue to operate long after the initial IRT is over, and it should be annually reviewed by the GNSO Council for compliance with the rules the WG has sought to create.

Further, NCSG submits that it needs to be very clear, and expressly in writing as a recommendation of the WG, that GNSO Council procedures take precedence over the Predictability Framework. Otherwise, we must object to the whole Predictability Framework.
New information or interests that the Working Group has not consideredTo do otherwise is to make the SPIRT and the Predictability Framework superior to the GNSO Council - which was never the WG’s intent, and certainly not the NSCG’s goal. No OpinionWe support Rounds, but do not necessarily support a predictable cadence of Rounds. The timing of Rounds should depend on the number of applications that is submitted - more applications and we should have a longer time between Rounds. It is important that Commenters, who will include NCSG members, have adequate time to review and comment on applications and critique and oppose them as needed. The timing of Rounds should be dependent on a high level of delegations, and a fair and full period for the Community to catch its breath, before a subsequent Round is announced.
New information or interests that the Working Group has not consideredCOVID19 is the new information. The world has changed and we will continue to work remotely for some time. This makes it even more difficult for organizations, including those in the NCSG, to work at breakneck speed. ICANN and the New gTLD Program and its Rounds must take into account the difficulties of the world of the Community and commenters. Support Output(s) as writtenDo not support certain aspects or all of the Output(s)
We do not support unlimited applications in every Round from any and all applicants. These rules dramatically favor large, existing and well-financed entities at the expense of encouraging applications for gTLDs from companies and communities around the world. We support 24 applications per company and/or any other reasonable limit the WG chooses. But limits are key lest the resources of ICANN and the good-will of the Community are overtaxed, while some companies are given enormous control over large numbers of gTLDs.
New information or interests that the Working Group has not consideredThe WG report does not convey why the WG considered application limits to be unprincipled. It only seems to convey a sense that applicants want an unlimited number of applications. NCSG submits there must be a stronger reason than desire provided… No, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)
There are many positive improvements here and the mandatory PICs have a lot of support.

We remain deeply concerned that RVCs (formerly voluntary PICs) can be used to violate due process and registrant protections including freedom of expression. They can be used to create content-oriented interference by registries that far exceeds the scope and function of ICANN. Accordingly, we must continue to disagree with RVCs and their inclusion in the new Applicant Guidebook.
New information or interests that the Working Group has not consideredThroughout the Internet, platforms are adopting *more processes* for better and more fairly handling allegations against speech, including disinformation, political bias and fraud. Yet, the WG moves to endorse the RVCs that could be used to provide complete control over content to registries. We understand why registries might want such control, but we submit that it is the wrong direction for ICANN (which is protected by its Bylaws that do not involve content) and the wrong direction for New gTLDs.
Support Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNCSG fully supports: “Recommendation 17.2: The Working Group recommends expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees and attorney fees related to the application process.”

To be fully complete, however, the WG must also “flesh out” other recommendations for applicant support, including non-financial support (education and information) and a better sense of the multiplier and bid credits that will be given to AS applicants to ensure them a fair chance to win a gTLD, even if they are in contention sets with much larger and better-funded companies. We understand this is a shared goal of the WG, and more details and direction are key to ensuring this will happen.

In addition, the funds must be made available for Applicant Support very early - so that even early education can be accompanied by funds and support as potential applicants learn about and become interested in application process.
Support Output(s) as written
18
9/27/2020 22:00:51Kun (Kevin) LiuFuxi InstitutionNoYes
19
9/28/2020 8:55:09ZHOU, LiGuoLegal Council, Intellectual Property Department, Tencent GroupNoNo, I would like to continue to the next sectionSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)We do not object the formation of the SPIRT mechanism under GNSO’s oversight for the purpose of continued program improvement. However, we do not support any new changes taking place during the application submission and evaluation process. We strongly believe that any changes to the program should be confirmed and implemented prior to the opening of the new round of application to better serve the interest of the applicant. If there’s absolute need for change during the application submission process due to program design flaw or any urgent condition confirmed by the ICANN Board, the overall program should be paused and all applicants should receive full or partial refund.Do not support certain aspects or all of the Output(s)We do not fully support Recommendation 3.5 . We believe that GNSO Council, as a policy development and facilitation body, does not have the right to recommend pausing the program unilaterally.

We also regret that the WG has not come to an agreement of the designated .brand application track but emphasizing in great details, as well as developing multiple proposals, on the closed-generic category. We appreciate the effort but we also strongly suggest that the WG should re-evaluate its strategy and focus on enabling the .brand application track.
Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)Given the importance of timely publication and awareness building for the subsequent and future rounds, we suggest that the AGB should be available in all 6 U.N. languages at the same time with the English version, and the English version serves as the authoritative version. Do not support certain aspects or all of the Output(s)We suggest that the communication period should take place at least 12 months prior to launch of the program. 6-month period isn’t sufficient to many corporations to manage internal communication and budget planning cycles. Support Output(s) as writtenNew information or interests that the Working Group has not consideredWe believe a volume discount or tiered-pricing approach should be considered for application fees. An applicant with multiple applications should be granted with fee discount. We also recommend that ICANN should decide the floor fee, its calculation method, and the volume discount / tiered-pricing schedule, 90 days after the Board adopts the SubPro report.Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as written
20
9/28/2020 11:54:08Gertrude LevineNational Association of Boards of Pharmacy (NABP)YesNational Association of Boards of Pharmacy (NABP)No, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)NABP supports Recommendation 4.1 and the inclusion of strings subject to Category 1 Safeguards as a type of TLD/string type requiring differential treatment. It should be added, however, that this string type would require different application questions, different application evaluation process/requirements, and contractual requirements. As part of these requirements, and as NABP notes in response to Recommendation 9.4, if the applicant does not self-identify and it is later discovered that the applied-for string is subject to Category 1 Safeguards, the applicant should be permitted to change their string type and, with that, must go through the change request process to make their application suitable to a Category 1 string, as well as another public comment period prior to evaluation of their revised application.No, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)NABP supports Recommendation 9.1 but with significant modification. As currently written, Specification 11 3(a) falls short of its intended purpose, protecting end users. Specification 11 3(a) only mandates that registries include in their Registry-Registrar Agreements specific language. It does not, however, require contractual enforcement of the safeguards described in the specified language. It is therefore necessary to revise Specification 11 3(a) to hold new TLDs that are subject to Category 1 Safeguards accountable for their registrants’ contractual compliance with those safeguards. Existing TLDs could be grandfathered as exempt from the Specification 11 3(a) revision.
NABP supports Affirmation 9.3 but with significant modification. “The integration of the relevant Category 1 Safeguards into the Registry Agreement, by way of PICS,” in and of itself, is not sufficient. The safeguards must be enforceable by ICANN (via the PICDRP process) to serve the purpose for which they were intended. This means Specification 11 3(a) must be revised for subsequent TLDs such that the RA mandates not just inclusion of a requirement in the RRA but accountability for compliance with those safeguards. As noted above, existing TLDs could be grandfathered as exempt from the Specification 11 3(a) revision.
NABP supports Recommendation 9.4 with significant modification and the addition of certain guardrails. If an applicant does not self-identify, as suggested in Implementation Guidance 9.5, and it is later discovered that the applied-for string is subject to Category 1 safeguards, the applicant should be permitted to change their application to be suitable to a Category 1 string but must go through the application change process, followed by another public comment period prior to evaluation of their application, thus delaying their application.
For the Category 1 Safeguards to be enforceable, Specification 11 3(a) must be revised for subsequent TLDs such that the RA mandates not just inclusion of a requirement in the RRA but accountability for compliance with Category 1 Safeguards. Existing TLDs could be grandfathered as exempt from the Specification 11 3(a) revision, just as they would be exempt from the process described in Recommendation 9.4 to determine if their string falls into one of the four groups defined by the NGPC framework for new gTLD strings deemed to be applicable to highly sensitive or regulated industries.
No, I would like to continue to the next sectionNo, I would like to continue to the next section
21
9/28/2020 12:04:30Sheri Falcon Minds + Machines Group Limited NoNo, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)Regarding Implementation Guidance 3.3: A new round may initiate even if steps related to application processing and delegation from previous application rounds have not been fully completed.

MMX does not believe a new round should initiate if application and delegation processing from previous rounds haven’t been completed because that creates a potential inequality between the rights the new round applicants have and the rights 2012 application holders have (e.g., no current ability to revise Voluntary PICs in 2012 round, still outstanding disputes regarding CPE process and determinations in 2012, etc.). This disparity could result in new rounds having their TLDs launch prior to the 2012 round launching all of it’s TLDs; this could impact commercial opportunities as well as substantive and procedural legal rights and remedies for 2012 round holders.
New information or interests that the Working Group has not consideredMMX agrees that the next round should be predictable and known but given there are still outstanding TLDs not yet delegated or launched from the 2012 round and given there are substantive rights procedures not yet established from the 2012 round - we feel it is premature to open the next round of applications up until those issues are resolved. This is essentially new information because earlier in the process we were unsure, and unable to determine, whether those issues would be resolved - but now we know they are not yet resolved.
22
9/29/2020 7:37:27Jorge CancioSwiss Government – Federal Office of Communications (OFCOM)NoNo, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)While we agree with Affirmations 1.1 to 1.3, we refer to GAC Communiqué from ICANN 56 (Helsinki) which, in its advice to the Board, requests that
I. The starting point for development of policy on further releases of new gTLDs should first take into consideration the results of all relevant reviews of the new gTLD round and determine which aspects and elements need adjustment and
II. All measures available to the Board should be used to ensure that a comprehensive and measured approach to further releases of new gTLDs is taken in a logical, sequential and coordinated way rather than through parallel and overlapping efforts and/or timeframes that may not be agreed by all relevant interests.
We also refer to the GAC Communiqué from ICANN 66 (Montreal) where de GAC advises the Board not to proceed with a new round of gTLDs until after the complete implementation of the recommendations in the Competition, Consumer Trust and Consumer Choice Review that were identified as "prerequisites" or as "high priority".
Do not support certain aspects or all of the Output(s)While we appreciate the efforts of the PDP WG to create a Predictability Framework, we are still not entirely persuaded of the added-value of creating the new SPIRT structure and therefore wish to reiterate comments raised in the ICANN68 Communique: “some GAC members raised doubts on the added-value of a SPIRT, and expressed concerns that its creation, if adopted, could add complexity to the current procedure and potential inconsistency with existing roles and responsibilities according to the ICANN Bylaws. It [is] proposed that if established, the new mechanism be lean, inclusive and transparent.”Support Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)We refer to previous GAC ICANN66 Communique Advice to the ICANN Board, whereby “the GAC advises the Board not to proceed with a new round of gTLDs until after the complete implementation of the recommendations in the Competition, Consumer Trust and Consumer Choice Review that were identified as "prerequisites" or as "high priority".”
Furthermore, we have concerns regarding the absence of policy recommendations on DNS Abuse Mitigation in the Subpro PDP WG Final Report, and note that the WG deems that such future effort should be holistic and must apply to both existing and new gTLDs (and potentially ccTLDs). On this point, we expect swift action from the GNSO Council in triggering such holistic effort, in order that the conditionality expressed in the GAC ICANN 66 Communique is met. In addition, reference to ccTLD’s in Recommendation 9.15 should be avoided as they do not fall under ICANN’s competence but operate under national legislation.We recognize that the PDP WG has taken into account GAC Beijing Advice, by affirming that the framework established by the New gTLD Program Committee (NGPC) to apply additional Safeguards to certain new gTLD strings that were deemed applicable to highly sensitive or regulated industries, creating 10 safeguards of various levels to be implemented among a set of 4 groups.
In this context, we would like to point out that the figure of the Registry Voluntary Commitments (RVCs) should not be used in any way to downplay the pressing need to introduce new mandatory PICs to combat abuse and to set safeguards for strings in highly sensitive or regulated sectors, as well as the pressing need to provide a clear compliance, enforcement and sanctions process in relation to PICs and to RVCs as required by Affirmation 41.1. Consistent with the GAC Montreal Communiqué, we believe that voluntary and mandatory PICs must be enforceable and that this goal should be achieved with clearly expressed contractual obligations and consequences for failure to meet these obligations. Improved clarity for PICs in terms of obligations and consequences will aid ICANN’s contractual compliance program in its enforcement of these provisions that safeguard the public interest. We also recall persistent GAC concerns regarding both the weak implementation of PICs applicable to gTLDs in highly-regulated sectors and the lack of clarity and effectiveness of the mechanism to enforce disputes (the Public Interest Commitments Dispute Resolution Process or PICDRP).
Support Output(s) as writtenDo not support certain aspects or all of the Output(s)We believe that more can and should be done to further the adoption of Universal Acceptance (UA) and encourage ICANN org to provide the necessary means to support the adoption of UA.Do not support certain aspects or all of the Output(s)We welcome the efforts and willingness of the WG to make the Application Guide Book (AGB) available in the 6 UN languages. However, we disagree with the recommendation that the English version of the AGB shall be available up to two months before the other language versions (Recommendations 12.5 and 12.6). We suggest that the AGB should be published at the same time in all languages.No OpinionDo not support certain aspects or all of the Output(s)It should be an obligation for ICANN to put in place systems that provide information about the gTLD process in major languages other than English, not just a possibility as foreseen by Affirmation 14.1 (“may”).No OpinionNo, I would like to continue to the next sectionSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)We note that the PDP WG’s Initial Report included a preliminary recommendation that the Applicant Support Program should include coverage of ongoing registry fees, which has since been removed from the final report. We are of the opinion that Applicant Support Program should consider the reduction or elimination of the ongoing ICANN registry fees, at least in part, to expand financial support available to eligible applicants.See answer to question 92.Support Output(s) as written
23
9/29/2020 9:05:35Wei WangFuxi InstitutionNoNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo Opinion
24
9/29/2020 9:24:19Yi ZhangFuxi InstitutionNoNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo Opinion
25
9/29/2020 9:30:18Xiaodong LeeFuxi InstitutionNoNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo Opinion
26
9/29/2020 9:34:29Kun LiuFuxi InstitutionNoNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo Opinion
27
9/29/2020 11:05:42Wes HardakerInternet Architecture BoardYesI'm submitting comments agreed to by the Internet Architecture BoardNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo Opinion
28
9/29/2020 11:45:51Marianne GeorgelinAfnicNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenNo OpinionSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredICANN might consider to significantly reduce application and recurring fees for future rounds and to offer waivers of application fees to developing countries' projects particularly when those projects are community-based and/or non-for profit.No, I would like to continue to the next sectionSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as written
29
9/29/2020 21:12:20Raymond ZylstraGoDaddy RegistryNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)Cross Reference with Topic 27.

It is not clear if in the Draft Final Report if RSP Pre-Evaluation would allow an applicant simply to indicate in their application that they will use a pre-evaluated RSP, without actually nominating which RSP would be used.

The Draft Final Report should be updated to clarify that an applicant must select the pre-evaluated RSP and nominate them in the application.
Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as written
30
9/30/2020 9:27:18Samantha Demetriou, RySG Vice-Chair PolicygTLDs Registries Stakeholder Group (RySG)YesThe comments are submitted on behalf of the gTLDs Registries Stakeholder Group (RySG).
In the interest of time, the RySG did not conduct a vote on these comments. We did discuss them on our mailing list and during a biweekly conference call, and no member opposed their submission.
No, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenNo OpinionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredPotential metrics to measure the impact of the New gTLD Program (first proposed in the RySG comments in the SubPro Initial Report):
- The presence of new gTLDs in lists of highly used websites, such as Alexa 1 Million and Cisco Umbrella 1 Million
- Recognition of specific gTLDs in niches, communities, and verticals
- Annual growth of new gTLDs as compared to legacy TLDs and previous application rounds, i.e., comparing the growth of TLDs approved in 2012 with TLDs approved in subsequent rounds
- Number of new registries and registrars year over year
- Locations of new registries and registrars year over year, in an effort to see how subsequent rounds affects diversity in the marketplace
- Categories of gTLDs offered and diversity metrics within those categories
Support Output(s) as writtenSupport Output(s) as writtenNew information or interests that the Working Group has not consideredThe RySG suggests that there should be a process to revise RVCs after delegation. For example, a RVC may no longer be fit for purpose (in practice, it could be either too broad or narrow to achieve its goal), expired if it is time bound, or a registry may wish to add RVCs after a period of operation. No OpinionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNew information or interests that the Working Group has not considered13.3 The RySG suggests that “at least six months” is only one component that needs to be incorporated in a well designed and comprehensive Applicant Support program. The communication period needs to provide ample runway to design, develop and implement the outreach program to potential applicants to ensure the programs best chance of success. Support Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not considered15.5 the application fee floor should also consider that new gTLDs are a valuable piece of the Internet and be reflective of the commitment of owning and operating a TLD. As such, an evaluation of the fee floor should be conducted and updated for each application round.

15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9. This will help ICANN remain efficient while ensuring the costs related to the return of the fees are not exceeded by the related resources to return the excess to applicants.

15.10 Periodic review should be conducted at a minimum of once every application round to ensure the contingency funds are adequately funded.

15.8 Excess funds should be returned to applicants in a timely manner. Options could include a percentage of the processing of applications for a specific application round i.e. 90%, predetermined time period i.e. 24 months or a credit against future ICANN fees. Timing should be provided before the application period opens.

This section of the Final Report does not seem to provide any guidance on how Applicant Support fees are determined, which would be useful.
No OpinionNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredThe RySG supports the goals of Applicant Support but notes strongly that every application should be evaluated to ensure the applicant is sufficiently funded and equipped to operate a registry for the long term in a manner that maintains the security and stability of the DNS and is able to implement accepted anti-abuse practices and principles.

17.2 financial support should be clarified and/or expanded upon to include a variety of professional fees (beyond application writing and attorney fees) such as financial viability, securing funding, etc.

17.5 Significant concerns on how bid credits, multipliers, and other features may be used in other unintended ways beyond benefiting AS applicants, and how the risk of gaming can be mitigated.

(see 35.2) Applicant Support applicants who have access to bid credits, multipliers, other should be protected from more sophisticated applicants who benefit financially from entering into a business combination or joint venture.

17.9 Metrics should include: a) number of applicants who received bid credits, multiplier, other and were successful in auction; b) number of applicants who withdrew from auction; c) number of applicants who entered in to a business combination or other forms of joint ventures; d) the value of the bid credits, multiplier, other; and e) length of time before any change of ownership occurred.

17.13 The amount of funding should be determined and communicated before the commencement of the application round. This will provide potential applicants with insight on their potential likelihood of success and whether they should apply for funding. It will also provide the information required to 17.14 in seeking additional funding partners without delay.

If there are difficulties in attaining the relevant funding, then the weighting of 15.9 (c) should be increased to help fund potential AS in future rounds.

17.17 financial support should include application fees and any related bid credit, multiplier or related benefits received by the applicants. Clarification on any amounts related to 17.2 should be described, i.e., professional services.

17.17 ‘Going out of business’ should be clearly defined to avoid any ambiguity, i.e., where the TLD is unable to meet their financial obligations and unable to secure financing or restructure operations to carry out operations in the short-term.
Support Output(s) as writtenDo not support certain aspects or all of the Output(s)The RySG is supportive of the proposed changes, however, supporting this recommendation does not endorse the eventual validity of any covenant not to sue drafted by ICANN. New information or interests that the Working Group has not considered
31
9/30/2020 4:17:36Dirk KrischenowskidotBERLIN GmbH & Co. KGNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionNo OpinionNo OpinionNew information or interests that the Working Group has not consideredWe recommend that the geographic names panel act in a transparent manner and make their deliberations public. We recommend that the result of the geographic names panel will be presented to the broader community, including the GAC, to inform potentially affected parties of the findings.Support Output(s) as writtenNo OpinionDo not support certain aspects or all of the Output(s)We believe that more can and should be done to further the adoption of Universal Acceptance (UA) and encourage ICANNorg to provide the necessary means to support the adoption of Universal Acceptance (UA).Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)On the topic of Implementation Guidance 15.8: “If excess fees are collected in subsequent procedures and the cost recovery model is followed (i.e., the application fee floor is not implemented) any excess fees should be returned to applicants where possible.“
We are of the opinion, that “If excess fees are collected in subsequent procedures and the cost recovery model is followed (i.e., the application fee floor is not implemented) any excess fees must be returned to applicants.” (emphasis added)
Support Output(s) as writtenWe agree with Recommendation 17.2: "The Working Group recommends expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees and attorney fees related to the application process."
We do not have a position if the Applicant Support Program should also include the reduction or elimination for eligible candidates of ongoing registry fees specified in Article 6 of the Registry Agreement.
Support Output(s) as written
32
9/30/2020 4:36:45Dirk KrischenowskiHamburg Top-Level-Domain GmbHNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo OpinionNo OpinionNew information or interests that the Working Group has not consideredWe recommend that the geographic names panel act in a transparent manner and make their deliberations public. We recommend that the result of the geographic names panel will be presented to the broader community, including the GAC, to inform potentially affected parties of the findings.Support Output(s) as writtenNo OpinionDo not support certain aspects or all of the Output(s)We believe that more can and should be done to further the adoption of Universal Acceptance (UA) and encourage ICANNorg to provide the necessary means to support the adoption of Universal Acceptance (UA).Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)On the topic of Implementation Guidance 15.8: “If excess fees are collected in subsequent procedures and the cost recovery model is followed (i.e., the application fee floor is not implemented) any excess fees should be returned to applicants where possible.“

We are of the opinion, that “If excess fees are collected in subsequent procedures and the cost recovery model is followed (i.e., the application fee floor is not implemented) any excess fees must be returned to applicants.” (emphasis added)
Support Output(s) as writtenWe agree with Recommendation 17.2: "The Working Group recommends expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees and attorney fees related to the application process."

We do not have a position if the Applicant Support Program should also include the reduction or elimination for eligible candidates of ongoing registry fees specified in Article 6 of the Registry Agreement.
Support Output(s) as written
33
9/30/2020 5:32:35Brian BeckhamWIPO YesWIPO Arbitration and Mediation CenterNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNew information or interests that the Working Group has not consideredThe WG may wish to clarify whether the concept of differential treatment for certain applications is intended, or not, to exempt certain application types from Objections Procedures.No OpinionNo, I would like to continue to the next sectionNo OpinionNo OpinionNew information or interests that the Working Group has not consideredThe WG may wish to consider referring – as Implementation Guidance – to best-practice resources such as the IBA Guidelines on Conflicts of Interest in International Arbitration (https://www.ibanet.org/Publications/publications_IBA_guides_and_free_materials.aspx#Practice) which are taken e.g., into account in WIPO ADR processes.New information or interests that the Working Group has not considered(9.1) In terms of implementation of certain aspects of PICs, the WG may wish to consider recommending that ICANN consider a uniform ADR mechanism (such as the UDRP) for rights holders to address claims of copyright infringement as prohibited under the applicable Registration Agreement.No OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo Opinion
34
9/30/2020 6:08:12Martin SuttonBrand Registry Group, IncNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNew information or interests that the Working Group has not consideredThe BRG believes that an amendment process is needed for RVCs and carefully developed to take into account factors such as:
- How substantive the proposed amendment is;
- The objection, concern or other risk the RVC was seeking to address or other reasons the RVC was adopted;
- The views of any party with a direct interest in the RVC, e.g. any party involved in an actual or threatened objection process or contention/string similarity resolution that was resolved by the adoption of the RVC, with the presumption that amendment to remove or weaken an RVC would not be possible without consent where the adoption of the RVC was instrumental in removing the objection/challenge;
- That since an RVC would have been subject to a public comment period then any amendment should also be subject to a comment process.
Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenThe BRG would be supportive of extending applicant support towards ongoing registry fees but this would need to be on a case-by-case basis. This should also be time-limited, agreeable in advance. Funding should be drawn from within the Application Support allocated budget. Support Output(s) as written
35
9/30/2020 9:23:09Nacho AmadozGeoTLD GroupNoNo, I would like to continue to the next sectionSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenWe support the improvements to better analyze and manage issues after AGB is approved (Predictability Framework & SPIRT) plus the opportunity to withdraw and get refund in case of significant changes;

There is nothing included on providing enough lead-time for governments support process.
Support Output(s) as writtenNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)The geographic string label may be too restrictive to encompass a kind of TLD which is geo-oriented, based on a community, and that is in many other regards almost equivalent to a geographic TLD (including support from governments, community support, and oriented to allow a linguistic and cultural community to be represented on the Internet, like .scot, .eus, etc.) and its scope could we widened to accommodate geo-oriented applications that do not fit the restrictive definition of a geoTLD. Support Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionNo OpinionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)The GeoTLD Group considers that applications coming from non for profit entities that are entrusted by a diversity of stakeholders and civil society agents to steward a cultural, linguistic and/or geographic identity/community online, such as the model that can be seen in different members of the GeoTLD Group, could be beneficiaries of potential support to ensure their participation in the Program if sufficient need is demonstrated. No Opinion
36
9/30/2020 7:32:55Jerry SenInternet DotTrademark Organisation LimitedNoNo, I would like to continue to the next sectionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)According to Recommendation 25.5, IDN gTLDs identified as IDN variants of already existing or applied for gTLDs will be allowed only if they have the same registry operator and back-end registry service provider. Due to such limitations, the Evaluation Procedure should be simplified, especially the Applicant Reviews. Therefore, the application fee of IDN variant TLDs should be partially exempted.

Also, the application fee floor should not apply to IDN variant TLDs (at least to the first variant application of an existing TLD). The purpose of an application fee floor is to deter speculation and potential warehousing of TLDs, as well as mitigate against the use of TLDs for abusive or malicious purposes. An IDN variant application does not apply to any of above due to those limitations.

The work of IDN Scoping Team on IDN variants TLD application is excellent. But the PDP, procedures and results are not predictable. IDN gTLD registry operators might have to file a full application in the next round.
37
9/30/2020 8:01:49Jim PrendergastThe Galway Strategy GroupNoNo, I would like to continue to the next sectionNew information or interests that the Working Group has not considered
38
9/30/2020 10:35:52Katrin OhlmerDotzon GmbHNoNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNew information or interests that the Working Group has not consideredRationale for Recommendation 9.2: We would like to add that according to our Abuse System, Security Threats seldomly happen under geoTLDs and very rarely under single registrant TLDs such as .brand TLDs.

For a decision whether a waiver for single registrant TLDs is appropriate we recommend a balance between the high relevance of this topic, the accountability of ICANN vis a vis Internet users and any potential voluntary self-commitments of single registrant TLDs.
No OpinionNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)Implementation Guidance 14.4: We recommend to provide an OT&E system for all users, to follow the industry standard. If this is technically not feasible, we agree with the notion from ICANNorg that “allowing some users to have access to the system for beta testing provided those users with an unfair advantage over others.”New information or interests that the Working Group has not consideredImplementation Guidance 14.6: We note that the previous application system did not cater for certain character combinations in the technical descriptions part (the "angle brackets" problem). This caused applicants to re-write certain parts of the technical descriptions of their application in the last minute. We therefore recommend that any future systems be tested against possible character combinations.Do not support certain aspects or all of the Output(s)Implementation Guidance 15.5: To add greater clarity that the cost recovery does refer to the period between the last and forthcoming application period, we recommend amending Implementation Guidance 15.5. as follows:
….For the next application round and each subsequent round, an assessment should take place prior to each round to estimate the application fee that would be necessary to achieve cost recovery for costs which arose between the last and forthcoming application round.”

Implementation Guidance 15.8: We are of the opinion, that “If excess fees are collected in subsequent procedures and the cost recovery model is followed (i.e., the application fee floor is not implemented) any excess fees must be returned to applicants.”
No, I would like to continue to the next sectionSupport Output(s) as writtenNo OpinionSupport Output(s) as written
39
9/30/2020 12:20:20Paul McGradySubmitting these comments on behalf of the IPC.YesThe IPC.No, I would like to continue to the next sectionSupport Output(s) as writtenNew information or interests that the Working Group has not consideredAs to the issue of “Dependencies” for the launch of the next round, the IPC does not agree that determining what dependencies might need to be completed prior to program launch is outside the remit of the Working Group and should be decided elsewhere as provided in the text of 1. b. The Working Group came up with a list of proposed dependencies in its face-to-face meeting in Barcelona and that list was never fully discussed at the Working Group level.Support Output(s) as writtenNew information or interests that the Working Group has not consideredThe IPC notes that the following statement in the Draft Final Report is governed by existing ICANN ByLaws and should therefore be moved to the “Recommendations” section rather than being stated as currently placed in the Implementation Guidance section: 2.2.2 b.
“In fact, the GNSO processes and procedures are incorporated into the Predictability Framework
explicitly. In the event of a conflict, existing GNSO processes and procedures, including the GNSO Input Process, GNSO Guidance Process, and EPDP as contained in the Annexes to the GNSO Operating Procedures take precedence.”

The IPC supports the proposed Predictability Framework generally, but reserves the right for further comment once the details of the SPIRT policy are available in order to support the Topic 2 outputs without reservation.
Do not support certain aspects or all of the Output(s)The IPC supports Affirmation with Modification 3.1 to revise the recommendation simply to read, “Applications must be assessed in rounds.” Processing applications in rounds provides the predictability needed for IP owners to monitor for new TLD applications which may infringe their brands. Similarly, the IPC supports the remaining requirements in Recommendation 3 for ICANN to publish either the date in which the next round will take place, or the specific criteria that must occur prior to opening a subsequent round, and to adhere to this stated cadence.

However, while the IPC does not specifically object to future policy development processes or reviews (e.g. CCT Review) running concurrently with future rounds, the IPC does not support policy recommendations 3.5 through 3.7 to the extent that they would preclude ICANN Org from pausing future rounds for not more than 30 days if ICANN deemed it prudent or necessary to do so in the event of an unforeseen emergency. Following any such 30 day emergency pause, the pause will be lifted unless the ICANN Board votes to keep it in place.
Support Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)The IPC supports the pre-evaluation program as envisioned in Recommendation 6.2. However, the program should not be established without an appeals mechanism allowing RSPs who are denied pre-evaluation status to request the reconsideration of the decision. RSPs being able to market themselves as pre-evaluated before an application round has started have a considerable competitive advantage that should not be underestimated. Even though pre-evaluation is a voluntary process and does not preclude RSPs from supporting applications and be evaluated again during the application window, there is a high risk that
applicants do not trust or choose RSPs that have not been pre-evaluated.

Choosing a pre-evaluated RSP also reduces the risk of additional costs during the application process. ICANN charges an additional fee when an extended review of one or more registry services is required during standard evaluation. Obviously, such fee does not apply if the evaluation has already been carried out before the filing of the application.

The competitive advantage of pre-evaluated RSPs is further increased through
Recommendation 6.9, providing that a list of pre-evaluated RSPs is timely published on ICANN’s website. This provides for an additional marketing tool for pre-evaluated RSPs. Therefore, RSPs who are denied pre-evaluation status deserve an adequate remedy for challenging ICANN’s decision.

Additionally, the IPC does not believe that an applicant who indicates that it will use a pre-evaluated RSP should have to select that RSP prior to filing its application. Such an applicant that indicates it intends to use a pre-evaluated RSP should be allowed to defer completion of the technical topics in the application and/or can defer selection of an RSP until the applicant is ready to sign a Registry Agreement with ICANN.
Not ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredThe IPC supports this recommendation, and further suggests taking into account the IBA Guidelines on Conflicts of Interest in International Arbitration (2014), available on https://www.ibanet.org/Publications/publications_IBA_guides_and_free_materials.aspx#Practice.
Do not support certain aspects or all of the Output(s)The IPC does not support certain aspects of this Output. Some within the IPC cannot support Recommendation 9.15, by which the SubPro WG elects to postpone a solution to the ongoing problem of DNS abuse. The IPC believes it was squarely within the remit of the WG to proactively address DNS abuse in the context of new TLDs, and some in the IPC are disappointed that the WG has published their draft final report without formulating any such solutions. To the extent the WG believes a holistic approach to DNS abuse is needed, the IPC agrees. However, some within the IPC do not believe it is wise to move forward with a new round of TLDs -- guaranteeing an expanded field of domains for abuse to be carried out -- without creating solutions. Others within the IPC believe that proceeding with the next round is acceptable, so long as there is a corresponding PDP instituted to address systematic DNS abuse, including intellectual property abuse, the outcomes of which once developed would apply across all gTLDs keeping in mind the unique nature of .Brand TLDs. The IPC remains very concerned that the postponement on DNS abuse solutions by the SubPro PDP only grants more time to bad actors to continue their abusive behaviors in both the existing TLDs, and soon in new TLDs in the absence of solutions. The IPC believes the security and stability of the DNS will continue to be under attack until a solution on DNS abuse has been developed and calls for quick action by the Council to institute a PDP on DNS Abuse without further delay.
Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenWe did not choose the oval above, but the oval two prior (Not ideal, but willing to accept Outputs as written). However, there is no text field to explain reasoning for the first three options of support/non-support (even though Working Group members pleaded with PDP Leadership to include such fields). So, this comment will have to go here.

The IPC supports the spirit and good intentions behind applicant support. However, the IPC urges that any such support does not result in the bringing into existence of non-viable registries who later place second level registrants at risk.
The IPC does not support the elimination of such fees as it does not believe that the ongoing subsidization of registry business models that are not self-sustaining is not in the interests of second level registrants.
Support Output(s) as written
40
9/30/2020 13:29:30Flip PetillionSubmitting these comments on behalf of the PETILLION law firm.NoSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredThe formation of a body such as SPIRT should be done independently of the launch of the next application round in order to avoid further delay.Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)PETILLION fully endorses the IPC’s position on this point, which is incorporated herein by reference. In addition, RSPs who are denied pre-evaluation status should be given full transparency about the reasons for such denial and about the qualifications and background of the pre-evaluators involved.Support Output(s) as writtenNew information or interests that the Working Group has not consideredPETILLION recommends taking into account the IBA Guidelines on Conflicts of Interest in International Arbitration (2014), available on https://www.ibanet.org/Publications/publications_IBA_guides_and_free_materials.aspx#Practice. Not ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenPETILLION endorses the IPC’s position on this point, which is incorporated herein by reference.PETILLION endorses the IPC’s position on this point, which is incorporated herein by reference.Not ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not considered
41
10/1/2020 2:40:16Nick Wenban-SmithNominet UKYesccNSO CouncilNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo OpinionSupport Output(s) as written
42
9/30/2020 13:48:44Vincent GouillartMinistry for Europe and Foreign Affairs - French RepublicNoNo, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)France, though thankful for these interesting new ideas, has reservations concerning the Standing Predictability Implementation Review Team (“SPIRT”). We commend the idea of trying to deal with unforeseeable events and strengthening predictability mechanisms. However, France believes that the creation of the SPIRT could have far-reaching consequences and will therefore pay close attention to the details of its possible implementation.

It has come to our attention during ICANN 68 that GAC would not be able to refer a matter to the SPIRT and would instead have to issue GAC Advice to the ICANN Board asking it to refer said matter the SPIRT. We regret this proposal, as we believe that all ACs and SOs should be able to refer matters directly to the SPIRT. In particular, since GAC Advice already has to go through in-depth discussions and reach consensus, we do not think it justified that it should go through the “filter” of the ICANN Board before being addressed to the SPIRT. What is more, allowing all ACs and SOs to refer matters to the SPIRT would accelerate the gathering of suggestions on the ongoing new gTLD Application Round and make the whole system more reactive.

France also fears that referring matters to the SPIRT through GAC Advice only may create a presumption, in the eyes of the ICANN Board, that any GAC Advice issued on the Round after its launch must be passed on to the SPIRT, which will then examine the GAC’s request and transfer it to the part of the ICANN Community it deems relevant. Such possibility would undermine the GAC’s prerogatives and its ability to weigh in on the Round. As a result, France is in favour of allowing the GAC to refer matters directly to the SPIRT, or, at least, of making it clear in the Final Report that GAC Advice, apart from that explicitly asking the ICANN Board to refer certain matters to the SPIRT, is destined solely to the ICANN Board and not to be passed on to the SPIRT, even if it concerns the ongoing Round.
Not ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredFrance has reservations about the “application floor” proposal. While this is an original idea serving a useful purpose (dissuading nefarious actors from applying to a gTLD), it is unclear how ICANN org would calculate the relevant level for this “floor”. Dissuasion rests on psychological mechanisms, whose translation into monetary thresholds often proves uneasy. Given the difficulty of such a task, we are afraid that such a “floor” may end up being a rough estimate or, in layman terms, reflect the “gut feeling” of its authors than be a strongly-documented and -backed calculation.

If this proposal is maintained, France believes that the calculation of the “application floor” by ICANN org should be both strongly-backed and fully transparent: it should disclose, among others, the arguments, studies, etc. upon which the calculation is based. As a result, Implementation Guidance 15.6 (“The development of the application fee should be fully transparent with all cost assumptions explained and documented.”) should not only concern the development of the Application Fee, but also that of the Application Fee Floor, a provision that is not yet included in the Draft Final Report.
43
9/30/2020 13:55:35Sivasubramanian MuthusamyNameshopYesNameshopNo, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)In Topic 3, Implementation Guidance 3.4 we note the conditions where “in general [it] not be possible to apply for a string that is still being processed from a previous application round.” However, that guidance falls short when attempting to address cases where an application has been marked, “will not proceed.”

There is at least one instance we know of, and likely more, where the applicant and ICANN staff are likely to disagree as to whether, “[a]ll appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or [a]ll applicable time limitations (statute of limitations) have expired.”

There are a variety of factors that might contribute to this type of outcome: vagueness in the procedures about tolling, and the timing and extent of a Cooperative Engagement Process, and differences of opinion about compliance of ICANN with its own review procedures.

In existing cases, if the subsequent procedures process relies on the opinion of ICANN staff or an ICANN declaration that states, for example, that, “appeals are exhausted,” then irreparable harm might befall the applicant as the investment in the application, its mission, and many ICANN time consuming and expensive review processes would be lost forever.

It is much better, we think, that deference be paid to applicants of previously applied-for TLD labels and that evidence of relinquishment by the applicant be required or, absent that, a check should be made with the applicant that the TLD label is available again.

As a balancing test, It is preferable to avoid the irreparable harm of mistaken forfeiture versus potentially holding back a single string for an additional round.
44
9/30/2020 16:37:38Steve DelBiancoNetChoiceYesThe ICANN Business Constituency (BC).

These comments were drafted by Mason Cole, Tim Smith, and Statton Hammock, with edits by Chris Wilson, Steve DelBianco, Andy Abrams, and Alex Deacon.

These comments were approved in accord with the BC Charter.
No, I would like to continue to the next sectionSupport Output(s) as writtenNo OpinionDo not support certain aspects or all of the Output(s)The BC appreciates the thorough analysis that has been given to creation of the SPIRT as a mechanism to deal with the Predictability Framework. In Annex E we note that the SPIRT does not require broad representation across the ICANN community when it states “The SPIRT should be open to all interested parties, but may not necessarily be representative of the ICANN community, as actual participation may depend on interest and relevance of the new gTLD Process. Membership criteria should identify knowledge, experience, responsibilities to their respective organization, rules of engagement, a Statement of Participation, etc.” While we agree with these basic qualifications, we believe that the SPIRT should be representative of the ICANN community and that specific qualifications should be determined before adopting the process.Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo OpinionDo not support certain aspects or all of the Output(s)The BC believes that all the same obligations should apply for all applicants with regard to Mandatory Public Interest Commitments (PICs) currently captured in Specification 11 3(a)-(d) of the Registry Agreement
without exception.

The BC further believes that steps -- even incremental steps -- to combat domain name system abuse are warranted. Accordingly, the BC diverges with the working group here and advocates the inclusion of enforceable DNS abuse mitigation measures in contracts governing new gTLDs.
Support Output(s) as writtenNo, I would like to continue to the next sectionNo OpinionNew information or interests that the Working Group has not consideredThe BC supports The Working Group’s recommendation that ICANN should clearly and thoroughly illustrate the possible problems that IDN registrants may face with user and platform acceptance, as well as the work previously initiated to address this challenge. We believe strongly that ICANN must commit resources to address universal acceptance and note that the Final Report includes a recommendation to resource future work to address various technical issues.
No OpinionDo not support certain aspects or all of the Output(s)The BC believes that businesses in all regions of the world should have equal access and opportunity to apply for TLDs in the next round. Accordingly we believe that the AGB should be published simultaneously in English and the 6 UN languages, both 4 months prior to the commencement of the application submission period. Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as written
No. Applicants must be financially capable of running a registry. Applicants may qualify for assistance in preparing their application but once they sign the registry agreement they should be financially sound and be able to meet the ongoing fee obligations in Article 6. The BC has expressed previously that it does not support subsidizing registry businesses although it does support the application support measures recommended by the Working Group. Please see https://www.bizconst.org/assets/docs/positions-statements/2017/2017_05May_22%20BC%20reply%20to%20questionnaire%20on%20new%20gTLD%20Subsequent%20Procedures.pdf at Page 3.
Support Output(s) as written
45
9/30/2020 14:59:15Lori SchulmanInternational Trademark Association (INTA)YesINTA is a global association of brand owners and professionals dedicated to supporting trademarks and related intellectual property (IP) to foster consumer trust, economic growth, and innovation. Our membership comprises nearly 6,500 organizations from 185 countries. The organizations represent more than 34,350 professionals, including brand owners from major corporations, small- and medium-sized enterprises, law firms, and nonprofits. Our community also includes government agency members, professors, and law students. INTA is a founding member of the Intellectual Property Constituency of ICANN.No, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)While INTA accepts the recommendation on this, we are disappointed in the outcome regarding discussions on DNS abuse, particularly in light of the GAC’s instructions on this topic. We agree in principle that DNS abuse should be addressed holistically, such that improvements are applicable to all gTLDs and not just future gTLDs. However, we would strongly urge the community to identify a concrete policy development path forward for having that holistic discussion, which is empowered to craft binding recommendations on this subject. We believe the Sub Pro PDP would have a role in providing input or otherwise supporting that effort and implementing any outcomes. Support Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)INTA continues to support a reduced fee process for .Brand applicants, given the lighter-touch evaluation process for such TLDs compared to open TLDs. In addition, excess fees should be applied to initiatives which would improve trust in the DNS, particularly around security threats, malware, fraud and intellectual property infringement rather than promoting new gTLDs generally. Further, INTA continues to support that any excess funds be allocated to ensure that there is robust monitoring and enforcement of the contractual commitments made by applicants and by registrars selling those names. INTA supports the concept of the segregated fund, and suggests that the fee floor/cost recovery concept be tied in with frequent review of segregated fund and adequate reserve, even though that might result in frequent adjustments to the fee floor/cost recovery amounts. Otherwise, INTA supports the Recommendations on this Topic.

Support Output(s) as writtenDo not support certain aspects or all of the Output(s)Although INTA supports the majority of the Topic 17 Recommendations, INTA suggests that Implementation Guidance 17.7 be clarified such that the restrictions against gaming not apply solely to Applicants getting Applicant Support who prevail in an auction – such restrictions should apply to this category of supported applicants regardless of how they ultimately secure the right to operate the applied-for TLD (they could just as easily prevail in acquiring the TLD without going to any auction and subsequently transfer to a third-party operator at a cost much lower than a non-supported applicant could have). In addition, the WG may wish to consider instead of elimination or a fixed reduction in registry fees, that a percentage of revenue scheme be adopted that would provide both a shared risk and promise of recovery of some or all normal fees for supported applicants.

Support Output(s) as written
46
9/30/2020 16:52:00Ephraim Percy KenyanitoARTICLE 19YesARTICLE 19No, I would like to continue to the next sectionSupport Output(s) as writtenOn the first topic, we welcome the first affirmation, which maintains the policy contained in the 2012 Applicant Guidebook that recommends that a “systematized manner of applying for generic Top Level Domains (gTLDs) be developed in the long term.” We also welcome the second affirmation that states the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable way.” ARTICLE 19 notes that this New gTLD Subsequent Procedures Initial Report and Public Comment Process is an attempt to develop recommendations using lessons learned from the 2012 process and we are happy to submit our comments under each of the 40 topics below.

Lastly, we welcome the third affirmation that the primary purpose of new generic Top Level Domains (gTLDs) are to foster diversity, encourage competition, and enhance the utility of the DNS. ARTICLE 19 notes that for freedom of expression and information to be fully exercised online, the Internet needs to be maintained and governed with this public interest goal at the forefront.
We welcome further engagement opportunities and avail ourselves to be of assistance in case of any questions or concerns.
Not ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredOn this topic, we welcome the fixed setting of predictable timeframes and procedures by the Working Group. We note that setting timeframes and procedures upfront provides generic Top Level Domains (gTLDs) applicants with fair and set rules by which they can gauge themselves and ICANN to ensure that the application process is being governed in a fair manner for everyone, as set out in the Applicant Guidebook and base Registry Agreement.

However, we recommend that the Standing Predictability Implementation Review Team (SPIRT) be reviewed on an annual basis and that results of any review should be made publicly available. This would ensure that any future policy changes to the program are informed by clear metrics.
Support Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredWe welcome the drafting of Recommendation 4. to allow for differential treatment of applications based on either the application type, the string type, or the applicant type. However, we find that the elements of differential treatment to be too limited despite the six categories (Applicant eligibility; Application evaluation process/requirements; Order of processing; String contention; Objections and Contractual provisions) being broad enough.
We recommend that fees should also be made an explicit category for differential treatment, as the topic should be drafted to provide exceptions or concessions, especially for strings that are for non commercial exercise of freedom of expression.
Support Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredWe welcome the work of the Working Group regarding this topic and support the regular collection, review and publication of relevant anonymized data to understand the impact of the New generic Top Level Domain (gTLD) Program.
We believe that in order to make future policy regarding the generic Top Level Domain (gTLD) Program and the DNS space, these decisions will be greatly informed by the data collected. We additionally request that the recommendations are redrafted to ensure that this data is collected, used, stored and disposed in line with international standards for data protection and with respect to the right to privacy.
Support Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNew information or interests that the Working Group has not consideredWe welcome the work of the Working Group regarding the topic. We especially highlight the fact that the language attempts to meet Recommendation 25 of the Competition, Consumer Choice & Trust (CCT) Recommendations that voluntary commitments must a) allow sufficient opportunity for community review, b) set limited Public Interest objection deadlines c) include intended goal and d) Be organized, searchable.
However, we recommend an amendment to Recommendation 9.1 and 9.2 to mandate that all RVCs must be in line with international human rights best practices by requiring registries and registrars to use tools such as human rights impact assessments to document and justify the balance of legitimate interests, and that the Specification 11 should reflect ICANN’s Human Rights Core Value.
Support Output(s) as writtenNo, I would like to continue to the next sectionNot ideal, but willing to accept Outputs as writtenWe welcome the work of the Working Group regarding this topic. However, we note that Affirmations 11.1, 11.2, Recommendations 11.3 and Implementation guidance 11.4 fail to go far enough to provide metrics to measure the success of Universal Acceptance adoption.
We believe that Universal Acceptance is important as it facilitates the ability for all groups and individuals to participate on the Internet using domains that reflect their local languages and scripts, and ensures that they do not face undue obstacles based on their geographic or regional representation, language, gender, age, physical disability, diverse skills, stakeholder group or constituency.
We thus recommend that the section must clearly introduce metrics to measure adoption that registries and registrars should be compelled to publish regularly, and the public disclosure of policies available to ensure the successful adoption of Universal Acceptance across all registries and registrars.
New information or interests that the Working Group has not consideredSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenWe welcome the work of the Working Group regarding this topic and support the affirmations and recommendations as written. We however request that the Systems are created in a manner through which any interested party receives updates on any indicated application, without any limiting criteria.
We believe that allowing all interested parties to receive updates on any indicated application further supports implementation of Workstream 2 Recommendations and supports the rights of both the applicants and the public to effectively participate in the governance of the DNS.
Do not support certain aspects or all of the Output(s)We welcome the work of the Working Group regarding this topic. However, we note that the recommendations fail to go far enough on the issue of fees and refunds, especially for applicants from the Global South or community organizations and thus request that the Working Group should propose exact fees and that recommendations should be drafted providing exceptions or very affordable fees especially for strings that are for non commercial exercise of freedom of expression.New information or interests that the Working Group has not consideredNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenWe welcome the work of the Working Group regarding this topic. We especially welcome Recommendation 17.2, expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees and attorney fees related to the application process.
This support is welcome, especially for applicants from the Global South or community organizations and for non commercial exercise of freedom of expression.
Support Output(s) as written
47
9/30/2020 16:55:45Michael FlemmingGNSOYesGMO Brights Consulting Inc.No, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as written
48
9/30/2020 17:54:44Zoe BonythonRrSGNoNo, I would like to continue to the next sectionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNo OpinionNew information or interests that the Working Group has not consideredThe RrSG believes that the option of allowing for the selection of pre-evaluated RSP's is a substantive change to the Applicant Guidebook. The Applicant Guidebook should make it clear that if the applicant is choosing to utilize a pre-evaluated RSP, the applicant does not need to complete the technical section of the application, nor do they need to actually have selected an RSP at the time of the application submission. This will allow applicants to focus on the business aspects of their application and defer the selection of their RSP and other technical vendors until needed before entering into a Registry Agreement with ICANN. This can allow applicants to select RSPs that will best serve the applicant’s needs, potentially resulting in less registries changing back-end providers (which results in increased costs for registrars and registrants). No OpinionNo OpinionNo OpinionNo OpinionNew information or interests that the Working Group has not consideredAlthough the RrSG generally supports the Applicant Support Program (ASP), the RrSG would like to ensure that any candidate receiving applicant support meets all of the stringent requirements of the other registries and that they conform to the technical standards. This is necessary to ensure that any registry from the ASP is interoperable with all registrars. The goal of the ASP is to help with some of the needed financial resources and other services, but not at the expense of security and stability of the DNS.No Opinion
49
9/30/2020 18:32:47Christa TaylorIndividualNoNo, I would like to continue to the next sectionNew information or interests that the Working Group has not consideredRecommendation 13.3 notes the communication period should begin ‘at least six months prior to the beginning of the application submission period’ and is only one component that needs to be incorporated in a well-designed and comprehensive Applicant Support program. The communication period needs to provide ample runway to design, develop and implement an effective outreach program to potential applicants to ensure the program and its applicants have the best chance of success. New information or interests that the Working Group has not consideredOther aspects for consideration:

15.5 the application fee floor should also consider that new gTLDs are a valuable piece of the Internet and be reflective of the commitment of owning and operating a TLD. As such, an evaluation of the fee floor should be conducted and updated for each application round.

15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9. This will help ICANN remain efficient while ensuring the costs related to the return of the fees do not exceed the resources required to return the excess to applicants. These funds could be used for items in Recommendation 15.9.

15.10 Periodic review should be conducted at a minimum of once every application round to ensure the contingency funds are adequately funded.

15.8 Excess funds should be returned to applicants in a timely manner. Options could include a percentage of the processing of applications for a specific application round i.e. 90%, predetermined time period i.e. 24 months or a credit against future ICANN fees. Timing should be provided before the application period opens.

A section on how Applicant Support fees are set would be useful and should be included.
No, I would like to continue to the next sectionOther aspects for consideration:

17.2 financial support should be clarified and/or expanded upon to include a variety of professional fees (beyond application writing and attorney fees) such as financial viability, securing funding, etc.

17.5 Significant concerns on how bid credits, multipliers, and other features may be used in other unintended ways beyond benefiting AS applicants, and how the risk of gaming can be mitigated.

(see 35.2) Applicant Support applicants who have access to bid credits, multipliers, other should be protected from more sophisticated applicants who benefit financially from entering into a business combination or joint venture.

17.9 Metrics should include: a) number of applicants who received bid credits, multiplier, other and were successful in auction; b) number of applicants who withdrew from auction; c) number of applicants who entered in to a business combination or other forms of joint ventures; d) the value of the bid credits, multiplier, other; and e) length of time before any change of ownership occurred.

17.13 The amount of funding should be determined and communicated before the commencement of the application round. This will provide potential applicants with insight on their potential likelihood of success and whether they should apply for funding. It will also provide the information required to 17.14 in seeking additional funding partners without delay.
If there are difficulties in attaining the relevant funding, then the weighting of 15.9 (c) should be increased to help fund potential AS in future rounds.

17.17 financial support should include application fees and any related bid credit, multiplier or related benefits received by the applicants. Clarification on any amounts related to 17.2 should be described, i.e., professional services.

17.17 ‘Going out of business’ should be clearly defined to avoid any ambiguity, i.e., where the TLD is unable to meet their financial obligations and unable to secure financing or restructure operations to carry out operations in the short-term
New information or interests that the Working Group has not considered
50
9/30/2020 18:52:20Paul FoodyIndividualNoNo, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)i) Replication of DotCom at the Top Level

ICANN still claims the new gTLD program will encourage competition and diversity.

An expanded gTLD program, simply replicating the DotCom registry at the Top Level, will increase the price of an internet presence from the dollars per annum cost today for a DotCom domain to millions of dollars for a TLD “domain” with the same impact.

Given the Sydney 2009 comments of ICANN economist, Steve Salop, that the key to competition is low entry costs, the massively increased cost of a new gTLD internet presence will erode and then destroy competition.

Furthermore, due to the considerable legal challenges involved in “proving” legal rights to any TLD string, including generic terms for which no rights exist, ownership of new TLDs will soon be limited, if not immediately, to only the largest corporations with unlimited legal budgets, destroying diversity.

Nothing in the new draft acknowledges or addresses this, I believe, inevitability.
New information or interests that the Working Group has not consideredii) The Sale of Language

As an observer of the New gTLD working group and its numerous meetings and emails, I have seen considerable discussion regarding the topic of closed generic terms. The general consensus seems to be that the sale of generic terms for such use will not affect the use of language since the addition of a “dot” will not create sufficient distinction from generic roots to create legal rights that would limit the use of its generic root.

However, I have not seen any discussion regarding the possibility of companies with multiple generic TLDs seeking to restrict the use of generics in its TLD ownership portfolios when combined with other generics also in its ownership.

The laws which have been introduced by Olympic Games’ Host Governments restricting the use of 3 & less, everyday words in adverts, excepting the adverts of Games’ sponsors, has surely established a precedent which prospective owners of multiple generic terms will be aware of and looking to take advantage of and even expand.

If this is an issue that has been discussed by the GNSO working group and I have missed it, I apologise and would ask to see the relevant debate, but if this issue has not even been raised, the GNSO has no option but to put the new TLD program on ice pending a global discussion on this extremely important issue or scrap the new gTLD program completely.
No, I would like to continue to the next section
51
9/30/2020 18:52:55Brian WinterfeldtWinterfeldt IP GroupYesThese comments are submitted on behalf of the Global Brand Owner and Consumer Protection Coalition (GBOC). GBOC is an organization of global industry-leading businesses and brand owners working together to address common concerns in the online consumer and brand protection space. Members of GBOC represent leaders in software and technology, consumer goods, hospitality, and apparel, among other sectors. No, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenNot ideal, but willing to accept Outputs as writtenGBOC supports the concept of proceeding with discrete future application rounds but with the exception of permitting the rolling opportunity for new .Brand applications outside the normal cycle. Otherwise, GBOC supports these Outputs as written. Support Output(s) as writtenSupport Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)While GBOC accepts the recommendation on this Topic, we would strongly urge the community to identify a concrete policy development path forward for having the envisaged holistic discussion regarding DNS abuse, which is empowered to craft binding recommendations on this subject. The current reference to some vague future holistic discussion or process is not sufficient to advance this critically important topic and achieve much needed enhancements in this area.Support Output(s) as writtenNo, I would like to continue to the next sectionSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)GBOC has supported a reduced fee process for .Brand applicants, given the lighter-touch evaluation process for such TLDs compared to open TLDs. In addition, GBOC continues to prefer that excess fees be applied to initiatives which would improve trust in the DNS, particularly around security threats, malware, fraud and intellectual property infringement rather than promoting new gTLDs generally. In this vein, GBOC continues to support the use of any excess funds to ensure that there is robust monitoring and enforcement of the contractual commitments made by applicants, registry operators, and registrars. Otherwise, GBOC supports the Output on this Topic.
No, I would like to continue to the next sectionSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)Although GBOC supports the majority of the Topic 17 Recommendations, GBOC suggests that Implementation Guidance 17.7 be clarified such that the restrictions against gaming not apply solely to Applicants getting Applicant Support who prevail in an auction – such restrictions should apply to this category of supported applicants regardless of how they ultimately secure the right to operate the applied-for TLD (they could just as easily prevail in acquiring the TLD without going to any auction and subsequently transfer to a third-party operator at a cost much lower than a non-supported applicant could have).GBOC would support, in principle, a reduction or elimination in ongoing registry fees for Applicant Support-eligible candidates who are ultimately awarded the right to operate the applied-for TLD, subject to a possible cost-recovery for ICANN based on some kind of revenue-sharing by the Applicant (Registry) – perhaps if the registry generates above a certain threshold in revenue over a given period (perhaps quarterly), a portion of such revenue would be shared with ICANN to cover a portion of the reduced or eliminated ongoing registry fees.Support Output(s) as written
52
9/30/2020 23:18:29Michael PalageInfoNetworks LLCNoNo, I would like to continue to the next sectionDo not support certain aspects or all of the Output(s)I believe that Affirmation should be amended to explicitly include a specific reference to the "security" of the DNSNo OpinionNo OpinionNo OpinionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)While the imposition of artificial limits are not desirable, the process must account for either ICANN or the GAC to raise competition concerns that may arise under national law. Nothing in the provision should be interpreted as blocking either ICANN or the GAC from raising these concerns.No, I would like to continue to the next sectionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)I believe that the last sentence in Implementation Guidance 6.7 should be stricken. The GNSO ICANN community is not static, and including language preventing RSP from being considered a contracting party seems inappropriate. As evidenced in the last round where the issue of vertical integration was discussed, ICANN contracting parties do not live in a neat binary world of Registries and Registrars. The future evolution of the CPH could include RSPs and/or Privacy-Proxy Providers. This language should be stricken as it does not directly impact the new gTLD process and could be used improperly to impede the future expansion of the CPH within the GNSO.No OpinionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)In connection with Community Objections and Community Priority Evaluations, there is a need for panelists with a knowledge of the alleged community. This proposed wording could/would be used to block potential panelist with knowledge of the alleged community from serving. To put this in more layperson terms, if participants in the SubPro group that will have a commercial interest in the next round of new TLD were not blocked from participating under a conflict of interest standard, a panelist with knowledge of the alleged community should similarly not be blocked absent a clear material conflict - "red" unresolvable conflict.Do not support certain aspects or all of the Output(s)I believe the proposed amendments water down important safeguards that were implement at the request of the GAC. This topic will need further discussion among the broader community before a final Applicant Guidebook can be published.

The inability for SubPro to reach consensus on the concept of "verified TLDs" was disappointing but not totally unexpected given the composition of the SubPro Working Group. The concept of "trust" is referenced several times in this final SubPro Report and ICANN's bylaws. However, it is hard to operate a "trusted" network when there are no Know Your Registrant (KYR) incentives.
No OpinionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)In connection with the "New Issues" section of this topic, I fully support the need for ICANN to be more visible in the important of UA both with ASCII and IDN. While ICANN should be applauded for the financial support that it has provided UA group, of which I have participated in the past, ICANN has not been nearly visible enough in raising this issue. This must be an IMMEDIATE priority over the next period of time that ICANN is finalizing this policy and the corresponding Applicant Guidebook. No OpinionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)While I appreciate the advocacy of commercial interests wanting to promote an aggressive communication time line, the fact that translations of the Applicant Guidebook will not be available until two months before the start of the submission date is problematic . I have personally worked with for-profit, non-profit, and governmental applicants from developed, emerging and developing economies in connection with standard, community and geographic applications. While six month is acceptable for a commercial applicant from a developed economy, two months for a non-commercial applicant from a emerging/developed economy whose does not read and speak English fluently is deeply concerning. Support Output(s) as writtenNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)ICANN Org needs to find a way to promote innovation without unreasonably burdening Applicants with excessive fees. Upon information and belief, ICANN has never returned a dime of any excess proceeds to Applicants from the 2000, 2004 or 2012 round. Therefore, it is highly doubtful that they will do so again in the next round(s). Therefore, Applicants should not be penalized with any excessive fees if there is an underlying public interest being advanced in connection with the proposed service. Do not support certain aspects or all of the Output(s)As noted above, there is a potential bias against non-English reading/speaking applicants that will not have a full translation of the Applicant Guidebook until two months prior to the application window. With this proposed 13 week submission window coupled with the two month (8 week) translation window it would be extremely for a non-English speaking not-for-profit applicant from a developing economy to meet this aggressive timeline.Do not support certain aspects or all of the Output(s)While it is important to recognize the Herculean effort that the SubPro Working Group undertook to address a fundamental short coming from the 2012 round, it unfortunately still falls short of addressing the needs of prospective applicants/Registry Operators for emerging and developing economies. This poses a rather fundamental question to ICANN Org of whether it is a global trustee of the Internet's unique identifiers or a quasi trade association for Contracting Parties and the professional consultants and lawyers that service them. As an individual that has provided profession consulting services to Contracting Parties over the last twenty years, I am keenly aware of the danger that ICANN faces of being perceived a mere trade association for contracting parties on the global stage. That is why this aspect of the Applicant Guidebook must be addressed and not merely sweep under the rug on the fears of "gaming" raised largely by portfolio applicants or their consultants. New information or interests that the Working Group has not consideredIn connection with the original "proof of concept" Round in 2000 when ICANN processed over 40 applications in approximately 3 months(start to finish) one of the Sponsored TLD selected was .MUSEUM. While most will claim it has failed to reach commercial success, it nevertheless serves a small distinct community on the Internet. That Registry today still pays $500 a year in Registry Fees to ICANN, not a $25,000. Of course this Registry Agreement was entered into when ICANN's annual budget was a mere 7 digits. Yes the economics as noted above in the case of .MUSEUM show that ICANN must do more or run the risk of being perceived on the international stage as a mere trade association. Do not support certain aspects or all of the Output(s)I oppose Recommendation 18.1. While I appreciate the efforts of the SubPro Working Group to provide predictability to prospective Applicants, the interests of prospective Applicants cannot jeopardize the creditability of ICANN on the global stage. This is even more of a concern now in light of increasing geo-political tensions that threaten a unified root. As evidenced in the 2004 round with .XXX and the 2012 with .AMAZON there will be a controversial string in the next round that we cannot yet anticipate. This Recommendation will only handcuff the ICANN Board from exercising its fiduciary duty and potentially undermine its standing on the global stage as the trustee of the Internet's unique identifiers.
53
10/5/2020 16:39:39Milton MuellerInternet Governance project, Georgia Institute of TechnologyYesInternet Governance Project No, I would like to continue to the next sectionNot ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)The goals of this section are self-contradictory. Either you have a predictable, transparent, and fair process OR you have a "process for managing issues that arise". A predictable and transparent process means that the criteria for new TLDs are set out in advance and there are fair procedures for determining compliance with the, and anyone who complies with them gets accepted. The creation of yet another standing committee (SPIRT) will be the opposite of predictable. It will allow people who want to oppose particular applications to raise "issues" after the application guidebook has been defined, regardless of the original criteria, simply because they don't like the applicant or the type of service proposed. Not ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)This attempt to categorize TLDs and create different rules for them is a waste of time. A TLD is a TLD. Support Output(s) as writtenSupport Output(s) as writtenNo OpinionSupport Output(s) as writtenDo not support certain aspects or all of the Output(s)PICs should all be abolishedDo not support certain aspects or all of the Output(s)Implementation guidance 10.2 undermines everything the freedom of expression requirement is meant to protect. There is no legal basis for "balancing" free expression rights with third party "legitimate interests" (which just means an attempt to suppress speech). No OpinionSupport Output(s) as writtenSupport Output(s) as writtenNo OpinionSupport Output(s) as writtenNo OpinionNo OpinionNo Opinion
54
Entered by ICANN Org StaffICANN BoardICANN BoardNoA. The Board welcomes recommendations to support predictability in future new generic top-level domains (gTLDs), and is encouraged by the thoughtful discussion that has taken place on this subject within the PDP WG.
B. The Board encourages the PDP WG to provide as much detail as possible to ensure clarity around the roles and responsibilities of the GNSO Council, ICANN org, applicants, objectors, other SO/ACs as well as the Board vis-a-vis the predictability framework. To inform implementation, the PDP WG may find it useful to provide case studies to illustrate roles and responsibilities of these different actors if and when changes to future application round processes are proposed and/or required.
C. . With regardtotheproposedStandingPredictabilityImplementationReviewTeam (SPIRT), the Board encourages the PDP WG to consider whether there are established processes within the GNSO (or within ICANN’s multistakeholder model) that might serve the intended role(s) of the SPIRT, rather than creating new ones.
D. TheBoardencouragesthePDPWGtoconsiderwhetherrecommendationsareneeded to avoid any unintended impact of the predictability framework on the necessary effectiveness and flexibility of ICANN org when implementing future new gTLD rounds. In this context, the Board notes Annex E that states “The SPIRT shall strive towards achieving Consensus on all advice and/or recommendations from the SPIRT. Even if consensus is not reached, the SPIRT can provide input on any particular issue received, as long as the level of consensus/support within the SPIRT is reported using the standard decision making methodology outlined in section 3.6 of the GNSO WG Guidelines.” The Board believes it might be helpful to recommend a timeframe by which the SPIRT needs to reach a decision. (Pg. 16)
E. It may also be useful for the PDP WG to consider the role of precedent in the Predictability Framework, e.g., can SPIRT recommendations form a body of decisions to guide handling of issues and increase efficiencies? (Pg. 16)
F. The Board notes that the Predictability Framework cannot replace the ICANN Board or org's need to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities.
The Board notes the affirmation of the revenue-neutral approach for future new gTLDs. (Pg. 31)A. The Board notes that as part of the restatement of ICANN’s mission as reflected in the post-IANA Stewardship Transition Bylaws, the current form of the Registry Agreements were explicitly excluded from challenge on grounds that they exceeded ICANN’s mission. See Bylaws, Section 1.1(d)(ii)(A)(1) and (2). This exclusion was brought about in large part by concerns from some in the community that some of the PICs within the Registry Agreements were outside of ICANN’s technical mission. The community did not wish to invalidate those contracts through the revised mission statement. The language of the Bylaws, however, could preclude ICANN from entering into future registry agreements (that materially differ in form from the 2012 round version currently in force) that include PICs that reach outside of ICANN’s technical mission as stated in the Bylaws. The language of the Bylaws specifically limits ICANN’s negotiating and contracting power to PICs that are “in service of its Mission.” The Board is concerned, therefore, that the current Bylaws language would create issues for ICANN to enter and enforce any content-related issue regarding PICs or Registry Voluntary Commitments (RVCs). Has the PDP WG considered this specific language in ICANN’s Bylaws as part of its recommendations or implementation guidance on the continued use of PICs or the future use of RVCs? Can the PDP WG provide guidance on how to utilize PICs and RVCs without the need for ICANN to assess and pass judgment on content?
B. In its comment on the Initial Report, the Board asked the PDP WG to give more clarity on how to frame “public interest” in the context of a PIC and the PIC Dispute Resolution Procedure (PICDRP). We note that this has not yet been developed. We would like to reiterate our view that clear guidance on this issue will be valuable, and we encourage the PDP WG to work to that end. Specifically, we ask that the PDP WG provide clear and consistent implementation guidance on “public interest” in this context, to ensure that objective enforceability lies within ICANN’s mission. (See also our comment on Topic 24 below.)
The Board notes the PDP’s Recommendation 15.7: “In managing funds for the New gTLD Program, ICANN must have a plan in place for managing any excess fees collected or budget shortfalls experienced. The plan for the management and disbursement of excess fees, if applicable, must be communicated in advance of accepting applications and collecting fees for subsequent procedures.” The Board asks the PDP to more carefully examine the concept of “excess” or shortage of fees, especially in the light of the likely need for ICANN org, a not-for- profit organization, to increase resources for the application process and the continued support of the new gTLD program. The proposed principle of cost recovery of the next round, as for the 2012 round is understood as a clear mechanism to state to the public that the fee to be paid by applicants is designed to only cover for the cost of the program and not to support non-program operations of ICANN org. the proposed principle does not require a dollar-to-dollar return of any potential excess. The lack of a clear definition of “closure” and “round” for any new gTLD subsequent procedures future ‘round’ is also problematic in this context and the Board encourages the PDP WG to contemplate including such definition in its Final Report. (Pg. 63)A. The Board notes that “The Working Group recommends expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees and attorney fees related to the application process” (Recommendation 17.2). The expansion of applicant support to affirmative payments of costs beyond application fees could raise fiduciary concerns for the Board. We encourage the PDP WG to ensure that applicant support is well scoped by preventing, to the extent possible, the possibility of inappropriate use of resources, e.g. inflated expenses, private benefit concerns, and other legal or regulatory concerns. (Pg. 68)
B. Implementation Guidance 17.14 states that “ICANN org should seek funding partners to help financially support the Applicant Support Program, as appropriate.” The ICANN Board notes that this would change the role of ICANN, as ICANN is not a grant-seeking organization. Alternatively, ICANN org – through the Pro Bono Assistance Program – could act as a facilitator in the introduction of industry players or potential funding partners to the prospective entrants.
55
Entered by ICANN Org StaffICANN Policy Staff in support of the At-Large Community / Evin Erdoğdu, Policy Development Senior CoordinatorALACYesALAC Statement submitted by At-Large staff. ALAC drafting team members include Justine Chew, Alan Greenberg, Marita Moll, Jonathan Zuck, Holly Raiche and Christopher Wilkinson.Do not support certain aspects or all of the Output(s)We maintain that there is no rush to have new applications, and there remains the need to properly assess actual benefits that the Program has brought about (or not) beyond just general consumer choice, and DNS marketplace competition aspects. In any event, should a next round proceed, it is more important to improve the application process to “get it right” rather than have ad hoc fixes post implementation which have not undergone community input. Further, in principle, prerequisite and high priority recommendations of the CCT Review Report of 2018 need to be implemented first.

In large part, the CCTRT recommendations focused on two things: intentions (goals, objectives) and data. For example Rec. 1, approved by the board, calls for the formalization and integration of data collection and metrics into all ICANN activities. Without clear, measurable objectives for a new round, there simply won’t be any way to evaluate it in a meaningful way. If a new round is being justified as creating “competition,” then a commitment needs to be made to get the necessary data from registries and registrars to adequately measure competition. If the objective of a new round is to improve consumer trust in the DNS then developing baseline metrics for consumer trust is essential so that improvements can be objectively measured.

As the first review after the IANA Transition, the CCTRT recommendations fell into a sort of purgatory and very little has been done to implement even those which were accepted outright by the board. Those that were directed to the Subsequent Procedures Working Group posed several questions about objectives for the new program which were not answered, making it difficult to evaluate changes to, for example, Applicant Support and Community Priority Evaluations. The CCTRT also found that the safeguards, imposed on the 2012 applicants, did little to prevent DNS Abuse from migrating to new gTLDs, where bulk sales, at lower prices, proved too good to pass up. Many of the security and stability recommendations, advanced by the CCTRT, were echoed in the recommendations coming out of the SSRT2.
Not ideal, but willing to accept Outputs as writtenDo not support certain aspects or all of the Output(s)The ALAC/At-Large maintains caution over the continued push for expansion of the Program, and expresses concern regarding the provision of option (a) in Recommendation 3.2, which read together with Recommendation 3.5 and Recommendation 3.6, seemingly mandate a very high threshold for pausing and/or stopping the Program in order to allow Community consideration and/or input on the impact of future reviews and/or policy development processes to be effectively taken into account.Support Output(s) as writtenNot ideal, but willing to accept Outputs as writtenNo OpinionDo not support certain aspects or all of the Output(s)Lack of specifics to Recommendation 7.1 that “meaningful metrics must be identified to understand the impact of the Program” does not inspire confidence - there must be descriptions of what data is needed and to prescribe that such data be necessarily collected by ICANN Org as a matter of priority, and/or by registries and/or registrars as a contractual obligation.New information or interests that the Working Group has not consideredFirst and foremost, absent clear objectives, against which to measure progress, “metrics” are far less useful. Furthermore, “objectives” are a matter of policy, not implementation and must be established through policy development. In particular, the ALAC are focused on clear, measurable objectives with regards to Consumer Trust, DNS Abuse, Universal Acceptance and expanded local/community participation in gTLDs. The latter must include objectives and metrics surrounding Applicant Support, Community Priority Evaluation, mentoring and regional applications for new strings. In fact, at this stage, the only clear rationale for a new round would be expanded and diversified participation in the program. As such, no further rounds should proceed without clear objectives surrounding applicant diversity both economic and geographic.

There was, at the very least, an implied requirement to justify the 2012 round with improved competition, choice and consumer trust. Now, all pretense for a justification has been replaced with “we said we would do it,” and the only clear objective is greater predictability and “fairness” for applicants. This fete accompli approach to a new round is fraught with pitfalls and, without prescribed benefits, the likely consequences to expanding the root are placed in stark relief.

The ALAC would like to see goals set and measured related to Consumer Trust including:
• Frequency of direct use (rather than redirect, QR code, etc.), commercial activity or consentual data sharing.
• Awareness of complaint channels (PICDRP and RRDRP);
• More granular reports on merit of complaints, action taken by whom, and responsiveness of registries and/or registrars to complainant to begin with

Note that due to character/word limit restrictions for each question, other metrics or measurements related to Universal Acceptance adoption, a communications plan, applicant support, EBERO and IDNs, have been included under Topics 11, 13, 17, 22, and 25, respectively.
Support Output(s) as writtenDo not support certain aspects or all of the Output(s)In respect of Recommendation 9.15, the ALAC maintains its position that new policy on DNS abuse mitigation must be put in place prior to the initiation of a new round of New gTLDs. While we agree in principle that the topic of DNS abuse should be dealt with in a comprehensive and holistic manner, and which addresses both existing/legacy TLDs and the new gTLDs to be delegated in the new/subsequent rounds, we disagree with the practice of pushing it off to another forum/PDP/etc.

We have seen periodic changes to the Base Registry Agreement through singular party-ICANN Org contract negotiations that incorporate incremental obligations as well as an incremental level of permissions which in general are beneficial to both sides, if not to everyone. We opine that these incremental obligations and permissions in the Base Registry Agreement for the operation of new gTLDs have been instrumental in inspiring registry operators of legacy TLDs to also adopt and take on similar (if not all) such obligations and/or permissions during negotiations for their Registry Agreement renewal.

Therefore, declining to make any recommendations on DSN abuse mitigation for subsequent procedures constitutes, to us, a missed opportunity to incentivize the voluntary adoption by existing registry operators of desirable changes to their Registry Agreements to bring about beneficial consequences to end-users.

We are also wary of a need to have not only more data, but the correct data, to be captured by registries and registrars in order to monitor and detect changes in not only the level of the DNS abuse but the types of DNS abuse (changing DNS abuse landscape) and that the obligation to collect such data may evolve in scope and/or breadth over time. In this respect we should be exploiting every opportunity to introduce desirable changes in respect of obligations to do with DNS abuse mitigation.
No OpinionDo not support certain aspects or all of the Output(s)ALAC remains convinced that any expansion of the new gTLD market must actively and effectively facilitate the inclusion of the next billion Internet end-users - those who depend on IDNs and IDN-emails. Merely “welcoming and encouraging the work of the Universal Acceptance Initiative (UAI) and the Universal Acceptance Steering Group (UASG)” even if “strongly” has no real effect on the goal of promoting Universal Acceptance (UA). To this end, SubPro PDP WG must recommend for greater action towards UA-adoption in a number of ways:

Adoption of UA
1. ICANN must include a metric on UA adoption by third parties as a measure of success for the New gTLD Program because without greater adoption of UA, any expansion of the Program would not facilitate inclusion of the next billion Internet end-users.(see also our comments in answer to Q.63)

Promotion of UA-readiness
1. ICANN must invest in being itself able and ready to communicate to registrants and end-users in languages/scripts for LGRs that have been released under the IDN Variant TLD Implementation.
2. ICANN must strongly encourage registries and registrars which are owned by the same entity to be UA-ready in any new gTLD application since these are the entities best positioned to offer IDN TLDs/SLDs.
3. The application process must require all applicants to state:
• The level of UA-readiness of their Registry operations (if not .brand TLD applicant), including whether they have policies in place to respond to IDN-email or to introduce IDNs.
• The level of readiness, both at Registry and Registrar levels, to accept IDN SL domain name registrations.
New information or interests that the Working Group has not consideredSome (additional) measurements to evaluate Universal Acceptance adoption include:
• Number of Registrars offering services per country/region/language and scope of contractual obligations on Registrars to provide IDNs and EAI, publication of same to applicants,
• Extent of Registry/Registrar structural separation; contractual non-discrimination requirements, publication of same to applicants,
• Web Scriptability, Incident Responsiveness and Manageability.
Support Output(s) as writtenDo not support certain aspects or all of the Output(s)With respect to Affirmation 13.1, it is important for the community to understand how “comment forums will be used to inform evaluation panels” - controlling factors such as when do comment forums open and close and the identification of commenters are important to avoid abusive use of the comment forums.

With respect to Recommendation 13.2, metrics are needed to evaluate the effectiveness of any communications strategy and plan in achieving program goals.
New information or interests that the Working Group has not consideredAs stated above, specific objectives need to be set for portions of the program, in terms of Applicant Support, Community Applications, DNS Abuse, Universal Acceptance, etc. It would then be against these measurable objectives that a communications plan would be judged. Simply constructing a communications plan, the execution of which is its own metric is insufficient. Communications metrics should incorporate surveys, both as part of communications as well as generally to understand reach. Specifically, the CCTRT recommended identifying a “profile” for applicants in underserved regions and trying to reach them directly, potentially with case studies which help a potential applicant to understand typical business models.

Some metrics/measurements essential to evaluate a communications plan, include:
• Marketing/promotional events across regions/countries/cities and by whom - how many, and when the first and last events took place,
• Languages used at events and/or for materials other than in the 6 UN working languages, Whether events involved ICANN community members or third parties
• Whether surveys were used to identify interests in Program - what kind of interest (to apply/operate standard, community or IDN TLDs vs general interest),
• Number of active follow ups vs unsolicited inquiries
New information or interests that the Working Group has not consideredIn respect of Recommendation 14.2 and Implementation Guidance 14.6, we believe that systems used for the application and evaluation processes should not only target applicants as its main end-users, but should also be able to support community needs in accessing, commenting and monitoring all publicly-available information pertaining to an application - including but not limited to responses to entries and historical changes to application question answers, Public Comment forum, Public Interest Commitments or Registry Voluntary Commitments offered.

In particular, we propose two additional opt-in notification tools be created for:
1. Specific to Non-AGB terms with geographic meanings - Participating GAC Members to be notified of applications submitted for strings which are exact matches of adjectival forms of country and territory names (per ISO 3166-1 list) in the official language(s) of the country in question and other terms with geographic meaning, as notified by any GAC Member to ICANN Org, where there exists an official document (eg. founding/incorporation of an administrative division) giving a geographic place its name, or it is attested that a geographic place or feature has the name from time immemorial (refer to comments under topic 21.1 Geographic Names)
2. Any interested party (without any limiting criteria) to receive updates on any indicated application.
Support Output(s) as writtenNo OpinionDo not support certain aspects or all of the Output(s)The ALAC has major concerns with many of the recommendations and implementation guidance which we believe either do not go far enough to improve the utility of ASP and/or suggest “implementation elements of ASP” which lack adequate policy guidance details which are highly necessary. Instead the approach in punting these off to the IRT is disappointing since the implementation phase typically does not incorporate extensive community participation.

In particular:
• Recommendation 17.1 should include within the ASP framework, a requirement that applicants must demonstrate how they would serve a beneficiary target region or community, not propose merely a general public interest benefit as an evaluation criterion.
• Recommendation 17.3 and Implementation Guidance 17.4 should expressly include a reference to business model education (eg. different business case studies) for applicants (as was identified the AM Global Study) to increase the utility of the ASP.
• Re: Recommendation 17.5 and Implementation Guidance 17.8, 17.9, 17.1, will a dedicated IRT established / charged with developing implementation elements of ASP – even if giving regard to the JAS WG Final Report and 2012 implementation of ASP – allow for effective community participation and/or input to be incorporated?
• Re: Recommendation 17.12 and Implementation Guidance 17.13 ad 17.14, given that the success of the ASP is intrinsically tied to the amount of ASP funds available, we want to know how ICANN org will develop such plan to source for ASP funds. In particular, we believe more concrete steps should be established to secure funding for ASP; that ICANN Org ought to actively inform, encourage and liaise with National banks and aid agencies worldwide to participate in sponsoring applicants or ASP funding; and that request for cooperation by GAC be made, as appropriate.
• Re: Recommendation 17.15 and Implementation Guidance 17.16, we are concerned about being asked to support important elements which lack adequate policy guidance details. To be clear, we maintain our proposal to allow an applicant who qualifies for ASP should be given priority in any string contention set, and not be subjected to any further string contention resolution process but note that if 2 or more applicants that qualify for Applicant Support were to be placed in a contention set, then a mechanism is still required to resolve that contention set. In this scenario, and should priority not be given to an applicant that qualifies for Applicant Support, then a version of the Vickrey auction should be the mechanism of last resort where the benefit of a multiplier should apply to bids placed by applicants that receive Applicant Support.
• Re: Recommendation 17.18, while we fully support the move to allow applicants that fail ASP evaluation the option to pay balance of full standard application fee and transfer to standard application process, we remain concerned over questions on (i) how SARP’s evaluation methodology will be expanded to include determination of wilful gaming; and (ii) the development of broad agreement on penalty to be applied to applicants found to be wilful gamers.
New information or interests that the Working Group has not consideredWe have some suggestions related to Implementation Guidance 17.10; if we are expecting uptake to improve then more consideration ought to be given to having established approach, suggest:
• Using points earn during evaluation to determine dispersion of funds if there are more applicants than funds
• Using “quota per region” approach

Separately, the term “Community” is subject to different interpretation by different groups, including evaluators and dispute resolution panelists. It is inherently difficult and unfair to expect an applicant or an objector to accept that a group determined to be a “community” within one aspect of the Program can then be rejected as a “community” in respect of another. An eg. might be an applicant that qualifies for Applicant Support because it has been able to persuade the Support Applicant Review Panel (SARP) that its application target/benefits a community while failing to do the same with a Community Priority Evaluation panelist. We not only support a recommendation that “Community” should be broadly interpreted, but would go further to advocate that the way “community” is interpreted should be applied consistently throughout each aspect of the application process.

And, in terms of metrics for the ASP, these should include:
• Number of enquiries, number of applications, distribution of applications by jurisdiction, first time/repeats; single vs existing or new portfolios; based on pre-existing trademarks or not
• Classification of applications by main categories, distribution by incorporation/private, country, language, scripts etc.
• Numbers and responsibilities of ICANN Staff assigned to support applicants - numbers of staff, including out-sourced, assigned to evaluation
• Budget available to finance pro-bono assistance,
• Third party financing: interest, outreach, T&C, amounts available etc.
• Mentorship program participation numbers
Yes, it should. We have expressed above our belief that more concrete steps should be established to secure funding for ASP; that ICANN Org ought to actively inform, encourage and liaise with National banks and aid agencies worldwide to participate in sponsoring applicants or ASP funding; and that request for cooperation by GAC be made, as appropriate. All these steps will help relieve the pressure on ICANN to fully and internally fund the ASP.

We also wish to provide input on guardrails for mitigating risk of gaming while increasing the appeal, utility of ASP, to boost overall success of ASP, as follows:

Joint financing of Applicant Support applications
• ICANN Applicant Support must take account of the overall investment costs necessary for the success of the proposed independent Registry, including how these costs will be financed.
• The financial evaluation of the application must be undertaken by qualified staff within ICANN Org. The applicant’s submitted financial data should be kept confidential, except that in the event of joint financing by third party entities (e.g. regional development banks) such data would have to be shared under conditions of confidentiality and with the applicant’s consent.
• ‘Portfolio applicants’ or incumbent Registry/ Registrar entities with 10 or more delegated gTLDs (new and legacy) are ineligible to apply for Applicant Support.
• To be eligible for Applicant Support, an applicant for:
o A geographic name string, must be incorporated in the jurisdiction corresponding to that geographic name, on the basis of prior authorization and regardless of intended use of the string.
o A non-geographic name string, must not be incorporated in the jurisdiction considered as tax havens by the OECD.
• To implement joint financing, ICANN Org must:
a. Undertake a review of the financing of independent gTLD applications arising from the 2012 Round. And publish the anonymised data arising from that review. This is not to be out-sourced.
b. Conduct a proactive information and promotional activity with possible third party entities to facilitate subsequent approaches from ICANN and applicants for Applicant Support.
c. Establish confidentiality rules and procedures with respect to the sharing of the applicants’ information with third party entities, including all of the applicant’s financial data.
No Opinion
56
Entered by ICANN Org StaffGACGACNoThe GAC appreciates the efforts of the PDP WG to create a Predictability Framework, and notes that some GAC members are still not entirely persuaded of the added-value of creating the new SPIRT structure and therefore wish to reiterate comments raised in the ICANN68 Communique: “some GAC members raised doubts on the added-value of a SPIRT, and expressed concerns that its creation, if adopted, could add complexity to the current procedure and potential inconsistency with existing roles and responsibilities according to the ICANN Bylaws. It [is] proposed that if established, the new mechanism be lean, inclusive and transparent.”

The GAC notes that final recommendations were updated by the PDP WG following community input and supports, in principle, Implementation Guidance 2.2 outlined in the PDP WG Final Report which notes that “the Working Group recognizes the challenges in determining the details of the framework and establishing the SPIRT and therefore emphasizes that implementation of both elements should focus on simplicity and clarity.”

Additionally, some GAC members would like to ask the PDP WG to further consider what role the GAC would have if the SPIRT is created, noting the idea of a GAC liaison was initially discussed within the PDP WG.

The GAC recommends that any changes made to the new gTLD program should be transparent and shared with community members, in keeping with Implementation Guidance 2.3 noting that “ICANN Org should maintain and publish a change log or similar record to track changes to the New gTLD Program, especially those that arise and are addressed via the Predictability Framework and the SPIRT”. The GAC finally notes that the annual review of the IRT is very important to ensure revisions and adjustments, and will also contribute to increased transparency.
The GAC recalls previous GAC ICANN66 Communique Advice to the ICANN Board, whereby “the GAC advises the Board not to proceed with a new round of gTLDs until after the complete implementation of the recommendations in the Competition, Consumer Trust and Consumer Choice Review that were identified as ‘prerequisites’ or as ‘high priority’.”

The GAC continues to harbour serious concerns regarding the absence of policy recommendations on DNS Abuse Mitigation in the Subpro PDP WG Final Report, and notes that the WG deems that such future effort should be holistic and must apply to both existing and new gTLDs. On this point the GAC expects swift action from the GNSO Council in triggering such holistic effort, in order for the conditionality expressed in the GAC ICANN66 Communique to be met. The GAC stresses the importance, to address this key issue more effectively, to implement CCT-RT Recommendations, in light of earlier GAC Montreal Advice, before the beginning of the next round of new gTLDs. This should not be postponed. Furthermore, reference to ccTLDs should be avoided as they do not fall under ICANN’s remit but operate under national legislation.

The GAC strongly supports the need for safeguards to address concerns around public interest during the next round of new gTLDs, and expects public interest safeguards for any future rounds. In this sense, the GAC notes that additional mandatory PICs should remain possible in case where unanticipated risks emerge.

The GAC recognizes that the PDP WG has taken into account GAC Beijing Advice in Affirmation 9.3 affirming the framework established by the New gTLD Program Committee (NGPC) to apply additional Safeguards to certain new gTLD strings that were deemed applicable to highly sensitive or regulated industries, creating 10 safeguards of various levels to be implemented among a set of 4 groups.

The GAC also notes that further information should be provided in the implementation phase on the role of the evaluation panel responsible for determining whether each applied-for string falls into one of the four groups, highlighting the need for the process to be inclusive and transparent, and, as outlined in the Final Report, the GAC supports the idea that “this process must be included in the Applicant Guidebook along with information about the ramifications of a string being found to fall into one of the four groups.”

Consistent with the GAC Montreal Communiqué, the GAC believes that voluntary and mandatory PICs must be effectively enforceable and that this goal should be achieved with clearly expressed contractual obligations and consequences for failure to meet these obligations. Improved clarity for PICs in terms of obligations and consequences will aid ICANN’s contractual compliance program in its enforcement of these provisions that safeguard the public interest.

The GAC recalls persistent GAC concerns regarding both the weak implementation of PICs applicable to gTLDs in highly-regulated sectors and the lack of clarity and effectiveness of the mechanism to enforce disputes (the Public Interest Commitments Dispute Resolution Process or PICDRP).
To the extent that any subsequent round includes gTLDs in highly–regulated sectors, the GAC reiterates the advice from the Beijing Communique advocating for safeguards to mitigate the higher levels of risks of abuse associated with strings in highly-regulated industries, which are likely to invoke a higher level of trust to consumers.
The GAC recommends the incorporation of the GAC advised safeguards regarding highly-regulated gTLDs into the PICs so that applicants for new gTLDs are aware of these requirements in advance.
The GAC generally supports the final recommendations on applicant support, noting the importance of extending the scope of the program beyond only economies classified by the UN as least developed and also considering the “middle applicant”. A suggested approach to benefit the “middle applicant” is to reduce the application fee, not to the extent of the reductions availed to underserved regions, so as to encourage “middle applicants” to cross the threshold in the domain namespace.

The GAC supports recommendations expanding the scope of financial support to also cover costs such as application writing fees among others. The GAC notes that the cost of a new gTLD extends beyond just the application fee to the cost of the application process as well as running a new gTLD. Interested applicants should be provided with a general estimation of fees and cost that would be required by the whole procedure before the filing of the gTLD application.

Furthermore, the GAC urges further consideration on how the Applicant Support Program (ASP) can include the reduction or elimination of the ongoing ICANN registry fees, at least in part, to expand financial support available to eligible applicants, since the Working Group’s Initial Report included a preliminary recommendation to this extent which has been removed from the final report.

The GAC highlights the importance of the implementation work as noted in the final report, regarding defining the “middle applicant” and drawing on expertise to develop appropriate program outreach, education and application evaluation.

The GAC agrees, as per the GAC Response to ICANN Board Clarification Questions on the GAC Montreal Communique “that expanding and improving outreach should be an ongoing effort, and expects the Board to make a judgment, in good faith, as to whether it considers outreach has been expanded and improved enough to justify proceeding with the new round of gTLDs.”
Outreach efforts regarding financial support and fee reduction should primarily target underdeveloped regions, so as to encourage them to cross the threshold in the domain namespace. Further, the GAC notes that there should be separate outreach activities to target “middle applicants” which are located in struggling regions that are further along in their development compared to underserved or underdeveloped regions, which would focus more on how the new gTLDs may practically benefit them against the more awareness-centric outreach programmes for underdeveloped economies and underserved regions.

The GAC also recommends community based applicants to be eligible to apply for Applicant Support Program, if the community they represent does not have the resources requested to submit an application, regardless of its country of origin.
The GAC also suggests that the ASP can also set up a support system to guide new applicants through the application procedure and deal with all the questions and queries of the applicants about navigating the application process as it can be a daunting task for a first-time applicant.
The GAC supports the intention of the recommendations to continue and to expand the applicant support program, and supports a meaningful evaluation of the program to assess its success.
57
Entered by ICANN Org StaffICANN orgICANN orgNoRecommendation 2.1:
The org requests that the PDP WG clarify the scope of the SPIRT and further explain the role and responsibilities of the GNSO. For example, the org understands that all policy level issues would be routed through the SPIRT to the GNSO. We would like to understand the role of the GNSO in these situations. Will the GNSO limit their input to clarifications of policy or would they recommend new policy? It may be helpful to be explicit about how this Recommendation interacts with Recommendations 3.6 and 3.7.
ICANN org notes that the ICANN Board and org retain the ability to act in emergency situations, including the ability to make business decisions in line with fiduciary responsibilities, which in extreme circumstances could mean halting the Program. This should be explicit within the Predictability Framework.
ICANN org suggests that the Predictability Framework should consider allowing for the use of a multistep process to resolve an issue. For example, in the case of name collision, the process for resolving the issue included requests for studies and multiple Public Comment periods. In such a multistep scenario, the Board and org need to retain flexibility to address the different issues as needed, taking into account Recommendations from SPIRT and/or the GNSO Council where applicable. This includes, for example, the ability for ICANN org to conduct Public Comment even if SPIRT does not recommend such a step.
Implementation Guidance 2.3:
ICANN org appreciates the Recommendation for a change log as an efficient and user-friendly tool to provide transparency and accountability into the operations of the Program. We view this as a mechanism that will aid communications, enhance trust, and create a comprehensive and authoritative record for both internal and external stakeholders. ​However, ICANN notes that, in some cases, the level of deta​il ICANN org posts in the change log may be determined by other considerations such as security, confidentiality, privacy, or other considerations. ICANN org understands that entries into the change log are not intended to be specific to individual applications, which will likely limit the likelihood of this occurring.
Implementation Guidance 2.5:
Implementation Guidance 2.5 seems to imply that a refund amount different than that defined in the refund schedule in the AGB might be applicable. Does the PDP WG intend that in situations where significant issues arise that require resolution via the Predictability Framework, applications affected by this particular circumstance are awarded a refund beyond the established refund schedule? Refunding an amount greater than what is defined in the refund schedule would leave a deficit that would be
covered by the Program which in turn would be borne by the other applicants. Could Recommendation 2.5 be rephrased to a “refund commensurate with the impact of the change,” rather than an open-ended provision?
General Comments:
ICANN org understands that the intent of this section is to address the lack of predictability that the PDP WG described in the 2012 round. ​ICANN org notes that several new GNSO processes, such as the GNSO Input Process and the GNSO Guidance Process, have been developed since the 2012 round. Given that the Board is able to raise issues directly to the GNSO Council when required, and that the GNSO now has additional processes available to it, the org notes that there may be ways for these processes to serve the desired objectives of the SPIRT without introducing a new set of processes.
Assuming the PDP WG recommends the establishment of the SPIRT as a mechanism dedicated to the New gTLD Program, ICANN org is providing feedback on several aspects of the Predictability Framework in a separate annex below.
Please also refer to the ICANN Board comment on this topic.
Annex: Comments on Predictability Framework Annex E
ICANN org suggests that as the SPIRT processes are developed, their overall impact to operational timelines will be given primary consideration, as issues that impact operations cause delay and increased cost and do not achieve the desired effect of increased predictability.
ICANN org recommends that the nature and scope of the SPIRT’s remit should be clearly documented and agreed to by all participants in the New gTLD Program at the outset, including definition and acknowledgement of ICANN org’s responsibilities to run the New gTLD Program as derived from the policy recommendations.
ICANN org understands that the SPIRT is intended to be a body to provide guidance in the operation of ongoing rounds in relation to GNSO policy processes. It may be helpful for the PDP WG to consider defining the scope and applicability, and potential closure point, of the SPIRT’s role. For example, would SPIRT recommendations be expected to apply to applications that have resulted in execution of a Registry Agreement and delegation of a gTLD? For issues that occur after contracting relating to, for example,, Continuing Operations Instrument (COI), Trademark Clearinghouse (TMCH), or other activities that are part of the New gTLD Program, is the SPIRT expected to continue to make recommendations on mechanisms to address issues that arise? ICANN org assumes that the scope of the Predictability Framework exists for the duration of a particular application round and applies to active applications within said round; however, this also underscores the need for specification of round closure conditions as the org noted in its feedback to Recommendation ​3.1.
ICANN org notes that the process/mechanism guidance from the SPIRT may result in changes or solutions that impact the Program and as a result may require updates to the gTLD Registry Agreements. It should be noted that the Registry Agreement contains its own change procedures and, as we understand the recommendations, the SPIRT does not have the remit to change these. It may be helpful for the Predictability Framework to state how this would be handled.​ S​ uch a process should take into consideration what happens if an issue affects Registry Agreements that have already been signed. If the Predictability Framework is defined as bound to pre-contracting processing only, this would not impact the provisions of the Registry Agreement.
a. Operational Considerations
If not carefully considered and correctly implemented, the framework might significantly constrain ICANN org’s ability to execute certain aspects of the Program. The potential changes in the global DNS environment, ICANN’s mission of security and stability, and ICANN org’s responsibility to apply policies fairly, transparently, and without singling out any particular party for discriminatory treatment mean that ICANN org needs the flexibility to respond appropriately to program management issues. For example, during the Prioritization Draw, applicants were required under California law to be physically present in order to participate. Recognizing that this requirement condition would have limited several applicants from participating in the draw, in order to ensure the opportunity to participate, ICANN arranged for a number of lawyers to act as proxies for those that could not physically attend. Creating the proxy network required ICANN to have the ability to decide and act quickly to avoid potentially delaying the Prioritization Draw. The inclusion of the Predictability Framework in this process would have added additional time and caused the delay of the draw.
Accountability Considerations
The SPIRT is proposed to be an open group, for which anyone can volunteer. There is neither a cap on membership numbers nor an appointing mechanism that could ensure that members have a relevant skill set. Though the SPIRT’s output is process recommendations, these decisions may have a direct impact on applications in process, including possible delays. The draft Final Report stipulates, “When appropriate, the Member of the SPIRT may recuse himself/herself, but required disclosure of a direct involvement in an application with an issue before the SPIRT does not, in and of itself require recusal.” However, no objective criteria is provided as to when recusal would be required. ICANN org encourages the PDP WG to provide additional guidance on this.
Process:
Based on the process detailed on page 223 of the draft Final Report, ICANN org understands that it determines if an issue falls into the ‘Operational - Minor’ category and, if so determined, notes the change in the log, and implements the change without a need for additional steps.
General Comments
The term “material impact” is used in several places of Annex E in the context of assessing the category of change. However, no specific criteria is given to judge the materiality of a change. ICANN org suggests that objective criteria be defined to avoid contention regarding the categorization of a particular change. For example, organizations often use established criteria to measure the severity of an issue, such as number of users impacted, inability to perform certain functions, or impact on current performance/efficiency.
ICANN org notes that resolution of several issues that occurred in the 2012 round included ICANN Board outreach to the GNSO and other parts of the community. In order to better understand how the SPIRT is intended to operate, ICANN org requests that the PDP WG provide examples of how issues from the 2012 round would be addressed by the SPIRT. We suggest the development and introduction of the Name Collision Management Framework as well as the decision to use a raffle/lottery system in place of ‘Digital Archery’ as possible case studies.
1. Operational
a. Operational - Minor
ICANN org notes that there may be a level of internal changes that may be classified as day-to-day operational changes and do not rise to the level of even a minor change. An example might be reshuffling of staff for the New gTLD Program, software upgrades by the vendor, addition of server capacity, updates to the New gTLD Program website, announcements of new vendor contracts, changes to ICANN’s data retention policy, etc. Breaking these types of changes out from the change log may minimize the number of transactions that the SPIRT will need to review.
Bullet number 3 in the list of Minor change examples mentions changing of sub-contractors. This is likely not a good example as this is not an accurate description of how ICANN org operates with vendors. As ICANN org does not select subcontractors, did the PDP WG intend to reference vendors/contractors? We would also note that examples are not the most effective way to provide guidance to ICANN org as any one of a number of factors could be seen as decisive criteria. ICANN org asks the PDP WG to consider including specific criteria for each type change to improve the accuracy of categorizing changes and thereby improve predictability to applicants, the community, and ICANN org.
b. Operational - Non-minor
Bullet number 1 in the list of Non-minor change examples mentions changes that impact the timeline. Is there a threshold at which the impact to timeline makes the change Non-minor or Significant?
Please also note that the application change request process referenced in this example is separate from the Predictability Framework. We understand that SPIRT would not have remit on approving or denying individual change requests.
Process:
ICANN org understands that, on changes falling into categories B (Operational - Non-Minor) and C (Operational - New Process or Significant Change to Internal Process), ICANN org submits its Framework analysis and proposed process to develop a solution to SPIRT. ICANN org would then take into consideration any guidance received from SPIRT (as approved by the GNSO Council) when implementing a change.
c. Operational - New Process or Significant Change to Internal Process
ICANN org would like to understand what is meant by “Internal Process” in this section. For example, does the PDP WG envision the inclusion of vendor processes performed in support of the Program?
Process:
The process description notes that the GNSO or ICANN Board may initiate action in categories C, D, and E. The GNSO and ICANN Board are not mentioned in categories A and B. Are these two entities restricted from initiating action in those categories?
2. Possible Policy Level - Changes that May Have a Policy Implications
Process:
The process description states “All recommendations are subject to the review and oversight of the GNSO Council, who maintains the discretion on whether or not to adopt the recommendations.” Has the PDP WG considered how the org should respond if the GNSO disagreed with a SPIRT Recommendation upon review? Further, how is the outcome of the GNSO Council consideration of the SPIRT recommendations to be considered in light of the GNSO Guidance Process already in place?
2. Composition of the SPIRT
ICANN org notes several aspects about the composition of SPIRT that may be of concern.
● The membership of SPIRT is proposed as open to all and not limited in number. First, the intention not to limit the number of members may complicate the prior section statement that “composition of the IRT should be balanced among stakeholder groups.” Additionally, we note that should the number of members be very high, this raises significant concerns as to the ability of the SPIRT to efficiently operate, given the consensus-based decision process. The org is concerned that delays within operation of the SPIRT will also lead to delays in the Program.
● The membership that is currently proposed could lead to capture and/or gaming by certain interest groups because there are currently no limits to membership. A particularly large representation of one particular group or organization could unduly influence the decision of the SPIRT.
● The PDP WG may want to consider building on the proposed improvements regarding PDP WG dynamics detailed in GNSO Policy Development Process 3.0.
3. SPIRT Role
Who can raise an issue to the SPIRT?
The Predictability Framework states that all SPIRT guidance is delivered to the entity that submitted the issue. However, it also says all recommendations are subject to the review and oversight of the GNSO Council which maintains the discretion on whether or not to adopt the recommendations. We suggest additional clarification on the roles and responsibilities within the Predictability Framework of the SPIRT, ICANN org, applicants, the Board, the GNSO Council, objectors, and the wider community, e.g., as providers of Advisory Committee advice. Such roles and responsibilities should be clearly referenced, documented, and agreed to by participants in the New gTLD Program. We suggest that use cases be included in the Final Report, including the example of GAC Advice that, if adopted, would require changes to the Program.
Further explanation of the scope and responsibilities of all organizations in the Predictability Framework (ICANN Board, GNSO, SPIRT, ICANN org) is needed in order to evaluate the impact on the responsibilities and obligations of the ICANN Board and org.
The second bullet point under the Role of the GNSO Council where it was the party raising the issue notes that the GNSO could take up to two GNSO Council meetings to act. From an operational view, a set number of calendar days would be more predictable for the applicants as the timing between GNSO Council meetings may vary.
Bullet three references 60 days plus a possible 30-day extension for the GNSO to take action. Given the additional time required for the referring body to initiate the request and the SPIRT to process and forward to the GNSO, it could be well over 90 days before ICANN org could even begin to implement the requested change. This could lead to lengthy delays in processing applications and lead to increased costs.
4. ICANN Staff Interaction with the SPIRT
ICANN org notes that department names and responsibilities may change over time. The org recommends that ICANN org should be identified within the Annex as responsible for assigning appropriate liaisons to work with the SPIRT. ​ICANN org also notes that the SPIRT Operating Principles and Decision-Making procedure should explicitly clarify that ICANN org personnel report to the President and CEO and therefore cannot act in any way that conflicts with Board direction to the President and CEO.
5. Operating Principles
As ICANN org is one of the entities eligible to submit issues to the SPIRT for consideration, one approach to help generate timely resolution and informed deliberation would be for ICANN org to develop and provide an impact analysis and proposed solution for any issue that it raises.
We would also flag to the PDP WG that it would need to be determined what happens to applications in process for the duration of the time it takes the SPIRT (and, subject to the SPIRT decision, possibly the GNSO Council) to consider the issue. Will processing of some or all applications be suspended until the SPIRT and/or the GNSO Council issue instructions or even until a new policy is developed, if that is the agreed upon remedy? If so, this could decrease predictability. It should be noted that many issues are interrelated and thus, other parts of the process may also be stalled until an outcome on any given issue is provided by the SPIRT/GNSO.
Similar considerations arise in the case where the SPIRT is not able to reach agreement within itself, or when the GNSO disagrees with the SPIRT Recommendations. It is unclear what is intended to happen to applications if an issue remains unresolved within the Predictability Framework. We note that, absent clarity on a means to reach resolution in this instance, the SPIRT could be a mechanism for manipulating the process by, for example, holding up one or more applications by stalling an agreement.
The process should include expected timeframes for SPIRT deliberations, including a time frame by which SPIRT is expected to provide a response to an issue submitted to it. The rationale for this is to avoid delays due to lengthy deliberations; established and agreed timeframes will help mitigate this risk.
The draft Final Report stipulated, “SPIRT deliberations should not be used as a tool to reopen a previously explored policy [...] unless the circumstances have changed and/or new information is available.” It is unclear what would constitute such a circumstance or new information, and we encourage the PDP WG to provide more objective criteria.
Implementation Guidance 3.3:
In the rationale, the PDP WG “does not believe that all applications from an application round must be processed and delegated before the subsequent round can open.” As some applications may involve complexities that require an extended time to resolve, it may additionally be useful to consider that policy changes could occur between rounds that would require changes to application processing. This could result in ICANN org needing to support a multitude of processes across several rounds. Should this happen, there would likely be an impact to cost and processing time of future applications. Has the PDP WG given consideration to what criteria might be used to determine an end to an active application round? The ability to close prior rounds would lessen the burden on ICANN org resources and allow for a more predictable expectation of application processing times.
Implementation Guidance 3.4:
The words “Active,” “Applicant Support,” “In Contracting,” “On-hold,” “In PDT,” “Will Not Proceed,” and “Not Approved” are ICANN operational status terms from the 2012 round. ICANN org would like to confirm its assumption that the particular terms used can change based upon need during implementation and remain consistent with the Implementation Guidance. Alternatively, the PDP WG might identify the criteria associated with each status term that applies in this Implementation Guidance.
There are currently two end states for an application: “Withdrawn” and “Delegated.” Has the PDP WG considered the scenario where an application does not meet requirements to sign a Registry Agreement and does not withdraw?
The Implementation Guidance states, “If all applications for a particular string have been Withdrawn, meaning the string has not been delegated, new applications for the string will be allowed in a subsequent round.” ICANN org notes that delegation is not a requirement to make a string unavailable. Once a Registry Agreement has been executed, the string is no longer available for application. Additionally, new policy might result in some strings no longer being eligible for application.
Does the reference to the ICANN Board approving new policies refer to Consensus Policies approved by the Board or to something else?
Recommendation 3.6:
This Recommendation appears to possibly be inconsistent with Section 4.6(d)(iv) of the Bylaws, which states, “For each of its recommendations, the CCT Review Team should indicate whether the recommendation, if accepted by the Board, must be implemented before opening subsequent rounds of new generic top-level domain applications periods.” The Bylaws therefore give future Competition, Consumer Trust, and Consumer Choice Review Teams (CCT-RT) the ability to recommend prerequisites for additional rounds, and the PDP WG may want to consider this in the context of subsequent rounds and reviews.
Additionally, ICANN org seeks any guidance on how the PDP WG would define “extraordinary circumstance,” and who would make that determination.
Recommendation 3.7:
ICANN org notes that in some situations an application may remain active for several years. ICANN org asks the PDP WG how long an application should remain exempt from a new or updated policy?
Additionally, ICANN org notes that the wording of this Recommendation appears to reference all policies, however we would like the PDP WG to clarify whether the
Recommendation is limited to policies that would impact the application process itself and that other generally applicable gTLD policies, such as a newly adopted policy concerning registration data or transfers, would apply to all existing and new gTLDs regardless of the timing of the application round.
General:
From an operational and practical perspective, ICANN org agrees with the PDP WG’s point of view that creating additional categories of different gTLD types will likely impact one or more aspects of the New gTLD Program. The requirement for differential treatment based on gTLD type will likely increase the overall complexity of the systems and processes of the Program, affecting cost and timing. Furthermore, the introduction of different gTLD types and corresponding differential treatment of applications could create inappropriate incentives for applicants to “game” the system and win an unfair advantage over other applicants. In order to minimize this, clear criteria for when and if an application can change its gTLD type will need to be established. Lastly, ICANN org agrees with the PDP WG that additional categories would potentially lead to a more complicated contractual compliance environment and pose new challenges.
In the table below, ICANN org has listed out the application types and their attributes that were recognized in the 2012 round. We have listed several key aspects of each as well as the process differences which marked each. Given that the PDP WG has relisted these same application types and attributes in this section, albeit in new categories, the org seeks input from the PDP WG as to any concerns or issues with the handling of the applications from the 2012 round.
Table: Application Types and Attributes (TLD Types) from 2012 round [staff note: see original comment for table]
Recommendation 4.1:
As a response to ICANN’s feedback on the initial Recommendations, it was helpful that the PDP WG distinguished between different application types, different string types, and different applicant types. The PDP WG also identified Category 1 - GAC Safeguards, IGO and governments, and Applicant Support as different TLD types and added a Recommendation that creating new types should be exceptional and should have a predictable process for the community to consider.
ICANN’s comments on the Initial Report also sought guidance on (i) whether the applicants must declare the gTLD type when submitting the application, and (ii) whether changes to gTLD types are permitted during the application process or prior to signing the Registry Agreement. Any additional clarification in these areas would be useful. In addition, ICANN org would like to confirm that the PDP WG has provided guidance on criteria and determination (self-identification or other) for each of the types listed and how they may simultaneously apply or interact with one another.
Additionally, ICANN org suggests using the term “variant TLD” instead of “IDN variant” to clarify that it is referencing a variant TLD string (and, for example, not a variant label of a second-level label) and also account for potential cross-script variant labels of an ASCII TLD (e.g., in Cyrillic script).
ICANN org notes that Geographic Names is listed as both an application type and a string type. Can the PDP WG elaborate on the distinction between the two types and provide clarity on whether or not there is an expectation to create two different Geographic Names processes, one for the application type and one for the string type?
Recommendation 4.2:
ICANN org seeks guidance from the PDP WG on what would be considered “exceptional circumstances,” or indicate when an additional type would be identified/addressed in the overall process.
Recommendation 6.2:
Our understanding is that this would not replace pre-delegation testing (PDT) which tests the technical and operational infrastructure for each gTLD as a prerequisite for delegation.
Recommendation 6.5:
We understand this Recommendation to suggest that once the registry service provider (RSP) is pre-evaluated, the pre-evaluation status will continue for the duration of the related application round even if substantial issues with the RSP are found during TLD operations. ICANN org seeks guidance on what conditions would allow for a “pre-approval” status to be revoked.

Please also refer to the ICANN Board comment on this topic.
Recommendation 7.1 and Implementation Guidance 7.2:
ICANN org notes that the term “meaningful” is subjective and could create opportunities for disagreement and dissatisfaction, rather than consensus. The Recommendation appears to suggest that the CCT-RT Recommendations referenced in the Implementation Guidance will fulfill the recommendation.
Alternatively, limiting the development of metrics and measurements to the criteria listed in the CCT-RT Recommendations may restrict ICANN org’s ability to develop “meaningful” metrics. Any additional clarification would be helpful.
Recommendation 7.3:
ICANN org confirms that the PDP WG recommends that subsequent procedures phases include metrics, service level agreements (SLA), and monthly reporting. We understand that the phases listed in the Recommendation are examples and not a requirement to be used, as the names of phases may change in subsequent rounds.
Recommendation 7.4:
ICANN org seeks guidance on whether the PDP WG has identified specific improvements or capabilities that they would like to see made to the SLA monitoring system. Would these “more robust” capabilities be expected to apply to gTLDs from prior rounds as well?
Recommendation 8.1:
The rationale for this Recommendation states, “that provisions in the 2012 round were insufficient to effectively guard against conflicts of interest among dispute resolution service provider panelists, the Independent Objector (IO), and application evaluators.” To inform ICANN org’s work on this topic, could the PDP WG elaborate on the ways that the provisions were considered insufficient? It will be helpful if the PDP WG can provide a definition of a conflict of interest in relation to the Program, as well as provide any new criteria that the PDP WG proposes, particularly if they are different for each of the three entities listed above.
Recommendation 9.1:
Please also refer to the ICANN Board’s comment on this topic.
ICANN org also notes that Specification 11 3(d) is about prohibiting the use of a TLD in a closed manner. As the PDP WG continues to discuss the issue of closed generic TLDs into the subsequent rounds, we would note that, absent changes, this Recommendation to retain Specification 11 section 3(d) might conflict with the PDP WG’s ultimate Recommendation on the topic of closed generic TLDs.
Additionally, ICANN org notes the expressions of confusion and discussions in the community regarding the meaning, scope, and interpretation of some of the existing obligations, especially Specification 11 sections 3(a), 3(b) and 3(c). Noting Recommendation 9.15, as well as the objective of having a common Registry Agreement across existing and future gTLDs as stated in the General Comment 6, ICANN org understands the PDP WG’s recommended approach is to seek a holistic solution on Domain Name System (DNS) abuse for both existing and future gTLDs (and potentially ccTLDs), and expects to engage with the community to clarify the meaning and scope of these obligations outside of this PDP WG’s policy recommendation process.
Recommendation 9.2:
ICANN org notes that a single-registrant TLD might still have third-party content, users, and licensees. Services utilizing any domain name can be compromised at any point in time (regardless of who the registrant or TLD is) and can be used for malicious purposes by an attacker. As such, ICANN org has concerns about the risks associated with this Recommendation, and urges the PDP WG to consider this issue.
If the PDP WG’s intention is to provide waivers to registry operators whose Registry Agreements contain either Specification 13 or an exemption to Specification 9, neither Specification 13 nor an exemption to Specification 9 limits registry operators to a single registrant.
Affirmation 9.3:
This Affirmation states that the Inherently Governmental Functions will require Category 1 Safeguards 1-10; however, the implementation from the 2012 round was that the Inherently Governmental Functions only required Category 1 Safeguards 1 through 8 and then 10, but not 9. As this is an “Affirmation,” and not an “Affirmation with the modification,” this may have been a typographical error.
Additionally, ICANN org believes Affirmation 9.3 and Recommendation 9.8 may benefit from additional clarity. While there have been almost no complaints based on the GAC Category 1 Safeguards, there could be an instance of community disagreement over the scope and meaning of these obligations similar to what we have seen with Specification 11(3)(a). ICANN Contractual Compliance enforces the text of the provisions as written, while some stakeholders believe that Compliance should adopt a more expansive interpretation. As stated in the General Comment 6 and ICANN org’s feedback to Recommendation 9.1, ICANN org would support a mechanism to engage with the community in an inclusive manner to clarify the meaning and scope of these obligations for existing and future new gTLDs, outside of this PDP.
Recommendation 9.4:
This recommends “establishing a process to determine if an applied-for string falls into one of four groups defined by the New gTLD Program Committee (NGPC) framework for new gTLD strings deemed to be applicable to highly sensitive or regulated industries.” Though there is Implementation Guidance to establish a panel to achieve this, there do not appear to be detailed criteria in the Recommendation nor Implementation Guidance to help guide development of such an evaluation. Without clear or detailed criteria, the panel review may be open to subjectivity and dispute. As per ICANN org’s comment to the Initial Report, it would be helpful if the PDP WG could clarify the “criteria for applied-for strings to be put into those categories,[...] implication on the evaluation and string contention processes” to help guide the implementation of this Recommendation.
Implementation Guidance 9.5:
This guidance states: “applicants may choose to self-identify if they believe that their string falls into one of the four groups. This designation will be confirmed, or not, using the process outlined below in Implementation Guidance 9.6.”
ICANN org requests the PDP WG to provide the underlying rationale for the guidance, “Applicants may choose to self-identify if they believe that their string falls into one of the four groups.” If the expert panel will review all applications, what are the intended benefits of self-identification? If none, is the Recommendation necessary given the added operational burden for org in processing these applications?
Implementation Guidance 9.6:
This guidance suggests the establishment of an evaluation panel. ICANN org notes a number of potential implementation challenges, which include identifying qualified experts (industries are subject to varying levels of regulation–ranging from high to none–depending on the jurisdiction), defining the scope of work, categorization criteria, credibility of the determinations, and the costs of compensating and supporting the panelists. Any further details that could address these potential implementation challenges will be helpful.
Recommendation 9.9:
This Recommendation states that “ICANN must allow applicants to submit Registry Voluntary Commitments (RVCs) (previously called voluntary PICs) in subsequent rounds in their applications or to respond to public comments, objections, whether formal or informal, GAC Early Warnings, and/or GAC Consensus Advice.” As stated under Recommendation 9.1, ICANN org asks the PDP WG to refer to the ICANN Board’s comment on this topic.
Additionally, is the PDP WG intention only to allow applicants to submit the revised RVC in response to those cases listed in Recommendation 9.9 (“public comments, objections, whether formal or informal, GAC Early Warnings, and/or GAC Consensus Advice”)? Or, can the applicants submit the revised RVC for other reasons?
Recommendation 9.9 also states that the “Applicants must be able to submit RVCs at any time prior to the execution of a Registry Agreement.” How does the PDP WG envision the potential impact to contention sets or objections if the RVC has been changed after the objection period has closed? As noted in our comment to the Initial Report, it would be helpful for the PDP WG to recommend “whether there should be a cut-off point in the Program process for changes to the voluntary PIC in order to allow for the opportunity for others to file objections based on the changes, or whether a new opportunity for objections to be filed after a change has been made should be allowed." Allowing the change up until the execution of a Registry Agreement could lead to less predictability for stakeholders and added operational complexity for ICANN org, both of which may lead to processing delays. This also provides an opportunity for applicants to resolve a contention set via the introduction or revision of the RVC, then submit another change request to revert back to its original RVC afterwards as a way to “cheat the system.”
Additionally, has the PDP WG considered the potential gaming of this Recommendation with regard to execution of the Registry Agreement, for example, if an applicant invokes the RVC change during the contracting phase? During the 2012 round, some applicants were reluctant to sign within the set time frame of nine months from the notification date. Without any mitigations, applicants could continuously submit unlimited RVC changes to exceed the allotted nine-month timeframe to execute the Registry Agreement. The nine-month time frame is affirmed as Affirmation 40.2 within the draft Final Report.
Lastly, ICANN org seeks guidance as to how the PDP WG envisions the evaluation of the RVCs. If the RVCs can be utilized to address GAC Advice, objections, or application comments, who will review the submitted RVC to ensure that it does indeed address the GAC, objector, or commenter’s concern all while being inside of ICANN’s remit, and how will that review be conducted?
Recommendation 9.10:
This Recommendation states, “RVCs must continue to be included in the applicant’s Registry Agreement.” Does this imply that 1) the RVCs must continue to be in the Registry Agreement after the contract renewal or assignment, and/or 2) RVCs cannot be modified or removed from the Registry Agreement in the future? It will be helpful if the PDP WG can provide further clarity on this Recommendation.
Implementation Guidance 9.11:
This guidance states that “​The Public Interest Commitment Dispute Resolution Process (PICDRP) and associated processes should be updated to equally apply to RVCs.” ICANN org seeks clarification that the Implementation Guidance is merely to add the RVCs to be treated equally to PICs in the current procedures, and not to amend any other substantive language of the PICDRP.
Recommendation 9.12:
This Recommendation states, “At the time an RVC is made, the applicant must set forth whether such commitment is limited in time, duration and/or scope.” ICANN org suggests the Recommendation require the applicant to provide the grounds on which it could modify or terminate a commitment, and an assessment of whether termination of a commitment would have any substantial impacts to existing registrants or the security and stability of the DNS.
Recommendation 9.12 also states: “that the commitments can adequately be considered by any entity or panel (e.g., a party providing a relevant public comment (if applicable), an existing objector (if applicable) and/or the GAC (if the RVC was in response to a GAC Early Warning or GAC Consensus Advice)) to understand if the RVC addresses the underlying concern(s).” There is no recommendation in this draft Final Report to establish a panel to review the RVCs nor is there a detailed recommendation for any standard by which to evaluate the RVCs. Could the PDP WG clarify which panel is envisioned to review the RVCs?
Lastly, the Voluntary PICs from the 2012 round were not uniform or mandatory across all agreements among the Category 1 strings, thus creating the disparity among Category 1 gTLDs relative to the Voluntary PICs. Does the PDP WG see the RVCs to be mandatory across strings considered to fall into one of four groups defined by the NGPC framework for new gTLD strings deemed to be applicable to highly sensitive or regulated industries?
Implementation Guidance 10.2:
This Implementation Guidance states “as the ICANN organization and community incorporate human rights into ICANN’s processes in line with the recommendations of Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) Work Stream 2 (WS2), they should consider the application of this work to elements of the New gTLD Program.” Additionally, the rationale for this Implementation Guidance states that the PDP WG “encourages ICANN org to give additional consideration to this issue in the implementation phase.”
ICANN org relies on the ICANN community to define and provide specific guidance and direction on how to balance between the interests of different stakeholders. This direction is likely to come from the implementation work on the Human Rights Framework of Interpretation (FoI) that the community will undertake as part of the CCWG-Accountability Work Stream 2. ICANN org's responsibilities under the FoI are limited to producing a framework for how the Human Rights Core Value will be taken into account when developing corporate or operational policies and executing its operations. This work does not impact the work of the community on the implementation of the FoI. ICANN org expects to provide the necessary facilitation support to the community in its FoI implementation efforts.
As such, ICANN org would like to recommend that the PDP WG include as part of the recommendations specific identification of the human rights impact, and provide additional guidance to the implementation effort on the types of examples it would like to see investigated. This will help ICANN org provide specific guidance to the evaluation panels, in line with the community's responsibilities under the FoI/WS2 Recommendation.
Affirmation with Modification 12.3 and Recommendation 12.5​:
The PDP WG recommends that “the commencement of the application submission period will be at least four (4) months after the issue of the Applicant Guidebook.” ICANN org requests the PDP WG consider providing a minimum and maximum time frame instead of the fixed four month period. Additionally, perhaps the PDP WG may want to consider capturing recommendation 12.5 - “the English version of the Applicant Guidebook must be issued at least four (4) months prior to the commencement of the applicant submission period” - with Recommendation 12.3.
Recommendation 12.4​:
The PDP WG recommends “focusing on the user when drafting future versions of the Applicant Guidebook (AGB) and prioritizing usability, clarity, and practicality in developing the AGB for subsequent procedures. The AGB should effectively address the needs of new applicants as well as those already familiar with the application process. It should also effectively serve those who do not speak English as a first language in addition to native English speakers.” ICANN org requests further clarity as to how the PDP WG envisions ICANN org “focus on the user.” Additionally, it would be helpful if the PDP WG could clarify as to how they see ICANN org “effectively address the needs of new applicants,” as well as how ICANN org should “effectively serve those who do not speak English as a first language.”
Recommendation 13.2:
This Recommendation states that the “Working Group believes that an effective communications strategy and plan is needed to support the goals of the program.” It would be helpful to understand the PDP WG’s definition of the goals of the Program and whether this Recommendation is in reference to Affirmation 6.1.1
Implementation Guidance 14.7​:
The PDP WG suggests allowing “applicants to view historical changes that have been made to the application by any system user, including ICANN org, both during the application and evaluation phases.” ICANN org would like to note that org sensitive data that may be appended to the application cannot be shared. Additionally, ICANN org would like to note that implementing end user differentiated access complicates system design and thus would result in greater time and higher costs.
Recommendations 14.8 and 14.9:
Because it is phrased in terms of subjective standards of predictability and transparency, ICANN org is concerned that opponents of the Program might argue the deployment of applicant-facing systems as insufficiently predictable or transparent, therefore potentially challenging org’s deployment of a system as a violation of policy. For example, if Implementation Guidance 14.9 were the policy Recommendation, this would be clearer and more implementable and 14.8 could be retained as principles or Implementation Guidance.
Implementation Guidance 14.10​:
The PDP WG suggests, “in service of transparency, once the systems are in use, ICANN should communicate any system changes that may impact applicants or the application process. Processes described under Topic 2: Predictability should be followed.” ICANN org would like to note that for issues related to security and stability, as well as the proper functioning of systems, ICANN org cannot be constrained to the processes outlined under Topic 2. ICANN org will need to respond rapidly to any issue that may fall under these categories.
Implementation Guidance 15.2:
As noted by the PDP WG, “fees for the technical and operational evaluation for the core registry services should be charged to an applicant if they are using a registry service provider that is not pre-evaluated.” ICANN org would like the PDP WG to consider a uniform fee for each application irrespective of the utilization of a pre-evaluated registry service provider.
Affirmation with Modification 15.3:
For understanding of the Affirmation, could the PDP WG clarify what it categorizes as historical costs and “actual costs directly related to implementation” (e.g., how would overhead, research and other costs be categorized?). Additionally, historical and development costs will only be known once the Program is fully developed (e.g., at the opening of the application window for each subsequent round). Alternatively, ICANN org is able to provide projections of the development cost.
Affirmation with Modification 15.4:
The PDP WG states that “this affirmation is modified by the below implementation guidance.” Could the PDP WG clarify which portions of the affirmation and implementation guidance are meant as policy recommendations versus implementation guidance?
Implementation Guidance 15.5:
The PDP WG notes, “in the event that the estimated application fee, based on the revenue neutral principle, falls below a predetermined threshold amount (e.g., the application fee floor), the actual application fee should be set at that higher application fee floor instead.” ICANN org notes that the PDP WG did not come to an agreement on a set of criteria for the application fee floor; however, it would be helpful to understand whether the PDP WG foresees ICANN org or some other entity determining the “predetermined threshold amount.” Org notes the PDP WG suggestion that an assessment should take place prior to each round.
Rationale for Implementation Guidances 15.5 and 15.6​:
The PDP WG notes that “the purpose of an application fee floor is to deter speculation and potential warehousing of TLDs, as well as mitigate against the use of TLDs for abusive or malicious purposes.” ​ICANN org seeks input on whether this provision could be harmonized with the "bona fide" applicant provision from the Auction section, as the fee schedule could be proactive as opposed to a reactive means of deterring speculative applications.
Recommendation 15.7 and Implementation Guidance 15.8:
The PDP WG states (Recommendation 15.7) that “ICANN must have a plan in place for managing any excess fees collected or budget shortfalls experienced. The plan for the management and disbursement of excess fees, if applicable, must be communicated in advance of accepting applications and collecting fees for subsequent procedures.” Additionally, the PDP WG notes (Implementation Guidance 15.8) that “if excess fees are collected in subsequent procedures and the cost recovery model is followed (e.g., the application fee floor is not implemented) any excess fees should be returned to applicants where possible.” ICANN org notes that this proposes a fundamentally new approach that departs from the manner in which the 2012 round was handled. Significant questions arise such as: (1) What is considered excess (in total, by application)? (2) When is an excess determined (at what stage of a round)? (3) Presuming that an excess should be determined, when is a round completed? (ICANN org notes that the 2012 round is still not completed and as such, some applicants may no longer be in operation when rounds are completed.)
Additionally, this approach may also create an incentive for applicants to challenge the performance of any procedure carried out by ICANN org or the Board. While ICANN should remain accountable at all times to stakeholders on its use of funds, the incentive for applicants to challenge activities for the purpose of maximizing a potential refund is highly likely. Please also refer to the ICANN Board comment on this topic.
Recommendation 15.9 and Implementation Guidance 15.10:
The PDP WG notes that in the event an application fee floor is used to determine the application fee, “to help alleviate the potential burden of an overall budget shortfall, a separate segregated fund should be set up that can be used to absorb any shortfalls and topped-up in a later round. The amount of the contingency should be a predetermined value that is reviewed periodically to ensure its adequacy.” It would also be helpful to understand whether the PDP WG foresees a separate contingency fund for each round or a general contingency fund for the entire program.
Rationale for Recommendations 15.7 and 15.9 and Implementation Guidance 15.8 and 15.10:
The PDP WG notes “that it is important for ICANN to have a contingency fund to support the Program if fees are insufficient to support program activities in the short term. The PDP WG notes that the fund could later be replenished through additional application fees collected in subsequent rounds.” ICANN org would like to understand whether costing for future rounds should include historical recoupment costs.
Recommendation 16.1:
The PDP WG recommends “that for the next application window and subsequent
application windows, absent “extenuating or extraordinary” circumstances, the application submission period must be a fixed period of 13 weeks and should not begin or end on a weekend.” ICANN org suggests the PDP WG to consider providing a minimum and maximum timeframe for the application submission period (instead of the fixed 13 week period) to allow for greater flexibility.
Recommendation 17.2:
The PDP WG recommends “expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees and attorney fees related to the application process.” ICANN org suggests that the PDP WG consider a per-applicant limit on the proposed fees and requirements that any such fees covered are both reasonable and based on documented costs incurred. Additionally, it would be helpful for the PDP WG to provide examples of the types of services for which it is recommending attorneys fees be covered, as further information is needed to understand how ICANN payment or support of such fees might be appropriate. ICANN org would also like to seek confirmation whether these fees are to be provided on a reimbursement basis, as eligibility for Applicant Support is determined after submission of an application. The PDP WG may want to consider capturing the proposed fees as part of the pro bono assistance program. ​Please also refer to the ICANN Board comment on this topic.
Recommendation 17.3​:
This Recommendation appears to conflate policy and Implementation Guidance, as the recommendation is to “improve” a number of activities “as proposed in the implementation guidance below.” An alternative formulation would be: “The Working Group recommends that ICANN conduct outreach, awareness-raising, application evaluation, and program evaluation elements of the Applicant Support Program, considering usability of the program.” The goal of this formulation is to create: (a) A policy requirement which can be clearly assessed as to whether it has been fulfilled and (b) a clearer distinction between the Program requirement and Implementation Guidance.
Implementation Guidance 17.6:
The PDP WG notes that “outreach efforts should not only target the Global South, but also ‘middle applicants,’ which are located in struggling regions that are further along in their development compared to underserved or underdeveloped regions.” ICANN org would like to understand the PDP WG’s criteria for an applicant to qualify as a “middle applicant,” as well as for “struggling regions.” Additionally, ICANN org notes its understanding that the WG does not recommend limiting outreach to a particular region and intends that the org engage with stakeholders in multiple regions ​who may not be aware of ICANN and the DNS ecosystem.
Implementation Guidance 17.8:
Furthermore, on the reference to “targeted regions,” ICANN org understands this in light of the guidance in 17.6 that outreach is not limited to particular regions.
Implementation Guidance 17.14:
Please refer to the ICANN Board comment on this topic.
Recommendation 17.15:
This Recommendation states that “if an applicant qualifies for Applicant Support and is part of a contention set that is resolved through an auction of last resort, a bid credit, multiplier, or other similar mechanism must apply to the bid submitted by that applicant.” ICANN org would like to note that Recommendation 17.15 will need further discussion in order to be implementable. One consideration would be that there is perhaps a dissonance between​ suggesting that an applicant requires support (including direct financial assistance for application drafting, etc.), while also suggesting the applicant should be holding some amount of funds in reserve in order to succeed in an auction. For example, how would these reserve funds be assessed as it pertains to financial assistance qualification? If there is no contention, should that bid amount be accessed? Additionally, ​it would be helpful to understand if the Applicant Support recipient is expected to pay a specified amount should it succeed in the bidding (any thresholds or percentages). ICANN org also notes that the possibility of auction bid credits might unintentionally encourage use of the Applicant Support Program by those who might not necessarily need financial assistance, as a means to game the system.
Implementation Guidance 17.17:
Similar to Recommendation 17.15,​ ​ICANN org notes that this Implementation Guidance may require further consideration in order to be implementable. The PDP WG notes that “If the Applicant getting Applicant Support prevails in an auction, there should be restrictions placed on the applicant from assigning the Registry Agreement, and/or from any Change of Control for a period of no less than three (3) years.” ICANN org seeks to understand what would happen if the Applicant Support Program (ASP) recipient merges or is acquired during this prohibition period. Would they lose the TLD? Additionally, ICANN org would like to clarify that an Emergency Back-end Registry Operator (EBERO) is a technical backstop and will not trigger an assignment.
The PDP WG suggests, “all assignments after such time shall be governed under the then-current Registry Agreement standard provisions; provided that any Assignment or Change of Control after the third year, but prior to the seventh year, shall require the applicant to repay the full amount of financial support received through the ASP plus an additional ten percent (10%).” ​Org would like clarity whether this Implementation Guidance is solely with respect to ASP auction scenarios or whether this would apply to any ASP recipient that may undergo an Assignment or Change of Control after the third year, but prior to the seventh year.
Recommendation 17.18:
The PDP WG notes “unless the Support Applicant Review Panel (SARP) reasonably believes there was willful gaming, applicants who are not awarded Applicant Support (whether “Qualified” or “Disqualified”) must have the option to pay the balance of the full standard application fee and transfer to the standard application process.” The PDP WG notes org’s concerns regarding a mechanism or potential penalty to identify and prevent such gaming. ICANN org appreciates the PDP WG’s efforts to address these concerns. ​It is unclear whether applicants that have been determined by the SARP to have engaged in deliberate gaming will have to reimburse any pro bono work, writing fees or attorney fees that they have received during the application process (Recommendation 17.2). Additionally, in the absence of willful gaming, it would be helpful to understand what happens to the above mentioned pro bono work, writing or attorney fees should an applicant choose to transfer to a standard application.
New Issues:
The PDP WG has requested “community input on whether the ASP should include the reduction or elimination of ongoing registry fees specified in ​Article 6​ of the Registry Agreement for eligible candidates.” ICANN org would like to note that any Recommendations in this area would require further consideration from an implementation perspective.
58
Entered by ICANN Org StaffCraig SchwartzfTLD Registry Services, LLCNo
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100