Dear Working Group members, Please see below the notes from the meeting on 18 May at 2000 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-05-18+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: ACTION ITEM: #1 -- Make sure that it is “only” the Board, ICANN Org, GNSO Council that can raise an issue. ACTION ITEM: #2 -- Change to “By letter from the ICANN CEO and/or the head of the Global Domains Division or his/her designee”; WG seems to be agreeing to delete the bulleted options under GNSO Council and make it the same as for the Board: “By letter from the ICANN CEO and/or her/her designee.” ACTION ITEM: Add to deliberations relating to the recommendations the background of how the operational procedures for the SPIRT were developed, with reference to the various guidelines and documents. ACTION ITEM: Create a flow chart to show how the SPIRT works operationally -- how an issue works through the system. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Document Review -- 2.2.2 Predictability: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kTw... 1. Who can raise an issue to the SPIRT? * Issues forwarded to the SPIRT should be subject to thoughtful analysis and have an impact beyond a single applicant. As such, issues can only be forwarded by: * ICANN Board; * ICANN org; or * The GNSO Council 2. How can each of these Groups forward an issue to the SPIRT? 3. Who receives the Advice / Guidance issued by the SPIRT? Discussion: -- If the SPIRT teams sees an issue it would bring it the the GNSO council -- Change to “From the ICANN CEO and/or his or her designee.” -- Cross check against ways that Councillors can raise annexes that Councillors can raise issues. -- If you have an issue where one group on Council says it should go to the SPIRT and the other group says no? -- The first 2-3 bullet points in #2 are inviting chaos. -- If it truly is an issue and it’s only one SG, you would think the SG could either convince the Council, ICANN Org, or the Board. -- If the SG can raise an issue directly to the SPIRT then it isn’t going through the GNSO Council, ICANN Org, or Board. -- Could just leave it that only the GNSO Council, ICANN Org, or Board can bring issues to the SPIRT and leave it up to the Council to determine how to address issues raised by its members. -- The SPIRT does not decide what is policy. -- The SPIRT is not the only entity to which issues are forwarded. They can go direct to the Council, ICANN Org, or the Board. -- On #3 -- Concerned about the SPIRT giving advice; particularly that ICANN Org should not be given equal footing with the GNSO Council and the ICANN Board. -- What happens if the GNSO Council doesn’t take action in 60 days? Could ICANN Org move ahead with an action in absence of the Council taking action? -- Create a default that if Council doesn’t do anything in 60 day then the action is rejected? Or just not deemed approved. -- Say if Council doesn’t take action in 60 days then no further action by the ICANN Board or ICANN Org will be taken. -- If it is an operational issue why does it need GNSO Council approval? The GNSO Council could stall something that needs to be changed. -- How entrenched are we to have issues be able to come from staff? Can’t the staff just go to the Board and have the Board raise it? It shouldn’t move forward until Council says so. -- Staff needs to be able to raise issues because most aren’t critical. -- Can SPIRIT target classes of applications? Can it target specific applications? Can we carve these out along with pausing rounds and not starting the next rounds? These would at least be some guardrails around all of this. -- Could say they couldn’t target, but that wouldn’t mean that a policy couldn’t be applicable to certain parties. -- Question: Thought that this would be governed by the principles for IRTs. Answer: We did incorporate IRT rules. ACTION ITEM: #1 -- Make sure that it is “only” the Board, ICANN Org, GNSO Council that can raise an issue. ACTION ITEM: #2 -- Change to “By letter from the ICANN CEO and/or the head of the Global Domains Division or his/her designee”; WG seems to be agreeing to delete the bulleted options under GNSO Council and make it the same as for the Board: “By letter from the ICANN CEO and/or her/her designee.” ACTION ITEM: Incorporate the concept that the SPIRT cannot target specific applications, pause rounds, or not start the next rounds. Operation of the SPIRT -- 1) Decision-making process and 2) Composition: Discussion: -- Question: Will the non-GNSO members have a vote? Answer: We haven’t indicated a formal voting structure. -- Another way to say it, will the non-GNSO members have the same weight as the GNSO members? -- Maybe just incorporate the IRT guidelines? This is a Standing IRT. -- IRT guidelines were not applicable in many cases, so we took the best from a number of different groups, and in previous versions we referenced them. Incorporated everything from the IRT that was applicable. -- Staff is assuming that the SPIRT is there for ambiguous cases. In cases where there is direct action taken by the responsible party, such as the Council, it might be helpful to have a process flow to show how issues circulate through these mechanisms. So, for example, does it make sense for ICANN Org to go to the SPIRT or to the Council. -- Even if something is clear, or operational, but that isn’t something staff or Org should do it alone, it still has to go through the SPIRT. ACTION ITEM: Add to deliberations relating to the recommendations the background of how the operational procedures for the SPIRT were developed, with reference to the various guidelines and documents. ACTION ITEM: Create a flow chart to show how the SPIRT works operationally -- how an issue works through the system.