November 2020 - Gnso-newgtld-wg

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

Dec. 9, 2020

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

9 11

Re: [Gnso-newgtld-wg] [Ntfy-gnso-newgtld-wg] **Reminder** Meeting Invitation | New gTLD Subsequent Procedures Working Group call | Tuesday, 01 December 2020 at 03:00 UTC
by mail＠christopherwilkinson.eu CW Nov. 30, 2020

Nov. 30, 2020

> > Good evening: Please note my apologies. I am no longer prepared to take calls at 04.00 a.m. > > CW > > El 30 de noviembre de 2020 a las 15:46 Andrea Glandon <andrea.glandon(a)icann.org> escribió: > Dear all, > > > > The New gTLD Subsequent Procedures Working Group call is scheduled on Tuesday, 01 December 2020 at 03:00 UTC for 90 minutes. > > > > Join the Zoom room directly (recommended): https://icann.zoom.us/j/93033235768?pwd=bVo2aENWTk1NNExhRS82dFZsM0EvQT09 [icann.zoom.us] https://urldefense.com/v3/__https:/icann.zoom.us/j/93033235768?pwd=bVo2aENW… > (no password required) > > > > Before joining the call: > Please send apologies and dial out requests to gnso-secs(a)icann.org mailto:gnso-secs@icann.org only > Please be sure you have read the Expected Standards of Behavior [icann.org] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource… > Visit the Wiki agenda page: https://community.icann.org/x/8oXzC > > Check your time zone: https://tinyurl.com/y3tuvwpz [tinyurl.com] https://urldefense.com/v3/__https:/tinyurl.com/y3tuvwpz__;!!PtGJab4!u3QKMFf… > > > If joining Zoom via the Zoom App, the following will be required: > Meeting ID: 930 3323 5768 > Password: 426hbq&jfm > > > > If you are joining via audio only: > > One tap mobile > > +16699006833,,93033235768#,,,,,,0#,,171117# US (San Jose) > +12532158782,,93033235768#,,,,,,0#,,171117# US (Tacoma) > > > > Dial in directly with your chosen number and provide: > > Meeting ID: 930 3323 5768 > Password: 171117 > > > > If this is your first time with Zoom, please take a look here: Welcome to Zoom [gnso.icann.org] https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d… > > > > Thank you. > Kind regards, > > > > Julie > > > > > > > > _______________________________________________ > Ntfy-gnso-newgtld-wg mailing list > Ntfy-gnso-newgtld-wg(a)icann.org > https://mm.icann.org/mailman/listinfo/ntfy-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. >

1 0

REMINDER: Review Revised Draft Final Report - DUE Tuesday, 01 December
by Julie Hedlund Nov. 30, 2020

Nov. 30, 2020

Dear WG Members, This is a reminder that the deadline for the review of the revised draft Final Report for errors and omissions only, if any, is 23:59 UTC on Tuesday, 01 December. Please see the details below. Kind regards, Julie From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Monday, November 23, 2020 at 3:04 PM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Review Revised Draft Final Report - DUE Tuesday, 01 December Dear WG Members, As noted during the WG meeting on Thursday, 19 November, please see for review the attached revised draft Final Report in Word and PDF, along with the Log of Final Report Action Items and Edits. The redlines in the attached revised draft Final Report reflect the edits made by leadership and support staff in accordance with the actions agreed to by the WG during the WG meetings held between 17 September and 09 November 2020, as noted in the Log with page references. These actions also were captured during each meeting and circulated to the WG. The following topics were covered by the WG in its meetings and addressed in the revised draft Final Report: Community Applications, General Comments, Predictability, Applicant Support, Limited Challenge/Appeal Mechanism, Applicant Guidebook, Communications, Systems, Application Change Requests, Application Fees, Base Registry Agreement, GAC Early Warning / GAC Consensus Advice, Role of Application Comment, and Objections. Note: In reviewing the revised draft Final Report WG members are requested to limit their review to the referenced pages in the Log and the redlines in the revised draft Final Report, and to focus only on errors and/or omissions, if any. If any errors/omissions are noted please send them to the WG email distribution list, referencing the page number and text, respectively. Please submit comments to the list, if any, not later than 23:59 UTC on Tuesday, 01 December. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 23 November 20:00 UTC
by Julie Hedlund Nov. 24, 2020

Nov. 24, 2020

Dear Working Group members, Please see below the notes from the WG meeting on 23 November 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-11-23+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 9 PICs / RVCs – Row 29<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> ACTION ITEM: The WG needs to revisit the recommendations and consider how they would be enforced. Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Discussion with Board Liaisons on Board Bylaws comments regarding: a. Topic 9 PICs / RVCs – Row 29<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> Discussion: -- From the new ByLaws Section 1.1.: (iv) ICANN shall have the ability to negotiate, enter into and enforce agreements, including public interest commitments, with any party in service of its Mission. -- Have used PICs to resolve disputes. -- Becky Burr, Board Liaison: Concerns about taking on more voluntary private commitments for which compliance is not objectively measurable. Need to remind ourselves that enforceability goes beyond whether something is content regulation or not. It goes back to looking at the voluntary commitments and understanding whether it is in furtherance of ICANN’s Mission: “Coordinates the allocation and assignment of names in the root zone of the Domain Name System ("DNS") and coordinates the development and implementation of policies concerning the registration of second-level domain names in generic top-level domains ("gTLDs").” And “ICANN shall not regulate (i.e., impose rules and restrictions on) services that use the Internet's unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a). For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority.” How is the WG thinking about the voluntary commitments with the Bylaws in mind, including contractual compliance. -- Avri Doria, Board Liaison: How have you thought about how to deal with this? At the end of the day the Board will look at the Bylaws and the recommendations and try to see where the public interest point is, but ultimately that will have to come from the WG. -- What happens if the answer is that the WG hasn’t concerned the Bylaws? Should we be asking ICANN Legal about the limits? -- In this case in drafting the Bylaws there was a lot of work, but even the plain meaning – when we talk about “regulates” the Bylaws defines that as imposing rules, as forcing something to be accepted. If we are talking about voluntary commitments then they are not regulations. They aren’t imposed, so not prohibited by the Bylaws. -- If there was a dispute between two parties – GAC gave advice against a string but said if you do x, y, and z we are okay with it and it can go forward. Does it matter what x, y, and z are? -- Avri Doria, Board Liaison: You tell us how that is to be read and enforced. If there those agreements can be objectively dealt with. There is what you can contract and what can you enforce in an objective way. The interpretation has to come from the PDP WG’s recommendation. -- Becky Burr, Board Liaison: The Board does not have a position on this issue and is looking for guidance from the GNSO via the PDP. The question of how you use these voluntary commitment to resolve contention or concerns, it probably would make a difference to how you go about addressing those. It seems like it is going to be hard to enforce in light of the language in the Bylaws. -- If we assume we could come up with a way for these to be objectively enforced, can these commitments be made? Let’s say there’s a legal rights objection against an applicant’s string. To resolve it there is an agreement with a third party to not infringe. If there are disputes these would be dealt with an arbitration association, but ICANN enforces the decision of the arbitration association. -- Avri Doria, Board Liaison: If the third party is doing something independently of ICANN, then we don’t know. If they are hired by ICANN, then no. -- Caution that the PDP WG can’t rewrite the Bylaws and interpretation has to be consistent with the history and language. This Bylaw is a compromise. Anything that is in the Registry Agreement should be in furtherance of ICANN’s mission. -- Are there examples of non-content related PICs that the WG could pull out as examples to set some criteria/parameters? -- Becky Burr, Board Liaison: Not sure that looking at existing PICs solves the problem. But it would be very useful to hear what kinds of things you think are fair game and what aren’t. -- These Bylaws have been changes several times so if this is a major barrier maybe it needs to be revisited. -- It’s clear that content is relevant to many TLDs. -- Avri Doria, Board Liaison: If there is a consensus recommendation that requires a change to the Bylaws then the Board will consider that. ACTION ITEM: The WG needs to revisit the recommendations and consider how they would be enforced. b. Topic 23 Closed Generics – Row 23<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Discussion: -- Becky Burr, Board Liaison: The Board adopted a temporary prohibition on closed generics and asked the community to develop policy. The temporary prohibition should not be considered to be policy. If there is no new policy then the temporary prohibition does not automatically stand as a default. -- The WG has taken the determination that in absence of a new policy we revert to how it happened in the last round. Not clear how the Board will interpret the status quo if we don’t do anything this time. -- The WG can’t assume how the Board will act if the WG does not make a recommendation. -- Avri Doria, Board Liaison: There is no standing policy on this since there was no explicit policy. -- Becky Burr, Board Liaison: There wasn’t policy because the Board didn’t have the authority to set the policy. -- The WG could adopt, affirmatively, the temporary prohibition. Would like to know if the Board would like the WG to make a recommendation. -- It would be better if the WG can develop policy on this. If not we should assume that it will fall one way or another. -- Question: There is still existing GAC advice on this topic and until that is addressed it is something the Board will have to handle. -- Avri Doria, Board Liaison: Without a policy recommendation the Board is left in the same position of having an indeterminate recommendation on advice. We would have to go back to the GNSO. c. Private Resolution of Contention Sets – Topic 35 Auctions – Row 24<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> Questions from the Small Team: “re: “A. The Board notes Recommendation 35.2, which states “[...] the Applicant Guidebook (AGB) must reflect that applicants will be permitted to creatively resolve contention sets in a multitude of manners, including but not limited to business combinations or other forms of joint ventures and private resolutions (including private auctions).” The Board encourages the PDP WG to provide a rationale why the resolution of contention sets should not be conducted in a way such that any net proceeds would benefit the global Internet community rather than other competing applicants.” Question - Can the Board expand upon what they mean by “net proceeds benefitting the global community?” Are there methods of contention resolution that the board has discussed specifically that the WG should take into consideration? There are deep divisions within the WG and across the broader community, as evidenced by public comment, about contention resolution where applicants use contention resolution as a means to make money, be it through creative private resolutions involving monetary agreements or private auctions where losers receive funds. What if we are not able to reach consensus on the rationale you are asking for? Discussion: -- There is a divide in the WG. -- Becky Burr, Board Liaison: Would you still come up with a policy permitting or not permitting private resolutions? -- Avri Doria, Board Liaison: The community has been very specific about what they wanted to do with the money from the auction of last resort – to be spent in the public interest. Why shouldn’t this apply to this money? -- What if part of the rationale is that allowing the money to encourage competition. It will be really hard for the WG to come to agreement on a rationale. -- Becky Burr, Board Liaison: Not wrong to provide two rationales. -- Avri Doria, Board Liaison: But it needs to be able to answer the questions people will ask us. -- There is a major factor that the environment has changed significantly since 2012. -- We haven’t talked about the significant investment people have made and in an auction scenario the applicant could walk away with nothing. -- Seems that the Board is concerned about recommendations that are overly complex or unclear that could lead to litigation. Is that the case? -- Becky Burr, Board Liaison: The Board would like to get simple and clear recommendations that avoid unnecessary complexity. -- Avri Doria, Board Liaison: Not only is it easier to make a decision on a simple and clear recommendation, but also easier to implement. re: “B. The Board notes that if “private” resolutions will be allowed or encouraged in subsequent procedures, the PDP WG is requested to provide a rationale for why these private processes should only partially be brought into the program rather than be kept outside of the program or be brought into the program. The Board also encourages the PDP WG to provide guidance on the kinds of transparency requirements that it would like to see applied in practice around private resolutions of contention sets.” Question - Could the Liaisons provide clarity on what the Board means when they say: “… private processes should only partially be brought into the program rather than be kept outside of the program or be brought into the program”, particularly the references to into or outside of the program. And more generally, why the Board is seeking a rationale on this issue and A. Discussion: -- Avri Doria, Board Liaison: We don’t understand why if such a process is going to be allowed why it wouldn’t be completely private or completely ICANN-run. Having this halfway measure is confusing. What is the reason for making this a partial ICANN policy. Some of the thoughts about the private auction did include some ICANN oversight, so it ceases to be a totally private arrangement. re: "D. The Board acknowledges the “potential non-exhaustive list of ‘factors’ that ICANN may consider in determining whether an application was submitted with a bona fide (good faith) intention to operate the gTLD.” We note that this non-exhaustive list of “factors” may put ICANN org or the ICANN Board into the position of subjectively trying to determine the state of mind of applicants, and take decisions that are subject to possible challenges. The Board asks the PDP WG to consider providing a clear problem statement of what types of behaviour or abuse the requirement of bona fide applications is meant to address. PDP WG members could then use such a statement to provide objective criteria for assessing the bona fide nature of an application. (Pg. 164)” Question - The Board is asking the WG for a clear problem statement about abusive behavior that the non-exhaustive factors are meant to address. However, the work on the non-exhaustive factors was motivated by what some in the WG believed was the Board’s indication that it disfavors private auctions. Does the Board actually disfavor private auctions? If so, does the Board have a clear problem statement leading it to disfavor private auctions? If so, can you please share that with us? Discussion: -- Becky Burr, Board Liaison: The Board does not have a shared view on private auctions. There are a range of concerns among the Board and across the community. The Board needs to understand how the WG arrived at its recommendation. -- Avri Doria, Board Liaison: There is no nugget of what the Board wants in any of these questions. re: “E. The Board notes that a statement of “bona fide” intentions would be expected for all applications, not only those involved in auctions, particularly since when an application is submitted the applicant likely will not know if it will be in contention. (Pg. 164) F. In this context, the Board suggests that the PDP WG consider the hypothetical scenario of an applicant intending to operate up to five gTLDs. To avoid contention sets the applicant might apply for 20 strings, with the expectation to drop 15 applications based on contention and their own preference. Would those 15 applications not be considered “bona fide,” and what would be the consequence for such an applicant? Similarly, a large number of applications could be submitted by separate corporations; would ICANN org be required to establish each applicant’s investor(s) and other controlling parties in order to affirm bona fide intent? The Board believes it would be helpful for the PDP WG to address these questions and provide guidance on making objectively enforceable rules to establish what constitutes a bona fide intention to run a gTLD. (Pg. 164)” Question - The Board comments presupposes that applicants will violate the certification of bona fide intent by proposing a hypothetical scenario in which an applicant would apply for 20 TLDs with an intent to only operate 5. This seems to indicate a deep distrust of applicants. Some within the WG believe that the issue of private auctions is a minor issue or even a non-issue compared with other extant and widespread DNS abuses costing global business billions of dollars. If the Board has serious concerns that applicants will lie about their bona fide intentions to operate the registries for which they have applied, why would the Board allow such entities access to running a registry? What can the Board do to ensure a higher quality of applicant in the program?

4 5

Re: [Gnso-newgtld-wg] Proposed edits to Recommendation 9.1 re: Category 1 Safeguards
by Jorge.Cancio＠bakom.admin.ch Nov. 24, 2020

Nov. 24, 2020

Dear all I would like to just briefly chime in to remind folks that the GAC consensus input includes a number of considerations about enforceability of PICs which go in a similar direction... Kindly Jorge Von: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> Im Auftrag von Levine, Gertrude Gesendet: Montag, 16. November 2020 22:34 An: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>; gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org> Betreff: [Gnso-newgtld-wg] Proposed edits to Recommendation 9.1 re: Category 1 Safeguards Hi all, In last Thursday's SubPro meeting, we discussed Topic 9: Category 1 Safeguards - in particular, Recommendation 9.1, which reads, in part, as follows: "Mandatory Public Interest Commitments (PICs) currently captured in Specification 11 3(a)-(d) of the Registry Agreement must continue to be included in Registry Agreements for gTLDs in subsequent procedures. ..." The section in question was Specification 11 3(a): Specification 11 3(a)-(d): 3. Registry Operator agrees to perform the following specific public interest commitments, which commitments shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process . . . (a) Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name. As we discussed in the meeting, Specification 11 3(a) as currently written falls short of its intended purpose, protecting end users. It is therefore necessary to revise Specification 11 3(a) to hold new TLDs that are subject to Category 1 Safeguards accountable for their registrants' contractual compliance with those safeguards. Existing TLDs could be grandfathered as exempt from the Specification 11 3(a) revision. It seems there was some interest among the working group members to further explore this idea. I would propose changing Recommendation 9.1 in the final report to add the underlined text below: "Mandatory Public Interest Commitments (PICs) currently captured in Specification 11 3(a)-(d) of the Registry Agreement must continue to be included in Registry Agreements for gTLDs in subsequent procedures." In addition, Specification 11 3(a) should be revised to hold new TLDs that are subject to Category 1 Safeguards accountable for their registrants' contractual compliance with those safeguards. Existing TLDs could be grandfathered as exempt from the Specification 11 3(a) revision. I'd be interested to hear others' thoughts. Thanks, Gg Gertrude "Gg" Levine Digital Health Manager 847/391-4497 [cid:image006.png@01D6C259.8FD13A20]National Association of Boards of Pharmacy 1600 Feehanville Dr, Mount Prospect, IL 60056 www.nabp.pharmacy<http://www.nabp.pharmacy/> | glevine(a)nabp.pharmacy<mailto:glevine@nabp.pharmacy> [cid:image007.png@01D6C259.8FD13A20]<https://www.facebook.com/NABP1904/> [cid:image008.png@01D6C259.8FD13A20]<https://twitter.com/nabp> [cid:image009.png@01D6C259.8FD13A20]<https://www.linkedin.com/company/national-association-of-boards-of-pharmacy/> [cid:image010.png@01D6C259.8FD13A20]<https://www.youtube.com/c/NationalAssociationofBoardsofPharmacy>

2 1

Post Call | New gTLD Subsequent Procedures Working Group | Monday, 23 November 2020 at 20:00 UTC
by Julie Bisland Nov. 23, 2020

Nov. 23, 2020

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

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 01 December 03:00 UTC
by Julie Hedlund Nov. 23, 2020

Nov. 23, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Tuesday, 01 December 2020 at 03:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 1: Continuing Subsequent Procedures<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Topic 3: Applications Assessed in Rounds<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Topic 5: Application Submission Limits<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Topic 16: Application Submission Period<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…> Topic 19: Application Queuing<https://docs.google.com/spreadsheets/d/1jS1m66MxbJRWhhQQTZBpyZnIuWm4ncpJFki…> 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

Review Revised Draft Final Report - DUE Tuesday, 01 December
by Julie Hedlund Nov. 23, 2020

Nov. 23, 2020

Dear WG Members, As noted during the WG meeting on Thursday, 19 November, please see for review the attached revised draft Final Report in Word and PDF, along with the Log of Final Report Action Items and Edits. The redlines in the attached revised draft Final Report reflect the edits made by leadership and support staff in accordance with the actions agreed to by the WG during the WG meetings held between 17 September and 09 November 2020, as noted in the Log with page references. These actions also were captured during each meeting and circulated to the WG. The following topics were covered by the WG in its meetings and addressed in the revised draft Final Report: Community Applications, General Comments, Predictability, Applicant Support, Limited Challenge/Appeal Mechanism, Applicant Guidebook, Communications, Systems, Application Change Requests, Application Fees, Base Registry Agreement, GAC Early Warning / GAC Consensus Advice, Role of Application Comment, and Objections. Note: In reviewing the revised draft Final Report WG members are requested to limit their review to the referenced pages in the Log and the redlines in the revised draft Final Report, and to focus only on errors and/or omissions, if any. If any errors/omissions are noted please send them to the WG email distribution list, referencing the page number and text, respectively. Please submit comments to the list, if any, not later than 23:59 UTC on Tuesday, 01 December. Kind regards, Julie Julie Hedlund, Policy Director

2 1

With PDFs Re: Review Revised Draft Final Report - DUE Tuesday, 01 December
by Julie Hedlund Nov. 23, 2020

Nov. 23, 2020

Dear WG members, For some reason the PDF documents did not send. Here they are again. Kind regards, Julie From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Monday, November 23, 2020 at 3:04 PM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Review Revised Draft Final Report - DUE Tuesday, 01 December Dear WG Members, As noted during the WG meeting on Thursday, 19 November, please see for review the attached revised draft Final Report in Word and PDF, along with the Log of Final Report Action Items and Edits. The redlines in the attached revised draft Final Report reflect the edits made by leadership and support staff in accordance with the actions agreed to by the WG during the WG meetings held between 17 September and 09 November 2020, as noted in the Log with page references. These actions also were captured during each meeting and circulated to the WG. The following topics were covered by the WG in its meetings and addressed in the revised draft Final Report: Community Applications, General Comments, Predictability, Applicant Support, Limited Challenge/Appeal Mechanism, Applicant Guidebook, Communications, Systems, Application Change Requests, Application Fees, Base Registry Agreement, GAC Early Warning / GAC Consensus Advice, Role of Application Comment, and Objections. Note: In reviewing the revised draft Final Report WG members are requested to limit their review to the referenced pages in the Log and the redlines in the revised draft Final Report, and to focus only on errors and/or omissions, if any. If any errors/omissions are noted please send them to the WG email distribution list, referencing the page number and text, respectively. Please submit comments to the list, if any, not later than 23:59 UTC on Tuesday, 01 December. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Three Guardrails for Voluntary PICs/RVCs
by Kathy Kleiman Nov. 23, 2020

Nov. 23, 2020

Hi All,You may have seen the piece on voluntary PICs that EFF circulated yesterday on its blog: https://www.eff.org/deeplinks/2020/11/icann-can-stand-against-censorship-an… Today I share a new document - THREE GUARDRAILS FOR VOLUNTARY PICS AND REGISTRY VOLUNTARY COMMITMENTS - elaborating on the three-part solution that EFF offered yesterday. To borrow a phrase from the great Paul McGrady, we would probably call this 3-part solution "Guardrails" for voluntary PICs and RVCs. We offer these Guardrails as a step forward to our mutual goal of voluntary PICs and RVCs which fall within the scope and mission of ICANN. I look forward to our discussion today and moving forward together on this important topic.Best, Kathy (Kleiman)

1 0

Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 09 November 15:00 UTC - re rationale of GAC Advice
by Jorge.Cancio＠bakom.admin.ch Nov. 23, 2020

Nov. 23, 2020

Dear all Regarding the language regarding the «rationale” of GAC Consensus Advice: please do just refer to the Bylaws language, without adding any additional requirements not contained in the Bylaws. Please note that the GAC input on this recommendation is based on GAC consensus: == (quote from the GAC input to the public consultation)== In this regard, the GAC does not support: ● PDP WG recommendations limiting the scope of GAC advice. In particular, the GAC does not support PDP WG recommendation 30.3 requiring that if GAC advice is “based on public policy considerations, well-founded merits-based public reasons must be articulated”, and considers that no additional requirements on what is established in the Bylaws regarding GAC Advice can nor should be established through policy recommendations. In this sense, current Bylaws (Section 12.3) already prescribe that the GAC, as any advisory committee, needs to provide a rationale, a requirement which the GAC has been abiding by consistently since the Bylaws change in 2016. The rationale provided by the GAC is based on its role under the Bylaws to “consider and provide advice on the activities of ICANN as they relate to governments, particularly matters where there may be an interaction between ICANN’s policies and various laws and international agreements or where they may affect public policy issues”, without any need to add any further requirements through policy. == Due to resource limitations GAC folks (like me) are normally not able to follow SubPro calls… However, I feel it would be fair and sensible that the WG considers GAC inputs, especially those based on GAC consensus very seriously. Best Jorge Von: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> Im Auftrag von Julie Hedlund Gesendet: Montag, 9. November 2020 17:54 An: gnso-newgtld-wg(a)icann.org Betreff: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 09 November 15:00 UTC Dear Working Group members, Please see below the notes from the working sessions on 09 November at 15:00 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-11-09+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 31: Objections<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…> Row 21 – ICANN Org re: Questions about "arbitration forum". ACTION ITEM: Check the language to make sure it is clear. Switch the terminology to make it clear -- use "panel" not "arbitration forum" or "arbitration" or be consistent. Topic 30: GAC Early Warning/GAC Consensus Advice<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…> Row 13 – Swiss Government OFCOM and Row 14 – GAC France re: Concerns about removal of "strong presumption" Reiterates GAC concerns listed under "new information" and Row 20 – GAC re: WG shouldn't make recommendations on limiting GAC activities under Bylaws; amend Recommendation 30.6 to allow applicants to address issues raised in GAC Early Warning. ACTION ITEM: Take the discussion to the list on the three options with respect to Recommendation 30.3 and GAC Consensus Advice. Options: 1) don’t change the language of the recommendation; 2) clarify the recommendation as suggested by IPC; 3) revise the recommendation to use the language it as in 12.3 of the Bylaws. Row 21 – ICANN Org re: Clarification on whether amendments permitted in response to "non-consensus advice"; need clear process and deadlines to change an application. ACTION ITEM: Clarify with Leadership the terminology to use be consistent re: “GAC Advice” and “GAC Consensus Advice”. ACTION ITEM: Send the question to the WG list: “is the WG recommending particular actions in the event that the GAC issued non-consensus advice?” Topic 28: Role of Application Comment<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 10 – Jamie Baxter re: Same application comment period for Standard and Community applications, for a predetermined period. ACTION ITEM: Add a recommendation along the lines suggested by Jamie Baxter/ALAC: “the Applicant Comment Period should only run for the predetermined period outlined in the AGB. Any comments received during the period would be the only comments considered during evaluations.” Row 14 -- PETILLION Law Firm re: Inform applicant if information is submitted on confidential portions of an application. ACTION ITEM: Revise Recommendation 28.13 that if such information is submitted, the applicant should be fully informed of the submitted information and be able to respond through the same mechanism. Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 31: Objections<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…> Row 14 – ALAC re: ALAC should be equal in standing to the Independent Objector insofar as not having to prove a link to the community invoked in its Community Objection. Leadership Comments: WG Discussed whether ALAC should automatically have standing for Community-based objections and there was no agreement within the Working Group to give ALAC that. Does WG want to revisit? Discussion: -- No agreement in Work Track 3 on this. They didn’t want to duplicate the Independent Objector role. -- No interest from the WG to revisit this issue. Row 16 -- Intellectual Property Constituency (IPC) and PETILLION Law Firm re: Applicants in String Confusion Objection set should respond if an objection is filed. Leadership Comments: Does the Working Group wish to consider a default option? -- No WG action noted. Row 18 – ICANN Board re: Identify the purpose of continuing the IO role. Leadership Comments: We did discuss this and there was no agreement on changing this part of the program. Discussion: -- No agreement in the WG to keep the IO, but no agreement to get rid of it. -- Decide whether the WG should respond to the Board to address their comments. Could say that the same justifications for the IO program exist as they did for the 2012 round. -- Don't get continued employment of an IO. It was a failed experiment and the Board is right to question us. The best we could say that some WG members think the same justifications as in 2012 exist for subsequent rounds, other WG members think it’s a wasteful and unnecessary program. Row 19 – ALAC re: Questions about budget/resources for IO panel Leadership Comments: More an issue for ICANN Org/IRT. Row 21 – ICANN Org re: Questions about "arbitration forum". Leadership Comments: These are all clarifications - we should check the language to make sure it is clear. #1 and #2: Arbitration forum is the same thing as the panel. Switch the terminology to make it clear -- use "panel" not "arbitration forum" or "arbitration" or be consistent. #4 - The answer is to determine whether they are reasonable. ACTION ITEM: Check the language to make sure it is clear. Switch the terminology to make it clear -- use "panel" not "arbitration forum" or "arbitration" or be consistent. Topic 30: GAC Early Warning/GAC Consensus Advice<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…> Row 13 – Swiss Government OFCOM and Row 14 – GAC France re: Concerns about removal of "strong presumption" Reiterates GAC concerns listed under "new information" and Row 20 – GAC re: WG shouldn't make recommendations on limiting GAC activities under Bylaws; amend Recommendation 30.6 to allow applicants to address issues raised in GAC Early Warning. Leadership Comments: Should we amend the language also submitted by Swiss Govt on "possible" mechanisms to address GAC Advice? Recommendation 30.3: As stated in the ICANN Bylaws, GAC Consensus Advice must include a clearly articulated rationale.[1] The Working Group recommends that GAC Consensus Advice be limited to the scope set out in the applicable Bylaws provisions and elaborate on any “interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues.” To the extent that the rationale for GAC Consensus Advice is based on public policy considerations, well-founded merits-based public policy reasons must be articulated. Discussion: -- WG recommendations can’t change the Bylaws. -- GAC says it can provide advice on policy, which may not be in the law. -- The recommendation is not a Bylaws change. -- Example: There is no law against Closed Generics. The existing advice is based on public policy. -- On the GAC Consensus Advice, when that came through after applications were submitted was problematic. -- GAC when it provides advice it has to provide a rationale. -- Make sure we are being consistent in the recommendations. -- Options re GAC Consensus Advice: 1) leave as is; 2) clarify as suggested by IPC; 3) state it as 12.3 of the Bylaws states it. ACTION ITEM: Take the discussion to the list on the three options with respect to Recommendation 30.3 and GAC Consensus Advice. Options: 1) don’t change the language of the recommendation; 2) clarify the recommendation as suggested by IPC; 3) revise the recommendation to use the language it as in 12.3 of the Bylaws. Row 21 – ICANN Org re: Clarification on whether amendments permitted in response to "non-consensus advice"; need clear process and deadlines to change an application. Leadership Comments: Fix terminology to be consistent. Clarity on Deadlines? Discussion: -- Look at 12:2a1: That’s what we had in mind when we made the recommendations and maybe the IPC. -- Re: non-consensus advice in 2012 – is the WG recommending particular actions in the event that the GAC issued non-consensus advice? -- Should we change the recommendation to say that applicants should be able to change an application in response to non-consensus advice? ACTION ITEM: Clarify with Leadership the terminology to use be consistent re: “GAC Advice” and “GAC Consensus Advice”. ACTION ITEM: Send the question to the WG list: “is the WG recommending particular actions in the event that the GAC issued non-consensus advice?” Topic 28: Role of Application Comment<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 10 – Jamie Baxter and also Row 12 – ALAC re: “the Applicant Comment Period should only run for the predetermined period outlined in the AGB. Any comments received during the period would be the only comments considered during evaluations.” Leadership Comments: This is still an issue. Agreed that it should be for a definitive period of time, but didn't say that they had to be at the exact same time. Recommendation 34.6: Evaluators must continue to be able to send Clarifying Questions to CPE applicants but further, must be able to engage in written dialogue with them as well. Recommendation 34.7: Evaluators must be able to issue Clarifying Questions, or utilize similar methods to address potential issues, to those who submit letters of opposition to community-based applications.  Recommendation 34.9: If the Community Priority Evaluation Panel conducts independent research while evaluating an application, limitations on this research and additional requirements must apply. The Working Group recommends including the following text in the Applicant Guidebook: “The Community Priority Evaluation Panel may perform independent research deemed necessary to evaluate the application (the “Limited Research”), provided, however, that the evaluator shall disclose the results of such Limited Research to the applicant and the applicant shall have an opportunity to respond. The applicant shall be provided 30 days to respond before the evaluation decision is rendered. When conducting any such Limited Research, panelists are cautioned not to assume an advocacy role either for or against the applicant or application.” Implementation Guideline 34.10: To support transparency, if the Community Priority Evaluation Panel relied on research for the decision it should be cited and a link to the information provided. Discussion: -- Comment period needs to be aligned with when the objections happen. -- There were never two application comment periods. ICANN just never closed the application comment period for community applicants. -- Question: Is there information that could come in during the evaluation that would be subject to public review? Answer: Research is provided to the applicant and others could get clarifying question. There isn’t a general open public comment period. But opportunities for those who have provided letters of objection or support to provide clarifications. -- If there was independent research thought we said that the applicant would be notified. Might be prejudicial if an applicant couldn’t get public comment on research that the applicant doesn’t agree with. -- In Rec 34.10 we do say the applicant can respond, but it’s not a public comment. -- Add a recommendation to specify that there is only one comment period and that all comments should be provided in that period. ACTION ITEM: Add a recommendation along the lines suggested by Jamie Baxter/ALAC: “the Applicant Comment Period should only run for the predetermined period outlined in the AGB. Any comments received during the period would be the only comments considered during evaluations.” Row 14 -- PETILLION Law Firm re: Inform applicant if information is submitted on confidential portions of an application. Leadership Comments: Ask the WG if this is a good clarification. ACTION ITEM: Revise Recommendation 28.13 that if such information is submitted, the applicant should be fully informed of the submitted information and be able to respond through the same mechanism. Row 15 – ALAC re: Clarify consequences of violation of Recommendation 28.3 and related IG; allow applicant time to reply to late comments. Leadership Comments: Consequence of a violation is that it won't be considered. Bring this up with the WG. 28.12 -- It's a clarification. No WG action noted. Row 17 – ICANN Org re: Differentiate between Recommendation 28.3 and related IG; concerns with data privacy, verification, confidentiality, security, and implementation. Leadership Comments: Many of these are clarifications. These can be noted, but nothing new or to change. Might be information to be provided to the IRT to consider. No WG action noted. ________________________________ ________________________________ [1] Section 12.3. PROCEDURES of the ICANN Bylaws states: “. . .each Advisory Committee shall ensure that the advice provided to the Board by such Advisory Committee is communicated in a clear and unambiguous written statement, including the rationale for such advice.” See https://www.icann.org/resources/pages/governance/bylaws-en.

2 2

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 23 November 20:00 UTC
by Julie Hedlund Nov. 19, 2020

Nov. 19, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Monday, 23 November 2020 at 20:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Discussion with Board Liaisons on Board Bylaws comments regarding: a. Topic 9 PICs / RVCs – Row 29<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> b. Applicant Changes as a result of disputes, objections, etc.: Topic 20 Application Change Requests – Row 20<https://docs.google.com/spreadsheets/d/1jS1m66MxbJRWhhQQTZBpyZnIuWm4ncpJFki…>; Topic 31 Objections – Row 19<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…>; Topic 23 Closed Generics – Row 23<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> c. Topic 34 Community Applications – Row 19<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…>; and d. Private Resolution of Contention Sets – Topic 35 Auctions – Row 24<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> 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

Correction - Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 19 November 15:00 UTC
by Julie Hedlund Nov. 19, 2020

Nov. 19, 2020

Dear Working Group members, Please see below the corrected notes (changes in red) from the WG meeting on 19 November at 15:00 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-11-19+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 6: RSP Pre-Evaluation<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 10 – Thomas Barrett (Individual) re: Optional to name selected pre-approved RSP in application; Row 11 – IPC; Row 12 -- PETILLION Law Firm; Row 13 – GoDaddy Registry; Row 19 -- RrSG ACTION ITEM: Send to the WG list the question of whether the recommendations should be updated to clarify that an applicant must select the pre-evaluated RSP and nominate them in the application. Ask also if it should be disclosed, but confidential. Row 18 – ICANN org re: Recommendation 6.2: Our understanding is that this would not replace pre-delegation testing (PDT) which tests the technical and operational infrastructure for each gTLD as a prerequisite for delegation. ACTION ITEMS: 1) specify in more detail which of the elements are required at or around the time of delegation; 2) which elements only need to be evaluated one time and in the pre-delegation process. We may not be able to be specific, so perhaps capture as a principle of streamlining for the IRT to work out the details. Topic 27: Applicant Reviews<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 16 – ALAC re: “support a permissible level of differential treatment for applicants that apply for Applicant Support which should take into account comment on the question in Topic 17 Applicant Support in respect of whether the scope of financial support for applicants what quality for Applicant Support should be expanded to also costs associated with operating the TLD.” ACTION ITEM: Add a clarification. Row 17 – ICANN org re: states that “Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only).” It’s not clear why this implementation detail should be the subject of generally applicable policy binding on ICANN, and therefore ICANN org suggests recategorizing this Recommendation as Implementation Guidance. ACTION ITEM: Change to Implementation Guidance. Re: Implementation Guidance 27.18: Need to look at the language. Need to define “default” more clearly and in connection with the 5 critical functions. ACTION ITEM: re: Implementation Guidance 27.18: Define “default” more clearly and in connection with the 5 critical functions. Topic 39: Registry System Testing<https://docs.google.com/spreadsheets/d/1YimiR8dKA2F76QO_36hfDRCFE7-l5syuQ2z…> Row 12 – ICANN org Recommendation 39.1: ACTION ITEM: Include “and its supporting/subcontracted Registry Service Providers (RSPs).” That is to say, the registry system tests should demonstrate the technical capabilities of the registry operator or its supporting RSP, as required. Implementation Guidance 39.5 ACTION ITEM: Clarify by rephrasing “tables that are pre-vetted by the community” to “reference LGRs.” Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 6: RSP Pre-Evaluation<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 10 – Thomas Barrett (Individual) re: Optional to name selected pre-approved RSP in application; Row 11 – IPC; Row 12 -- PETILLION Law Firm; Row 13 – GoDaddy Registry; Row 19 -- RrSG Leadership Comments: Clarify whether recommendations require you to name the operator or just state that you have an operator? In the text of the recommendation we say that you have to say that you are using one, but not name it. Discussion: -- Couple of reasons why this should be mandatory (to name the operator): 1) If you have an applicant that is applying for 20 TLDs and you don’t name your RSP, that could be suspicious; 2) when ICANN org evaluates applications and testing with RSPs re: capacity to manage X number of TLDs, important to know how many TLDs the operator will be supporting. -- If an applicant wanted to change its back-end provider prior to contract would that have to be an application change request, or could it be changed in contracting? Could depend on what the change was – whether it was to another pre-approved RSP. -- There is a benefit to confidentiality regarding an RSP. -- It can still be a factor of consideration if applicants decide to identify their pre-evaluated RSPs voluntarily – if we have a factor about bona fide in the application. -- Don’t put too much weight into having an agreement with an RSP as an intent to operate. When you operate an agreement for one or 2 strings, maybe but when its for 10, 20 50 or 200, its a one time deal. ACTION ITEM: Send to the WG list the question of whether the recommendations should be updated to clarify that an applicant must select the pre-evaluated RSP and nominate them in the application. Ask also if it should be disclosed, but confidential. Row 11 – IPC re: appeals mechanism allowing RSPs who are denied pre-evaluation status to request the reconsideration of the decision Leadership Comments: We considered this during our Appeals discussion and for the following reasons did not adopt an appeals process: (a) Evaluators can ask clarifying questions during process, (b) the remedy for winning a challenge is to be re-evaluated which is what happens anyway during the evaluation period, (c) allotting time for an appeal could delay the commencement of the actual round for applications. Row 14 -- InfoNetworks LLC Leadership Comments: Perhaps rewording stating that the RSP as an RSP is not a contracting party, but if the RSP is a Registry Operator in another context, then it would be one for that other purpose. Row 18 – ICANN org re: Recommendation 6.2: Our understanding is that this would not replace pre-delegation testing (PDT) which tests the technical and operational infrastructure for each gTLD as a prerequisite for delegation. Leadership Comments: Confirm whether this would replace parts of pre-delegation testing. Discussion: -- Was part of the intent of the pre-evaluation was to replace a technical part of the evaluation as well as the need for PDT. -- It was to replace part of the PDT, such as language tables and the ability to do EPP commands. -- May need to delve into this a little more and clarify/confirm the PDT elements it would replace, and what it wouldn’t. -- Not sure we can be more specific than that the pre-evaluation replaces “aspects” of the PDT. Seems to be a judgement call involved here. -- Question: So if PDT is required the RSP will need to be known at the time of submitting the application in order to complete the evaluation process, no? Answer: It has to be known at the time of contracting. -- An idea on PDT: perhaps it be done on a timeline basis that provides that an RSP is only required to submit to testing no more than once every three months and this will be decided by the PDT queue. ACTION ITEMS: 1) specify in more detail which of the elements are required at or around the time of delegation; 2) which elements only need to be evaluated one time and in the pre-delegation process. We may not be able to be specific, so perhaps capture as a principle of streamlining for the IRT to work out the details. Row 18 – ICANN org re: Recommendation 6.5: We understand this Recommendation to suggest that once the registry service provider (RSP) is pre-evaluated, the pre-evaluation status will continue for the duration of the related application round even if substantial issues with the RSP are found during TLD operations. ICANN org seeks guidance on what conditions would allow for a “pre-approval” status to be revoked. Leadership Comments: Just as today once a Registry is approved, there is no revocation, there would be no revocation of an RSP that was successfully re-evaluated. Discussion: -- But if new evaluation criteria appears, that could lead to an update of pre-evaluation. -- Don’t know if there would be new evaluation criteria in the middle of the round. -- Make it clear that an RSP needs to be pre-evaluated during each round. Topic 27: Applicant Reviews<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 10 – GoDaddy Registry re: Require applicant to identify pre-approved RSP in application or delete Recommendation 27.14. Leadership Comments: They were supposed to address their scalability in their application and ICANN has to be satisfied. Row 11 -- Dotzon GmbH Leadership Comments: Discussed that if you are an existing business on one of the financial markets you don't need the financial review, but they are suggesting a new criteria that is not consistent with what the Work Track said/or supported. Row 14 – RrSG re: Include "streamlined application process". Leadership Comments: That seems like a clarification. See if the WG agrees to include Row 16 – ALAC re: “support a permissible level of differential treatment for applicants that apply for Applicant Support which should take into account comment on the question in Topic 17 Applicant Support in respect of whether the scope of financial support for applicants what quality for Applicant Support should be expanded to also costs associated with operating the TLD.” Leadership Comments: ALAC comment makes a good point/clarification. ACTION ITEM: Add a clarification. Row 17 – ICANN org re: states that “Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only).” It’s not clear why this implementation detail should be the subject of generally applicable policy binding on ICANN, and therefore ICANN org suggests recategorizing this Recommendation as Implementation Guidance. ACTION ITEM: Change to Implementation Guidance. Leadership Comments: -- Recommendation 27.5: WG addresses this. If public info then public question, if private then private. Discussion: On clarifying questions: ICANN should have the discretion to redact information they consider confidential. I think the intent of the publishing the CQs was transparency and potentially giving other applicants a 'heads up'. -- Recommendation 27.14: We are talking about scalability. -- Implementation Guidance 27.16: Think we saying that we aren't telling you whether you have a good or bad business model, just how you would handle a business failure. Don’t see the inconsistency with the Implementation Guidance. -- Implementation Guidance 27.18: Need to look at the language. Need to define “default” more clearly and in connection with the 5 critical functions. ACTION ITEM: re: Implementation Guidance 27.18: Define “default” more clearly and in connection with the 5 critical functions. Topic 39: Registry System Testing<https://docs.google.com/spreadsheets/d/1YimiR8dKA2F76QO_36hfDRCFE7-l5syuQ2z…> Row 12 – ICANN org Recommendation 39.1: ACTION ITEM: Include “and its supporting/subcontracted Registry Service Providers (RSPs).” That is to say, the registry system tests should demonstrate the technical capabilities of the registry operator or its supporting RSP, as required. Implementation Guidance 39.5 ACTION ITEM: Clarify by rephrasing “tables that are pre-vetted by the community” to “reference LGRs.”

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 19 November 2020 at 15:00 UTC
by Andrea Glandon Nov. 19, 2020

Nov. 19, 2020

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

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 19 November 15:00 UTC
by Julie Hedlund Nov. 19, 2020

Nov. 19, 2020

Dear Working Group members, Please see below the notes from the working sessions on 19 November at 15:00 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-11-19+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 6: RSP Pre-Evaluation<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 10 – Thomas Barrett (Individual) re: Optional to name selected pre-approved RSP in application; Row 11 – IPC; Row 12 -- PETILLION Law Firm; Row 13 – GoDaddy; Row 19 -- RrSG ACTION ITEM: Send to the WG list the question of whether the recommendations should be updated to clarify that an applicant must select the pre-evaluated RSP and nominate them in the application. Ask also if it should be disclosed, but confidential. Row 18 – ICANN org re: Recommendation 6.2: Our understanding is that this would not replace pre-delegation testing (PDT) which tests the technical and operational infrastructure for each gTLD as a prerequisite for delegation. ACTION ITEMS: 1) specify in more detail which of the elements are required at or around the time of delegation; 2) which elements only need to be evaluated one time and in the pre-delegation process. We may not be able to be specific, so perhaps capture as a principle of streamlining for the IRT to work out the details. Topic 27: Applicant Reviews<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 16 – ALAC re: “support a permissible level of differential treatment for applicants that apply for Applicant Support which should take into account comment on the question in Topic 17 Applicant Support in respect of whether the scope of financial support for applicants what quality for Applicant Support should be expanded to also costs associated with operating the TLD.” ACTION ITEM: Add a clarification. Row 17 – ICANN org re: states that “Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only).” It’s not clear why this implementation detail should be the subject of generally applicable policy binding on ICANN, and therefore ICANN org suggests recategorizing this Recommendation as Implementation Guidance. ACTION ITEM: Change to Implementation Guidance. Re: Implementation Guidance 27.18: Need to look at the language. Need to define “default” more clearly and in connection with the 5 critical functions. ACTION ITEM: re: Implementation Guidance 27.18: Define “default” more clearly and in connection with the 5 critical functions. Topic 39: Registry System Testing<https://docs.google.com/spreadsheets/d/1YimiR8dKA2F76QO_36hfDRCFE7-l5syuQ2z…> Row 12 – ICANN org Recommendation 39.1: ACTION ITEM: Include “and its supporting/subcontracted Registry Service Providers (RSPs).” That is to say, the registry system tests should demonstrate the technical capabilities of the registry operator or its supporting RSP, as required. Implementation Guidance 39.5 ACTION ITEM: Clarify by rephrasing “tables that are pre-vetted by the community” to “reference LGRs.” Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 6: RSP Pre-Evaluation<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Row 10 – Thomas Barrett (Individual) re: Optional to name selected pre-approved RSP in application; Row 11 – IPC; Row 12 -- PETILLION Law Firm; Row 13 – GoDaddy; Row 19 -- RrSG Leadership Comments: Clarify whether recommendations require you to name the operator or just state that you have an operator? In the text of the recommendation we say that you have to say that you are using one, but not name it. Discussion: -- Couple of reasons why this should be mandatory (to name the operator): 1) If you have an applicant that is applying for 20 TLDs and you don’t name your RSP, that could be suspicious; 2) when ICANN org evaluates applications and testing with RSPs re: capacity to manage X number of TLDs, important to know how many TLDs the operator will be supporting. -- If an applicant wanted to change its back-end provider prior to contract would that have to be an application change request, or could it be changed in contracting? Could depend on what the change was – whether it was to another pre-approved RSP. -- There is a benefit to confidentiality regarding an RSP. -- It can still be a factor of consideration if applicants decide to identify their pre-evaluated RSPs voluntarily – if we have a factor about bona fide in the application. -- Don’t put too much weight into having an agreement with an RSP as an intent to operate. When you operate an agreement for one or 2 strings, maybe but when its for 10, 20 50 or 200, its a one time deal. ACTION ITEM: Send to the WG list the question of whether the recommendations should be updated to clarify that an applicant must select the pre-evaluated RSP and nominate them in the application. Ask also if it should be disclosed, but confidential. Row 11 – IPC re: appeals mechanism allowing RSPs who are denied pre-evaluation status to request the reconsideration of the decision Leadership Comments: We considered this during our Appeals discussion and for the following reasons did not adopt an appeals process: (a) Evaluators can ask clarifying questions during process, (b) the remedy for winning a challenge is to be re-evaluated which is what happens anyway during the evaluation period, (c) allotting time for an appeal could delay the commencement of the actual round for applications. Row 14 -- InfoNetworks LLC Leadership Comments: Perhaps rewording stating that the RSP as an RSP is not a contracting party, but if the RSP is a Registry Operator in another context, then it would be one for that other purpose. Row 18 – ICANN org re: Recommendation 6.2: Our understanding is that this would not replace pre-delegation testing (PDT) which tests the technical and operational infrastructure for each gTLD as a prerequisite for delegation. Leadership Comments: Confirm whether this would replace parts of pre-delegation testing. Discussion: -- Was part of the intent of the pre-evaluation was to replace a technical part of the evaluation as well as the need for PDT. -- It was to replace part of the PDT, such as language tables and the ability to do EPP commands. -- May need to delve into this a little more and clarify/confirm the PDT elements it would replace, and what it wouldn’t. -- Not sure we can be more specific than that the pre-evaluation replaces “aspects” of the PDT. Seems to be a judgement call involved here. -- Question: So if PDT is required the RSP will need to be known at the time of submitting the application in order to complete the evaluation process, no? Answer: It has to be known at the time of contracting. -- An idea on PDT: perhaps it be done on a timeline basis that provides that an RSP is only required to submit to testing no more than once every three months and this will be decided by the PDT queue. ACTION ITEMS: 1) specify in more detail which of the elements are required at or around the time of delegation; 2) which elements only need to be evaluated one time and in the pre-delegation process. We may not be able to be specific, so perhaps capture as a principle of streamlining for the IRT to work out the details. Row 18 – ICANN org re: Recommendation 6.5: We understand this Recommendation to suggest that once the registry service provider (RSP) is pre-evaluated, the pre-evaluation status will continue for the duration of the related application round even if substantial issues with the RSP are found during TLD operations. ICANN org seeks guidance on what conditions would allow for a “pre-approval” status to be revoked. Leadership Comments: Just as today once a Registry is approved, there is no revocation, there would be no revocation of an RSP that was successfully re-evaluated. Discussion: -- But if new evaluation criteria appears, that could lead to an update of pre-evaluation. -- Don’t know if there would be new evaluation criteria in the middle of the round. -- Make it clear that an RSP needs to be pre-evaluated during each round. Topic 27: Applicant Reviews<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 10 – GoDaddy re: Require applicant to identify pre-approved RSP in application or delete Recommendation 27.14. Leadership Comments: They were supposed to address their scalability in their application and ICANN has to be satisfied. Row 11 -- Dotzon GmbH Leadership Comments: Discussed that if you are an existing business on one of the financial markets you don't need the financial review, but they are suggesting a new criteria that is not consistent with what the Work Track said/or supported. Row 14 – RrSG re: Include "streamlined application process". Leadership Comments: That seems like a clarification. See if the WG agrees to include Row 16 – ALAC re: “support a permissible level of differential treatment for applicants that apply for Applicant Support which should take into account comment on the question in Topic 17 Applicant Support in respect of whether the scope of financial support for applicants what quality for Applicant Support should be expanded to also costs associated with operating the TLD.” Leadership Comments: ALAC comment makes a good point/clarification. ACTION ITEM: Add a clarification. Row 17 – ICANN org re: states that “Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only).” It’s not clear why this implementation detail should be the subject of generally applicable policy binding on ICANN, and therefore ICANN org suggests recategorizing this Recommendation as Implementation Guidance. ACTION ITEM: Change to Implementation Guidance. Leadership Comments: -- Recommendation 27.5: WG addresses this. If public info then public question, if private then private. Discussion: On clarifying questions: ICANN should have the discretion to redact information they consider confidential. I think the intent of the publishing the CQs was transparency and potentially giving other applicants a 'heads up'. -- Recommendation 27.14: We are talking about scalability. -- Implementation Guidance 27.16: Think we saying that we aren't telling you whether you have a good or bad business model, just how you would handle a business failure. Don’t see the inconsistency with the Implementation Guidance. -- Implementation Guidance 27.18: Need to look at the language. Need to define “default” more clearly and in connection with the 5 critical functions. ACTION ITEM: re: Implementation Guidance 27.18: Define “default” more clearly and in connection with the 5 critical functions. Topic 39: Registry System Testing<https://docs.google.com/spreadsheets/d/1YimiR8dKA2F76QO_36hfDRCFE7-l5syuQ2z…> Row 12 – ICANN org Recommendation 39.1: ACTION ITEM: Include “and its supporting/subcontracted Registry Service Providers (RSPs).” That is to say, the registry system tests should demonstrate the technical capabilities of the registry operator or its supporting RSP, as required. Implementation Guidance 39.5 ACTION ITEM: Clarify by rephrasing “tables that are pre-vetted by the community” to “reference LGRs.”

1 0

Working Group Call with ICANN Board Liaisons on Monday, November 23rd
by Jeff Neuman Nov. 18, 2020

Nov. 18, 2020

All, Yes, we still have a call on Thursday, November 19th at 15:00 UTC and the agenda has been sent out for that. However, we do want to also provide advance notice of the call that will take place on Monday, November 23rd at 20:00 UTC. During that call on Monday, we will have our two SubPro ICANN Board Liaisons, Becky and Avri, on the call to answer our questions on the following topics (though it may not be in this order): * Public Interest Commitments / Registry Voluntary Commitments * Application Change Requests (specifically those added to resolve disputes, objections, etc. by adding PICs/RVCs) * Closed Generics * Auctions / Private Resolution of Contention Sets / Bona Fide Good Faith Intent / Transparency (Donna, Paul and Jim are preparing questions from their small group to ask Avri and Becky) * Community Priority Evaluation * Other topics? For each of these, we will be addressing the ICANN Board comments, and for those, you can look up the links to those topics up on the Work Plan<https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…>. We will also send out the relevant sections to the group after our Working Group call this Thursday. There are a lot of topics on here so we will ask that everyone (a) focus on the Board comments for those topics, (b) ask good clarification questions and listen to the answers, and (c) refrain as much as possible from giving your thoughts or opinions on the matters (since we have had lots of time to do that already). The purpose of the call is to get their thoughts on the comments and on where we take our deliberations from here, not on debating with the Board or advocating our positions 😊 Also please keep in mind that they are Liaisons from the Board and cannot always speak on behalf of the Board. Leadership has briefed both Avri and Becky and have asked them to get clearance on certain comments from the Board, but of course there will be a number of things that they may tell us that they don’t know the Board view or there may not be a Board view yet. That said, this is a great opportunity for all of us and we believe is one of the aspects of SubPro which makes it a unique policy group in its interaction with the Board. Sincerely, Jeff and Cheryl Co-Chairs, SubPro PDP

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 19 November 15:00 UTC
by Julie Hedlund Nov. 17, 2020

Nov. 17, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Thursday, 19 November 2020 at 15:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 6: RSP Pre-Evaluation<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…> Topic 27: Applicant Reviews<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Topic 39: Registry System Testing<https://docs.google.com/spreadsheets/d/1YimiR8dKA2F76QO_36hfDRCFE7-l5syuQ2z…> 1. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Best, Julie Julie Hedlund, Policy Director

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Tuesday, 17 November 2020 at 03:00 UTC
by Terri Agnew Nov. 17, 2020

Nov. 17, 2020

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

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 17 November 03:00 UTC
by Julie Hedlund Nov. 17, 2020

Nov. 17, 2020

Dear Working Group members, Please see below the notes from the working sessions on 17 November at 03:00 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-11-17+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 41: Contractual Compliance<https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS…> Row 13 – ALAC re: Compliance should publish thresholds and guidelines to assess registry/registrar practices. ACTION ITEM: Rec 41.2 – Adding text on the information we are seeking. Staff will consult with leadership on the new wording. Topic 37: Registrar Non-Discrimination / Registry/Registrar Standardization<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> Row 17 – RrSG re: Exempted registries must demonstrate unsuccessful outreach to registrars. ACTION ITEM: Rewrite the recommendation to provide clarity about this recommendation on the impact of .brands. Topic 25: IDNs<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 11 – RySG re: Warn applicant if risk of string never being delegated; consider related work in progress. ACTION ITEM: Revise the recommendation to include the warning for an applicant that there is a risk of a string never being delegated. Row 14 – ICANN Board re: Don't process applied-for strings in script not integrated in the RZ-LGR; assess impacts on other processes; clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing for the new gTLDs. ACTION ITEM: The WG should work on the list to find middle ground on this issue. ACTION ITEM: Provide a rationale as to why the WG considered the Board’s comments on Recommendations 5 and 6 and didn’t address them. Row 15 – ALAC re: Supports offering IDN variants to registry operator of existing/applied for gTLDs, not separate application; metrics to evaluate promotion/availability of IDNs at top level. ACTION ITEM: Add this as Implementation Guidance. ACTION ITEM: Add a reference in the rationale re: offering IDN variants to registry operator of existing/applied for gTLDs, not separate application. Row 16 – ICANN Org re: various issues ACTION ITEM: Clarify definition of 1-character codes in accordance with ICANN Org's comments and what “single entity” means. ACTION ITEM re: “ICANN org notes that the PDP WG has taken into account the Variant TLD Recommendations, and has also identified areas which do not appear to be directly addressed. ICANN org understands that, following the work of the IDN Scoping Team, the GNSO is considering initiating another policy development effort focused on IDNs to address these areas. Until discussion on these additional topics is complete, some details may be unclear around how to proceed with IDN TLDs and variant labels in subsequent rounds. Thus, moving forward with the next round of TLD applications may have some dependency on the GNSO PDP on IDNs.” -- Take this issue to the WG list on this issue and the status of the IDN EPDP, and circle back with the IDN team in ICANN Org. Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 41: Contractual Compliance<https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS…> Row 9 -- Swiss Government OFCOM re: Strengthen compliance enforcement with financial penalties; Rec 41.2 insufficient. Leadership Comments: Do we want to introduce sanctions akin to RAA? Row 10 – IPC; Row 11 – INTA and Row 12 – GBOC (also anti-abuse); Row 19 -- BC re: Strengthen compliance Leadership Comments: Noted. Also related to DNS abuse provisions. Row 13 – ALAC re: Compliance should publish thresholds and guidelines to assess registry/registrar practices. Leadership Comments: Do we want to introduce more transparency into actions taken (and measurements used) for compliance actions that do not result in breach? Discussion: -- Usually these types of comments are closed. Contracted parties wouldn’t want this disclosed. -- Possible action to withhold the name of the entity. -- No clear indication of the thresholds to assess. -- Ask for what is it that ICANN Org is using to assess undesirable behavior by the contracted parties. -- We could add a few words that including the threshold…so long it is not publishing information about the registry operator. -- Question: Are we talking about setting up two compliance programs? We can’t reach backward. Answer: If we added the ALAC action about action, and instead added a few words about what ICANN is already doing then we wouldn’t be making new policy. --- Support introducing standards and thresholds. -- We can address this by adding a few words to the recommendation. ACTION ITEM: Rec 41.2 – Adding text on the information we are seeking. Staff will consult with leadership on the new wording. Row 17 – ICANN Board re: Recommended data is already being published. Leadership Comments: We believe Compliance Dashboard covers our recommendations sufficiently. Row 18 – ICANN Org re: WG should provide specific examples of data to be published and/or examples. Leadership Comment: ICANN Org asks why we believe this is only relevant for next rounds of new gtLDs? Response: We are not saying it is only relevant for the next rounds, but it is outside our scope to recommend anything with respect to legacy TLDs. Topic 37: Registrar Non-Discrimination / Registry/Registrar Standardization<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> Row 10 – BRG re: Supports exemption for .Brand TLD/include in Spec 13. Leadership Comments: Do we grant additional extensions (namely, not having to use a registrar at all)? This was discussed within Work Track, but not carried forward. Row 13 – ICANN Org re: No registrar application in New gTLD application; keep process separate and Row 21 InfoNetworks LLC re: Consider a consolidated Registry/Registrar Agreement. Leadership Comments: Do we want to revisit the notion of allowing both accreditations in same TLD application? Discussion: -- Did not have support in the WG to elevate this to a recommendation. Row 17 – RrSG re: Exempted registries must demonstrate unsuccessful outreach to registrars. Leadership Comments: Do we want to add this clarification (eg., true demonstration of outreach and then if policies change, a re-evaluation of exemption is needed). Discussion: -- Seems to add more clarity to an existing recommendation. -- Don’t see strong support for the exemption. Concern that ICANN’s role is to make the TLDs available, it’s up to the registries to make them successful. -- Comments were lukewarm. -- Goes back to what the BRG said. -- With .brands, we have never proposed getting rid of the exemption for Spec 13. Not sure that this question that was out for community input would affect .brands. -- The action item here is to provide clarification of the impact on .brands from this recommendation. ACTION ITEM: Rewrite the recommendation to provide clarity about this recommendation on the impact of .brands. Topic 38: Registrar Support for New TLDs<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> Row 10 – InfoNetworks LLC re: Registrars without an RAA shouldn't be able to object to proposed RAA amendments. Leadership Comments: New idea: Limit Registrars review of RRA Amendments to only those Registrars that have signed the RRA, (Include with Base Agreement discussion). Probably just affect existing TLDs and not new TLDs. Topic 25: IDNs<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 8 – Anthony Lee and other comments re: Continue to develop a mechanism that also takes the concerns of both the SSAC and Joint ccNSO-GNSO IDN Workgroup reports into consideration. Overarching Leadership Comment: Consider referring all of our recommendations to the GNSO IDN Scoping Team for including in their PDP. Row 9 -- Wei Wang (Individual) re: Waiving application fees of IDN gTLD variant and existing/applied IDN gTLD with same registry operator. Leadership Comments: Noted. Row 10 – IAB Leadership Comments: Noted. Row 11 – RySG re: Warn applicant if risk of string never being delegated; consider related work in progress. Leadership Comments: Warning sounds like a good clarification recommendation; See above on referring all recommendations to IDN Groups to consider. ACTION ITEM: Revise the recommendation to include the warning for an applicant that there is a risk of a string never being delegated. Row 12 – WIPO re: Domain abuse by homograph spoofing. Leadership Comments: This is an issue for IDN Group, RPM PDP and future DNS Abuse efforts. Row 12 – RrSG re: Vet IDN tables/variants prior to delegation, not outright rejection. Leadership Comments: Could this be part of the RSP Pre-approval process? -- We don’t talk about the tables being rejected. Row 14 – ICANN Board re: Don't process applied-for strings in script not integrated in the RZ-LGR; assess impacts on other processes; clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing for the new gTLDs. Leadership Comments: -- Review Recommendations 5 and 6 of Variant TLD Recommendations? The Board asks the PDP WG to clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing for the new gTLDs. The Board suggests that the PDP WG considers Reference IDN tables being published by ICANN org as the candidate pre-vetted IDN tables. (Pg. 178) ACTION ITEM: The WG should work on the list to find middle ground on this issue. ACTION ITEM: Provide a rationale as to why the WG considered the Board’s comments on Recommendations 5 and 6 and didn’t address them. Discussion: -- Board suggestion is different from the WG’s recommendation. -- Not sure how realistic the Board suggestion is. -- Would be difficult to do the evaluation if the RZL isn’t part of the rules. -- We discussed this at some length didn't we? I understand ICANN Board's desire for efficiency, but weren't we balancing out others who may be caught up in contention sets or want to file objections? -- The idea of having the RZ generation rules was that you could have a situation where you were using the rules is that you needed to have some rules for those that weren’t in the RZ generation rules. -- Is there a way to do both? The applicant would be entering contention at its own risk. It should be able to go through a number of steps until the RZ generation rules are finalized. -- For a string in a script that is not part of the RZ-LGR, there is no guarantee it will ever be valid. ACTION ITEM: The WG should work on the list to find middle ground on this issue. Row 15 – ALAC re: Supports offering IDN variants to registry operator of existing/applied for gTLDs, not separate application; metrics to evaluate promotion/availability of IDNs at top level. Leadership Comments: Noted. Discussion: -- Question: What does it mean: “and the corresponding level of assignment of ICANN staff support and evaluators”? This seems like an IRT issue. This will be noted by IRT. -- To be a meaningful measure then staff commitment comparison to other non IDNs need to be looked at as well NEW and yes Implementation. -- Question: Will this go to the IRT? ACTION ITEM: Add this as Implementation Guidance. ACTION ITEM: Add a reference in the rationale re: offering IDN variants to registry operator of existing/applied for gTLDs, not separate application. Row 16 – ICANN Org re: various issues Leadership Comments: -- Does the Working Group want to specify that unless and until new IDN rules are finalized, that it not hold up subsequent rounds, which will apply existing rules (eg., not allow variants). -- In the same token, should this group formally refer issues of "(a) the process by which an existing registry operator could apply for, or be given, an IDN variant for its existing gTLD; and (b) the process by which an applicant applying for a new IDN gTLD could seek and obtain any allocatable IDN variant(s) ICANN Org does not believe any string should be processed if the Label Generation Rules for that script are not integrated into the RZ-LGR; AND that these applications should not hold up other ones that are integrated. -- Clarify definition of 1 character codes in accordance with ICANN Org comments. Clarify what Single entity means. ACTION ITEM: Clarify definition of 1-character codes in accordance with ICANN Org's comments and what “single entity” means. ACTION ITEM re: “ICANN org notes that the PDP WG has taken into account the Variant TLD Recommendations, and has also identified areas which do not appear to be directly addressed. ICANN org understands that, following the work of the IDN Scoping Team, the GNSO is considering initiating another policy development effort focused on IDNs to address these areas. Until discussion on these additional topics is complete, some details may be unclear around how to proceed with IDN TLDs and variant labels in subsequent rounds. Thus, moving forward with the next round of TLD applications may have some dependency on the GNSO PDP on IDNs.” -- Take this issue to the WG list on this issue and the status of the IDN EPDP, and circle back with the IDN team in ICANN Org.

1 0

Proposed edits to Recommendation 9.1 re: Category 1 Safeguards
by Levine, Gertrude Nov. 16, 2020

Nov. 16, 2020

Hi all, In last Thursday's SubPro meeting, we discussed Topic 9: Category 1 Safeguards - in particular, Recommendation 9.1, which reads, in part, as follows: "Mandatory Public Interest Commitments (PICs) currently captured in Specification 11 3(a)-(d) of the Registry Agreement must continue to be included in Registry Agreements for gTLDs in subsequent procedures. ..." The section in question was Specification 11 3(a): Specification 11 3(a)-(d): 3. Registry Operator agrees to perform the following specific public interest commitments, which commitments shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process . . . (a) Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name. As we discussed in the meeting, Specification 11 3(a) as currently written falls short of its intended purpose, protecting end users. It is therefore necessary to revise Specification 11 3(a) to hold new TLDs that are subject to Category 1 Safeguards accountable for their registrants' contractual compliance with those safeguards. Existing TLDs could be grandfathered as exempt from the Specification 11 3(a) revision. It seems there was some interest among the working group members to further explore this idea. I would propose changing Recommendation 9.1 in the final report to add the underlined text below: "Mandatory Public Interest Commitments (PICs) currently captured in Specification 11 3(a)-(d) of the Registry Agreement must continue to be included in Registry Agreements for gTLDs in subsequent procedures." In addition, Specification 11 3(a) should be revised to hold new TLDs that are subject to Category 1 Safeguards accountable for their registrants' contractual compliance with those safeguards. Existing TLDs could be grandfathered as exempt from the Specification 11 3(a) revision. I'd be interested to hear others' thoughts. Thanks, Gg Gertrude "Gg" Levine Digital Health Manager 847/391-4497 [cid:image002.png@01D6BC2D.DF198470]National Association of Boards of Pharmacy 1600 Feehanville Dr, Mount Prospect, IL 60056 www.nabp.pharmacy<http://www.nabp.pharmacy/> | glevine(a)nabp.pharmacy<mailto:glevine@nabp.pharmacy> [cid:image003.png@01D6BC2D.DF198470]<https://www.facebook.com/NABP1904/> [cid:image004.png@01D6BC2D.DF198470]<https://twitter.com/nabp> [cid:image005.png@01D6BC2D.DF198470]<https://www.linkedin.com/company/national-association-of-boards-of-pharmacy/> [cid:image006.png@01D6BC2D.DF198470]<https://www.youtube.com/c/NationalAssociationofBoardsofPharmacy>

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 17 November 03:00 UTC
by Julie Hedlund Nov. 12, 2020

Nov. 12, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Tuesday, 17 November 2020 at 03:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 41: Contractual Compliance<https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS…> Topic 37: Registrar Non-Discrimination / Registry/Registrar Standardization<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> Topic 38: Registrar Support for New TLDs<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> Topic 25: IDNs<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> 1. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Best, Julie Julie Hedlund, Policy Director

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 12 November 20:00 UTC
by Julie Hedlund Nov. 12, 2020

Nov. 12, 2020

Dear Working Group members, Please see below the notes from the working sessions on 12 November 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-11-12+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 34: Community Applications<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> ACTION ITEM: WG members are requested to review the notes from the three sessions on the CPE Guidelines: https://community.icann.org/display/NGSPP/2020-09-17+New+gTLD+Subsequent+Pr…, https://community.icann.org/display/NGSPP/2020-09-24+New+gTLD+Subsequent+Pr…, https://community.icann.org/display/NGSPP/2020-10-01+New+gTLD+Subsequent+Pr…. Row 18 – ALAC re: (1) A need for greater community participation in ICANN’s engagement of a CPE service provider/panellists, namely in 4 aspects: (i) the development of criteria by which ICANN Org is to evaluate and select candidates; (ii) the shortlisting of identified candidates; (iii) the final selection process; and (iv) the terms for inclusion into the contract between ICANN Org and the selected candidate. ACTION ITEM: Take the ALAC 1(ii-iv) comments to the list for discussion. Notes: 1. Updates to Statements of Interest: -- Javier Rua has made some updates to his SOI. He has moved from ALAC to the ccNSO. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 9: RVC/PICS<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> Concerns about exemptions/waivers (Spec 11 3(s) and 3(b)): Row 10 -- Thomas Barrett (Individual) re: Exemptions/waivers: Concerns about exemptions/waivers for single-registrant TLDs for Spec 11 3(a) and 3(b); Row 12 – NABP re: stronger enforcement needed; Row 15 – BC; Row 27 -- Dotzon GmbH; Row 31 – ICANN Org Discussion: -- The exemptions aren’t necessarily tied to a single registrant TLD. -- Discuss whether this matters. Does the same rationale exists for the .brand TLDs if they aren’t a single-registrant TLD? -- Seem to be a good grouping of those who accept the wording as is. -- Recommendation and rationale don’t mention Spec 13. Wording seems good as is. -- No WG action noted. Content enforcement/conflicts with Bylaws: Rows 11 and 23 – NCSG; Row 29 – Board Leadership Comments: This will be covered in the discussions with ICANN Board Liaisons to solution within the Working Group. -- Hold for discussion with Board Liaisons. Strong enforcement needed: Row 12 – NABP; Row 13 -- Swiss Government OFCOM; Row 21 – RrSG; Row 30 -- GAC Leadership Comments: This also relates to topic from last week on Base Agreement where provisions only require that provisions documented in RRA, not actually doing it. Do we want to revise the recommendation to also include compliance of the PICs?; Consider limiting waiver of PICs to only those true single entity Spec 13 and Spec 9 CoC exemptions. -- Could there be a simpler mechanism to bring a complaint, other than the PICDRP. -- Will come back to this discussion in relation to the PICs and Bylaws conflicts. DNS Abuse: Row 13 -- Swiss Government OFCOM; Row 14 – IPC; Row 14 – BC; Row 16 – INTA; Row 17 – GBOC; Row 20 – ALAC; Row 30 – GAC -- Reminder that SubPro filed a letter with the Council that this should be handled in a holistic manner and is beyond the scope of this PDP. -- Some groups did not like this decision (GAC, ALAC). -- Nothing for the WG to do on the DNS abuse comments at this point. Topic 34: Community Applications<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> Definition of Community: -- Noted those comments. -- Address by providing more flexibility in the Guidelines (see notes from sessions during public comment period: https://community.icann.org/display/NGSPP/2020-09-17+New+gTLD+Subsequent+Pr…, https://community.icann.org/display/NGSPP/2020-09-24+New+gTLD+Subsequent+Pr…, https://community.icann.org/display/NGSPP/2020-10-01+New+gTLD+Subsequent+Pr… Row 11 -- Swiss Government OFCOM; Row 14 -- InfoNetworks LLC; Row 16 -- fTLD Registry Services, LLC re: threshold too high in 2012. Row 11 -- Swiss Government OFCOM re: New idea: Provide support for non-profit community-based applications. Leadership Comments: This is a new proposal. -- No WG action noted. Row 16 -- fTLD Registry Services, LLC Leadership Comments: Discuss the role of application change requests and community based applications. We did not conclude the discussion on whether there are any sections in the Application which should not be allowed to have material changes. -- No WG action noted. Row 18 – ALAC re: (1) A need for greater community participation in ICANN’s engagement of a CPE service provider/panellists, namely in 4 aspects: (i) the development of criteria by which ICANN Org is to evaluate and select candidates; (ii) the shortlisting of identified candidates; (iii) the final selection process; and (iv) the terms for inclusion into the contract between ICANN Org and the selected candidate. Discussion: -- Why would we not want community involvement? -- There could be increased bureaucracy or bias. -- I don't know what "greater community participation" means. Isn't that what we are doing now and what the IRT will do? Haven't we already developed analogous mechanisms like the selectors for the IRP standing panel? ACTION ITEM: Take the ALAC 1(ii-iv) comments to the list. Row 19 – Board re: recommendations should be more detailed. Leadership Comments: Reflect larger discussion of ICANN Bylaws issues. This relates to discussions we had during Public Comment Period Row 21 – ICANN Org Leadership Comments: On changing the Principles: We accept that in 2012 ICANN staff decided to outsource the evaluation of CPE. Whether ICANN decides to outsource those evaluations or not is a decision for ICANN Org so long as the recommendations in the report are carried out. Re - Efficiency, transparency and predictability, we have made a number of recommendations including: - All rules published in advance, including those used by evaluators to assess criteria, - There must be a verification of those entities that support and oppose Community Status - We have added clarity to CPE Guidelines. - We have encouraged more dialogue - Evaluators must disclose all outside research and give applicant chance to comment - We have added a challenge process - We have synchronized the public comment periods Question: Can we limit the potential Accountability Mechanism challenges?

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 12 November 2020 at 20:00 UTC
by Andrea Glandon Nov. 12, 2020

Nov. 12, 2020

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

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 12 November 20:00 UTC
by Julie Hedlund Nov. 9, 2020

Nov. 9, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Thursday, 12 November 2020 at 20:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 9: RVC/PICS<https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AG…> Topic 34: Community Applications<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> 1. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Best, Julie Julie Hedlund, Policy Director

1 0

Post Call | New gTLD Subsequent Procedure Working Group call | Monday, 09 November 2020 at 15:00 UTC
by Michelle DeSmyter Nov. 9, 2020

Nov. 9, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 09 November 2020 at 15:00 UTC can be found on the agenda wiki page <https://community.icann.org/display/NGSPP/2020-11-09+New+gTLD+Subsequent+Pr…> (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