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

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 14 December 15:00 UTC
by Julie Hedlund Dec. 10, 2020

Dec. 10, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Monday, 14 December 2020 at 15: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 8: Conflicts of Interest<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Topic 10: Applicant Freedom of Expression<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> Topic 33: Dispute Resolution Procedures After Delegation<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…> 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, 10 December 2020 at 03:00 UTC
by Julie Bisland Dec. 10, 2020

Dec. 10, 2020

Dear all, The recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 10 December 2020 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/-IXzC> (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 Julie

1 0

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

Dec. 10, 2020

Dear Working Group members, Please see below the notes from the WG meeting on 10 December at 03: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-10+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 21.1: Geographic Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 11 -- dotBERLIN GmbH & Co. KG and Hamburg Top-Level-Domain GmbH, this statement was also included as "new information" by the GeoTLD Group re: Reiterates proposals and position discussed in WT5; Always require letters for Non-Capital City Names ACTION ITEM: Refer to the EPDP on IDNs. Topic 4: Different TLD Types<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 17 – ICANN Org 2. Note the change of language between IDN Variant and Variant TLD. Agree we should change the term when applying at the TLD level. ACTION ITEM: Note the use of terms and make sure they are consistent. Notes: 1. Updates to Statements of Interest: None provided. 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: -- Goal is to start the Consensus Call on 23 December and end it on Tuesday, 05 January 2021. -- Co-Chairs to post consensus designations on 06 December and to ask for responses by 08 January along with any minority statements. -- WG members should start to prepare minority statements as soon as possible. -- Deliver everything to the Council by the motion and document deadline by 11 January 2021. -- Consideration should be given to packaging the recommendations and that should be communicated well ahead of time. -- The guidelines for the Consensus Call and designations will be sent out in an email. Topic 21: Reserved Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 10 -- Thomas Barrett (Individual) re: Define process for unreserving a reserved string. Leadership Comments: WG to discuss guideline on principles (perhaps) but process to IRT Jeff: I think this relates to names at the second level and was discussed initially within WT 2 (I think) - So, it should just be noted. Row 11 – ARTICLE 19 re: Concerns about freedom of expression. Leadership Comments: CLO: Discussed and reservation IS the exception IMO. Jeff: Correct, and most names currently reserved are IGOs which is separate PDP. Row 16 -- Internet Architecture Board Leadership Comments: We should propose referencing in the rationale SAC113 on the Private Use TLD proposal, but I am not sure we are in a position to affirm. Row 17 – WIPO Leadership Comments: Noted - This should be referred to RPM PDP Phase 2. Row 19 – ICANN Org re: “Has the PDP WG considered the inclusion of a process by which words on the reserved names listed in the 2012 round could be released to the related organization to operate as a registry (for example, the string ‘IETF’ released to the Internet Engineering Task Force)?” Leadership Comments: WT did discuss this with the geographic terms and WG agreed that any such process for the release of those should be a separate effort. Discussion: -- Maybe think about the two-characters – there is language in the registry agreement to allowing for two letters at the second level. Maybe language that gives ICANN Org discretion. -- Is it really that names are being reserved for a particular entity or because of confusion with that entity. May need to be resolved by a separate PDP. Row 20 – SSAC members re: Call with SSAC Working Party members on 19 October 2020 (https://gnso.icann.org/sites/default/files/policy/2020/transcript/transcrip…) - Two character letter digit combinations should not be allowed. - Notes SAC113. Leadership Comments: There was a lot of discussion on this in WT2, also in WT5. The WG did not recommend character-letter. Topic 21.1: Geographic Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 10 -- Swiss Government OFCOM re: Reiterates proposals and position discussed in WT5; Notification Tool Leadership Comments: Noted. Let’s check the "notifications" we have with other sections and perhaps add an ability to receive notifications for any applications that indicate they are a geoTLD. WG to consider new Implementation Guidance to publish or notify everyone that these applications are geographic, or are of which type of string. Isn't this already in the application status? The difference is that this would be an outward push. Discussion: -- We talked about this for a long while in WT5. It always begs the question which is notified by who and also how that who decides what should be notified. I don't think we should be second guessing this at this late stage. -- It only seems to be workable if it is an 'opt in' notification. -- More useful to have notification system for public comments on individual applications rather than having to monitor the individual application page. -- It will be difficult to find a system that works completely. -- At best this is a "nice to have". Let's focus on critical things. -- The problem is building a system to do what can be done just by reading the source material available to all. -- Also, there is nothing keeping ICANN Org from doing this voluntarily of their own free will. I don't think we should codify this in the report in any way. -- Doesn’t need to be policy. Row 11 -- dotBERLIN GmbH & Co. KG and Hamburg Top-Level-Domain GmbH, this statement was also included as "new information" by the GeoTLD Group re: Reiterates proposals and position discussed in WT5; Always require letters for Non-Capital City Names Leadership Comments: (E) Noted 1. Noted as this was discussed in Work Track 5 and not supported to go forward. 3. Non-Capital City - Noted as this was discussed in Work Track 5 and not supported to go forward. Discussion: -- Could the substance fall under the scope of the EPDP on IDN Variants? -- Forward to the EPDP on IDNs. ACTION ITEM: Refer to the EPDP on IDNs. Row 19 -- Xiaodong Lee (Individual) re: Reduce/waive charges for city Name TLDs. Leadership Comments: Noted. This service would have to go through an RSEP (Or initial RSTEP during APPLICATION). Row 20 – ALAC and Row 21 – GAC re: Develop and implement a Notification Tool: no limiting criteria, opt-in basis; or limited to GAC members. Leadership Comments: 1. Open notification tool - See above 2. The GAC can always work with their ICANN support staff to have such a tool regardless of whether we recommend this or not as official policy. Row 22 – ICANN Org re: Clarify if reserved names with variant labels according to the RZ-LGR will also be reserved; provide guidance relating to "relevant governments or public authorities". Leadership Comments: Variant issue should be with reserved names section. This should be looked at by ePDP IDN group. Topic 4: Different TLD Types<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 11 -- National Association of Boards of Pharmacy (NABP) re: Must be able to change application to Category 1 if string is found to be in that category. Leadership Comments: There would be status in the portal/look up website, which would change based on the evaluation Row 17 – ICANN Org Leadership Comments: 1. Let’s display the Table during the call as it could provide a good visual guide. 2. Note the change of language between IDN Variant and Variant TLD. Agree we should change the term when applying at the TLD level. ACTION ITEM: Note the use of terms and make sure they are consistent. 3. Geographic Names are both an application type and a string type. The application type means those applications that apply for a geographic TLD with the intent to use it as a geographic TLD (For the ones of course not reserved). Those must have support, etc. A string, however, can be geographic (when used in one context), but the application is not for a geographic TLD (in the sense it is not being used in its geographic capacity) and therefore may not need support. This is more of a semantic distinction as opposed to having 2 "categories of TLDs 4. "Exceptional Circumstances" is hard to predict in advance. But in theory it is possible for someone to propose adding a TLD that is to be used with IoT. It may have no "registrants" in the sense we normally thing of them, but rather may have registered "devices". If that were the case, then that applicant could propose eliminating some of the contractual provisions, or other requirements that don’t make sense to apply to them. This in theory could result in the creation of a new category of TLDs. We have no idea if anyone would ever apply for something like that, but we do believe some flexibility should be in place. Refer to the general principles of encouraging innovation and competition. Stating that while the WG is clear that they don't support creating new categories for the sake of doing so, but there should be some flexibility for new types. Exceptional circumstances should be dealt with in a transparent manner in a case-by-case basis per the predictability framework. Discussion: -- Important for ICANN Org to be responsive to innovation and change. -- ICANN Org doesn’t have to do this alone.

1 0

5th Topical Questions: Applicant Fees
by Jeff Neuman Dec. 9, 2020

Dec. 9, 2020

All, This is the Fifth Topical E-mail on outstanding questions being "put to the list." This covers Applicant Fees (Topic 15) 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. Working Group Draft Report: 1. 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 implementation guidance below describes in more detail how this should be accomplished. 2. 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. The disbursement mechanism must be communicated before applicants submit applications and fees to ICANN. ICANN Board Comment: 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) Working Group Discussion: There are several main points in this comment. First is that there should be some money set aside to continue to fund the ongoing new gTLD Program for subsequent rounds. Second, there is an issue as to the timing of when refunds are issued. Leadership Recommendation - Proposed Implementation Guidance: * Although ICANN must operate the new gTLD Program on a Cost Recovery basis (subject to any floors as set forth in this report) may set aside a certain small percentage of excess fees (to the extent there are excess fees) to apply towards covering the costs of future subsequent rounds of new gTLDs to ensure that the new gTLD Program is able to continue into the future. * In addition, with the remainder of any excess fees, ICANN may establish a schedule for the disbursement of refunds upon the achievement of specified milestones. For illustrative purposes only, such a schedule could establish that once 50% of the applications have been fully processed (eg., delegated, withdrawn, or not approved), ICANN would issue a payment of 25% of the excess fees back to the applicants. * ICANN should further explore these with the Implementation Review Team and ensure that the resulting implementation is clearly documented in the Applicant Guidebook. 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@01D6CA1C.7886E610] 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

7 11

Re: [Gnso-newgtld-wg] REMINDER: Review Revised Draft Final Report - DUE Tuesday, 01 December
by Julie Hedlund Dec. 9, 2020

Dec. 9, 2020

And here are the original attachments for reference. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Monday, November 30, 2020 at 10:12 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] REMINDER: Review Revised Draft Final Report - DUE Tuesday, 01 December Dear WG Members, This is a reminder that the deadline for the review of the revised draft Final Report for errors and omissions only, if any, is 23:59 UTC on Tuesday, 01 December. Please see the details below. Kind regards, Julie From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Monday, November 23, 2020 at 3:04 PM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Review Revised Draft Final Report - DUE Tuesday, 01 December Dear WG Members, As noted during the WG meeting on Thursday, 19 November, 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 in accordance with the actions agreed to by the WG during the WG meetings held between 17 September and 09 November 2020, as noted in the Log with page references. These actions also were captured during each meeting and circulated to the WG. The following topics were covered by the WG in its meetings and addressed in the revised draft Final Report: Community Applications, General Comments, Predictability, Applicant Support, Limited Challenge/Appeal Mechanism, Applicant Guidebook, Communications, Systems, Application Change Requests, Application Fees, Base Registry Agreement, GAC Early Warning / GAC Consensus Advice, Role of Application Comment, and Objections. Note: In reviewing the revised draft Final Report WG members are requested to limit their review to the referenced pages in the Log and 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 23:59 UTC on Tuesday, 01 December. Kind regards, Julie Julie Hedlund, Policy Director

9 11

Re: [Gnso-newgtld-wg] 7th Topical E-mail: GAC Advice (Topic 30)
by Jorge.Cancio＠bakom.admin.ch Dec. 8, 2020

Dec. 8, 2020

Dear all regarding 30.3 and the obligation to provide a rationale: as the GAC consensus input mentions, this flows from Section 12.3. of the Bylaws applicable to all ACs: „Section 12.3. PROCEDURES Each Advisory Committee shall determine its own rules of procedure and quorum requirements; provided that each Advisory Committee shall ensure that the advice provided to the Board by such Advisory Committee is communicated in a clear and unambiguous written statement, including the rationale for such advice. The Board will respond in a timely manner to formal advice from all Advisory Committees explaining what action it took and the rationale for doing so.“ As to 30.4., while it is true that there is no GAC consensus position on retaining the „strong presumption“ language, it is supported by many and the rationale for retaining it is more nuanced as presented. Here is the full argumentation from the GAC input: „ Regarding Recommendation 30.4, some GAC Members continue to consider that the Bylaws changes from 2016 did not introduce any modification to the section on GAC Advice which would require a change of the language included in Section 3.1 of the 2012 Applicant Guidebook which states that GAC Consensus Advice “will create a strong presumption for the ICANN Board that the application should not be approved”. In the opinion of said GAC Members this language was part of a delicate compromise during the 2012 round preparations and should therefore be maintained. Finally, said GAC Members consider that the possibility of maintaining a dialogue with the concerned applicant is not hampered by this language, considering that recommendation 30.7 of the PDP WG establishes ways and means to conduct such a dialogue even in the case of GAC Consensus Advice objecting to an application.“ best Jorge (in my national capacity) ________________________________ Von: mail(a)christopherwilkinson.eu CW <mail(a)christopherwilkinson.eu> Datum: 4. Dezember 2020 um 19:39:57 MEZ An: Jeff Neuman <jeff(a)jjnsolutions.com>, gnso-newgtld-wg(a)icann.org <gnso-newgtld-wg(a)icann.org> Betreff: Re: [Gnso-newgtld-wg] 7th Topical E-mail: GAC Advice (Topic 30) Good evening: The original text on the Scope of GAC Advice is unnecessarily antagonistic to the GAC and I grant Leadership's wisdom in making the changes, albeit, diplomatically, damage has likely already been done. 1. I do not support linking GAC advice or indeed the advice of GAC members explicitly to the Bylaws. (a) the Bylaws are not themselves immutable and (b) it is impossible to foresee all issues that may arise in the context of large and complex Rounds in the future. 2. I would retain the `strong presumption` language. I do not recall a consensus in the PDP to delete that. Quibbling about it can but become an embarrassment to the Board. 3. I would propose to replace 'various laws' with 'applicable local law' (Articles of Incorporation language). Thankyou CW El 4 de diciembre de 2020 a las 15:46 Jeff Neuman <jeff(a)jjnsolutions.com> escribió: 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 _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

2 1

Operational protections for registrants
by Kathy Kleiman Dec. 8, 2020

Dec. 8, 2020

Hi Jeff, Cheryl and All,Tx for a good meeting yesterday. On a small note, I did not hear any objections to my suggestion that we rename yesterday's section slightly to "Operational protections for registrants." This reflects the scope that Jeff presented and his intro and a clearer picture of the EBERO issues of the matter. I would ask leadership to consider for clarity. Tx much, Kathy

4 3

Post Call | New gTLD Subsequent Procedures Working Group | Monday, 07 December 2020 at 20:00 UTC
by Terri Agnew Dec. 7, 2020

Dec. 7, 2020

Dear all, The recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 07 December 2020 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/_YXzC> (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 Terri

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 10 December 03:00 UTC
by Julie Hedlund Dec. 7, 2020

Dec. 7, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Thursday, 10 December 2020 at 03: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 21: Reserved Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Topic 21.1: Geographic Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Topic 4: Different TLD Types<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> 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

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 07 December 20:00 UTC
by Julie Hedlund Dec. 7, 2020

Dec. 7, 2020

Dear Working Group members, Please see below the notes from the WG meeting on 07 December at 20: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-07+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 18: Terms and Conditions<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…> Row 13 – RySG and Row 14 -- The Galway Strategy Group re: Reference other relevant recs in this section ACTION ITEM: Check to make sure that mentions of changes to Terms and Conditions in other sections are cross-referenced in Section 18. Row 19 – ICANN Board Re: ““[u]nless required by specific laws,ICANN Board members’ fiduciary duties, or the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, ICANN org must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.”” ACTION ITEM: Double check against the GAC language. Revise to ensure language also is consistent with the Bylaws. Topic 22: Registrant Protections<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 11 – ALAC re: GDD should publish more detail/explanation on 5 critical registry functions triggering EBERO. ACTION ITEM: Add to Metrics Section. Topic 7: Metrics and Monitoring<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 13 – RySG re: Suggested metrics ACTION ITEM: Add the metrics suggested. Row 16 – ALAC ACTION ITEM: Include ALAC suggested metrics on EBERO. Row 17 -- ARTICLE 19 re: Metrics and monitoring should be in line with data protection rules and privacy rights. Leadership Comments: I think we can add a general disclaimer that this be adhered to. ACTION ITEM: Add a general disclaimer that metrics and monitoring should be in line with data protection rules and privacy rights. Topic 23: Closed Generics<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> ACTION ITEM: Leadership will meet to discussion and come back with some suggestions for how we go from here. Notes: 1. Updates to Statements of Interest: None provided. 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 18: Terms and Conditions<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…> -- Most commenters agreed with the output as written. Row 13 – RySG and Row 14 -- The Galway Strategy Group re: Reference other relevant recs in this section ACTION ITEM: Check to make sure that mentions of changes to Terms and Conditions in other sections are cross-referenced in Section 18. Row 19 – ICANN Board Leadership Comments: A. The purpose of our changes are to ensure predictability to the process. The Reservation of Rights for the ICANN to reject any application for any reason essentially obliterates all of the improvements added to the program to ensure there is predictability in the process. If there are certain reasons for being able to reject an application that are not enumerated, then please let us know what you believe is missing. Re: ““[u]nless required by specific laws, ICANN Board members’ fiduciary duties, or the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, ICANN org must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.”” ACTION ITEM: Double check against the GAC language. Revise to ensure language also is consistent with the Bylaws. Discussion: -- Question: Does the language of the recommendation parallel the GAC language? -- We didn’t cite the language from the Bylaws on the exercise of fiduciary duties. B. The purpose of this provision is not to give applicants grounds to allege that the appeal process didn’t meet their satisfaction, but rather to state the Working Group's view that a covenant not to sue in favor of ICANN is only palatable if the Appeals / Challenge mechanism (as described in Section 32 is actually implemented). If there is language ICANN legal would like to add to make this clear in the actual Ts and Cs, and that language is consistent with the intent of the Working Group, then we would encourage ICANN to run that by the IRT. Row 20 – ICANN Org re: Considerations regarding covenant not to sue. Clarify recs regarding refunds. Leadership Comments: 1. See above. 2. Discuss Refund issue with WG Re: “applicants must be allowed some type of refund if they decide to withdraw an application because substantive changes are made to the AGB or program processes and such changes have, or are reasonably likely to have, a material impact on applicants.” Discussion: -- If it is a material change and impacts the applicant in a significant way then there should be a full refund. -- Wonder about the mechanism and logistics of a full refund – how to determine the threshold. -- Maybe we need a benchmark of what a material change would be. Could be if a change is made to the AGB that makes an applicant ineligible then it should get a full refund. -- It's important to acknowledge that the investment of applying for a new gtld/s is more than just the $185k application fee. -- Keep it as is but specify that it is up to a full refund. Topic 22: Registrant Protections<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 11 – ALAC re: GDD should publish more detail/explanation on 5 critical registry functions triggering EBERO. ACTION ITEM: Add to Metrics Section. Row 13 – ICANN Board Re: The Board encourages the PDP WG to provide more details in its rationale and to ensure there are no hypothetical cases in which an EBERO might be appropriate. In addition, the Board encourages the PDP WG to consider the potential impact on end users and consumers in the event of a short-term or long-term technical or business failure of a .BRAND TLD. Discussion: -- Think we should have language about EBERO for .BRANDs. -- Not sure how a .BRAND shutting down would impact anyone except .BRAND. -- There could be technical reasons that a .BRAND registry would need to shut down. -- I also believe this is firmly about registrant protection. It's about ensuring that those who have built their digital presence on a domain within a TLD that fails, do not lose that digital presence. Recognizing the cost to transition to a new domain is not insubstantial. -- What about help for a .BRAND that is having technical problems? -- This is the Brand's problem. It shouldn't be forced to have this protection. This is help that is not wanted. -- EBERO is not a protection for a TLD - it is a death of a TLD, and just zombie copy of the last state of the TLD. Row 14 – ICANN Org re: Concerns about proposed COI exemptions Leadership Comments: Noted for 22.5, 22.6, and 22.7 Topic 7: Metrics and Monitoring<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 13 – RySG re: Suggested metrics Leadership Comments: Suggest inclusion? ACTION ITEM: Add the metrics suggested. Row 14 – ALAC Leadership Comments: Noted. Some of these have been discussed in other contexts Row 15 – ALAC Leadership Comments: These metrics were already incorporated into the Applicant Support Program section. Row 16 – ALAC ACTION ITEM: Include ALAC suggested metrics on EBERO. Row 17 -- ARTICLE 19 re: Metrics and monitoring should be in line with data protection rules and privacy rights. Leadership Comments: I think we can add a general disclaimer that this be adhered to. ACTION ITEM: Add a general disclaimer that metrics and monitoring should be in line with data protection rules and privacy rights. Row 18 – ICANN Org Leadership Comments: Need to explore re: 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.” Noted. Topic 23: Closed Generics<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> See Closed Generics Proposals included in the draft Final Report: https://community.icann.org/display/NGSPP/Proposals+Included+in+Draft+Final… -- In general, very little support for the two extremes (all all/restrict all). -- Fair number of comments on closed generics that support the public interest goal. -- ICANN would probably not want to be involved in a public interest test. -- Legitimate public interest goal is difficult to define. But also don’t think this WG would agree to allow Closed Generics without restrictions. -- Don’t see how we can get agreement on the three proposals. -- GAC is not likely to withdraw its comments. -- Don’t see we can come to something that is acceptable. Banning Closed Generics might be the only option. -- One thing the Board can do is reject the GAC Advice on the basis that a PDP WG has discussed this and come up with a number of proposals – there has been community discussion without a unified position. -- IPC and BC had concerns in their comments about why it wasn’t acceptable for the WG to have a non-recommendation. -- If we cannot define “global public interest” and make it predictable, then we can’t recommend Closed Generics. -- 1. We need to be responsive – may want to be more pointed than just an objective summary. Need to highlight why this was difficult – defining the “global public interest” in this context. 2. Determine whether we have consensus against unfettered Closed Generics. Recommendation could be that Closed Generics are suspended. A ban seems to go beyond what we could agree to. -- It certainly is OK to put the details of non-agreement to change the 2012 AGB in the Deliberations section, but not to pretend there are levels of agreement that might rise to a rough consensus that would convert one of the 3 non-agreed options into a Recommendation. -- Some support for a recommendation of suspension, but some don’t support. -- Do not support an indefinite suspension. This is one of the most active PDP WGs with consistent attendance. Discussing this for another two to three years isn't going to change much. -- We can also recommend that this be worked on and a permanent result should be arrived at. -- We have no way to understand the harm. What about rather than an suspension, a number of closed generics be allowed in order to better understand whether the perceived harm is real or are there benefits to Internet users and innovation in the domain name space. -- The fallback on this topic could just as easily be 2012 implementation versus the 2012 silence on the topic. In all other areas, 2012 IMPLEMENTATION is the fallback. -- Wonder whether it’s possible to agree to allow Closed Generics on a case-by-case basis and for them to be challenged. -- There is a difference between a "Closed Generic that serves a Public Interest" versus determining that a Closed Generic is "in the Global Public Interest". Further policy development efforts should be focused on the former. -- Make it clear that we are not recommending a ban in the form of a suspension – that we want it to be dealt with. ACTION ITEM: Leadership will meet to discussion and come back with some suggestions for how we go from here.

1 0