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

Review Revised Final Report - DUE Thursday 10 December at 3:00 UTC
by Emily Barabas Dec. 7, 2020

Dec. 7, 2020

Dear WG Members, Please see for review the attached revised draft Final Report in Word and PDF, along with the Log of Final Report Action Items and Edits. The redlines in the attached revised draft Final Report reflect the edits made by leadership and support staff on the following: * Actions agreed to by the WG during the WG meetings held between 17 November and 03 December 2020, as noted in the Log with page references. These actions also were captured during each meeting and circulated to the WG. * Actions stemming from the Co-Chairs Topical Emails 1-3 (see the Log for links to the relevant emails). * Updates to the “boilerplate” sections of the report (for example the Preamble and Conclusion) to reflect that this is the Final Report as opposed to the draft Final Report. * Minor updates throughout the document to ensure that the content is current, for example in reference to the status of initiatives external to the PDP. The following are not included in this redline and will be included in the following redline version: * Additional updates to Topic 34: Community Applications, based on recent email exchanges on the mailing list following publication of the last redline. * Actions stemming from Topical Emails 4-8, as the deadline for responding to these emails have not yet passed. Note: In reviewing the revised draft Final Report WG members are requested to limit their review to the redlines in the revised draft Final Report, and to focus only on errors and/or omissions, if any. If any errors/omissions are noted please send them to the WG email distribution list, referencing the page number and text, respectively. Please submit comments to the list, if any, not later than 3:00 UTC on Thursday 10 December. Kind regards, Emily Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Fourth Topical Questions: String Similarity Outstanding Questions
by Jeff Neuman Dec. 7, 2020

Dec. 7, 2020

All, This is the Fourth topical E-mail on outstanding questions being "put to the list." The first was on Predictability, second on Applicant Support, third was the Guidebook, and this covers string similarity (Topic 24). Remember: We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document. If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP. Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered. Lets not let the perfect be the enemy of the good. 1. Intended Use Comments * Comments: Some commenters have expressed concerns about Recommendation 24.3 in that it calls for an evaluation of the "intended use" of an applied-for string to determine whether terms that appear to be the singular/plural of each other will be allowed to co-exist (our paraphrasing). * WG Recommendations i. Recommendation 24.3. ...Specifically, the Working Group recommends prohibiting plurals and singulars of the same word within the same language/script in order to reduce the risk of consumer confusion. For example, the TLDs .EXAMPLE74 and .EXAMPLES may not both be delegated because they are considered confusingly similar. This expands the scope of the String Similarity Review to encompass singulars/plurals of TLDs on a per-language/script basis. * An application for a single/plural variation of an existing TLD or Reserved Name will not be permitted if the intended use of the applied-for string is the single/plural version of the existing TLD or Reserved Name. For example, if there is an existing TLD .SPRINGS that is used in connection with elastic objects and a new application for .SPRING that is also intended to be used in connection with elastic objects, .SPRING will not be permitted... * Path Forward i. First, put aside for the moment the issues expressed by the Board on "content" and assume for now that we can make these recommendations. An e-mail later will address the content / bylaws issue. ii. Second, most of the Working Group had little/no issue when the Plural / Singular evaluation was between two brands or a brand and a generic application. * Examples: Apple (brand) / apples (generic); Caterpillar (Brand) / caterpillars (generic); Gap (brand) / gaps (generic); Whirlpool (Brand) / whirlpools (generic). iii. Remember also that we have added sections to the Report to now require that applicants describe their proposed use of a TLD in their application and that the evaluators can ask Clarifying questions if they are unable to ascertain the intended use from the Applicant Responses (IG 24.4). Finally, If both versions (singular/plural) are allowed, then both applicants (in the case where they are both applied for strings) or the 1 successful applicant (in the case where the application is for a singular/plural of an existing TLD) will have to agree to be bound by its commitment to use the TLD only in the manner in which it proposed in its application. * Again, please ignore the potential Bylaws issue FOR NOW. We promise that we will address this later. iv. Here are the options we have * Leave the language As-Is; * Ban the co-existence of Singulars and Plurals except for where either one or both of the strings are a Specification 13 (Brand TLD); or * Ban the co-existence of Singulars and Plurals regardless of intended use completely. v. Absent agreement on either 2 or 3, we will stick with the language that we have (Option 1). A lot of work has gone into this already so we need a good amount of support from within the Working Group to change. Please have your comments (If any) by no later than 23:59:59 UTC on Monday, December 7, 2020. Sincerely, Jeff & Cheryl SubPro Co-Chairs

3 2

9th Topical Email: Processing of Applications for IDN Scripts
by Jeff Neuman Dec. 7, 2020

Dec. 7, 2020

This is the Ninth Topical E-mail on outstanding questions being "put to the list." This covers a question stemming from the ICANN Board's comment that applications for strings not integrated in the RZ-LGR should not be processed at all. (Topic 25) Remember: We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document. If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP. Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered. Let's not let the perfect be the enemy of the good. Language from Draft Final Report: Implementation Guidance 25.3: If a script is not yet integrated into the RZ-LGR, applicants should be able to apply for a string in that script, and it should be processed up to but not including contracting. Comment from the ICANN Board: The Board suggests that any applied-for string in a script not integrated in the RZ-LGR should not be processed until its validity and variant labels can be determined by RZ-LGR, following the Recommendation 5 of the RZ-LGR Study Group. Leadership Proposal. Based on the discussions that took place on the call as well as in other discussions of similar topics, we would recommend: 1. Leaving the language in the report as is with respect to the recommendation. Rationale: Although the Study Group recommended that the label should not "proceed through evaluation", it did not offer any thoughts as to whether the other uniquely GNSO new gTLD processes should apply. It did not discuss contention sets, public comments, objections, etc. This is most likely because the group with comprised of ccNSO members (as well as GNSO) and the aforementioned processes are uniquely for new gTLDs and not for the ccTLD Fast Track. 1. Include a warning for applicants that apply for scripts that have not been integrated into the RZ-LGR (one will be included in the next draft) that states that there is a chance that the application may not ever pass evaluation and that the applicant may be responsible for the costs of additional evaluations of that string. This is mentioned in the Study Group Report as "Option B". Please have your comments (If any) by no later than 23:59:59 UTC on Wednesday, December 9, 2020. Sincerely, Jeff & Cheryl SubPro Co-Chairs

2 1

Outstanding Final Questions on Applicant Support
by Jeff Neuman Dec. 4, 2020

Dec. 4, 2020

All, This is the Second topical E-mail on outstanding questions being "put to the list." The first was on Predictability. This one covers Applicant Support (Topic 17). Remember: We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document. If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP. Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered. Lets not let the perfect be the enemy of the good. 1. Define the "Middle Applicant"? * 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. * Our recommendation states: 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. In addition, the evaluation criteria for Applicant Support must treat "middle applicants" similar to those currently set forth in Criteria #1, Section 4 (Operation in a developing economy) of the Financial Assistance Handbook. * Recommendation: Rather than providing a definition of "middle applicants", we can remove the term from the recommendation to state: "Outreach efforts should not only target the Global South, but also those located in struggling regions that are further along in their development compared to underserved or underdeveloped regions. In addition, the evaluation criteria for Applicant Support must treat those applicants similar to those currently set forth in Criteria #1, Section 4 (Operation in a developing economy) of the Financial Assistance Handbook. 1. Gaming Bid Credits. The RySG stated that they have "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.' * On the Applicant Support call we asked the Registries to provide more information on their concerns on how the credits could be gamed. No examples have been provided. * Action Item: Please provide examples of the types of gaming that you are concerned about and any recommendations to handle those examples. Note: If we do not get any examples, then our recommendations will stay as is. Please have your comments (If any) by no later than 23:59:59 UTC on Thursday, December 3, 2020. Sincerely, Jeff & Cheryl Co-Chairs, SubPro PDP [cid:image001.png@01D6C7C1.FF10B970] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

2 1

8th Topical E-mail: Selection of CPE Provider
by Jeff Neuman Dec. 4, 2020

Dec. 4, 2020

All, This is the Eighth Topical E-mail on outstanding questions being "put to the list." This covers an additional Community question stemming from the ALAC comments (Topic 34) Remember: We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document. If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP. Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered. Lets not let the perfect be the enemy of the good. Comment from the ALAC: The ALAC set forth some processes for the selection of the CPE Provider(s) - Namely, that there is a need for greater community participation in ICANN's engagement of a CPE service provider/panelists, in the following 4 aspects: (i) the development of criteria by which ICANN Org is to evaluate and select candidates; (ii) the shortlisting of identified candidates; (iii) the final selection process; and (iv) the terms for inclusion into the contract between ICANN Org and the selected candidate. Leadership Proposal. Based on the discussions that took place on the call as well as in other discussions of similar topics, we would recommend adopting the following recommendation: "The Working Group recommends that the process to develop evaluation and selection criteria for the Community Priority Evaluation Provider (CPE Provider) must include mechanisms to ensure appropriate feedback from the ICANN community. In addition, any terms included in the contract between ICANN Org and the CPE Provider regarding the CPE process must be subject to public comment." Please note that based on previous discussions, Leadership did not believe that involving the community in the actual selection of the CPE Provider had sufficient support or would be acceptable to ICANN Org. Please have your comments (If any) by no later than 23:59:59 UTC on Tuesday, December 8, 2020. Sincerely, Jeff & Cheryl SubPro Co-Chairs [cid:image002.png@01D6CA31.802FC1B0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

2 3

7th Topical E-mail: GAC Advice (Topic 30)
by Jeff Neuman Dec. 4, 2020

Dec. 4, 2020

All, This is the Seventh Topical E-mail on outstanding questions being "put to the list." This covers GAC Advice (Topic 30) Remember: We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document. If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP. Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered. Lets not let the perfect be the enemy of the good. ISSUE: Scope of GAC Advice 1. Current Recommendations * Recommendation 30.3: As stated in the ICANN Bylaws, GAC Consensus Advice must include a clearly articulated rationale. The Working Group recommends that GAC Consensus Advice be limited to the scope set out in the applicable Bylaws provisions and elaborate on any "interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues." To the extent that the rationale for GAC Consensus Advice is based on public policy considerations, well-founded merits-based public policy reasons must be articulated. * Recommendation 30.4: Section 3.1 of the 2012 Applicant Guidebook states that GAC Consensus Advice "will create a strong presumption for the ICANN Board that the application should not be approved." Noting that this language does not have a basis in the current version of the ICANN Bylaws, the Working Group recommends omitting this language in future versions of the Applicant Guidebook to bring the Applicant Guidebook in line with the Bylaws language. The Working Group further notes that the language may have the unintended consequence of hampering the ability of the Board to facilitate a solution that mitigates concerns and is mutually acceptable to the applicant and the GAC as described in the relevant Bylaws language. Such a solution could allow an application to proceed. In place of the omitted language, the Working Group recommends including in the Applicant Guidebook a reference to applicable Bylaws provisions that describe the voting threshold for the ICANN Board to reject GAC Consensus Advice. 1. Comments 1. Re 30.4 - Some governments (including France and Switzerland) have concerns about the removal of "strong presumption", but this is not a GAC Consensus statement. 2. Re 30.3 - The GAC (and this is supported by a Consensus of GAC) opposes any limitation on the scope of GAC Advice like that found in 30.3 * Bylaws State: "The Governmental Advisory Committee should consider and provide advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues." * Our Report states: To the extent that the rationale for GAC Consensus Advice is based on public policy considerations, well-founded merits-based public policy reasons must be articulated * The Difference: Our WG added the language "well-founded merits-based public policy reasons must be articulated." * IPC Argues: We should make this even stronger and add more requirements that there should be data, facts or other evidence provided by GAC as well as reference to relevant national or Internation law wherever possible. * GAC: Argues that this is not right. If for 30.4 we are insisting on mirroring the language in the Bylaws, why, they argue, are we not mirroring the Bylaws language for 30.3? 1. Leadership Proposal: 1. Leadership believes that the Working Group still supports the notion of defaulting to the Bylaws when talking about GAC Consensus Advice and that we should be consistent. Therefore, we would recommend keeping 30.4 as is, but changing 30.3 to "As stated in the ICANN Bylaws has been the practice of the GAC since at least as early as ICANN56, GAC Consensus Advice must include a clearly articulated rationale. The Working Group recommends that GAC Consensus Advice be limited to the scope set out in the applicable Bylaws provisions and elaborate on any "interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues." To the extent that the rationale for GAC Consensus Advice is based on public policy considerations, well-founded merits-based public policy reasons must be articulated. 2. Rationale * We recognize that this goes counter to the comments of the IPC, but we believe we should be consistent. If we are insisting adherence to the Bylaws, then we should take them as a whole, not just the parts that we support. And the reality is that even though it makes logical sense for well-founded merits-based public policies be articulated, this language is not in the Bylaws. * With respect to the first change, we could not find in the ICANN Bylaws where it mandates a clearly articulated rationale, but it has been the practice of the GAC to include one since ICANN56. Please have your comments (If any) by no later than 23:59:59 UTC on Tuesday, December 8, 2020. Sincerely, Jeff & Cheryl SubPro Co-Chairs [cid:image002.png@01D6CA22.4C0E6940] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

2 1

6th Topical E-mail: Base Registry Agreement (Topic 36)
by Jeff Neuman Dec. 4, 2020

Dec. 4, 2020

All, This is the Sixth Topical E-mail on outstanding questions being "put to the list." This covers the Base Registry Agreement (Topic 36) Remember: We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document. If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP. Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered. Lets not let the perfect be the enemy of the good. Question we asked Community to Comment on Recommendation 36.4 states: "ICANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices." The Working Group discussed two options for implementing the recommendation: the addition of a PIC or a provision in the Registry Agreement. A new PIC would allow third parties to file a complaint regarding fraudulent and deceptive practices. ICANN would then have the discretion to initiate a PICDRP using the third-party complaint. If a provision regarding fraudulent and deceptive practices would be included in the RA, enforcement would take place through ICANN exclusively. Which option is preferable and why? ALAC Comment: ALAC does not object to the inclusion of the above provision as a PIC, but they are concerned that as a PIC, the only third parties that would have standing to commence a PDDRP would be an entity that can demonstrate that it was "harmed" by the alleged fraudulent or deceptive practice. Therefore, they would like to allow third parties to have standing to commence a compliance action based on fraudulent or deceptive practices regardless of whether they could demonstrate significant harm. Discussion / Recommendation: Based on the discussion on this topic and the general topic of ICANN compliance, Leadership recommends the following: 1. Confirm our support for the recommendation of adding a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. 2. In the event that ICANN receives an order from a court that a Registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. 3. In the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in (b) above, ICANN may, at its discretion, either commence Dispute Resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a Panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the Reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the Registry Operator's act or omission. Please have your comments (If any) by no later than 23:59:59 UTC on Tuesday, December 8, 2020. Sincerely, Jeff & Cheryl SubPro Co-Chairs [cid:image001.png@01D6CA1D.131AE3C0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 07 December 20:00 UTC
by Julie Hedlund Dec. 3, 2020

Dec. 3, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Monday, 07 December 2020 at 20:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 18: Terms and Conditions<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…> Topic 22: Registrant Protections<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Topic 7: Metrics and Monitoring<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Topic 23: Closed Generics<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> 1. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Best, Julie Julie Hedlund, Policy Director

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 03 December 2020 at 15:00 UTC
by Michelle DeSmyter Dec. 3, 2020

Dec. 3, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 03 December 2020 at 15:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/9YXzC> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards Michelle

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 December 15:00 UTC
by Julie Hedlund Dec. 3, 2020

Dec. 3, 2020

Dear Working Group members, Please see below the notes from the WG meeting on 03 December at 15:00 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-12-03+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 26: Security and Stability<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Rationale 26.4: It means that ICANN should strive for 5% and if for whatever reason it believes a different percentage should apply, it must either run that by the IRT (if before the AG) or through the Predictability Framework if after. ACTION ITEM: Add language to clarify re: Predictability Framework and IRT. ACTION ITEM: Re 26.7 -- Rephrase this Implementation Guidance as a general suggestion to ICANN org rather than a specific department. Also, need to clarify if we should change Root Zone Manager to Root Zone maintainer. ACTION ITEM: Need to update IG 26.8 based on new OCTO document on Root Zone early warning system. “ICANN should continue the work on the early warning monitoring system.” Also point to the OCTO paper and comment period in the rationale. Review the OCTO paper in case we need to further adjust the language. Circulate the revised language to the WG to review. ACTION ITEM: 26.9: Recommend keeping language the same and including ICANN's comment in the Rationale section. Since this WG did not do the work cited by ICANN org, it does not seem appropriate to change the wording in the Recommendation itself. Topic 29: Name Collisions<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> ACTION ITEM: Update the rationale of this section as to the current status of Study 2. Reflect the fact that the Board will not be acting on Study 2 until after the issuance of the Final Report and we should say our recommendations could be affected by further Board actions. ACTION ITEM: Discuss with leadership team and staff as to whether new Implementation Guidance should be developed for how the IRT should proceed with respect to the recommendation for a test to determine if there are any high-risk labels. Topic 11: Universal Acceptance<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> ACTION ITEM: Implementation Guidance that it would be useful for data to be collected by the UASG prior to the next round for the IRT. Notes: 1. Updates to Statements of Interest: -- Maxim Alzoba will be temporarily representing the RySG on the SSC through December. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 26: Security and Stability<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 14 – ICANN Org Leadership Comments: 1. 26.2: No, conservatism does not mean the rates that were in 2012. It means that when presented with a number of options, ICANN errs on the side of caution in general. Given the comments we have received and the reports we have reviewed, we believe the recommendations in this section about looking at the rate of change is "conservative." 2. IG 26.4: No, this has nothing to do with the SLAs, but rather governs when a registry operator may submit a valid request for delegation. Re: “Rationale for Implementation Guidance 26.4: The PDP WG notes "further work should be done on establishment of an appropriate rate for delegation," but this guidance says not more than five percent per month. Should it be interpreted that five percent per month is the upper-bound but ICANN could implement a lower bound if it is deemed appropriate? Implementation Guidance 26.6” Rationale 26.4: It means that ICANN should strive for 5% and if for whatever reason it believes a different percentage should apply, it must either run that by the IRT (if before the AG) or through the Predictability Framework if after. ACTION ITEM: Add language to clarify re: Predictability Framework and IRT. 4. IG 26.6: This is directly excepted out of SAC 100. Perhaps the question is better addressed to them as opposed to us. 5. 26.7: Agree with ICANN Recommendation as to the change in wording, but not on the last sentence which implies that the RZERC redo everything that we (the WG) and the SSAC have done on this subject. ACTION ITEM: Re 26.7 -- Rephrase this Implementation Guidance as a general suggestion to ICANN org rather than a specific department. Also, need to clarify if we should change Root Zone Manager to Root Zone maintainer. ACTION ITEM: Need to update IG 26.8 based on new OCTO document on Root Zone early warning system. “ICANN should continue working on the feasibility of the early warning monitoring system.” ACTION ITEM: 26.9: Recommend keeping language the same and including ICANN's comment in the Rationale section. Since this WG did not do the work cited by ICANN org, it does not seem appropriate to change the wording in the Recommendation itself. Row 15 – SSAC comments in meeting on 19 October 2020 – see: https://gnso.icann.org/sites/default/files/policy/2020/transcript/transcrip… Topic 29: Name Collisions<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 11 – ALAC re: Subject to recommendations of SSAC/NCAP; Row 14 – IPC re: Some support for 90-day controlled interruption; some support for NCAP to develop tests for risk and mitigation measures. Leadership Comments: Noted. This has been exhaustively discussed. Studies 2 and 3 are not yet fully scoped (nor will be by the time we finish our report). In addition, they still MUST be approved by the Board. Finally, the delegation of nearly every string will pose a "risk" of name collision. It’s the quantification of that risk along with the mitigation of that risk that is the real question. Finally, we note your request that the SSAC study the risks (if any) of Man in the Middle attacks. But this request should go to them and not to us. ACTION ITEM: Update the rationale of this section as to the current status of Study 2. Reflect the fact that the Board will not be acting on Study 2 until after the issuance of the Final Report and we should say our recommendations could be affected by further Board actions. Row 15 – ICANN Board re: Provide details on how future NCAP study result should be dealt with in future rounds. Leadership Comments: To the extent that there are any new recommendations as a result of the work of the NCAP, and those recommendations have an impact on the new gTLD program (either as a whole or with respect to future individual applications), then those should be introduced like all other changes, through the Predictability Framework. If the recommendations involve changing the policies (or adding new policies), then the Predictability Framework will involve the GNSO through its processes. See Topic 2. Discussion: -- Assume that the name collision policy would apply to all rounds in future. -- Question: How will the WG respond to the Board concerning its questions? Answer: The plan is to focus on getting the Final Report out with some possible changes to rationale where appropriate. After the report is out craft a response to the Board on why we did what we did. -- Concerned about potential delays where policy issues may be involved. -- SSAC said on 19 October that they are not creating dependencies on the outcome of the NCAP. So it doesn’t make sense for the WG to create dependencies. See also: https://www.icann.org/en/system/files/correspondence/chalaby-to-drazek-et-a…. Board doesn’t say that it should be a dependency and doesn’t seem to be agreement in this WG that it should be a dependency. -- The relevant issue for us is how do we address community efforts and recommendations that may come after we have concluded our work? Notwithstanding NCAP is the issue we are discussing now, there is potential for other subjects to collide in some way with our recommendations. So wouldn't it be prudent for us to have a high level discussion about how to account for those situations? The recommendation from leadership on this topic may be appropriate more broadly. -- We’ve built in processes to handle changes that occur before or after the AGB and round. Row 16 – ICANN Org re: Concern about technical challenges as a result of Implementation Guidance. Leadership Comments: Question back to ICANN: When a TLD is delegated, nic.TLD is put into the zone and is sent to the registry NIC page (and also to whois.nic.tld). How would exempting a name out of the Wildcarding process be any different. In other words, the impacts second level name could return an NXDOMAIN response, the NIC.TLD would return the usual response to the registry page, and every other name would return the specified controlled interruption page. Why would you need to suspend controlled interruption for every name if there is an issue with one label? Additional Questions for ICANN Org: -- First question is on the second example -- there was no generally available DNS implementation of Controlled Interruption prior to its artificial creation during the 2012 new gTLD round, so how difficult would this (or something like this) be to implement (recognizing that we have at least 2-3 years prior to a new TLD even being near delegation into the root). -- Second question is whether there are any other alternatives other than the extreme alternatives presented by the ICANN comment of either stopping controlled interruption for everything for 1 name? -- Third question is whether there were any examples in the 2012 round that they were aware of where this situation would have come into play. [Namely, what is the real risk of this edge case] -- Fourth question is If this is not possible, then why does ICANN state this in their proposed Name Collision plan for ccTLDs: “Managers of new ccTLDs are recommended to have a name collision reporting mechanism to act upon cases of severe harm (e.g., clear and present danger to human life) caused by name collision for, at least, the early days of the life of the new ccTLD's operation (please see for example <https://forms.icann.org/en/help/name-collision/report-problems>). Examples of measures that may be taken would include: removal of wildcard records from DNS during the controlled interruption period; removal of a second-level domain name from the DNS; and in extreme cases, removal of the TLD itself from the root zone (e.g., in case of harm caused by the TLD itself – dotless name – during the controlled interruption period). Note that these measures are only intended to be temporary while the affected party effects changes in their network configuration to avoid future harm (https://www.icann.org/resources/pages/cctld-mitigation-2014-10-02-en [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/cctld-miti…>).” Discussion: -- If the recommendation is for there to be a test to determine if there are any high-risk labels, and the IRT comes back and says based on the NCAP that a test isn’t feasible, it could be a policy issue. -- The IRT needs to converse with the NCAP, Board, etc. and decide what can be done and come back to the GNSO Council if it isn’t feasible. We haven’t provided any guidance on how the IRT should work. ACTION ITEM: Discuss with leadership team and staff as to whether new Implementation Guidance should be developed for how the IRT should proceed with respect to the recommendation for a test to determine if there are any high-risk labels. Topic 11: Universal Acceptance<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> Row 8 – ARTICLE 19 re: More should be done on UA - metrics on adoption. Leadership Comments: Noted. But what data will registries and registrars have on UA of issues that occur at other layers of the Infrastructure (namely applications). Row 11 -- Swiss Government OFCOM; dotBERLIN GmbH & Co. KG; Hamburg Top-Level-Domain GmbH and Row 12 -- InfoNetworks LLC re: More should be done on UA and Row 17 – ALAC re: suggested metrics Leadership Comments: Noted. And this can be directed to the UASG Row 13 – ALAC re: More should be done on UA - metrics on adoption, promotion of UA-readiness. Leadership Comments: Noted. The WG could discuss the following points 1. UA generally deals with the ability of third parties to accommodate new gTLDs (labels). Judging success of a program based on what third parties not under the auspices of ICANN and not within the control of the registries and registrars would not be appropriate. A program's success or lack thereof should only be measured by factors that can be controlled by the program being measured. 2. The ability to accept IDN second level registrations has not been a UA problem in years. Every registry and registrar that offers domain names for sale in a particular language/script by definition can accept, transmit and register IDN second levels. The problem is at the application layer, not the infrastructure layer. 3. Noting the above points, then what metrics (beyond perhaps a before and after next round comparison of data collected by the UASG) could be proposed, within the context of our SubPro remit Discussion: Re: “…and the public disclosure of policies available to ensure the successful adoption of Universal Acceptance across all registries and registrars.” -- How can you judge the success or failure of a program as a whole on the basis of actions outside of the control of the program, i.e., third parties? -- Also the issue of whether registries or registrars have applications that are accessible in all languages and scripts. You could do something on that from a compliance level, but not with third parties outside of ICANN control. Registries and registrars rely on third-party platforms. -- This isn’t only applicable to IDNs. Ensure that there is an adequate communication program next time. -- Our recommendations refer to the work of the UASG and that it should continue. One of our recommendations is to the IRT to collect data. -- If the metrics is already being collected can those be referred to? And I also don't think that promotion of UA readiness is a bad idea, notwithstanding Jeff's point that much of the problem is outside registries and registrars. -- And note too that the current focus on UASG work also includes provision of a lot of education material for implementation that should be activity around the timing of the next round as well. Data captured therefore will be useful (and interesting to some of us). ACTION ITEM: New Implementation Guidance that it would be useful for data to be collected by the UASG prior to the next round for the IRT. Topic 40: TLD Rollout<https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS…> Row 8 -- GoDaddy Registry re: Require Registry Operators to show "use" of the TLD within 1 year of delegation. Leadership Comments: New Proposal; Discuss with WG. But this would be incredibly subjective Discussion: -- Be clearer about what we mean by “use”. -- We spent quite a bit of time discussion “use”. -- We know in the case of some applicants they may have intent to launch, but having a 12-month launch could be unreasonable. Some may want to wait to launch during a quiet period. -- Also agree that until there are real protections for .brands (i.e. ICANN has to do a trademark search before it sells a TLD to someone that contains someone else's brand) in this program, we don't want to be dictating how much "use" a .brand needs to undertake. Keeping your brand from being squatted to death is a very important use. -- Lots of reasons why a registry may want to delay, some by choice and some by necessity.

1 0