December 2020 - Gnso-newgtld-wg

GAC Letter to Subpro PDP WG Co-Chairs - 14 Dec. 2020
by Benedetta Rossi Dec. 14, 2020

Dec. 14, 2020

Dear Cheryl and Jeff, Please find attached a letter from the GAC Chair, Manal Ismail, regarding the updated work plan for the Subsequent Procedures for New gTLDs PDP WG. The letter has been posted on the GAC website correspondence page [gac.icann.org]<https://urldefense.com/v3/__https:/gac.icann.org/contentMigrated/gac-respon…> and will be forwarded to GNSO Council leadership as an informal FYI due to ongoing discussions on this matter. Thank you, Kind regards, Benedetta -- Benedetta Rossi | GAC Advice and Policy Support, Senior Manager benedetta.rossi(a)icann.org<mailto:benedetta.rossi@icann.org> | +32.491.90.42.50 ICANN | Internet Corporation for Assigned Names and Numbers

2 1

Re: [Gnso-newgtld-wg] Thoughts on PICs / RVCs (LONG NOTE)
by Alan Greenberg Dec. 14, 2020

Dec. 14, 2020

Jeff, Sorry for the delay in replying to this message. I am not at all sure I agree with some of you "principles", but the specific details are not relevant to this message. However, the fact that I don't fully agree, and that you have used the expression "I/we believe/think" six times in this messages clearly implies some level of uncertainty regarding whether what you believe (or hope?) is how all of this will play out. Moreover, in at least one part of the scenario, you state as a fact something that may not turn out to be the case (see 1st remedy). There are two remedies that can address these issues: 1. There needs to be an enforceable contractual provision that in the case of PIC/RVC disputes, the Registry must contract with an ICANN identified dispute resolution provider (or one of a pre-selected group of providers). And obviously pay for the process. If the Ry can choose the provider, or simply refuse to do it, the whole thing becomes a sham. I also note that there may be costs associated with setting up the dispute resolution process and ICANN would have to bear that. 2. As noted above, there are a LOT of assumptions, beliefs and hopes in all of this. If any of these prove false, the house of cards collapses and we may be left in the laughable position of ICANN signing contracts which they know will not be enforceable. In the real world, there will always be cases where some contractual terms end up being unenforceable, but it makes no sense at all to have that knowledge before signing and proceed. We must include a recommendation that, should it turn out that the PIC/RVCs are not fully enforceable, the ICANN Board must take appropriate action to remedy the situation and ensure enforceability, even if that action requires Bylaw amendment. Alan At 2020-12-09 03:22 PM, Jeff Neuman wrote: >All, > >I know there have been a lot of e-mails on this >subject in the last week or so. I wanted to >give you some perspectives that we discussed at >the leadership level to see if we can find some >common themes and then we can see if any >language in our report needs to change (which I >am not convinced there will need to be >substantial changes). This is my (Jeff Neuman) >summary to move the discussion along. > >So, here is where I think we are on principles: > > > * Existing PICs used as PICs in New Registry > Agreements: We believe that the existing PICs > worded substantially the same as they were in > 2012 are ok under ICANNâs Bylaws as they > are sspecifically âgrandfatheredâ in. > > > * Domain Name Eligibility Rules: We all > seem to be on the same page that eligibility > rules for the registration/renewal (but not > necessarily usage) can be included in PICs/RVCs under ICANN Bylaws. > > > * Voluntary Registry Commitments: > > > * Commitments made by Registries without ICANN Enforcement > > >i. Registries and Registrars have reserved >their rights to take down domain names for >phishing, pharming, malware, and other forms of >domain name abuse. With respect to Registries, >some have built these directly in as PICs while >others have just built this into their >Registry-Registrar Agreements (and some do >both). These types of PICs / RVCs do not seem >to present any issue under the ICANN Bylaws (in our view). > > > > >ii. We also believe that it is fairly >common for registries to have policies that >allow them to take down any domains used in >connection with illegal activity, child >exploitation, fraud, the sale of illegal pharmaceuticals, etc. > > > > >iii. Because these do not require ICANN >enforcement, we see no reason how or why this >would present an ICANN Bylaw >issues. Conversely, we see no reason why we >(through a PDP) would have any ability to >restrict the ability of a registry to impose >these types of commitments on their registrants >(through registrars or directly). So while we >appreciate Kathyâs concern about a >Registryâs ability to take down domain names, >we do not believe that we are in a position to >either require registries to take down names >based on content or to prohibit them from doing >so either. Both could be considered forms of >regulation (imposing rules on what a registry has to do or what it may not do). > > > > >iv. Real Example Today. .gay. The >Registry Operator for .gay (Top Level Design) >want to have a safe space for the LGBTQ >community. That community, as most of you know, >has historically been the subject of hate >speech, violence, bullying, etc. Having a safe >space for the gay community according to the >registry is its differentiator and is absolutely >necessary. It has an incredibly strict Rights >Protections Policy >(<https://www.ohhey.gay/gay-cares>https://www.ohhey.gay/gay-cares) >that prevents Registrants from (i) inciting or >promoting violence against others, (ii) >Bullying, engaging in cyber bullying or inciting >others to bully, (iii) Harassing, or encouraging >others to harass or harm others, (iv) Stalking, >(v) Abusive intent to cause fear or threaten >violence, (vi) Hate Speech, (vii) Or activity >intended to organize, coordinate, or otherwise >enable one of the above. It also reserves the >right to take down any sites that do any of the above at its sole discretion. > > > * Commitments made by Registries that may > require ICANN Enforcement in some capacity > > > >Some Registries will want to make voluntary >commitments in response to public comments, >Government early warnings, objections, GAC >Advice, etc. We do not see an issue with having >these commitments reflected in Registry >Agreements even if they fall outside of >ICANNâs core mission IF in the case where the >commitment does not fall within ICANNâs >mission, neither ICANN itself nor any third >party under ICANNâs control is involved in the >decision as to whether the commitment itself has >been violated. Where an independent third party >finds a violation of the commitment, ICANN >should be able to rely on that third party >decision and enforce a pre-arranged contractual >remedy, which could include sanctions and/or >termination of the Registry Agreement. > > > >Examples / Use Cases: > > > * If an Applicant applies for the TLD > â.dictionarywordthatisalsobrandxâ and Brand > X objects to the application. Applicant agrees > with Brand X that it will not use the TLD in an > infringing manner to Brand X. In exchange for > that Agreement, Brand X agrees to drop its > Objection IF the Applicant agrees to put this > commitment into its Registry Agreement in the form of an RVC. > * As a PDP Working Group we have often > said that it is our preference for disputes, > objections, etc. to be worked out between the > parties where this is possible. This is in > line with our desire to see future expansion of > the TLD space and encourage innovation and competition. > * As a result, this type of private resolution should be encouraged. > * The question, however, is whether > ICANN could enforce this commitment. > * After our discussions with the ICANN > Board liaisons and the comments we received by > the community, the real concern was that ICANN > did not believe it could be put in a decision > to make these types of decisions (namely in > this case whether Applicantâs use of the TLD > violates its commitment to Brand X). > * If the Applicant and Brand X agree > that any disputes involving their > âsettlementâ are resolved by an independent > third party (not ICANN) and the costs are borne > by the parties (as opposed to ICANN), this should not present a problem. > * If ICANN implements the decision by > the independent third party (which the > Applicant agreed in its Registry Agreement to > allow ICANN to do), this too should not present a Bylaws issue. > * The key point here is that ICANN > itself is not imposing the restrictions on the > Applicant and therefore should not be violating its own Bylaws. > > > * What if an Applicant applies for > .ideaexchange? The Applicant wants to run the > TLD as a place where registrants can put their > open source ideas on the Internet and allow > others to use their ideas in connection with > whatever they want. Comments are filed by > businesses, governments, intellectual property > owners and others concerned that this will be a > space where users will exchange intellectual > property that they do not own. Lets also > assume that the Independent Objector files an > objection as well. Assume Applicant never > intended that and agrees that it will have a > policy whereby Registrants agree that they will > not use the TLD to distribute any intellectual > property that is not owned by them. And the > Applicant also reserves the right to take down > any names that use the TLD in violation of this > policy. To resolve the comments filed by > governments, businesses, etc., the Applicant > voluntarily agrees to have an RVC that states > this policy and the takedown processes. Each > of the commenters and the Independent Objector > agree that this would settle the matter and if > documented in the Registry Agreement, they would drop their challenges. > * We believe that having these comments > resolved in an amicable manner should be encouraged. > * Because this new policy has to be > documented somewhere, the only real place it > can be documented is as an RVC in the Registry Agreement. > * ICANN should not be the arbiter of > whether there is a violation of this policy. > This would certainly arguably be beyond its mission. > * However, if the arbiter of any > disputes is an independent third party, not > paid by ICANN, etc., then this would seemingly > be ok even if it is agreed by the Applicant to > follow the third party decision and to allow > ICANN to impose the appropriate remedy. > > > >Bottom Line: I believe that so long as ICANN is >not the ultimate decision maker in whether a >policy that may arguably be outside of its >mission, there should be no issues with having >new PICs and/or Registry Voluntary >Commitments. If this indeed is the case, then >we would just need to add a recommendation that >(a) independent third parties must be used to >resolved any potential violations of the PICs / >RVCs, and (b) Applicants would need to agree in >a Registry Agreement to be bound by the decision >of the third party and to allow ICANN to impose sanctions / penalties. > > > >[] > > >Jeffrey J. Neuman > >Founder & CEO > >JJN Solutions, LLC > >p: +1.202.549.5079 > >E: <mailto:jeff@jjnsolutions.com>jeff(a)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

Thoughts on PICs / RVCs (LONG NOTE)
by Jeff Neuman Dec. 11, 2020

Dec. 11, 2020

All, I know there have been a lot of e-mails on this subject in the last week or so. I wanted to give you some perspectives that we discussed at the leadership level to see if we can find some common themes and then we can see if any language in our report needs to change (which I am not convinced there will need to be substantial changes). This is my (Jeff Neuman) summary to move the discussion along. So, here is where I think we are on principles: 1. Existing PICs used as PICs in New Registry Agreements: We believe that the existing PICs – worded substantially the same as they were in 2012 – are ok under ICANN’s Bylaws as they are specifically “grandfathered” in. 1. Domain Name Eligibility Rules: We all seem to be on the same page that eligibility rules for the registration/renewal (but not necessarily usage) can be included in PICs/RVCs under ICANN Bylaws. 1. Voluntary Registry Commitments: * Commitments made by Registries without ICANN Enforcement i. Registries and Registrars have reserved their rights to take down domain names for phishing, pharming, malware, and other forms of domain name abuse. With respect to Registries, some have built these directly in as PICs while others have just built this into their Registry-Registrar Agreements (and some do both). These types of PICs / RVCs do not seem to present any issue under the ICANN Bylaws (in our view). ii. We also believe that it is fairly common for registries to have policies that allow them to take down any domains used in connection with illegal activity, child exploitation, fraud, the sale of illegal pharmaceuticals, etc. iii. Because these do not require ICANN enforcement, we see no reason how or why this would present an ICANN Bylaw issues. Conversely, we see no reason why we (through a PDP) would have any ability to restrict the ability of a registry to impose these types of commitments on their registrants (through registrars or directly). So while we appreciate Kathy’s concern about a Registry’s ability to take down domain names, we do not believe that we are in a position to either require registries to take down names based on content or to prohibit them from doing so either. Both could be considered forms of regulation (imposing rules on what a registry has to do or what it may not do). iv. Real Example Today. .gay. The Registry Operator for .gay (Top Level Design) want to have a safe space for the LGBTQ community. That community, as most of you know, has historically been the subject of hate speech, violence, bullying, etc. Having a safe space for the gay community according to the registry is its differentiator and is absolutely necessary. It has an incredibly strict Rights Protections Policy (https://www.ohhey.gay/gay-cares) that prevents Registrants from (i) inciting or promoting violence against others, (ii) Bullying, engaging in cyber bullying or inciting others to bully, (iii) Harassing, or encouraging others to harass or harm others, (iv) Stalking, (v) Abusive intent to cause fear or threaten violence, (vi) Hate Speech, (vii) Or activity intended to organize, coordinate, or otherwise enable one of the above. It also reserves the right to take down any sites that do any of the above at its sole discretion. * Commitments made by Registries that may require ICANN Enforcement in some capacity Some Registries will want to make voluntary commitments in response to public comments, Government early warnings, objections, GAC Advice, etc. We do not see an issue with having these commitments reflected in Registry Agreements even if they fall outside of ICANN’s core mission IF in the case where the commitment does not fall within ICANN’s mission, neither ICANN itself nor any third party under ICANN’s control is involved in the decision as to whether the commitment itself has been violated. Where an independent third party finds a violation of the commitment, ICANN should be able to rely on that third party decision and enforce a pre-arranged contractual remedy, which could include sanctions and/or termination of the Registry Agreement. Examples / Use Cases: 1. If an Applicant applies for the TLD “.dictionarywordthatisalsobrandx” and Brand X objects to the application. Applicant agrees with Brand X that it will not use the TLD in an infringing manner to Brand X. In exchange for that Agreement, Brand X agrees to drop its Objection IF the Applicant agrees to put this commitment into its Registry Agreement in the form of an RVC. * As a PDP Working Group we have often said that it is our preference for disputes, objections, etc. to be worked out between the parties where this is possible. This is in line with our desire to see future expansion of the TLD space and encourage innovation and competition. * As a result, this type of private resolution should be encouraged. * The question, however, is whether ICANN could enforce this commitment. * After our discussions with the ICANN Board liaisons and the comments we received by the community, the real concern was that ICANN did not believe it could be put in a decision to make these types of decisions (namely in this case whether Applicant’s use of the TLD violates its commitment to Brand X). * If the Applicant and Brand X agree that any disputes involving their “settlement” are resolved by an independent third party (not ICANN) and the costs are borne by the parties (as opposed to ICANN), this should not present a problem. * If ICANN implements the decision by the independent third party (which the Applicant agreed in its Registry Agreement to allow ICANN to do), this too should not present a Bylaws issue. * The key point here is that ICANN itself is not imposing the restrictions on the Applicant and therefore should not be violating its own Bylaws. 1. What if an Applicant applies for .ideaexchange? The Applicant wants to run the TLD as a place where registrants can put their open source ideas on the Internet and allow others to use their ideas in connection with whatever they want. Comments are filed by businesses, governments, intellectual property owners and others concerned that this will be a space where users will exchange intellectual property that they do not own. Lets also assume that the Independent Objector files an objection as well. Assume Applicant never intended that and agrees that it will have a policy whereby Registrants agree that they will not use the TLD to distribute any intellectual property that is not owned by them. And the Applicant also reserves the right to take down any names that use the TLD in violation of this policy. To resolve the comments filed by governments, businesses, etc., the Applicant voluntarily agrees to have an RVC that states this policy and the takedown processes. Each of the commenters and the Independent Objector agree that this would settle the matter and if documented in the Registry Agreement, they would drop their challenges. * We believe that having these comments resolved in an amicable manner should be encouraged. * Because this new policy has to be documented somewhere, the only real place it can be documented is as an RVC in the Registry Agreement. * ICANN should not be the arbiter of whether there is a violation of this policy. This would certainly arguably be beyond its mission. * However, if the arbiter of any disputes is an independent third party, not paid by ICANN, etc., then this would seemingly be ok even if it is agreed by the Applicant to follow the third party decision and to allow ICANN to impose the appropriate remedy. Bottom Line: I believe that so long as ICANN is not the ultimate decision maker in whether a policy that may arguably be outside of its mission, there should be no issues with having new PICs and/or Registry Voluntary Commitments. If this indeed is the case, then we would just need to add a recommendation that (a) independent third parties must be used to resolved any potential violations of the PICs / RVCs, and (b) Applicants would need to agree in a Registry Agreement to be bound by the decision of the third party and to allow ICANN to impose sanctions / penalties. [cid:image002.png@01D6CE3F.28E24FB0] 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

3 6

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

Dec. 11, 2020

Dear WG Members, Please find below the updated 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: 1. Update from Small Team – Auctions – References: See the Public Comment Review Tool at: https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw… See the draft Final Report starting on page 163, with Contention Resolution Transparency Requirements starting on page 166 at: https://gnso.icann.org/en/drafts/draft-final-report-new-gtld-subsequent-20a… 1. Topic 8: Conflicts of Interest<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> 2. Topic 10: Applicant Freedom of Expression<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> 3. 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

Voluntary PICs/RVCs
by Kathy Kleiman Dec. 11, 2020

Dec. 11, 2020

Hi All, On a larger note, some of us have been working on principles for Voluntary PICs/RVCs in keeping with the 2016 Bylaws, responsive to concerns raised by the ICANN Board, and following our informative conversation with Becky and Avri, our Board liaisons. We re-propose the three “Guardrails for Voluntary PICs” and add a fourth one for our valuable, formative Human Rights Core Value. FOUR GUARDRAILS FOR VOLUNTARY PUBLIC INTEREST COMMITMENTS/RVCS ENTERED INTO BY ICANN AND NEW GTLD REGISTRIES 1. VOLUNTARY PICS/RVCS CAN ONLY ADDRESS ISSUES WITH DOMAIN NAMES THEMSELVES, INCLUDING ELIGIBILITY CRITERIA CONSISTENT WITH POINT 2 BELOW—NOT THE CONTENTS OF WEBSITES OR APPS THAT USE DOMAIN NAMES; 2. COMMITMENTS NEED TO BE CONSISTENT WITH THE HUMAN RIGHTS CORE VALUE ESTABLISHED IN THE ICANN BYLAWS; 3. PICS/RVCS SHOULD NOT GIVE REGISTRIES UNBOUNDED DISCRETION TO SUSPEND DOMAIN NAMES; AND 4. PICS/RVCS SHOULD NOT BE USED TO CREATE NEW POLICIES THAT DIDN’T COME THROUGH ICANN PROCESSES. Please note that the Guardrails below are designed to include all GAC-negotiated settlements (original purpose of voluntary PICs), and we would be happy to insert a statement if that needs to be set out even more clearly. Best, Kathy

3 2

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

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