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

10th and (hopefully) Final Topical E-mail - Community Scoring
by Jeff Neuman Dec. 15, 2020

Dec. 15, 2020

This is the Tenth Topical E-mail on outstanding questions being "put to the list." This covers the question of overall scoring to pass CPE (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. Let's not let the perfect be the enemy of the good. I. Current Applicant Guidebook Language: "An application must score at least 14 points to prevail in a community priority evaluation." II. Issue: Some commenters to the Draft Final Report, including the ALAC, Infonetworks, Swiss Government, fTLD Registry Services supported lowering the threshold from 14 out of 16 points (approx. 88%) to 12 out of 16 points (75%). However, it should be noted that during our discussions, not everyone supported the lowering of the threshold. III. Discussion Points * We have recommended a number of changes already to CPE, including more transparency, more flexibility to recognize non-economic based communities, increased scrutinization of letters of opposition, more involvement in the selection process of evaluators, etc. These changes should go a long way to mitigate the issues faced in 2012. * That said, the current scoring framework was rigid and required a perfect or nearly perfect scoring on every evaluation criteria. As we observed, very few applications were able to achieve community status. * On the other hand, merely lowering the scoring down to 12 (from 14) would only have resulted in one additional application during the 2012 round achieving Community Priority. * Finally, even if we lower the threshold to an actual number, leaves little flexibility to implement a new scoring mechanism (should the ICANN community desire such a new mechanism) which encompasses all of the policy changes we have recommended. IV. Proposal: Given the Working Group's affirmation of the importance of the prioritization of community-based applications, and subject to all of the Recommendations and Implementation Guidance set forth in this Report, the Working Group urges the Implementation Review Team to consider changing the passing score for achieving community priority status from a hard score of 14 out of 16 points to achieving a score of at least 75-80% of the total available evaluation points. This not only emphasizes the importance we place on community-based applications, but also provides some flexibility in any future scoring methodology. Please have your comments (If any) by no later than 23:59:59 UTC on Wednesday, December 16, 2020. Absent a strong showing of support on the list for this change, we will default back to the original text in the Draft Final Report. [cid:image002.png@01D6D1FC.0E863AD0] 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

8 7

Work Plan Changes and Preliminary Information on Consensus Calls
by Jeff Neuman Dec. 15, 2020

Dec. 15, 2020

All, The Leadership Team met a few hours ago to discuss a number of issues including how to get to the finish line……We are nearly there! As discussed on the last call (about 24 hours ago), we are making the following changes to the Work Plan: * 11 December 2020 * Latest Redline of Final Report containing changes from all topics discussed to date as well as changes (if any) as a result of the 9 Topical E-mails * Meeting of the small team on Auctions to see if there can be any recommendations to the Full Working Group * 14 December 2020 * Discussing (a) Auctions Topic (results if any from small team; (b) Conflicts of Interest, (c) Applicant Freedom of Expression, and (d) Dispute Resolution Procedures after Delegation. * 15 December 2020 * Comments due to 11 December 2020 Redline * Release of Any redlines to as a result of the topics discussed on 14 December 2020 * 17 December 2020 * Comments due to December 15 Redline * Working Group Call (already on your calendars) to close out any last issues * Content Freeze / Lockdown – Other than if there are any changes to close out last issues, all content is locked down for the Consensus Call * 22 December 2020 * Final Report is released to the Working Group * Commencement of Consensus Call (See some notes below) * 5 January 2020 * Consensus Call Ends * 6 January 2020 * Designation of Levels of Support by Working Group Leadership Team * 7 January 2020 * Call of the Working Group to discuss designations, answer questions, and hopefully celebrate a job well done * 8 January 2020 * Challenges to Designation of Levels of Support by Working Group Leadership Team are due (if any) * Minority Reports (if any) are due * 11 January 2020 * Final Report delivered to the Council * Document Deadline for discussion during January’s GNSO Council Meeting Some Notes 1. A longer note will follow in the next couple of days on how we will structure the Consensus Call. We strongly recommend that if you were not on the last working group call on 10 December 2020 at 03:00 UTC, please do go back and review at least the first 15-20 minutes of the call. (Link to Call<https://community.icann.org/display/NGSPP/2020-12-07+New+gTLD+Subsequent+Pr….>) 1. Although more details will be provided later: * Leadership will be grouping the Topics into batches for purposes of the Consensus Calls. We will not be voting on each recommendation / implementation guidance separately (as there are several hundred of them). * We will do our best to only include in the batches the lesser controversial topics; stated differently, Leadership has a sense of which sections should be supported by either full consensus or (rough) consensus. Of course we could always be wrong, but we will do our best. i. If there is a batch that contains a part that you do not support, then in the Consensus Call, we will ask you specifically which element or elements do you not support. In other words, if we grouped topics 1,2 and 3 together and you indicate that you do not support the batch, you will be asked to specify which of the Topics you do not support, and which element(s) within that topic you do not support. We will assume that the topics / elements you do not list are ones that you would support. So being specific will be important. * Topics where we can already foresee that there will be a difference of opinion (eg., Closed Generics, Mechanisms of Last Resort), we will make sure we have those topics in the Consensus Call on their own (i.e., not in batches with other topics). * All expressions of support / non support during the Consensus Call MUST be submitted through the formal mailing list. We will not be counting any responses to the Consensus Call that are not submitted on the list. It is critical that all of the information is on the record and documented. * The Consensus Call is NOT A VOTE – Leadership will not be determining levels of support based on the quantity of responses, but will take into consideration other factors such as the groups with whom an individual associates, etc. * We will be following Section 3.6 of the Working Group Guidelines (https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-1-g…) 1. Minority Reports are due just 2 days after the designation of Levels of Consensus. We know that is not a lot of time. However, given that we have had a draft final report, comments to the draft final report, extensive discussions of those comments of the draft final report, and you have seen several redlines already, we believe that if you disagree with the way the group is heading, you should pretty much know that now. There is no reason to wait until the designations of levels of support to start drafting. In fact, I am told that the ALAC has already been working on a minority report to certain topics for some time now. Bottom Line – you can start working on any minority report now. The worst thing that will happen is that you draft your report and there is a consensus call surprise where you find out you may not be in the minority and you decide not to submit the statement 😊 1. We are nearly there!!!!!!!!! Thanks. Your humble Leadership Team, Cheryl and Jeff – Co-Chairs With very special thanks to Martin, Annabeth, Robin and Flip who have been participating in Leadership calls for many months and providing valuable insight & of course to Steve, Emily and Julie, without whom, none of this would be possible

5 11

PLEASE SHARE: Nomination Opens for ICANN Community Excellence Award
by Terri Agnew Dec. 14, 2020

Dec. 14, 2020

ICANN.ORG announcement: https://www.icann.org/news/announcement-2020-12-14-en twitter post: https://twitter.com/ICANN/status/1338552129414451201?s=20 Nominations Now Open for the ICANN Community Excellence Award LOS ANGELES – 14 December 2020 – Today, the Internet Corporation for Assigned Names and Numbers (ICANN) opened the nomination period for the ICANN Community Excellence Award. The closing date for submissions is 29 March 2021 23:59 UTC and the winner(s) will be announced at ICANN71. Launched in 2014, the ICANN Community Excellence Award recognizes ICANN community members who have deeply invested in consensus-based solutions and contributed substantively to the ICANN multistakeholder model. The ideal recipient(s) will have: · Participated in the ICANN community for at least five years. · Served in multiple ICANN working groups or committees. · Collaborated with more than one Supporting Organization (SO) and/or Advisory Committee (AC) in a significant capacity. Candidates will be evaluated by a panel of ICANN community members appointed by the SO/AC chairs using a merit-based point system evaluated against three criteria: 1. Demonstrated ability to work across community lines with both familiar and unfamiliar ICANN stakeholders with the aim of building consensus. 2. Facilitator of dialogue and open discussion in a fair and collegial manner, through the spirit of collaboration as shown through empathy, and demonstrating a sincere desire to engage with people from other backgrounds, cultures, and interests. 3. Demonstrated additional support for the ICANN multistakeholder model and its overall effectiveness through volunteer service via working groups or committees. Please submit your nominations via this Nomination Form<https://forms.gle/xzpuHXVaQMXad9ND8> including detailed information outlining why the nominee meets the award criteria. Self-nominations will not be considered. Any additional information in support of nominations and/or questions about the award process may be submitted via email to excellenceaward2021(a)icann.org<mailto:excellenceaward2021@icann.org>. The award recipient(s) will be announced in June 2021 at ICANN71. For more information, please refer to the ICANN Community Wiki.<https://community.icann.org/x/YyOAAw> About ICANN ICANN's mission is to help ensure a stable, secure, and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation with a community of participants from all over the world.

1 0

Fwd: Work Plan Changes and Preliminary Information on Consensus Calls
by Cheryl Langdon-Orr Dec. 14, 2020

Dec. 14, 2020

- *Jorge, please see interspaced below responses from Jeff and me...* On Sat, 12 Dec 2020 at 01:11, Jorge.Cancio--- via Gnso-newgtld-wg < gnso-newgtld-wg(a)icann.org> wrote: > Dear Jeff and all > > > > Thanks very much for this email! > *Thank you also for your thoughtful reply * > > > Speaking personally, I’m afraid that the proposed timeline with consensus > calls over the holiday break (at least in the Northern hemisphere) is not > very helpful. > *We recognise this is an impost and a challenge, and regret that not everyone will find it at all convenient, but we are needing to complete our finalisation of the work in a manner that allows us to meet the January GNSO Council Meeting document deadline. Considering that we have been flagging the "End of Calendar Year" endpoint for the delivery of our Final Report to the Council for a lengthy period of time we had hoped that these dates and the minor *extension in timing* we propose would not be seen as too problematic, we trust that everyone will appreciate we added time into the End Dec point to allow for the activities to be completed recognising that a few days at least for some, would be being carved out for their social and familial purposes at this time of year. We note this timing is regrettable but in our view unavoidable.* > > > At least for those of us needing to do extensive consultations (be it > inside a Government or within a larger community) such dates are completely > unworkable. > *We note that the consensus call had been planned for an earlier date from Dec 17 on, leaving 7 days the finalisation of other steps before the 23rd and then the close of the ICANN Offices, the planning we have now produced allows a longer time (14 days) with yes all be it some public holidays in some places... As WG Members and their associated communities had been working towards the earlier date and less time between these final steps, and noting we have ensured the regular updating and sending of redlined text as we go to reduce the burden of looking for changes in a Final Report we hope that the extent of such consultations would be being already managed, and we note that some parts of the ICANN COmmunity have certainly done so... The Government Advisory Committee of course (along with the other ACs) also have the post Report to GNSO opportunity to create any Advice on the Report that it sees fit and that works within the constraints of their consultative mechanisms. We do hope however that they will also through any Members of the WG also contribute to the Consensus Call.* > > > Not sure how others feel about this… > > > > Personally, I would suggest starting the consensus calls once we are back > from the break, e.g. on January 4th. > *That would at the least push Report lodgement to the GNSO to at least February and that would require us to petition the GNSO Council for permission to do so. That is not a timeline we have either endorsed or worked towards since our last petition for an extension of the timeline to the end of the Calendar year earlier in 2020.* > > > In addition, I feel that for the same reasons (need for consultations > etc.) the time allotted between consensus designations by the co-chairs and > the deadline for submitting minority reports should be significantly > extended (e.g. at least to one full week). > *We trust that as we have encouraged for some time now consideration, if not the preparation of Minority Reports has been at least kicked off by WG Members, noting that with the freeze of text on the 17th December everyone will have all that goes into the final report with the exception of the specific detailing of the degree(s) of consensus associated with the recommendations designated by the Co-Chairs after the Consensus Call formally completes. So we would encourage you and others to make full use of that time from the 17th onward if such Minority Report drafting has not already begun. * > > > Hope this is doable… > > > > Kind regards > > > > Jorge > > > > *Von:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> *Im Auftrag > von *Jeff Neuman > *Gesendet:* Freitag, 11. Dezember 2020 06:08 > *An:* gnso-newgtld-wg(a)icann.org > *Betreff:* [Gnso-newgtld-wg] Work Plan Changes and Preliminary > Information on Consensus Calls > > > > All, > > > > The Leadership Team met a few hours ago to discuss a number of issues > including how to get to the finish line……We are nearly there! > > > > As discussed on the last call (about 24 hours ago), we are making the > following changes to the Work Plan: > > > > - *11 December 2020* > - Latest Redline of Final Report containing changes from all topics > discussed to date as well as changes (if any) as a result of the 9 Topical > E-mails > - Meeting of the small team on Auctions to see if there can be any > recommendations to the Full Working Group > - *14 December 2020* > - Discussing (a) Auctions Topic (results if any from small team; > (b) Conflicts of Interest, (c) Applicant Freedom of Expression, and (d) > Dispute Resolution Procedures after Delegation. > - *15 December 2020* > - Comments due to 11 December 2020 Redline > - Release of Any redlines to as a result of the topics discussed on > 14 December 2020 > - *17 December 2020* > - Comments due to December 15 Redline > - Working Group Call (already on your calendars) to close out any > last issues > - Content Freeze / Lockdown – Other than if there are any changes > to close out last issues, all content is locked down for the Consensus Call > - *22 December 2020* > - Final Report is released to the Working Group > - Commencement of Consensus Call (See some notes below) > - *5 January 2020* > - Consensus Call Ends > - *6 January 2020* > - Designation of Levels of Support by Working Group Leadership Team > - *7 January 2020* > - Call of the Working Group to discuss designations, answer > questions, and hopefully celebrate a job well done > - *8 January 2020* > - Challenges to Designation of Levels of Support by Working Group > Leadership Team are due (if any) > - Minority Reports (if any) are due > - *11 January 2020* > - Final Report delivered to the Council > - Document Deadline for discussion during January’s GNSO Council > Meeting > > > > *Some Notes* > > 1. A longer note will follow in the next couple of days on how we will > structure the Consensus Call. We strongly recommend that if you were not > on the last working group call on 10 December 2020 at 03:00 UTC, please do > go back and review at least the first 15-20 minutes of the call. (Link > to Call > <https://community.icann.org/display/NGSPP/2020-12-07+New+gTLD+Subsequent+Pr….> > ) > > > > 1. Although more details will be provided later: > 1. Leadership will be grouping the Topics into batches for purposes > of the Consensus Calls. We will not be voting on each recommendation / > implementation guidance separately (as there are several hundred of them). > 2. We will do our best to only include in the batches the lesser > controversial topics; stated differently, Leadership has a sense of which > sections should be supported by either full consensus or (rough) > consensus. Of course we could always be wrong, but we will do our best. > > i. If > there is a batch that contains a part that you do not support, then in the > Consensus Call, we will ask you specifically which element or elements do > you not support. In other words, if we grouped topics 1,2 and 3 together > and you indicate that you do not support the batch, you will be asked to > specify which of the Topics you do not support, and which element(s) within > that topic you do not support. We will assume that the topics / elements > you do not list are ones that you would support. So being specific will be > important. > > 1. Topics where we can already foresee that there will be a difference > of opinion (eg., Closed Generics, Mechanisms of Last Resort), we will make > sure we have those topics in the Consensus Call on their own (i.e., not in > batches with other topics). > 2. All expressions of support / non support during the Consensus > Call MUST be submitted through the formal mailing list. We will not be > counting any responses to the Consensus Call that are not submitted on the > list. It is critical that all of the information is on the record and > documented. > 3. The Consensus Call is NOT A VOTE – Leadership will not be > determining levels of support based on the quantity of responses, but will > take into consideration other factors such as the groups with whom an > individual associates, etc. > 4. We will be following Section 3.6 of the Working Group Guidelines > ( > https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-1-g… > ). > > > > 1. Minority Reports are due just 2 days after the designation of > Levels of Consensus. We know that is not a lot of time. However, given > that we have had a draft final report, comments to the draft final report, > extensive discussions of those comments of the draft final report, and you > have seen several redlines already, we believe that if you disagree with > the way the group is heading, you should pretty much know that now. There > is no reason to wait until the designations of levels of support to start > drafting. In fact, I am told that the ALAC has already been working on a > minority report to certain topics for some time now. *Bottom Line – > you can start working on any minority report now. The worst thing that > will happen is that you draft your report and there is a consensus call > surprise where you find out you may not be in the minority and you decide > not to submit the statement **😊* > > > > 1. We are nearly there!!!!!!!!! > > > > Thanks. > > > > Your humble Leadership Team, > > > > Cheryl and Jeff – Co-Chairs > > > > *With very special thanks to Martin, Annabeth, Robin and Flip who have > been participating in Leadership calls for many months and providing > valuable insight & of course to Steve, Emily and Julie, without whom, none > of this would be possible* > > > > > > > > > _______________________________________________ > 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.

5 7

Post Call / New gTLD Subsequent Procedures Working Group call / Monday, 14 December 2020 at 15:00 UTC
by Michelle DeSmyter Dec. 14, 2020

Dec. 14, 2020

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

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