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

Post Call | New gTLD Subsequent Procedures Working Group | Monday, 29 June 2020 at 15:00 UTC
by Terri Agnew June 29, 2020

June 29, 2020

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

June 29, 2020

Dear Working Group members, Please see below the notes from the meeting on 29 June 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-06-29+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: "Can't Live With" comments on Package 5: 2.4 Application Change Requests Proposed new Implementation Guidance: Implementation Guidance xx (rationale 3) ACTION ITEM: Accept the change from Justine to include text in brackets, “Insofar as it is feasible, ICANN org should explore the possibility of allowing applicants to delay [by 60-90 days] evaluation of relevant applications pending early submission [prior to their own] of an applicant change request on the basis of business combination or other forms of joint ventures, so as to facilitate evaluation (instead of re-evaluation) of the new combined venture or entity, in an effort to save time and cost.” Also make consistent the text in Rationale for Recommendation xx (rationale 3). Recommendation xx (rationale 4): [Suggested edit to the preceding sentence: [Applicants of .Brand strings will be given the opportunity to continue with the application process for a change in string that is linked to their brand without the need for an auction of last resort to resolve contention, contingent on process guardrails which ensure that changes in the applied-for string occur only under narrow circumstances, limit impact on the New gTLD Program more broadly, and are subject to public comment and objections processes.] ACTION ITEM: The WG agrees to the change. 2.8.1 GAC Consensus Advice and GAC Early Warning Rationale for recommendation xx (rationale 6): ACTION ITEM: Revise the text with text in brackets: Application changes would be subject to [public comment and] evaluation by ICANN as discussed in section xx Application Change Requests.” 2.5.4 Applicant Support Recommendation xx (rationale 2): ACTION ITEM: Revise the text to include text in brackets and strikeout: “In addition, the Working Group recommends that ICANN continue to facilitate [and promote] non-financial assistance including the provision of pro-bono assistance to applicants in need.” [ICANN will provide educational materials and outreach during the communications period to both the applicants and potential providers of pro bono services.] Also, update Rationale for Affirmation xx with modification (rationale 2). Recommendation xx (rationale 4) Implementation Guidance xx (rationale 4) ACTION ITEM: Revise the text with text in brackets: “The Working Group recommends that ICANN improve outreach, awareness-raising, application evaluation, and program evaluation elements of the Applicant Support Program, [as well as usability of the Applicant Support Program] as proposed in the Implementation Guidance below.” ACTION ITEM: Revise the text with the text in brackets: “In implementing the Applicant Support Program for subsequent rounds, the dedicated Implementation Review Team should draw on experts with relevant knowledge, including from the targeted regions, to develop appropriate program elements related to outreach, education, [business case development,] and application evaluation. Regional experts may be particularly helpful in providing insight on the [development] of business plans from different parts of the world.” Also, update Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 4). c. New issues raised in deliberations since publication of the Initial Report, if applicable. [Proposed additional paragraph: The Working Group considered a comment submitted by the ALAC during the call for public comments to the Initial Report which proposed for an applicant that qualifies for ASP to be given priority in any string contention set, and not be subjected to any further string contention resolution process. While the Working Group noted that applicants which apply for applicant support would consider themselves as applicants in need of financial support and therefore less likely to possess the financial wherewithal to succeed in an auction of last resort, the Working Group did not come to an agreement on the ALAC’s proposal. Instead, the Working Group preferred to consider the ALAC’s secondary proposal for the provision of a multiplier (or equivalent) to help applicants which qualified for applicant support to effectively ACTION ITEM: Integrate concept with content about the multiplier/bid credit -- to be added to ASP section and released with package 7. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Complete review of "Can't Live With" comments on Package 5, start on page 95: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> 2.4 Application Change Requests [Proposed new Implementation Guidance: Implementation Guidance xx (rationale 3): Insofar as it is feasible, ICANN org should explore the possibility of allowing applicants to delay evaluation of relevant applications pending early submission of an applicant change request on the basis of business combination or other forms of joint ventures, so as to facilitate evaluation (instead of re-evaluation) of the new combined venture or entity, in an effort to save time and cost.] C5.6 - Justine Chew proposed adding new Implementation Guidance. Rationale: "In the interest of transparency and predictability, it should be clarified if application change requests are allowed immediately after close of the application period and when all applied-for strings and corresponding applicants are revealed. Where permissible, we should consider allowing applicants which have applied for exactly matching strings or strings which in their belief run the risk of being confusingly similar an opportunity to delay their evaluation/reviews pending submission of an applicant change request on the basis of business combination or other forms of joint ventures. Having to evaluate just the new combined venture or entity will help avoid need for re-evaluation, also save time and costs. Withdrawals of application and corresponding refunds should be allowed." Discussion: -- Any suggestions for the amount of time for the delay. -- Clarify that an applicant could delay his/her own application. -- Suggest a an applicant could ask for a delay of 60-90 days. -- Define “early” in “pending early submission”. ACTION ITEM: Accept the change from Justine to include text in brackets, “Insofar as it is feasible, ICANN org should explore the possibility of allowing applicants to delay [by 60-90 days] evaluation of relevant applications pending early submission [prior to their own] of an applicant change request on the basis of business combination or other forms of joint ventures, so as to facilitate evaluation (instead of re-evaluation) of the new combined venture or entity, in an effort to save time and cost.” Also make consistent the text in Rationale for Recommendation xx (rationale 3). Recommendation xx (rationale 4): [Suggested edit to the preceding sentence: [Applicants of .Brand strings will be given the opportunity to continue with the application process for a change in string that is linked to their brand without the need for an auction of last resort to resolve contention, contingent on process guardrails which ensure that changes in the applied-for string occur only under narrow circumstances, limit impact on the New gTLD Program more broadly, and are subject to public comment and objections processes.] JC5.8 - Justine Chew proposed editing the preceding sentence - underlined text is new. Rationale: "For greater comfort, the sentence “Applicants will be given the opportunity to continue with the application process for a string linked to their brand without the need for an auction of last resort to resolve contention.” must be expressly tied to a .Brand context and contingent on the process guardrails described. As it stands, that sentence is too open-ended." ACTION ITEM: The WG agrees to the change. 2.8.1 GAC Consensus Advice and GAC Early Warning Rationale for recommendation xx (rationale 6): KK5.6 - Kathy Kleiman proposed adding the words "and the Community" to this sentence. Rationale: "Should not be controversial; many application changes reviewed by ICANN are also reviewed by the Community. Just clarifying here." ACTION ITEM: Revise the text with text in brackets: Application changes would be subject to [public comment and] evaluation by ICANN as discussed in section xx Application Change Requests.” 2.5.4 Applicant Support Recommendation xx (rationale 2): [Proposed alternate text to the preceding sentence: In addition, the Working Group recommends that ICANN proactively manage the pro bono assistance program by not only encouraging the provision of non-financial pro-bono assistance but also by coordinating communication in respect of the provision of pro-bono assistance to and uptake by applicants in need.] JC5.9 - Justine Chew proposed alternate text to the preceding sentence. Rationale: "In addition, the Working Group recommends that ICANN proactively manage the pro bono assistance program by not only encouraging the provision of non-financial pro-bono assistance but also by coordinating communication in respect of the provision of pro-bono assistance to and uptake by applicants in need." Discussion: -- Be careful that ICANN Org is not assisting applicants. Passive language would be better. -- Education and promotion is fine, but should be delivered generally and transparently. -- Add “In addition, ICANN Org will publicize the program and provide educational materials for applicants who qualify for support.” -- The solution lies in outreach. Add a clause “including ICANN Org making the need for pro bono assistance known throughout the legal community.” -- Needs to be outreach to vendors that can provide that support. What is our timing? The communications period is described in that section – a least 6 months. ACTION ITEM: Revise the text to include text in brackets and strikeout: “In addition, the Working Group recommends that ICANN continue to facilitate [and promote] non-financial assistance including the provision of pro-bono assistance to applicants in need.” [ICANN will provide educational materials and outreach during the communications period to both the applicants and potential providers of pro bono services.] Also update Rationale for Affirmation xx with modification (rationale 2). Recommendation xx (rationale 4): The Working Group recommends that ICANN improve [utility,] outreach, awareness-raising, application evaluation, and program evaluation elements of the Applicant Support Program, as proposed in the Implementation Guidance below. JC5.11 - Justine Chew proposed adding the word "utility." Rationale: "At-Large considers the element of education around viable business models for applicants as identified by the AMGlobal Study is also important to increase the utility of the ASP for potential ASP applicants." And Implementation Guidance xx (rationale 4): In implementing the Applicant Support Program for subsequent rounds, the dedicated Implementation Review Team should draw on experts with relevant knowledge, including from the targeted regions, to develop appropriate program elements related to outreach, education [(including education on business models, for e.g. through different business case studies)], and application evaluation. Regional experts may be particularly helpful in providing insight on the evaluation of business plans from different parts of the world. JC5.12 - Justine Chew proposed adding the highlighted text to this sentence. Rationale: "The proposed change corresponds to the change to the above the above Recommendation xx (rationale 4)." - see JC5.11. ACTION ITEM: Revise the text with text in brackets: “The Working Group recommends that ICANN improve outreach, awareness-raising, application evaluation, and program evaluation elements of the Applicant Support Program, [as well as usability of the Applicant Support Program] as proposed in the Implementation Guidance below.” ACTION ITEM: Revise the text with the text in brackets: “In implementing the Applicant Support Program for subsequent rounds, the dedicated Implementation Review Team should draw on experts with relevant knowledge, including from the targeted regions, to develop appropriate program elements related to outreach, education, [business case development,] and application evaluation. Regional experts may be particularly helpful in providing insight on the [development] of business plans from different parts of the world.” Also, update Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 4). Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 6): There will need to be a clear plan in place for funding the Applicant Support Program. ICANN will need to evaluate the extent to which funds will be provided from the ICANN org budget and if additional funding is needed, should consider additional funding sources. [Proposed additional sentence: In this respect, ICANN org should actively inform, encourage and liaise with National banks and aid agencies worldwide to participate in sponsoring applicants or funding for the Applicant Support Program, as well as to take steps to structure a mechanism to implement joint financing.] JC5.14 - Justine Chew proposed adding this sentence to the end of the paragraph. Rationale: "Securing funding for the ASP is critical to its chance for success. In anticipation of more applicants for ASP in the next round, there should be concerted effort to raise more than the USD2mil allocated in the last round. In this respect, stronger language with more concrete exploratory steps is needed to compel securing of such funding." Discussion: -- This looks like Implementation Guidance, not rationale. It is very specific. -- This seems to be beyond scope. -- There already is Implementation Guidance relating to this. -- This could be raised in public comments. c. New issues raised in deliberations since publication of the Initial Report, if applicable. [Proposed additional paragraph: The Working Group considered a comment submitted by the ALAC during the call for public comments to the Initial Report which proposed for an applicant that qualifies for ASP to be given priority in any string contention set, and not be subjected to any further string contention resolution process. While the Working Group noted that applicants which apply for applicant support would consider themselves as applicants in need of financial support and therefore less likely to possess the financial wherewithal to succeed in an auction of last resort, the Working Group did not come to an agreement on the ALAC’s proposal. Instead, the Working Group preferred to consider the ALAC’s secondary proposal for the provision of a multiplier (or equivalent) to help applicants which qualified for applicant support to effectively JC5.15 - Justine Chew proposed adding a new paragraph. Rationale: "Reference to the ALAC/At-Large proposal that an applicant that qualifies for ASP be given priority in any string contention set, and not be subjected to any further string contention resolution process is omitted. Unsure if this omission was intended because of the latest deliberation on a multiplier/bid credit for applicants which qualify for ASP." ACTION ITEM: Integrate concept with content about the multiplier/bid credit -- to be added to ASP section and released with package 7. 3. Private Resolutions: Hybrid Proposal 2+ and Proposal 4: https://docs.google.com/document/d/1X8F8zHkgMzQg2WqGHpuoEP78rhpDkFOjD2qKrZZ… [docs.google.com]<https://docs.google.com/document/d/1X8F8zHkgMzQg2WqGHpuoEP78rhpDkFOjD2qKrZZ…> Discussion: -- Support – reflects the reality on the ground. -- How do we enforce that? Who is going to determine if intent is bona fide or not? -- What if an applicant changes their mind once they see the other applications? This is too easily gamed. -- What is the purpose of preserving private auctions. Why are they so critical to this program? (aside from allowing large portfolio players to game this). -- Penalize for next round? Why not penalize "this" round? Bad actor can reconstitute in many ways to participate in the next round - how do we police that? -- Without taking a position on the substance, and agreeing that bad intent should not be assumed, we should be realistic about the ability to enforce any attestation of intent. -- Would people agree in restricting private resolution to Brand TLDs ? -- People are going to game – try find a way to allow this to work. Try to put in guardrails to minimize the gaming. -- ICANN endorsing the concept of private auctions up front is a dangerous path in this this environment. Too big a spot light on them. You do Vickery up front - its transparent and takes out the possibility of all the collusions. -- Complete transparency will limit gaming. Requiring all details of private resolution with ICANN (and potentially the community) Failure to be transparent will result in penalty and disclosure. -- If we say that everything must be disclosed – to ICANN if not also to the community? Consider the proposal of transparency. Could allow us to gather data (which we could not do next time). -- Think about this in the context of the benefits to the community. 

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 29 June at 15:00 UTC for 90 Minutes
by Julie Hedlund June 26, 2020

June 26, 2020

Dear all, Please find below the proposed agenda for the WG meeting on Monday, 29 June 2020 at 15:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Complete review of "Can't Live With" comments on Package 5, start on page 95: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 3. Private Resolutions: Hybrid Proposal 2+ and Proposal 4: https://docs.google.com/document/d/1X8F8zHkgMzQg2WqGHpuoEP78rhpDkFOjD2qKrZZ… 4. 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>. Kind regards, Julie

1 0

Re: [Gnso-newgtld-wg] Deadline 30 June - Comments on Revised Draft Recommendations - Package 6
by Steve Chan June 26, 2020

June 26, 2020

Dear WG Members, We hope you all had a productive ICANN68 meeting. This is a friendly reminder to review Package 6 and if applicable, provide any “cannot live with” input by Tuesday 30 June at 23:59 UTC. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Emily Barabas <emily.barabas(a)icann.org> Date: Friday, June 19, 2020 at 12:15 PM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Deadline 30 June - Comments on Revised Draft Recommendations - Package 6 Dear all, The leadership team is releasing the sixth set of revised draft recommendations for your review. There are 6 topics in package 6 here, beginning on page 117: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com] · 2.2.4 Different TLD Types (last discussed on 23 Apr) · 2.2.8 Conflicts of Interest (this is new section, but the recommendation contained in it was discussed on 9 Apr under topic Objections) · 2.6.1 Application Queuing (last discussed on 8 Jun) · 2.7.3 Closed Generics (last discussed on 14 May) · 2.8.1 Objections (last discussed on 9 Apr) · 2.9.1 Community Applications (last discussed on 8 Jun) Please limit comments to items in the revised sections that you absolutely “cannot live with.” If there is text that you cannot accept, please fill out the attached form and send it to the WG by email. Please do not provide your input in any other format. Deadline for comments is Tuesday 30 June at 23:59 UTC Comments will be tracked here: https://community.icann.org/x/JDKJBw. Kind regards, Emily

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 25 June 2020 at 20:00 UTC
by Julie Bisland June 25, 2020

June 25, 2020

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

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 25 June at 20:00 UTC
by Julie Hedlund June 25, 2020

June 25, 2020

Dear Working Group members, Please see below the notes from the meeting on 25 June 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-06-25+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Predictability Framework: The SPIRT may develop policy and undermine Council remit. ACTION ITEM: Revised to include the bracketed text: “The SPIRT’s functions include issue triage and providing advice on operational issues. It is not a policy-making body [and will not knowingly develop policy]. ACTION ITEM: Update the table on page 8. ACTION ITEM: Revise to include the bracket text: “The SPIRT’s functions include issue triage and providing advice on [non-minor] operational issues.” The SPIRT could be subject to the influence of lobbying (e.g., targeting other applications, re-opening issues, invoking the Framework in the first place, other?). ACTION ITEM: Add “The SPIRT cannot assign itself work; it must be assigned by the GNSO Council, the ICANN Board, or ICANN org. ICANN Org will be able to make certain decisions on its own without consulting with the community (i.e., bucket 1). This could include mis-categorizing an issue (either purposely or as a matter of subjectivity). ACTION ITEM: Add -- A recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions). -- Council maintains a supervisory role over the SPIRT. -- All recommendations are subject to the review and oversight of the GNSO Council, who maintains the discretion on whether or not to adopt the recommendations made to the Council. It is unclear why the SPIRIT is better positioned compared to others in determining what is policy versus implementation. ACTION ITEM: Add as IG about making the Framework and SPIRIT clear. Determining which ”bucket” something is in will not always be clear. ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions). The Framework and SPIRT are too complicated and GAC Concern [it is not clear that they create value versus existing mechanisms for issue mitigation.] ACTION ITEM: Create a “PR” document. GAC Concern - The Framework and SPIRT may undermine existing roles and responsibilities afforded to the ICANN organizations under the ICANN Bylaws. ACTION ITEM: Add “The SPIRIT is representative.” ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions). "Can't Live With" comments on Package 5: 2.8.2 Limited Challenge/Appeal Mechanism a. Recommendations and/or implementation guidelines Affirmation xx (rationale 1): [Proposed alternate text to Affirmation xx (rationale 1), in order to match text in section Objections: Affirmation xx with modification (rationale 1): Recommendation 12 from 2007 states: “Dispute resolution and challenge processes must be established prior to the start of the process.” Consistent with Implementation Guidance xx below, the Working Group affirms Recommendation 12 with the following modification in italicized text: “Dispute resolution and challenge processes must be established prior to the start of the process, the details of which must be published in the Applicant Guidebook.”] ACTION ITEM: The WG agreed to adopt the revised text. Recommendation xx (rationale 2): The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that [are] [appear to be] inconsistent with the Applicant Guidebook. ACTION ITEM: The WG agreed to include the bracketed language. “The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and [formal] objections decisions” KK5.2 - Kathy Kleiman proposed adding the word "formal" to this sentence. Rationale: "The term “formal objection” comes from the current AGB (see current Module 3) and it may help to flag readers to understand the important distinction of evaluation changes and objection appeals – a clarity issue." ACTION ITEM: The WG agreed to include the bracketed language, but make sure we are being consistent in our report. Implementation Guidance xx (rationale 5): ACTION ITEM: Change Annex xx to add the ability of challenging “standing” as a ground for appeal. Implementation Guidance xx (rationale 6): ACTION ITEM: The WG agrees to the change to "New panel with different RSTEP panelists selected from the standing roster." Implementation Guidance xx (rationale 7): ACTION ITEM: Check in the AGB to see how that situation is handled and add to the rationale. Rationale for Affirmation xx (rationale 1): ACTION ITEM: The WG agrees to the update based on previous suggestion from Justine. Rationale for Implementation Guidance xx (rationale 4): In general, the Working Group believes that parties affected by an evaluation or objections decision should have the opportunity to file a challenge/appeal [under limited circumstances]. The affected parties for each type of evaluation and objection under different circumstances are outlined in Annex xx. ACTION ITEM: The WG agrees to include the text in brackets. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Continue to review the Predictability Framework, see: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT… and the attached chart. General Discussion: -- Concerns about not having time to review the document. -- Make sure we are following the rules for IRT. We did incorporate that into the framework document. -- SPIRT should be the screening tool for everything that arises, not staff. The SPIRT may develop policy and undermine Council remit. -- Could we add a bullet that says the SPIRIT will not knowingly develop Policy. -- re: “The SPIRT’s functions include issue triage and providing advice on operational issues. It is not a policy-making body.” How does "operational issues" reconcile with "operational changes"? Is the table on page 8 outdated --- yes. -- So back to the 2nd bullet mitigation for the 1st concern .... should it be ....."NON-MINOR operational issues"? ACTION ITEM: Revise to include the bracketed text: “The SPIRT’s functions include issue triage and providing advice on operational issues. It is not a policy-making body [and will not knowingly develop policy]. ACTION ITEM: Update the table on page 8. ACTION ITEM: Revise to include the bracket text: “The SPIRT’s functions include issue triage and providing advice on [non-minor] operational issues.” The SPIRT could be subject to the influence of lobbying (e.g., targeting other applications, re-opening issues, invoking the Framework in the first place, other?). -- Missing from the mitigation about lobbying – SPIRT cannot assign itself work. ACTION ITEM: Add “The SPIRT cannot assign itself work; it must be assigned by the GNSO Council, the ICANN Board, or ICANN org. ICANN Org will be able to make certain decisions on its own without consulting with the community (i.e., bucket 1). This could include mis-categorizing an issue (either purposely or as a matter of subjectivity). -- Every decision should involve the SPIRT before ICANN Org would implement it – that is, ICANN Org would not be able to make any implementation decisions. -- Concerns about the SPIRT becoming a bottleneck. -- Could be a change log. -- But the notion that you are going to have staff determining when an issue arises whether it should be referred to the SPIRT or not brings us back to the original problem. -- We tend to think of major changes, but the WG should think about changes like last time where ICANN Org created a custom-made ticketing system for support, but it didn’t work so ICANN Org went to an off-the-shelf software. Do we really want the SPIRT to make that decision? -- Suggest that when staff "encounters an issue" during the implementation phase, they need to advise GNSO Council and the SPIRT of the change. -- Could add that “The GNSO Council retains review and oversight.” -- Could add “Council maintains a supervisory role over the SPIRT.” ACTION ITEM: Add -- A recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions). -- Council maintains a supervisory role over the SPIRT. -- All recommendations are subject to the review and oversight of the GNSO Council, who maintains the discretion on whether or not to adopt the recommendations made to the Council. It is unclear why the SPIRIT is better positioned compared to others in determining what is policy versus implementation. -- This seems like a marketing issue – the mitigation point is that staff/somebody will come up with a simple guide on how the SPIRT works. ACTION ITEM: Add as IG about making the Framework and SPIRIT clear. Determining which ”bucket” something is in will not always be clear. ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions). The Framework and SPIRT are too complicated and GAC Concern [it is not clear that they create value versus existing mechanisms for issue mitigation.] ACTION ITEM: Create a “PR” document. GAC Concern - The Framework and SPIRT may undermine existing roles and responsibilities afforded to the ICANN organizations under the ICANN Bylaws. -- We also don't want to limit to "from", since this would restrict membership. For instance, GAC Secretariat is not a GAC Member. ACTION ITEM: Add “The SPIRIT is representative.” ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions). What to do with this document? Could be included as an annex, but might be cleaner to include it as rationale, particularly where there is new Implementation Guidance. Update the text of the documents and the flow chart and schedule for the meeting on Thursday, 02 July. 3. Continue to review "Can't Live With" comments on Package 5, start on page 80: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… (time permitting) 2.8.2 Limited Challenge/Appeal Mechanism a. Recommendations and/or implementation guidelines Affirmation xx (rationale 1): The Working Group affirms Recommendation 12 from 2007, which states: “Dispute resolution and challenge processes must be established prior to the start of the process.” [Proposed alternate text to Affirmation xx (rationale 1), in order to match text in section Objections: Affirmation xx with modification (rationale 1): Recommendation 12 from 2007 states: “Dispute resolution and challenge processes must be established prior to the start of the process.” Consistent with Implementation Guidance xx below, the Working Group affirms Recommendation 12 with the following modification in italicized text: “Dispute resolution and challenge processes must be established prior to the start of the process, the details of which must be published in the Applicant Guidebook.”] JC5.3 - Justine notes that there is an inconsistency between the above affirmation and the affirmation with modification under section Objections. Suggested solution: "Perhaps, adopt the (final) text for the affirmation of Recommendation 12 under “Objections”?" Rationale: "Insofar as the topic of Objections serves as an antecedent to this topic of Limited Challenge/Appeal Mechanism, is there an inconsistency with the approach the WG is taking in (possibly) affirming Recommendation 12 with modification under the topic of Objections?" Discussion: -- Good suggestion. Original language is vague. In line with what we state in the Objections section. ACTION ITEM: The WG agreed to adopt the revised text. Recommendation xx (rationale 2): The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that [are] [appear to be] inconsistent with the Applicant Guidebook. KK5.1 - Kathy Kleiman proposed replacing the word "are" with "appear to be." Rationale: "It’s not inconsistent with the Applicant Guidebook until there is a finding as such. Until then, the applicant is making an allegation!" ACTION ITEM: The WG agreed to include the bracketed language. The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and [formal] objections decisions KK5.2 - Kathy Kleiman proposed adding the word "formal" to this sentence. Rationale: "The term “formal objection” comes from the current AGB (see current Module 3) and it may help to flag readers to understand the important distinction of evaluation changes and objection appeals – a clarity issue." ACTION ITEM: The WG agreed to include the bracketed language, but make sure we are being consistent in our report. Implementation Guidance xx (rationale 5): The type of decision that may be challenged/appealed should vary depending on the process being challenged/appealed. The Working Group’s guidance on this issue is summarized in Annex xx. JC5.5 - The nature of this intervention is more inquisitorial at this point and as pointed out earlier, the topic of Limited Challenge/Appeal Mechanism with Annex xx is very much connected to the topic of Objections. I am happy to take this up again when we consider the topic of Objections provided that Annex xx is still open for further edits. The key question here is whether the draft recommendation and/or Implementation Guidance under Objections which confirms the ALAC as an established institution for the purposes of a Community Objection, altogether removes any requirement on the part of the DRSP to find on the issue of standing to object vis a vis the ALAC. If the answer is yes, then Annex xx is necessarily complete. If the answer is no, then Annex xx may need to be clarified to include “standing” as a ground of appeal. Discussion: -- We did discuss this in the Sub Group on Objections and didn’t agree to make any changes. -- Need to change the Annex to the grounds of “standing”. -- ALAC is likely to disagree with this change. -- This is just about the availability of an appeal, not whether a group has standing. ACTION ITEM: Change Annex xx to add the ability of challenging “standing” as a ground for appeal. Implementation Guidance xx (rationale 6): RK5.3 - See https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8f…<https://www.google.com/url?q=https://docs.google.com/spreadsheets/d/1R4eU7C…> (Tab 1, cell E14). For challenge of Registry Services Evaluation decision, the arbiter of the challenge is currently listed as: "Existing evaluator entity - different ultimate decision maker(s) within the entity." Rubens Kuhl proposes changing this to "New panel with different RSTEP panelists selected from the standing roster." Rationale: "RSTEP is not done by entities, so the arbiter of challenge needs to be changed." ACTION ITEM: The WG agrees to the change to "New panel with different RSTEP panelists selected from the standing roster." Implementation Guidance xx (rationale 7): For all types of appeals to objections, the parties to a proceeding must be given the opportunity to mutually agree upon a single panelist or a three-person panel, bearing the costs accordingly. KK5.4 - Kathy Kleiman asked a question: "What if the parties don’t agree, e.g., one wants a single panelist (or that is all they can afford) and the other party(ies) want three panelists? Default perhaps one panelist?" ACTION ITEM: Check in the AGB to see how that situation is handled and add to the rationale. b. Deliberations and rationale for recommendations and/or implementation guidelines Rationale for Affirmation xx (rationale 1): The Working Group believes that it is important for New gTLD Program elements to be predictable for applicants and other interested parties. By establishing dispute resolution and challenge processes in advance, ICANN provides a greater degree of predictability. Therefore, the Working Group affirms Recommendation 12 from the 2007 policy. JC5.4 - Rationale requires update corresponding to JC5.3 above. ACTION ITEM: The WG agrees to the update. Rationale for Implementation Guidance xx (rationale 4): In general, the Working Group believes that parties affected by an evaluation or objections decision should have the opportunity to file a challenge/appeal [under limited circumstances]. The affected parties for each type of evaluation and objection under different circumstances are outlined in Annex xx. ACTION ITEM: The WG agrees to include the text in brackets. 2.4 Application Change Requests Recommendation xx (rationale 3): [Proposed new Implementation Guidance: Implementation Guidance xx (rationale 3): Insofar as it is feasible, ICANN org should explore the possibility of allowing applicants to delay evaluation pending early submission of an applicant change request on the basis of business combination or other forms of joint ventures, so as to facilitate evaluation (instead of re-evaluation) of the new combined venture or entity, in an effort to save time and cost.] JC5.6 - Justine Chew proposed adding new Implementation Guidance. Rationale: "In the interest of transparency and predictability, it should be clarified if application change requests are allowed immediately after close of the application period and when all applied-for strings and corresponding applicants are revealed. Where permissible, we should consider allowing applicants which have applied for exactly matching strings or strings which in their belief run the risk of being confusingly similar an opportunity to delay their evaluation/reviews pending submission of an applicant change request on the basis of business combination or other forms of joint ventures. Having to evaluate just the new combined venture or entity will help avoid need for re-evaluation, also save time and costs. Withdrawals of application and corresponding refunds should be allowed." Discussion: -- This causes an undue delay to a community applicant. -- Do we want to put in some qualifier? Define “early”? Instead of making a broad change. -- Return to this item on the next meeting.

1 0

Re: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 25 June at 20:00 UTC for 90 Minutes
by Steve Chan June 25, 2020

June 25, 2020

Dear WG Members, In support of agenda item 2 on the Predictability Framework, the Co-Chairs and staff sought to organize what we understand the primary concerns to be (as identified in the slides from the ICANN68 working session) and the corresponding mitigations in place. The expectation is that this will aid the working group in determining whether the concerns are adequately addressed or if additional measures may be helpful. We understand this is late delivery, but nevertheless, we are hopeful that it will facilitate the discussion and is therefore worth sharing even if close to the meeting start time. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, June 23, 2020 at 10:25 PM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 25 June at 20:00 UTC for 90 Minutes Dear all, Please find below the proposed agenda for the WG meeting, open to Observers, on Thursday, 25 June 2020 at 20:00 UTC for 90 minutes. The agenda will be posted to the wiki at: https://community.icann.org/display/NGSPP/2020-06-25+New+gTLD+Subsequent+Pr…. Proposed Agenda: Review Agenda/Updates to Statements of Interest Continue to review the Predictability Framework, see: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT… Continue to review "Can't Live With" comments on Package 5, start on page 80: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… (time permitting) AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org. Kind regards, Julie

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 25 June at 20:00 UTC for 90 Minutes
by Julie Hedlund June 24, 2020

June 24, 2020

Dear all, Please find below the proposed agenda for the WG meeting, open to Observers, on Thursday, 25 June 2020 at 20:00 UTC for 90 minutes. The agenda will be posted to the wiki at: https://community.icann.org/display/NGSPP/2020-06-25+New+gTLD+Subsequent+Pr…. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Continue to review the Predictability Framework, see: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT… 3. Continue to review "Can't Live With" comments on Package 5, start on page 80: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… (time permitting) 4. 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>. Kind regards, Julie

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 23 June 2020 at ICANN68
by Julie Hedlund June 23, 2020

June 23, 2020

Dear Working Group members, Please see below the notes from the meeting on 23 June 2020 at ICANN68. 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://68.schedule.icann.org/meetings/xpMnL8W47Yk8sK5kF. Kind regards, Julie Notes and Action Items: 1. Topic 1: Private Resolutions, see attached slides and: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… Slide 11: Space for Compromise? (to aid in discussion): * In summary, the diverging interests appear to be: * Allowing applicants to creatively seek ways to resolve string contention. * Seeking to remove incentives for applicants to submit applications where there is no strong intent to operate the gTLD (e.g., incentives being, to leverage funds for other contention sets and/or financial benefit) Questions: * Assuming that incentivizing frivolous applications is bad for the program, how can creativity still be allowed/encouraged? * Are there program benefits to private auctions and other forms of private resolution (that are consistent with ICANN’s Commitments and Core Values)? Slide 12: Hybrid Proposal 2+: Primary goals of proposal: 1. Reducing incentives for submission of frivolous applications 2. Also, integrating agreed improvements to auctions: mechanism of last resort (i.e., single round, sealed bid auction). Key elements to achieve goal 1: * Add T&Cs against “Prohibited Application Activities” below: * Submitting applications for financial benefit * Resolving contention where non-winning applicants receive financial benefit to lose. * Incorporate mandatory contractual warranty/representation in RA that the Registry Operator did not participate in any of the Prohibited Application Activities. Slide 13: Amending Hybrid Proposal 2+: * Emphasis is on interest of reducing incentives for submission of frivolous applications. * The proposal allows for applicants to create partnerships and joint ventures. Can the support for the interest of creative contention resolution be increased in this proposal? Discussion: -- Are we all on the same page and agreed as to what constitutes a "frivolous" application? -- It's a subjective term that will no doubt be difficult to prove. -- Applying with no intent to actually operate the TLD is usually agreed to. -- The "assumption" that is baked into the question casts applications that had to be let go were retroactively "frivolous" -- Board concern was about applications that were filed without the intent to run a registry. We should address the Board’s concerns: 1) you can’t file an application without the intent to run a registry, and 2) can't file an application for the sole purpose of participating in a private auction. -- So, we should try to answer the questions but rather than focusing on whether an application is “frivolous”, since we don’t agree on what that is, or banning private auctions, we should focus on how to ensure that applicants do intend to operate a registry. -- Focus on how we can find the best candidates and not those with the deepest pockets. -- It seems we can agree that “frivolous” was not the right word to use. -- Also, we're not saying that anyone applied for the sole purpose of making money in the 2012 round, we don't believe that that was the case, but we think that there are applicants in future rounds that could try to do that. -- Suggestion for the use of a randomized draw – noting that the WG did discuss this idea, but there didn’t seem to be support for it. -- We've got the opportunity to put in place some guidelines or as Paul would say guardrails that help us from going down that path once again. -- We are overstating the likelihood of this problem. We should disincentivize it, not shut it down. -- Not sure how the guardrails would work – how can you be assured when an applicant says it will run the registry? -- This is a business decision – let the industry decide. -- Concerned that we are looking to develop policy when there isn't consensus on the intended outcome or motivation of that policy. Picking up on co-chair CLO's response to my question, that "there is considerable concerns being voiced", that tells me that we should try to nail this down before pushing forward. How are we to decide the mechanism if we are not sure what motivates the mechanism? -- The solution is not to ban the so-called private auction or any other private sector solution. The solution is to require applicants to affirmatively represent that they (1) have a bona fide intention to run any registry for which they apply; and (2) that they are not submitting the application for the sole purpose of participating in private auctions. -- This whole process is about ICANN distributing critical pieces of internet infrastructure with the public interest in mind. Full stop. It is not about: Enriching private parties through private auctions or making it easier for portfolio applicants to grab larger slices of the pie. After the .ORG dilemma, ICANN is on the radar in Sacramento, Washington, and Brussels to name a few. Do we as a community want to bring more heat by allowing what happened in 2012 to happen again? -- It's also important to keep in mind that in 2012, any applicant in a contention set could opt to go with ICANN's auction of last resort and many chose to do that. I am aware of a number of applicants, small businesses, who had applied for a string that ended in contention and much to their dismay could not even recoup their costs. -- Banning a particular mechanism isn't the solution. Let's build guardrails to deal with applications that are filed without a bona fide intent to run the registry if awarded and filed sole for the purpose of participating in private auctions. Solves the problem without resulting in ICANN interfering in the private market. -- Re bona fide intention - and to that point, in the trademark context we demand a bona fide/good faith intention to use the mark. This has been enforced/enforceable for a long time, even without being the most precise standard in the world. -- Would be ok to issue "office actions" / clarifying questions seeking to determine whether an applicant truly intends to operate the registry? -- Paul and Heather we're comparing bona fide intend to use to at least in the US system. To what you have to represent when you apply for a trademark and if trademark office if the US patent trademark office has any questions about that they issue what's called an office action and can try to get additional information from the applicant for the trademark. So they were making an analogy there. -- "Letting the market do its thing" requires market correction mechanisms to allow for single TLD applicants, new entrants, Global South & middle applicants. -- it's a shame we can't explore some of the options/suggestions in the chat in more detail. Like @Anne's payment into the applicant support fund. and Paul's applicant assurances. Combining some of these could well give the disincentive being looked for without unduly constraining "genuine applicants" who unfortunately don't win out in contention. -- Question: Do we have evidence that applicants had no intention of running DLD. It seems quite specious to me. I would also question how this was actually determined in the past. The investment and losing money and time to actually apply was already high enough to discourage plenty to apply in the first place without having to try and divine their actual intentions. Answer: We don't have evidence from the last round that applicants initially went into this applying for a pod with the intent to benefit. We only have evidence of applicants actually financially benefiting and in some cases public company filings where they certainly don’t boast about the fact that they've made more money running or in a private auction and getting the TLD, but they certainly use that information to boost the health of their public companies. 2. Topic 2: Predictability Framework, see attached slides and: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT… Slide 16: Predictability Framework – Key Features: * The WG is considering a Standing Predictability IRT (SPIRT) to serve in this role. The “Framework” recognizes that issues can be of varying levels of seriousness/impact and accordingly, can be put into 3 buckets. * Minor or non-minor changes to ICANN’s internal processes: This bucket exists in part to allow ICANN Org flexibility to operate the New gTLD Program effectively. Requiring any change, no matter how minor, to be filtered through SPIRT can paralyze program. * New or significantly altered internal ICANN processes: This bucket exists to ensure that where parties are highly likely to be meaningfully affected, that the solution must be developed in collaboration between ICANN Org and the community (i.e., SPIRT). * Policy changes or new policy: This bucket exists for circumstances where an issue arises and there is some ambiguity in how it should be resolved. If an issue is unambiguously policy, there is unlikely to be the need to filter the issue through the SPIRT (e.g., develop policy immediately) Slide 17: Predictability Framework – Key Features: * As currently devised, SPIRT limited to serve as a body that utilizes the Framework and provides that recommendation to the GNSO Council (and if applicable, the issue originator as well). The SPIRT may also be asked to help scope an issue during the course of its consideration of the issue. However: * The SPIRT shall NOT develop solutions (except in collaboration with ICANN Org for issues in bucket 2). It will generally be limited to serving as a triage body that helps in identifying resolution mechanisms. * The SPIRT shall NEVER be used to make policy or circumvent the policy process. * The SPIRT shall ALWAYS be subordinate to the GNSO Council, to help ensure that the SPIRT remains faithful to its remit. Slide 18: Some Concerns Raised: * The SPIRT may develop policy and undermine Council remit. * The SPIRT can be lobbied. * ICANN Org should not be able to make decisions on its own (i.e., bucket 1). * Determining what is policy versus implementation is always hard/subjective, so why would the SPIRT be able to do it better? * Determining which ”bucket” something is in will not always be clear. * The Framework and SPIRT may be seen as overly complicated and need to be simplified * Are there measures to address these concerns? What is the “risk profile” for each of these issues (e.g., likelihood and severity)? Discussion: -- Question: Who decides in what bucket that category falls? Answer: We're hoping that this would be done in collaboration between ICANN org and the SPIRT, but of course the GNSO Council, which has a supervisory role over the SPIRT, can always jump in to the process if it disagrees with the spirit team on its categorization of the issue or the of course the advice that a spirit team gives on how to handle that issue. -- Question: Wonder if that mechanism provides more predictability, or just adds more complexity? Answer: it certainly adds a little more complexity, but we believe that having members of the community and experts serve on this SPIRT could help guide ICANN org and provide some advice so that ICANN org is not dealing with all of these issues on an ad hoc basis escalating all of those issues to the ICANN board when they could be more efficiently vetted through this SPIRT. -- Question: Didn’t think that staff should be determining the bucket – SPIRT should be determining the bucket. Answer: The SPIRT team will certainly be collaborating with ICANN org to help figure out which of the buckets, whether it's three or five these fall into. -- Question: What if the predictions are invalid? Are there any factors that are pre-considered in the predictability framework? Answer: There are certainly areas where we may have predicted that certain things would happen and they turn out differently and issues arise and so where that happens that is precisely the reason for this standing committee. That can help guide a process for moving forward with those issues. So that's certainly one of the important factors for coming up with this in the first place. -- For the composition, the WG could look at the GNSO Standing Selection Committee (SSC). -- Question: What is the community? Are At-large, ALAC, and GAC included? Answer: So although it's envisioned that this SPIRT would fall under the GNSO remit, because the GNSO is tasked with developing policies for generic top level domains, it is certainly envisioned including members from advisory committees and supporting other supporting organizations that may be Impacted and want to participate in these types of endeavors. So short answer is yes. -- Question: What is our take on where we are most everyone on board and working out details are still up in the air on the idea itself. Answer: Unless we're reading things wrong that everyone, or at least we haven't done consensus calls as, as you know, but it seems to us that the group is leaning towards this model and yes I we think we're working out details at this. General Questions: -- Question re: discussion last night about our letter to the GNSO Council, noting that we're not intending to address DNS abuse, as requested by the GAC, Board, and CCT-RT recommendations. How can it make sense to move forward with the next round procedures not addressing DNS abuse at all? It seems counterintuitive and the president atmosphere. Answer: DNS abuse is a topic that is being worked on right now by the entire community in many different ways. There have been contracted parties that have put together their framework. There's excellent discussions going on within the a lot about things that they'd like to see registries do and you know that the working group discussed this issue and certainly felt that any solution or any new mechanisms to deal with DNS abuse should be done in a holistic manner. It doesn't make sense to only apply new procedures to incoming registries when that is going to be at least three, four years away. And the second reason is all of the abuse you see right now is our definition in the existing TLDs and the new gTLDs that will be launched in three, four years. We strongly believe that DNS abuse can be worked on by the community in the next three years in parallel with implementing the new gTLD program. So we believe that by the time a new TLD is delegated in two, three years, that there is a solution out there or mechanisms out there to deal with not only the new gTLDs but also, but all existing TLDs. The other thing is that the mission of the new TLD program or one of the missions is to ensure competition. And usually when you have new entrants into the market, you don't make it more difficult for the new entrants to compete than you do with the legacy or incumbent providers -- that is actually the opposite of what should be done to encourage competition. So from a personal perspective, I would say that or strongly encourage the community to work as a whole to solve these issues with the entire TLD landscape as opposed to trying to pigeonhole it in the new TLD program and then apply it to legacy TLDs in 10 years when their contracts renew. So we're hoping that these things can be done at the same time. -- Question: Regarding DNS abuse -- hear there's an idea foot to form a CCWG as opposed to a PDP in order to address this issue community wide with this holistic approach requiring subsequent PDP in order to incorporate any obligations into contracts parties house contracts and so would that not cause delays? Answer: think that certainly to incorporate new obligations on contracted parties, you are correct. That would require a PDP, but that's a good question for the GNSO Council as they're trying to figure out what the next steps are.

1 0

**Updated to a Webinar room and open to Observers** Meeting invitation: New gTLD Subsequent Procedures Working Group call | Thursday, 25 June 2020 at 20:00 UTC
by Julie Bisland June 23, 2020

June 23, 2020

Dear all, The New gTLD Subsequent Procedures Working Group call, open to Observers, is scheduled on Thursday, 25 June 2020 at 20:00 UTC for 90 minutes. **Updated** Join the Zoom Webinar room: https://icann.zoom.us/j/98927397068?pwd=THUyTVBrZ2dHRTJjSG0zRVF5bW5MUT09 Password: 6P%ffA1^Rk 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/3wAdC Check your time zone: https://tinyurl.com/y8ty35wz [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y8ty35wz&d…> If you are joining via audio only: Webinar ID: 989 2739 7068 Password: 379202 International numbers available: https://icann.zoom.us/u/ayStXMbZK 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, Andrea

1 0