December 2020 - Gnso-newgtld-wg

New gTLD Subsequent Procedures PDP WG Consensus Call - Closes Friday, 08 January 2021 at 23:59 UTC
by Emily Barabas Jan. 8, 2021

Jan. 8, 2021

Dear WG members, On behalf of the WG Co-Chairs, and as discussed during the WG meeting on Thursday, 17 December, this email is to notify you of the opening of the online Consensus Call on the WG Outputs (i.e., Affirmation, Affirmation with Modification, Recommendation, Implementation Guidance, and No Agreement) of the New gTLD Subsequent Procedures GNSO Policy Development Process (PDP). Pursuant to the content freeze on 18 December, please see the attached PDF of the Outputs and contextual language, which has received a handful of non-substantive updates (for a redline version that shows the minor edits made since 18 December, please see the wiki<https://community.icann.org/display/NGSPP/h.+Final+Report+Drafting>). WG members who wish to familiarize themselves with the steps involved and the various levels of consensus applicable to GNSO PDP recommendations can refer to the recording of the 17 December meeting<https://community.icann.org/display/NGSPP/2020-12-17+New+gTLD+Subsequent+Pr…> where the Consensus Call process was described. This Consensus Call opens today, Tuesday, 22 December 2020 and closes on Friday, 08 January 2021 at 23:59 UTC. Per the GNSO Working Group Guidelines [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/…>, WG members are requested to indicate via reply to this list whether they support, or do not support, the Outputs. If a WG member does not respond this will be taken as support. The Outputs are largely being presented in a single package and should be considered as an integrated set of Outputs, which are the result of many years of WG discussions and input received. This includes not only the work of the WG, but also the comments we received to Constituency Comments 1 & 2, the work of Work Tracks 1-5, comments to the Initial Report and the two Supplemental Initial Reports, and the comments to the Draft Final Report. Therefore, there will likely be Outputs that you believe are imperfect, so the Co-Chairs encourage you to consider the Outputs in the aggregate. Even if given that context, you still believe there are Outputs that you do NOT support, please specifically identify the Specific Recommendations and/or Implementation Guidance within the Outputs that you do cannot support and why. For the purposes of this Consensus Call, the Outputs are being organized accordingly: * Topic 9: Registry Voluntary Commitments / Public Interest Commitments; * Topic 23: Closed Generics; * Topic 34: Community Applications/CPE; * Topic 35: Auctions: Mechanisms of Last Resort / Private Resolution of Contention Sets; and * All other Outputs in the report. As noted on the 17 December 2020 WG call, the Consensus Call is being issues to Individual Working Group members (and not to the Constituencies, Stakeholder Groups, Supporting Organizations, and/or the Advisory Committees in which such individuals participate). Therefore, WG members will be assumed to be responding to the consensus call on their own behalf unless they explicitly state in their response that they are responding on behalf of their group/organization. Following the close of the Consensus Call, the WG Co-Chairs will meet on Monday, 11 January 2021 to review the responses from the WG members and determine the Consensus Designations for the Outputs. The WG Co-Chairs will post the results of their determination to the WG email distribution list on January 11, 2021. On 12 January 2021 at 20:00 UTC, the Working Group will have its next and hopefully final call to discuss any questions or comments to the Consensus Designations. Calendar invites have been sent out to Working Group members. Although the meeting is scheduled for 120 minutes, WG leadership will stay on the call until all questions have been addressed. Working Group members will then have until 13 January 2021 at 23:59 UTC to object to the Consensus Call designations. The final Consensus Call designations shall then be included in the Final Report. Finally, to the extent they are needed, WG members may begin working on minority statements now and through the Consensus Call period, with the ultimate due date of 18 January 2021. Kind regards, Steve, Julie and Emily on behalf of the SubPro Leadership Team

17 18

Re: [Gnso-newgtld-wg] Response to Alan on "Recommendations" (long note)
by Alan Greenberg Dec. 23, 2020

Dec. 23, 2020

Jeff, your quoting of the guidelines is correct, but in my mind, that was in recognition of the Council not ratifying recommendations such as those that are "Divergent". That is no longer the case, and my belief is that our methodolo9gy needs to accommodate that, or at least VERY CLEARLY state it to the Council. I believe that the "accommodation" I mention *IS* within our purview because it exactly matches our methodology throughout the PDP. If we understood during the discussion that a proposed recommendation had divergent views among the WG members, or over that there were strong, we would certainly not have drafted it as a recommendation. Even those with some strong support (as some of the positions regarding auctions or closed generics did not make it to the recommendation level for that reason. The bottom line is that it makes little sense to me to propose a "CONSENSUS POLICY" (which is what a PDP does) based on concepts that do not have clear CONSENSUS within the PDP WG. Your position is noted and presuming it doesn't change, I will raise the issue with the ALAC and the ALAC may choose to raise the issue in its minority report and any further communications with the GNSO Council and the Board. I presume that other groups may act accordingly. Alan At 2020-12-23 12:40 PM, Jeff Neuman wrote: >All, > > > >In an effort to be as transparent as possible, I >am providing the rationale as to our decision to >keep the wording in the Final Report As-is >regardless of the levels of support / >non-support as a result of the Consensus >Call. But please note we will be equally as >transparent as to what levels of support that >they have (or dont have) as required by the >Working Group Guidelines AND our charter. > > > >The Working Group has been working for more than >5 years on this Final Report and developing >Recommendations and Implementation >Guidance. We do appreciate your feedback, but >at this point the Leadership has decided that >the Final Report will not change. We will be >including the language Recommendation, >Affirmation and Implementation Guidance as >they are in the Final Report AND indicate their >levels of support just as has been done with >every recent PDP and like they are required in the Operating Guidelines. > > > >Alans comments (and those supporting Alans >comments) are not in line with the Working Group >Guidelines in our view nor are they in line with past practice. > > > * Language of the Guidelines: Section 3.6 > (which is included in our charter) states: 3.6 > Standard Methodology for Making Decisions The > Chair will be responsible for designating each > position as having one of the following designations: > * Full consensus - when no one in the > group speaks against the recommendation in its > last readings. This is also sometimes referred to as Unanimous Consensus. > * Consensus - a position where only a > small minority disagrees, but most agree. > * Strong support but significant > opposition - a position where, while most of > the group supports a recommendation, there are > a significant number of those who do not support it. > * Divergence (also referred to as No > Consensus) - a position where there isn't > strong support for any particular position, but > many different points of view. Sometimes this > is due to irreconcilable differences of opinion > and sometimes it is due to the fact that no one > has a particularly strong or convincing > viewpoint, but the members of the group agree > that it is worth listing the issue in the report nonetheless. > * Minority View - refers to a proposal > where a small number of people support the > recommendation. This can happen in response to > a Consensus, Strong support but significant > opposition, and No Consensus; or, it can happen > in cases where there is neither support nor > opposition to a suggestion made by a small number of individuals. > > > >Further, the ><https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-2-p…>PDP >Manual also states: Each recommendation in the >Final Report should be accompanied by the >appropriate consensus level designation (see >section 3.6 Standard Methodology for Making >Decisions in the GNSO Working Group Guidelines) > > > >Leaderships view is that deleting all >recommendations (as recommendations) that do not >have Consensus or Full Consensus would >render Section 3.6 meaningless. Why would there >be a provision in the Guidelines that requires >us to differentiate between Consensus, Strong >Support, Divergence, etc., if we deleted all of >those positions that did not have Consensus. > > > >We are providing a Report to the Council on our >activities. What the Council decides to do with >the recommendations/implementation guidance that >does not have Consensus is the Councils >decision and not ours. To fail to include these >would simply be censoring our own work, which is >not something we wish to do. A Recommendation >is still a Recommendation even with Strong >Support. The issue is not what we call it, but >rather what the Council and the Board does with >it. Some people may not like what Council has >done with Recommendations that have not had >Consensus support, but that is an issue with the >Council. And we will follow the Guidelines. > > > * Past Examples > * ePDP Phase 2 Final Report: All of the > Recommendations were included as > Recommendations even if they did not get a > Consensus. See for example Recommendation #8 > which got Strong Support, but Significant > Opposition and even Recommendation #6 which > was labeled as > Divergence. > (<https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phas…>https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phas…) > > * ePDP Phase 2 Final Report: Again, all > of the Recommendations were included in the > Final Report. This includes Recommendations 2 and 16 which had Divergence. > > > * Lets take an example, lets take the first > Affirmation: 1.1: The Working Group recommends > that the existing policy contained in the 2012 > Applicant Guidebook, that a systematized > manner of applying for gTLDs be developed in the long term, be maintained. > > > * Now lets suppose that there are 50 > members of the Working Group that Support this > Affirmation coming from the 50 most active > members of the Working Group (those that have > been with us for all 5 years, those that have > attended a majority of the calls, responded on > mailing lists, participated in compromise discussions). > * Now suppose for arguments sake that there > are 20 members of the Working Group that for > one reason or another say they do NOT support > this Affirmation. And lets suppose that most > of these members joined after the Work Tracks > competed their work and the Initial Report was > done. Lets also assume that most of them did > not attend any calls, nor did they actively > participate on the mailing list. But they are > nonetheless Members of the Working Group and > have the right under the Guidelines to support > or not support. Lets also assume that some are > members are registries, some are from the BC, > some from the ALAC and some from the registrars. > * In this case, Leadership may have some > difficulty in finding Consensus and may have > to classify it as Strong Support / significant opposition. > > > >Applying Alans new rule would mean that we >could not call this an affirmation in the >Final Report. It would essentially mean that >the Affirmation that holds this program together >could not be included. To Leadership, that does not make sense. > > > > > >Finally, the ICANN Board will have to make a >decision on each and every one of these items >regardless of whether there was consensus or >not. For example, take the Recommendation that >states all applications should be done in >rounds. Assume there is Strong Support (but not >Consensus). The Board will still have to decide >whether applications should be done in >rounds. Shouldnt the Board know that there was >Strong Support for this Recommendation when it >considers this question? Shouldnt it know that >there was Strong Support within the Working >Group for the Recommendation (even if not Consensus)? > > > >At the end of the day, we want to represent the >report as a reflection of all of the work we >have done and in compliance with the Working >Group Guidelines and our Charter. The GNSO >Council and the ICANN Board will understand that >if a Recommendation is labeled as Divergence >that it is not truly a recommendation endorsed >by the Working Group. We have to assume that >everyone up the chain will take their >responsibilities seriously, read the report, and >act on what is presented. We cannot and >should not change our responsibilities under the >Working Group Guidelines because we are >concerned about what the Council may or may not do with our work. > > > >Please have a happy holidays and hopefully we >will see each other soon to celebrate the >tremendous work we have almost completed. > > > >Sincerely, > > > >Jeff (sent on behalf of the Leadership team). > > > >[] > > >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

Consensus on Recommendations
by Alan Greenberg Dec. 23, 2020

Dec. 23, 2020

I raised an issue during the last call and I wanted to repeat it here for those who were not on the call and have not reviewed the recording. Jeff described how the leadership team will assess the level of consensus on recommendations (packages of recommendations if I recall correctly, but that is not relevant here) and state them clearly in the final report. For recommendation that achieve a Full Consensus or Consensus (as defined in the PDP Charter), that is fine. But I have a great problem if a "Recommendation" does not achieve either level of Consensus and is still labelled as a "Recommendation". Historically most Recommendations coming out of PDPs have WG consensus. Until recently, for the few cases where a "Recommendation" did not have WG consensus, the GNSO Council chose to not endorse it and did not pass it on to the Board. That changed recently with the EPDP where the GNSO Council ratified recommendations that did not achieve consensus, including even one with Divergent opinions (defined in the WG Charter as "No Consensus"). There is no way of knowing how the Board will treat such recommendations, nor how the CURRENT GNSO will react to receiving recommendation s from us that do not have consensus. But I feel that we should be taking a prudent stance going forward. We have been very careful only to draft recommendations that seem to have WG consensus. However, until we do the final assessment, we do not know if there is really agreement or not. If there is not agreement, that we must delete them as Recommendations. We still of course need to fully document the discussion AND the difference of opinion. But to keep them as a formal recommendation that might be accepted by the GNSO Council and the Board violates our basic operating principles. I think that many of us would react poorly to finding a specific recommendation on closed generics where clearly we do NOT have consensus. Why would it be more acceptable to keep other recommendations where the final assessment is that despite what we thought earlier, there is similarly no consensus on the recommendation? Alan

7 11

Response to Alan on "Recommendations" (long note)
by Jeff Neuman Dec. 23, 2020

Dec. 23, 2020

All, In an effort to be as transparent as possible, I am providing the rationale as to our decision to keep the wording in the Final Report "As-is" regardless of the levels of support / non-support as a result of the Consensus Call. But please note we will be equally as transparent as to what levels of support that they have (or don't have) as required by the Working Group Guidelines AND our charter. The Working Group has been working for more than 5 years on this Final Report and developing "Recommendations" and "Implementation Guidance." We do appreciate your feedback, but at this point the Leadership has decided that the Final Report will not change. We will be including the language "Recommendation", "Affirmation" and "Implementation Guidance" as they are in the Final Report AND indicate their levels of support just as has been done with every recent PDP and like they are required in the Operating Guidelines. Alan's comments (and those supporting Alan's comments) are not in line with the Working Group Guidelines in our view nor are they in line with past practice. 1. Language of the Guidelines: Section 3.6 (which is included in our charter) states: "3.6 Standard Methodology for Making Decisions The Chair will be responsible for designating each position as having one of the following designations: * Full consensus - when no one in the group speaks against the recommendation in its last readings. This is also sometimes referred to as Unanimous Consensus. * Consensus - a position where only a small minority disagrees, but most agree. * Strong support but significant opposition - a position where, while most of the group supports a recommendation, there are a significant number of those who do not support it. * Divergence (also referred to as No Consensus) - a position where there isn't strong support for any particular position, but many different points of view. Sometimes this is due to irreconcilable differences of opinion and sometimes it is due to the fact that no one has a particularly strong or convincing viewpoint, but the members of the group agree that it is worth listing the issue in the report nonetheless. * Minority View - refers to a proposal where a small number of people support the recommendation. This can happen in response to a Consensus, Strong support but significant opposition, and No Consensus; or, it can happen in cases where there is neither support nor opposition to a suggestion made by a small number of individuals. Further, the PDP Manual<https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-2-p…> also states: "Each recommendation in the Final Report should be accompanied by the appropriate consensus level designation (see section 3.6 - Standard Methodology for Making Decisions in the GNSO Working Group Guidelines)" Leadership's view is that deleting all recommendations (as recommendations) that do not have "Consensus" or "Full Consensus" would render Section 3.6 meaningless. Why would there be a provision in the Guidelines that requires us to differentiate between Consensus, Strong Support, Divergence, etc., if we deleted all of those positions that did not have Consensus. We are providing a Report to the Council on our activities. What the Council decides to do with the recommendations/implementation guidance that does not have Consensus is the Council's decision and not ours. To fail to include these would simply be censoring our own work, which is not something we wish to do. A "Recommendation" is still a "Recommendation" even with "Strong Support". The issue is not what we call it, but rather what the Council and the Board does with it. Some people may not like what Council has done with "Recommendations" that have not had Consensus support, but that is an issue with the Council. And we will follow the Guidelines. 1. Past Examples * ePDP Phase 2 Final Report: All of the Recommendations were included as "Recommendations" even if they did not get a Consensus. See for example "Recommendation #8" which got Strong Support, but Significant Opposition and even "Recommendation #6" which was labeled as "Divergence". (https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phas…) * ePDP Phase 2 Final Report: Again, all of the Recommendations were included in the Final Report. This includes Recommendations 2 and 16 which had "Divergence." 1. Lets take an example, let's take the first Affirmation: 1.1: The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a "systematized manner of applying for gTLDs be developed in the long term," be maintained. * Now let's suppose that there are 50 members of the Working Group that Support this Affirmation coming from the 50 most active members of the Working Group (those that have been with us for all 5 years, those that have attended a majority of the calls, responded on mailing lists, participated in compromise discussions). * Now suppose for argument's sake that there are 20 members of the Working Group that for one reason or another say they do NOT support this Affirmation. And lets suppose that most of these members joined after the Work Tracks competed their work and the Initial Report was done. Lets also assume that most of them did not attend any calls, nor did they actively participate on the mailing list. But they are nonetheless "Members" of the Working Group and have the right under the Guidelines to support or not support. Lets also assume that some are members are registries, some are from the BC, some from the ALAC and some from the registrars. * In this case, Leadership may have some difficulty in finding "Consensus" and may have to classify it as "Strong Support / significant opposition". Applying Alan's new rule would mean that we could not call this an "affirmation" in the Final Report. It would essentially mean that the Affirmation that holds this program together could not be included. To Leadership, that does not make sense. Finally, the ICANN Board will have to make a decision on each and every one of these items regardless of whether there was consensus or not. For example, take the Recommendation that states all applications should be done in rounds. Assume there is Strong Support (but not Consensus). The Board will still have to decide whether applications should be done in rounds. Shouldn't the Board know that there was Strong Support for this Recommendation when it considers this question? Shouldn't it know that there was Strong Support within the Working Group for the "Recommendation" (even if not Consensus)? At the end of the day, we want to represent the report as a reflection of all of the work we have done and in compliance with the Working Group Guidelines and our Charter. The GNSO Council and the ICANN Board will understand that if a "Recommendation" is labeled as "Divergence" that it is not truly a recommendation endorsed by the Working Group. We have to assume that everyone up the chain will take their responsibilities seriously, read the report, and act on what is presented. We cannot and should not change our responsibilities under the Working Group Guidelines because we are concerned about what the Council may or may not do with our work. Please have a happy holidays and hopefully we will see each other soon to celebrate the tremendous work we have almost completed. Sincerely, Jeff (sent on behalf of the Leadership team). [cid:image003.png@01D6D928.D2A3D5C0] 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

Re: [Gnso-newgtld-wg] Content Freeze - Final Report
by Donna＠registry.godaddy Dec. 22, 2020

Dec. 22, 2020

To Emily, Steve, Julie and the GNSO Secretariat Many thanks for your dedication and providing exceptional support not only to Jeff, Cheryl and the leadership team, but also to the rest of us that try to follow along and contribute each week. Your largely invisible work is truly appreciated. Kind regards Donna Sent from my iPhone > On Dec 18, 2020, at 8:21 AM, Emily Barabas <emily.barabas(a)icann.org> wrote: > > Notice: This email is from an external sender. > > > Dear all, > > Please find attached the Final Report with previous redlines accepted and only a single new edit, a new footnote #70 on page 49, discussed on the mailing list. > > At this stage the content of report is “frozen,” meaning that no further substantive edits will be made. As a reminder, the consensus call will open on Tuesday 22 December. If in the course of reviewing the document prior to the consensus call, you find any typos, numbering errors, etc, you can send these directly to staff. > > 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/> > > > _______________________________________________ > 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.

4 3

Content Freeze - Final Report
by Emily Barabas Dec. 19, 2020

Dec. 19, 2020

Dear all, Please find attached the Final Report with previous redlines accepted and only a single new edit, a new footnote #70 on page 49, discussed on the mailing list. At this stage the content of report is “frozen,” meaning that no further substantive edits will be made. As a reminder, the consensus call will open on Tuesday 22 December. If in the course of reviewing the document prior to the consensus call, you find any typos, numbering errors, etc, you can send these directly to staff. 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/>

3 2

Post Call / New gTLD Subsequent Procedures Working Group call / Thursday, 17 December 2020 at 20:00 UTC
by Julie Bisland Dec. 17, 2020

Dec. 17, 2020

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

Dec. 17, 2020

Dear Working Group members, Please see below the notes from the WG meeting on 17 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-17+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: 1. Updates to Statements of Interest: None provided. 2. Discussion of Consensus Call process and final milestones, including WG meeting on Consensus Designations See revised Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn… – column B -- WG has the Final Report content now. -- Staff and leadership will do non-substantive clean up (typos, etc.) through to 22 December. -- Consensus call starts on 22 December. Revised Work Plan: 17 December 2020 Freeze on all Content for the Final Report 22 December 2020 Consensus Call Begins 8 January 2021 Consensus Call Ends 23:59 UTC 11 January 2021 Consensus Call Designations are released (may deliver Final Report to Council but without Minority Reports for the Document Deadline) 12 January 2021 WG Call to discuss designations (Calendar Invites will be sent shortly) 13 January 2021 Challenges due to Consensus Call Designations (if any) 18 January 2021 Minority Reports are due by 23:59 UTC; Delivery of Final Report package to the GNSO Council Levels of Consensus in the Working Group Guidelines, Section 3.6 at: https://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-24oct19-en.pdf * Full consensus - when no one in the group speaks against the recommendation in its last readings. This is also sometimes referred to as Unanimous Consensus. · Consensus - a position where only a small minority disagrees, but most agree. · Strong support but significant opposition - a position where, while most of the group supports a recommendation, there are a significant number of those who do not support it. · Divergence (also referred to as No Consensus) - a position where there isn't strong support for any particular position, but many different points of view. Sometimes this is due to irreconcilable differences of opinion and sometimes it is due to the fact that no one has a particularly strong or convincing viewpoint, but the members of the group agree that it is worth listing the issue in the report nonetheless. · Minority View - refers to a proposal where a small number of people support the recommendation. This can happen in response to a Consensus, Strong support but significant opposition, and No Consensus; or, it can happen in cases where there is neither support nor opposition to a suggestion made by a small number of individuals. Consensus Call Mechanics: -- Topics where there may be divergence from consensus: Closed Generics, Mechanisms of Last Resort/Auctions, Communities/CPE. -- Consensus Call held on 4 parts: Closed Generics, Communities/CPE, Mechanisms of Last Resort/Auctions – 4th part is the rest of the report. -- Respond on the list with your support or non-support in those four parts. If non-support ask that you specific exactly what you do not support. Example, if you do not support changing the threshold to a percentage on CPE, but you don’t list anything else, we’ll assume you support everything else in that topic. -- We weren’t planning on including PICs, but we’ll have that discussion today on the redlines for that topics. -- If there was something else in another topic that a WG member doesn’t support the member can list it. -- For the Consensus Designations, there is an appeal process in the Working Group Guidelines, but there are no dates/timing in the Guidelines. -- What about RVCs/PICs? Can there be Minority Statements on that topic? The above-mentioned topics are the most likely, but there may be others. Anyone can file a Minority Report on any recommendation or output. -- On EPDP, if there was a recommendation with no consensus or divergence the Chair of the PDP chose to include that recommendation in the report to the Board. -- In the recent EPDP, the Council decided the recommendations were so inter-related, that the ones that did not receive full consensus could not be “picked off.” So, my understanding is that there is some thought process behind those decisions. -- Responses will be considered to be from individual WG members, unless it is stated that the response is from a group. -- Could be minority views on Geographical Names – even if not called out there can still be minority view lodged. -- Consensus Designation: will all members of the WG be treated equal, or will the Co-Chairs look at participation? Every member is entitled to express support or non-support, and there is no prohibition on that. But, the Co-Chairs have the right to look at participation – not quantitative. Hard to evaluation active participation over a 5-year effort. -- WG members can, but do not have to, consult with their groups (if they are acting as representatives, not individuals), and such consultation will not be used as a rationale for extending the timeline. -- Hard to say what the consensus designations will look like until the Co-Chairs have seen the responses. -- Question: What do you do when you have lack of support for a recommendation from several individuals, but for different reasons? Answer: That would go into the category of divergence, but the Co-Chairs are not documenting (themselves) the reasons, the WG members can decide to file a Minority Report stating the reasons. Co-Chairs are only documenting the levels of support not the rationale. -- This is not a quantitative vote, but the Co-Chairs can consider who is providing the responses (individuals, groups, etc.). -- Trying to avoid a vote or capture/gaming, or over-representation of certain views. 3. Review of outstanding issues from the redline PICs/RVCs: -- Leadership did not see any basis to change any of the recommendations/outputs, but to put in some supporting language in the rationale. -- Kathy Kleiman proposed additional language on guardrails supported by Jorge Cancio: “RVCs will not address the contents of websites or apps that use domain names, they will be consistent with ICANN’s Human Rights Core Value, they will not allow the registry arbitrary discretion to suspend a domain name and they will not be used to create new policies that did not come through ICANN processes.” -- Also proposal from Alan to include language requiring a recommendation that PICs must be enforceable, other than with a PICDRP. -- Could be a lot of PICs requests in future rounds and many of them will tax the ICANN contracting department. Guardrails could be helpful. -- These topics were thoroughly discussed before the preliminary report, after the draft Final Report (per the comments). -- We’ll put this out as a separate topic for views during the Consensus Call. 4. Reply to ICANN Board comments -- After the consensus designation, the WG can prepare a response to the Board. Not as an official WG activity, but for interested members to contribute. -- Draft some responses in more detail to explain how the WG came out where it did.

1 0

Finishing up PICs
by Kathy Kleiman Dec. 17, 2020

Dec. 17, 2020

All, Let’s remember that this is a contract between ICANN and the New gTLD Registries. It is not a Registry-Registrar Agreement or a Registrar-Registrant Agreement. Accordingly, everything in it must be legit under ICANN’s Bylaws. We want our ICANN Board Members, including Becky, to sleep at night. To do so, terms that are put into an RVC must fall within terms to which ICANN, as a signatory to this contract, must agree. Again, this is *ICANN’s contract.* There are many things we would not put into the vPICs/RVCs therefore, even though they may happen. Like some cooperation with local law enforcement and providing data on users and use. It may happen; it’s not in our contracts or blessed or enforced by ICANN. Accordingly, to the end of Recommendation 9.12, we must add something about the requirements of the RVC. A registrant cannot be required to paint the moon pink, and the PICs should not be allowed to push ICANN outside its mission, mandate, scope and core values. These are ICANN commitments to all of us, and to the world, in its Bylaws. _Accordingly we must add: RVCs will not address the contents of websites or apps that use domain names, they will be consistent with ICANN’s Human Rights Core Value, they will not allow the registry arbitrary discretion to suspend a domain name, and they will not be used to create new policies that did not come through ICANN processes. _ These limitations are substantive – they will keep the RVCs within the bounds of what ICANN is allowed to sign and what ICANN is allowed to do. The Attorney Generals do not want to see a spate of new contracts from California public interest corporation coming without principles and guardrails for what one party, in its self-interest, can impose on other parties, particularly those who are weaker – a registry imposing arbitrary and unfair terms on its registrants (note: unfair RVCs _did not, _in Round 1, come through the public processes we are working hard to protect, including GAC Early Warnings, GAC Consensus Advice, and settlements of Objections e.g., Community, Legal Rights, etc). We need to finish up 9.12 with the additions above. RVCs will no longer be the dumping ground or the “kitchen sink” as they were in 2013-2014. This is critical for ICANN’s integrity, and for this I quote, as I did in my March 11, 2020, CircleID article: Becky Burr, then and still an ICANN Board member, speaking in her personal capacity at an event at American University Washington College of Law in February 2019, ICANN and New gTLDs, DESCRIBING THE ROUND 1 PRIVATE PIC PROCESS: "_I HOPE WE NEVER SEE ANY LIKE THAT [AGAIN]", "THE PROCESS BY WHICH THAT HAPPENED WAS APPALLING," "AND MOST REGISTRIES AND REGISTRARS WERE APPALLED BY THAT PROCESS AS WELL." "A SUBSET OF… REGISTRY APPLICANTS CAME IN AND MADE ... COMMITMENTS THAT WERE LIKE, LITERALLY, EVERYTHING IN THE KITCHEN SINK."_ [emphasis added] NO MORE “KITCHEN SINK,” AND WE’RE DONE. Best, Kathy

6 9

FW: Finishing up PICs
by Susan Payne Dec. 17, 2020

Dec. 17, 2020

Adding my opposition here too Susan Payne Head of Legal Policy Com Laude | Valideus D: +44 20 7421 8255 M: +44 7971 661175 E: susan.payne(a)comlaude.com<mailto:susan.payne@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Marc Trachtenberg via Gnso-newgtld-wg Sent: 17 December 2020 20:13 To: PMcGrady(a)taftlaw.com<mailto:PMcGrady@taftlaw.com>; kathy(a)kathykleiman.com<mailto:kathy@kathykleiman.com>; jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com>; gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>; langdonorr(a)gmail.com<mailto:langdonorr@gmail.com> Subject: Re: [Gnso-newgtld-wg] Finishing up PICs I agree with Jeff and Paul here. This is neither necessary nor timely. Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commmerce and Social Media Practice Greenberg Traurig, LLP 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 T +1 312.456.1020 M +1 773.677.3305 trac(a)gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig] From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of McGrady, Paul D. Sent: Thursday, December 17, 2020 2:09 PM To: Kathy Kleiman <kathy(a)kathykleiman.com<mailto:kathy@kathykleiman.com>>; Jeff Neuman <jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com>>; gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>; langdonorr(a)gmail.com<mailto:langdonorr@gmail.com> Subject: Re: [Gnso-newgtld-wg] Finishing up PICs *EXTERNAL TO GT* All, I agree with Jeff. It is very late in the process (too late) to be introducing these so-called guardrails. If the guardrails are the Bylaws, as Kathy suggests, there is no need to include them because the Bylaws are in place and nothing this WG does can change the Bylaws. If the so-called guardrails are not already in the Bylaws, we just don’t have time to entertain sweeping ideas like these introduced at 11:59:59 in the process. As for Jeff and Cheryl’s legacy, all I will say is that I am confident their legacy is sound and their intense work over these years is appreciated. Best, Paul From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Kathy Kleiman Sent: Thursday, December 17, 2020 1:40 PM To: Jeff Neuman <jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com>>; Kathy Kleiman <kathy(a)kathykleiman.com<mailto:kathy@kathykleiman.com>>; gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>; langdonorr(a)gmail.com<mailto:langdonorr@gmail.com> Subject: Re: [Gnso-newgtld-wg] Finishing up PICs Jeff, The Guardrails are the Bylaws. Pure and simple. They are ICANN's commitment to stay outside of content (Bylaws 1.1) and operate consistent with internationally recognized human rights (Bylaws 1.2) and respect the policy procedures in which we all engage (in which this PDP WG operates). As an individual you have fought long and hard for the private PICs which you created for .BIZ when you wored at Neustar. I know you worked hard for your former employer. But the 2016 Bylaws and the .ORG battles commit ICANN to a higher standard. We are bound by that standard. We have talked about that standard, and our Bylaws, at length. We have heard from our Board liaisons that they are worried on this issue. They told us that ICANN cannot enforce that which does not fall under its mission. That is true We are very close. I'm asking us to tie up one last loose end. But it's an important one. The vast, vast majority of all of the private PICs/RVCs we want to protect fall under the Guardrails - the hundreds of GAC early warnings from Round 1, the GAC Advice from Beijing, the settlement of Community Objections in Round 1 (I did one; maybe the only one then). I want your legacy and that of Cheryl's to be solid on this PDP which has lasted so long and where you, and all members, have worked so hard. Please step back from your deep personal involvement on this issue. Telling ICANN that the working group says "anything goes" in RVCs is not true, and not right. We are all bound by ICANN's 2016 Bylaws. None of us is above the law; we are not above the Bylaws. This seems like a pretty easy fix, Jeff. Best, Kathy ----- Original Message ----- From: "Jeff Neuman" <jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com>> To: "Kathy Kleiman" <kathy(a)kathykleiman.com<mailto:kathy@kathykleiman.com>>, "gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>>, "langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>" <langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>> Cc: Sent: Thu, 17 Dec 2020 19:10:50 +0000 Subject: RE: Finishing up PICs Kathy, ***View as the Co-Chair - I do not believe the guardrails you have proposed have support within the working group. The rules/guardrails you have proposed represent a drastic departure from what the Working Group has discussed, that I do not believe it is realistic to think that they can be adopted at this point. Other members of the Working Group have supported the PICs and RVCs and have also supported the notion that they can be done in compliance with the Bylaws provided that we do not put ICANN in the position of determining whether any content based commitment was actually violated. That adjudication may be beyond the scope of ICANN’s mission. But if the actual adjudication is done by a third party and the registry agrees to be bound by the decision of that unrelated third party, then the Working Group members have weighed in that this seems in line with the Bylaws. We will discuss this further. __________________________ ****Personal View Follows**** Taking Co-Chair hat off – the following represents only my opinion. If the Working Group takes an opposing view, then as co-chair I will follow that. 1. I personally disagree with the overbroad guardrails. Take the .gay registry as an example. The .gay registry has a very tight anti-bullying / anti-harassment policy and reserves the right to take down sites that it finds violating that policy. Their goal is to present a safe space where a group of people that have historically been (and in a lot of cases still are) the subject of persecution, discrimination, harassment and bullying. The registry wants a space where its registrants and end users feel safe to belong, participate, celebrate, and just be themselves. If they want to commit to a content based policy, then who are we to tell them that they cant. 1. I believe I was at that American University event, and even explained then that registries aim to make TLDs a brand. If they want to have policies that distinguish their TLDs from others, even if related to content, then why should they be forbidden from doing so. I think I raised the example of Anti-abuse policies. When Neustar in 2008 or 2009 (when I was there) adopted an anti-abuse policy stating it would take down names using for phishing, pharming, malware, etc., it did so because it was starting to appear on ISP block lists for not taking that action. Legitimate registrants were having their e-mails blocked because the registry wasn’t taking action. The .biz brand was taking a huge dip. We made the bold decision and actually became the first registry to adopt an anti-abuse policy addressing these behaviors. I believe the EFF and others made the same arguments you were making. But the registry cleaned up its act, got taken off block lists and became (at the time) one of the safest TLDs. The brand became more respectable and registrants emails were again getting through. Over time, you, the EFF and others came to accept anti-abuse monitoring and now it is employed by virtually every registry and registrar. Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com<https://urldefense.com/v3/__http:/jjnsolutions.com__;!!DUT_TFPxUQ!TM2BMIaqc…> From: Kathy Kleiman <kathy(a)kathykleiman.com<mailto:kathy@kathykleiman.com>> Sent: Thursday, December 17, 2020 1:43 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>; Jeff Neuman <jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com>>; langdonorr(a)gmail.com<mailto:langdonorr@gmail.com> Subject: Finishing up PICs All, Let’s remember that this is a contract between ICANN and the New gTLD Registries. It is not a Registry-Registrar Agreement or a Registrar-Registrant Agreement. Accordingly, everything in it must be legit under ICANN’s Bylaws. We want our ICANN Board Members, including Becky, to sleep at night. To do so, terms that are put into an RVC must fall within terms to which ICANN, as a signatory to this contract, must agree. Again, this is *ICANN’s contract.* There are many things we would not put into the vPICs/RVCs therefore, even though they may happen. Like some cooperation with local law enforcement and providing data on users and use. It may happen; it’s not in our contracts or blessed or enforced by ICANN. Accordingly, to the end of Recommendation 9.12, we must add something about the requirements of the RVC. A registrant cannot be required to paint the moon pink, and the PICs should not be allowed to push ICANN outside its mission, mandate, scope and core values. These are ICANN commitments to all of us, and to the world, in its Bylaws. Accordingly we must add: RVCs will not address the contents of websites or apps that use domain names, they will be consistent with ICANN’s Human Rights Core Value, they will not allow the registry arbitrary discretion to suspend a domain name, and they will not be used to create new policies that did not come through ICANN processes. These limitations are substantive – they will keep the RVCs within the bounds of what ICANN is allowed to sign and what ICANN is allowed to do. The Attorney Generals do not want to see a spate of new contracts from California public interest corporation coming without principles and guardrails for what one party, in its self-interest, can impose on other parties, particularly those who are weaker – a registry imposing arbitrary and unfair terms on its registrants (note: unfair RVCs did not, in Round 1, come through the public processes we are working hard to protect, including GAC Early Warnings, GAC Consensus Advice, and settlements of Objections e.g., Community, Legal Rights, etc). We need to finish up 9.12 with the additions above. RVCs will no longer be the dumping ground or the “kitchen sink” as they were in 2013-2014. This is critical for ICANN’s integrity, and for this I quote, as I did in my March 11, 2020, CircleID article: Becky Burr, then and still an ICANN Board member, speaking in her personal capacity at an event at American University Washington College of Law in February 2019, ICANN and New gTLDs, describing the Round 1 private PIC process: "I hope we never see any like that [again]", "the process by which that happened was appalling," "and most registries and registrars were appalled by that process as well." "A subset of… registry applicants came in and made ... commitments that were like, literally, everything in the kitchen sink." [emphasis added] No more “kitchen sink,” and we’re done. Best, Kathy ________________________________ If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster(a)gtlaw.com<mailto:postmaster@gtlaw.com>, and do not use or disseminate the information. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>

1 0