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

Post call | New gTLD Subsequent Procedures Working Group call | Tuesday, 26 May 2020 at 15:00 UTC
by Julie Bisland May 26, 2020

May 26, 2020

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

MUST, SHOULD, SHALL etc
by Aikman-Scalese, Anne May 26, 2020

May 26, 2020

Jeff, Cheryl, et al - below I paste the IETF definitions that were linked - note, for example, that "should" says "can be ignored" under certain circumstances - not sure anyone in the WG ever had that understanding of "should". Anne Network Working Group S. Bradner Request for Comments: 2119 Harvard University BCP: 14 March 1997 Category: Best Current Practice Key words for use in RFCs to Indicate Requirement Levels Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119<https://tools.ietf.org/html/rfc2119>. Note that the force of these words is modified by the requirement level of the document in which they are used. 1<https://tools.ietf.org/html/rfc2119#section-1>. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2<https://tools.ietf.org/html/rfc2119#section-2>. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3<https://tools.ietf.org/html/rfc2119#section-3>. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4<https://tools.ietf.org/html/rfc2119#section-4>. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Bradner Best Current Practice [Page 1] ________________________________ <https://tools.ietf.org/html/rfc2119#page-2> RFC 2119<https://tools.ietf.org/html/rfc2119> RFC Key Words March 1997 5<https://tools.ietf.org/html/rfc2119#section-5>. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 6<https://tools.ietf.org/html/rfc2119#section-6>. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. 7<https://tools.ietf.org/html/rfc2119#section-7>. Security Considerations These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification. 8<https://tools.ietf.org/html/rfc2119#section-8>. Acknowledgments The definitions of these terms are an amalgam of definitions taken from a number of RFCs. In addition, suggestions have been incorporated from a number of people including Robert Ullmann, Thomas Narten, Neal McBurnett, and Robert Elz. Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D63340.C252AD10] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> [cid:image003.jpg@01D63340.C252AD10] Because what matters to you, matters to us.(tm) ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. ?2510-2521.

4 4

Re: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 21 May at 03:00 UTC for 90 Minutes
by mail＠christopherwilkinson.eu CW May 24, 2020

May 24, 2020

Good evening: I must say that I could not possibly accept that GNSO Council would have the authority to decide and/or to overrule the recommendations of the SPIRIT. GNSO is but one of the SO/AC in play here. GNSO Council is not "FINAL" anything. Lacking time to go into this at length, I rest that this is a critical issue for the multistakeholder ICANN community. Regards Christopher Wilkinson Begin forwarded message: From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Subject: Re: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 21 May at 03:00 UTC for 90 Minutes Date: 21 May 2020 at 21:11:44 CEST To: Steve Chan <steve.chan(a)icann.org>, Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Jeff, Cheryl, Steve et al, Regarding the process chart, and as discussed on last night’s call, the language in the middle of the chart does not seem accurate. It says that issues “identified” as fitting in A or B are expected to be decided by ICANN staff. The issue raised in the call last night was who gets to “identify” what bucket the issue falls in. I see staff working with the SPIRT to make those recommendations. SPIRT may agree with staff that an issue falls into A or B, but Staff should not itself have the final call if there’s an issue. In all cases, buckets A, B, C, D, and E, GNSO Council has the FINAL call. SPIRT is there to discuss and try to classify which bucket the issue goes in and NOT to make policy if it believes that a policy issue is involved. It’s not at all workable to have one person on the SPIRT be able to kick an issue up to GNSO as policy if the majority believe it can be handled by staff or handled with GNSO Input or Guidance (rather than through policy-making). (Remember that any GNSO action always takes precedence over the SPIRT .) This “sorting into buckets” function is why it is so important for the SPIRT to have members from all parts of the community (which is supposed to be the case for regular IRTs as per the section I pasted in chat last night – see Section C of IRT Recruitment in the attachment). It Is clearly NOT working at all to pick and choose different parts of the IRT Guidelines to try to structure the SPIRT as we have done in the current draft. When you do that, you get “the SPIRT may not be representative” and you leave out FOUNDATIONAL language like “SPIRT recruiting must be very broad and invitations should go to all former regular attending members of the PDP Working Group” which is in Item C of the IRT Guidelines. For some reason, the draft we have now says the SPIRT team should include at least ONE member of the PDP WG. Why would there be such emphasis on getting just ONE member of the PDP for this Standing IRT? And why do we want to emphasize that the SPIRT may not be representative rather than emphasizing that recruitment should be broad as shown in the attached IRT Principles and Guidelines? (Last night Paul asked to see the IRT Guidelines. They are attached for your consideration before the next call.) Donna mentioned that staff runs the IRT process. The Guidelines for IRTs state that the staff member is the GDD Project Manager. Every IRT appoints among its members a GNSO Council Liaison. I’m not sure why we have to call the person heading the SPIRT team a “Chair”. What is wrong with GNSO Council Liaison? THE SPIRIT DOES NOT DECIDE ANYTHING, IT SHOULD CONSIDER ANY ISSUE WITH STAFF AND RECOMMEND WHICH BUCKET THE ISSUE BELONGS IN – A, B, C, D, or E. Staff should not be telling the SPIRT that something that comes up as an issue in the implementation phase will not be coming to the SPIRT because staff believes it fits in A or B. Staff should be bringing that issue to the SPIRT to see whether the SPIRT agrees that it is in Bucket A or B. Similarly, Issues that the SPIRT believes fall in C, D, or E, are opportunities for the SPIRT to identify issues, recommend a method of resolving, e.g. use GNSO Input, GNSO Guidance, GNSO EPDP, or even GNSO PDP and send that recommendation to the GNSO Council. The SPIRT DOES NOT MAKE POLICY. It’s a Standing IRT. It works with staff to make recommendations to process issues in an efficient manner within GNSO guidelines and processes. All IRT Principles and Guidelines should apply unless there is a clear reason to deviate and so far, I don’t see why we are trying to create a different animal when the Public Comment was – yes, give us a Standing IRT because we know issues arise at later stages. Thank you, Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org mailto:gnso-newgtld-wg-bounces@icann.org > On Behalf Of Steve Chan Sent: Wednesday, May 20, 2020 2:07 PM To: Julie Hedlund <julie.hedlund(a)icann.org mailto:julie.hedlund@icann.org >; gnso-newgtld-wg(a)icann.org mailto:gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 21 May at 03:00 UTC for 90 Minutes Dear WG Members, One of the action items from the 18 May WG call was to develop a process flow chart to help illustrate how the SPIRT may operate. Attached, please find a draft prepared by staff and WG leadership. Note, we try to share documents at a minimum, 24 hours ahead of the call, but there was a short turnaround between calls in this instance. Hopefully this document is still helpful to the discussions for the upcoming call. Best. Steve

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 26 May at 15:00 UTC for 90 Minutes
by Julie Hedlund May 21, 2020

May 21, 2020

Dear all, Please find below the proposed agenda for the call on Tuesday, 26 May 2020 at 15:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics: a. 2.2.2 Predictability: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT… b. Review "Can't Live With" comments on packages 1-3: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 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>. Kind regards, Julie

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 21 May 0300 UTC
by Julie Hedlund May 21, 2020

May 21, 2020

Dear Working Group members, Please see below the notes from the meeting on 21 May at 0300 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-21+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: 1. Updates to Statements of Interest: No updates provided. 2. 2.2.2 Predictability: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT…, start at page 10 Process Flow Chart (see attached): -- Top swim lane is the SPIRT. -- Three groups are: ICANN Board, ICANN Org, GNSO Council. -- Type A, B, C, D, and E – correspond to the chart in the Annex on page 8: Type of change SPIRT involved Notes A - Operational - minor no B - Operational - non-minor no C - Operational - new process [or significant change to internal process] yes It is a SPIRT task to recommend when an otherwise operational change has a possible policy implication D - Possible policy level changes yes E - Possible policy level new proposals yes Notes on the Chart: -- SPIRT: Any requests from SO/AC/SG/Cs have to come through ICANN Board, ICANN Org, or GNSO Council. -- GNSO Council: Issues of type A and B are addressed by ICANN Org; issues C, D, and E must be referred to the SPIRT. -- GNSO Council could refrain from forwarding and issue to the SPIRT. -- GNSO Council could 1) agree with the SPIRT outcome; 2) seek to resolve issues with the SPIRT; 3) resolve the issue using available resources. -- “GNSO” in the pink diamond in the GNSO Council swim lane means the “GNSO Council”. -- Add a key at the bottom to indicate what are the different types. From the recommendations: “The Predictability Framework is principally: A framework for analyzing the type/scope/context of an issue and if already known, the proposed or required Program change, to assist in determining the impact of the change and the process/mechanism that should be followed to address the issue.” Composition of the SPIRT: First bullet: “The SPIRT should at a minimum, [for the first 2 years] [for the first 5 years] include at least one participant from the original PDP WG and IRT who can provide insight into the original reasoning behind consensus policy recommendations and implementation decisions.” -- Don’t make it prescriptive since it may not be possible, which could hold up the establishment of the SPIRT. -- We could just leave in the minimum requirement, but not include the text in brackets/not specify the term. -- Composition depends on what issues the SPIRT gets and we also need to determine who runs the SPIRT. If it is deciding on policy then staff shouldn’t run it. -- If it’s clearly policy it is something that the GNSO Council would handle through its existing mechanisms. -- But we are saying that not everything is black and white so the GNSO Council may want a group of experts to pull out issues that are policy. -- We are not saying that the GNSO Council should make policy. -- Consider a change where if the SPIRT considers that something is policy it sends it back to the body that sent it to them, so that the ICANN Board or GNSO Council can decide what to do next. -- The issue with that is the SPIRT is not supposed to make any decisions. -- Look at why we thought we needed a framework in the first place – to avoid the problem in 2012 of staff making fundamental decisions. The SPIRT is an objective impartial kind of circuit breaker. -- The intent is that if something is policy it goes to the GNSO Council, but it’s not clear from the flow chart who makes the determination. It needs to be fast track so it’s not holding up the applicants. -- Afraid that what we are seeing here is going to be a long process. Role of the SPIRT member (representative vs independent judgement) * [For the purpose of assessing level of consensus, where there is a difference between the view of the individual member and the known position of the group that individual represents, the SPIRT member is expected to represent the known position of the group.] * [The SPIRIT presumes that members are presenting the positions of their group.] -- If you have a technical expert on the group they wouldn’t be a voting representative. -- IRTs generally are open and don’t have a representative structure, but it is a guideline that the IRT should be as representative as possible. -- IRTs follow the consensus decision-making process that is in the GNSO Operating Procedures. -- We originally thought the SPIRT would be a standing IRT, but then we changed. But maybe we don’t need this section. -- Not sure there is a difference between the two bullets. -- This just seems like we are setting up a miniature GNSO Council. -- This section is here because if you have certain numbers from different groups you want to know how they are represented. -- If we drop section 5 then you could say this is an open structure or if you have a representative structure you could still have members operate independently. -- You could have members representing their different groups but still acting in their independent capacity. -- So we are saying that the group should be diverse but not represent their groups in a formal representative capacity. -- Sounds like the conversation we had about the composition of the CSC and we looked at the scope first. -- Should say that the group should have a diversity of membership coming from different stakeholders but are members acting in their individual capacity. -- There should be representatives of applicants on the SPIRT since they would be most affected. -- Reference the Consensus Policy Implementation Framework, which says IRTs should be representative. -- We are saying it is representative but that members can act in their individual capacity. -- Thought this was supposed to be a small nimble group, but if you open it to everybody then it isn’t. -- Once we determine the scope we can get to the optimal number. Conflicts of interest procedures -- Don’t we need a recusal mechanism? -- We went away from that concept because if the people with the most expertise have to recuse then you won’t get effective discussions. -- Everyone has an interest and so long as those interests are known in a Statement of Participation then you don’t need a recusal mechanism. -- Also, at the end of the day it is the Council that will adopt or not and there is the opportunity to abstain. -- There needs to be transparency and regular disclosure. SPIRT Leadership -- Eliminate the comment on how the chair counts.

1 0

Post call | New gTLD Subsequent Procedures Working Group call | Thursday, 21 May 2020 at 03:00 UTC
by Julie Bisland May 21, 2020

May 21, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 21 May 2020 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/yIPsBw> (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 - Thursday, 21 May at 03:00 UTC for 90 Minutes
by Julie Hedlund May 19, 2020

May 19, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 21 May 2020 at 03:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics: * 2.2.2 Predictability: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT…, start at page 10 * Review "Can't Live With" comments on packages 1-3, time permitting: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 3. 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

Post call | New gTLD Subsequent Procedures Working Group call | Monday, 18 May 2020 at 20:00 UTC
by Andrea Glandon May 18, 2020

May 18, 2020

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

May 18, 2020

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+Pr…. 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-zyvfGGcDB3NWQhodVsffdqbyb6kT… 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.

1 0

Update - merged working documents
by Emily Barabas May 15, 2020

May 15, 2020

Dear all, In recent discussions, Working Group members requested that we reduce the number of working documents in use to produce draft recommendations. In response to this request, the following sections are now included in the master working document here<https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…>: * 2.3.2 Global Public Interest * 2.5.4 Applicant Support * 2.7.3 Closed Generics * 2.8.1 GAC Early Warning and GAC Advice * 2.9.1 Community Applications A few important things to note: * If you have new input on these sections, please add it to the master working document<https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…> only and not any other document. We don’t want to lose track of your input! * Due to a limitation in the functionality of Google Docs, we were only able to bring over clean versions of these sections rather than redlines. The comments have been carried over. If you want to view the redline, you can find a link to the redlined version at the beginning of each of these sections in the master document. * Some of these sections still need to be revised further by staff based on recent discussions before they are covered again on calls. You may see additional redlines to these sections in the coming days. If you have any questions, please let us know. Kind regards, Emily Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0