Dear Working Group members, Please see below the notes from the meeting on 12 December 2019. 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/2019-12-12+New+gTLD+Subsequent+Pro.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: ACTION ITEM 1: Page 3 Re: 1(c), New ICANN Organization Internal Process footnote 3: “Changes here are expected to be procedural in nature. To the extent that a change is envisioned to the scope or nature of a process (e.g., changes to the standing requirements or dispute resolution principles for objections), the issue is more appropriately considered under section (c) below.” Make sure the footnote is still relevant. ACTION ITEM 2: Create a flow chart for the SPIRT. Notes: 1. Updates to Statements of Interest (SOI): -- Kristine Dorrain has a change to her SOI. She now is on the 2020 NomCom. 2. Predictability Framework: -- Question re: Limited Appeals Mechanism: When will we finalize the chart? Might get more input from IPC. Answer: We haven’t set a deadline, but the sooner the better. -- Same document from before Montreal but updated from discussions at ICANN66. Policy Goals: -- Keep these in mind. -- As issues arise after the application acceptance window commences, the issues must be resolved in a predictable, transparent, and fair manner. [sentence needs to be cleaned up] -- Community should rely on a Predictability Framework specific to the new gTLD program. -- In the event significant issues arise that require resolution via the Predictability Framework, applicants should be afforded the opportunity to withdraw their application from the process and receive an appropriate refund. -- The Predictability Model intends to complement the existing GNSO processes and procedures and is not intended to be a substitute or replacement for those, nor should the Model be seen as supplanting the GNSO Council’s decision-making authority. In fact, the GNSO processes and procedures are incorporated into the Predictability Framework explicitly. In the event of a conflict, existing GNSO processes and procedures, including GNSO Input Process, GNSO Guidance Process, and EPDP as contained in the Annexes to the GNSO Operating Procedures take precedent. What are we proposing: -- Type/scope /content of a change will guide the process for change/modification. -- WG recommends a SPIRT be formed after publication of the AGB. -- GNSO Council will be responsible for oversight of the SPIRT. -- Categories of Changes to the New gTLD Program after Publication of the Applicant Guidebook: 1. Changes to ICANN Organization Internal Processes a. Implemented by ICANN Org without consultation: change in internal process workflow for contracting or pre-delegation testing, changing backend accounting systems, selecting or changing subcontractor, rolling out an organization wide change with no material impact. b. Non-minor changes [or revisions] to ICANN Org’s internal processes must be communicated to all impacted: change in ICANN Org’s internal Service Level Agreements, changes made to workflow for handling change requests. c. [should indicate go through the SPIRT process below] Not a change to an Internal Process, but new Internal Process: new public comment platform/tool, new process/platform to submit objection, new procedural mechanism to determine order of applications are evaluated, [question about where something like a substantial change in the evaluation timeline or fees would apply] Discussion: -- What would be considered “substantial” as to a change? We’ll need to consider this after we get back to the topic of application processing. -- A change that isn’t substantive but still have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Affect substantive LRO (elements, standing, etc.) but there may be some potential objections that, for one reason or another, can’t use that platform. ACTION ITEM: Make sure footnote 3 is still necessary, makes sense. 2. Possible Policy Level Changes: -- May materially differ from the original intent of the policy – SPIRT Team options. -- First bullet: Add a footnote that it is recommendations from the IRT and add “and ensuing policy implementation”. -- Recommend additional consideration by the community. -- Extraordinary circumstances: recommend that the New gTLD Program could be halted – provide rationale and trigger point to get the program restarted. Discussion: -- Question: Is there anywhere else in the document where we say there is a bias against change to the program after applications are in? Answer: We will make a note to check, but think it is in other overarching sections. -- Note conflict of SPIRT being formed after final AGB – we need to make sure that there is no conflict and decide when the predictability model would kick in. If using the GNSO procedures as a guideline – policy is effective when implementation ends. This SPIRT should deal with any issues that arise after publication of the final AGB, as opposed to what it says in the Policy Goals. So, after the IRT, which ends officially at the effective date of the policy, which would be the day when the final AGB is released. -- Question: For SPIRT to go to the community for policy changes, is this exclusive of going to the Board? Where does the stuff come from that goes into the SPIRT? Answer: The hope is that this would provide the mechanism for the Board to kick it back to the community – funnel requests through the SPIRT process. This is to give the community more input into the process and discourage everyone from bringing everything to the Board. -- Question: So, any questions from the community the SPIRT will address them? Answer: It is not intended to be this mechanism for people to ask for any changes, but hard to say that it is exclusively for staff. We are trying to create a community mechanism for input into how changes are made. The SPIRT doesn’t decide whether changes are made, but the process for how to deal with a request. So, to the Council because it is a policy level change, or minor and staff can just implement. -- If changes are coming directly from staff that would be better, rather than anyone who wants a change after the fact. We need to answer the question of where does the SPIRT get its input. -- If we think back to the 2012 round the changes came from a bunch of different sources, not just staff. Example is name collision – raised by the security community. Ultimately the staff took it on. But if you look at the changes to the agreement, that came strictly from ICANN staff. Changes to the TMCH: some from the registries. We are not intending to set up a fourth place for these requests to come into – they come from existing channels but changes shouldn’t be made to the program until the requests are considered by the SPIRT. -- Question: Why would we want to create something for people to go to ask for changes, in addition to the Board or the Council? Answer: The SPIRT cannot on its own take in a request from the community, it needs to be referred to by the staff or the Board. -- Think the referrals should come from staff and the Board, no one else. -- SPIRT is not the instigator of changes or that the community can go to with requests. It is a body that helps determine the process that is used depending on the type of change. -- Important to remember the reasons for having this and why it is a “standing” IRT. In 2012 issues arose after the applications were in – such as GAC advice. That would go to the Board and then the Board would assign it to the SPIRT. This is a readiness tool. -- We could say that all requests have to come in from staff, Board, or GNSO Council, but we want to avoid the situation where the SSAC goes to the Board and the Board just does something. No matter where the legitimate request comes from we want to ensure the community considers it. -- We could put in a “bias against changes” statement where we really hope the Board won’t take unilateral actions. -- One challenge with GAC and SSAC advice is that the Board has a process to follow. The Board is the only one who could reject GAC advice. Not confident that we could require the advice comes back to the SPIRT. -- Question: Could the Board or GNSO Council withhold an issue from the SPIRT? -- Don’t see that it is a conflict to have a process for Board consideration of GAC or SSAC advice, we are saying this is the mechanism that must be followed for policy changes. The Board will still need to get input from the GNSO on any of these issues and this is the process. -- We could probably end up with a compromise that requests to the SPIRT should come from the staff or GNSO Council. A request from the Board could go to the Council and the Council could decide if it should go to the SPIRT. -- Not sure something would have to go through Council before going to the SPIRT. That would cause delays. But the Council could be one source of input. -- What would be helpful is if the SPIRT is related to implementation issues only, then it doesn’t really matter where the request comes from. -- It is limited to implementation issues, but is also supposed to be tool that staff could use to determine if something is implementation or policy. If a change is policy then the SPIRT refers it to the GNSO for the usual policy process. -- If staff or Board or Council believes something is definitely policy then it would not go through the SPIRT, only to the Council. -- ICANN Org shouldn’t be the one making the policy versus implementation determination, that’s the benefit of SPIRT. -- The point of the SPIRT is to speed up the process. -- If we are going to make implementation versus policy as the gate-keeping function, then we should make it clear what we are willing to do 180s on and not. -- Maybe the Council needs to do a first pass to determine if the issue is policy versus implementation. If it is implementation it goes to SPIRT and if policy then the Council deals with it. ACTION ITEM: Create a flow chart for the SPIRT.