Thanks Donna. I don't have the power to reject any proposal, so everything from Anne below is on the table and I was just offering my thoughts. My concern however is even reflected in your language, "It may be possible for the Council to come up with a mechanism". That introduces even more variables outside the control of our group and provides yet even more uncertainty about potential delays. Plus, if one of the key roles for the SPIRT is to provide advice/recommendations to the Council as to whether they believe an issue amounts to a policy/implementation or execution change, and their advice/recommendations will be subject to review of the Council anyway, then what is the potential downside of having the issues from the Board/staff go to this new standing committee established with the expertise to handle precisely these types of situations. The second concern I personally have is that we have been increasing the role of Council incredibly over the years. Initially, there role was strictly as managers of the policy process. Now with the new Empowered Community, they have been given additional responsibilities. To give the Council the first right to deal with these types of things would now introduce even more importance to serving on the Council and finding expertise even more expertise in this new area. Giving the Council oversight over issues and the work of this group makes complete sense. Bringing these issues directly to the Council, when they most likely will not involve "policy" per se, as opposed to directly to a group that has the requisite expertise (technically, operationally and policy-wise on the new gTLD Program) does not seem to make the most sense to me especially if the GNSO Council does retain oversight authority. Lets run through some examples (and assume for these that the AGB did not already account for how these changes would be made): Caveat: I am making all of the following up for illustrative purposes. Lets not get bogged down is why ICANN may actually want to recommend doing the following things. Some of them may not be realistic, but they are provided as examples to see how we would deal with this. Ex. 1 ICANN receives 10,000 applications when it only planned for 2,000 and as a result would like to do the following: * Add another provider for providing evaluation services of the applications; * Change the back-end system for public comment but has same functionality * Change the timelines for completing initial evaluation from what was in the AGB; * Change the mechanism for batching the applications by stating that they will now review all applications that have self designated as community applications before other applications; * Cut off the number of applications at 5,000 and push the remaining 5,000 applications to the next round; Ex 2: Completely unrelated to the first example, the ICANN Board wants to add provisions into the new gTLD Registry Agreement to require all new gTLD Registries to now verify that all registrants are who they say they are and that they have a legal right to a registration in any new gTLD. For Example 1: In my mind (personally speaking), a, b and c are modifications of ICANN's internally processing systems. 1. seemingly should be able to be done without any consultation with a SPIRT, but with just notice to the community 2. there should be some consultation with the SPIRT to verify that the new system really would not have an impact on the functionality and if so the SPIRT would recommend that ICANN just be allowed to make the change. If it would have an impact on the applicants, it could recommend that notice go out to the community about the change and solicit comment. The SPIRT could then review the comments with ICANN staff and make recommendations on how that new system should be implemented. Of course the GNSO would have oversight and could if it wanted choose to use one of its own processes to deal with the proposal. Sending this to the GNSO Council first before the SPIRT team would (n my mind) just add unnecessary delay and the Councilors presumably are not equipped to evaluation this type of change. To wait a period of time just for the Council to ultimately send it to the SPIRT would not make sense in my mind. 3. Changing the timelines is a little trickier, but it would seem that this could go to the SPIRT to discuss the potential ramifications and whether the AGB already had a mechanism in there to handle this. They could then recommend to the GNSO Council whether they thought the ICANN proposal was consistent or inconsistent with the AGB and if inconsistent could send a recommendation to the GNSO council on a proposed process forward on how process further (eg., should there just be an opportunity for the public to comment or should it go through a GNSO process). For examples (d) and (e), these are more significant changes. Arguably (d) should go to the SPIRT to recommend whether they believe this is something that is consistent with (or inconsistent) with the AGB and if inconsistent should then send a recommendation to the GNSO Council on how they believe this proposal should be dealt with. The GNSO Council would then get those recommendations and figure out how to process. (e) would seemingly be inconsistent with the AGB and should go straight to the GNSO Council to initiate one of its processes. In my mind this would not be the type of change that the SPIRT team would be equipped to handle and would involve such a large number of changes, that going to the SPIRT team would not serve a purpose. For Example 2 above (changing the Registry Agreement), this too would be of such huge policy significance that it should go directly to the GNSO Council for it to process and figure out how that request should be handled. No referral to the SPIRT team would be necessary. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Austin, Donna <Donna.Austin@team.neustar> Sent: Thursday, December 12, 2019 10:04 PM To: Jeff Neuman <jeff.neuman@comlaude.com>; Aikman-Scalese, Anne <AAikman@lrrc.com>; gnso-newgtld-wg@icann.org Subject: RE: Predictability Framework Jeff, I don't think it really matters which way you slice this process they will all create the potential for delays. The line between policy and implementation is very vague which is why I think it makes more sense to have the Council consider the question first rather, because they are the experts on this particular question, as opposed to the SPIRT. I like Anne's suggestion about how to consider requests from the Board, community vs ICANN org staff and we should think about that some more. It may be possible for the Council to come up with a mechanism that would respond to concerns about delay and make the consideration process more streamlined. So I don't think we should reject any suggestion outright at this point and encourage others from the working group to contribute to the discussion. Donna From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Thursday, December 12, 2019 1:52 PM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Predictability Framework [cid:image001.gif@01D5B198.C08589A0] Thanks Anne. I do disagree with this and probably didn't do well explaining why, but I will try again. The GNSO Council is not intended as a body that can take quick actions. It is not as if the GNSO Council Chair can get a request and use her or his discretion to forward it to the SPIRT Team. The Council Chair would have to send it to the rest of the Council. Then the Council does not have a process where it can approve the forwarding of the request to the SPIRT team immediately. It would have to take that action at a meeting. And if the request does not come in within 14 days before a meeting (I may have the number of days wrong), then it cannot be dealt with at that next meeting, but has to be dealt with at the following one or a newly set up extraordinary meeting (which could be up to 40+ days after the request comes in). Then, if the SPIRT team is just going to discuss and recommend that it is a policy level change and must be dealt with through the GNSO anyway. So, that process could take at least another 30 days to send it back from where it came. So, in total now, you could have up to 70 days just to get to the point of sending back the request to the body that initially had the quest. That is a VERY long time if the request is urgent. We have to think of the gTLD Program like a business. It needs to move efficiently. If something is clearly policy on its face, then it should go straight to the GNSO to deal with. But most things are never that clear. And sending it directly to the SPIRT to get its thoughts and recommendations to help the Council and Community is essentially. The Council can accept/reject those as it sees fit. Please look out for an email from me in next couple of days with a better explanation about why this is needed. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Thursday, December 12, 2019 9:39 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>>; Steve Chan <steve.chan@icann.org<mailto:steve.chan@icann.org>>; Cheryl Langdon-Orr <langdonorr@gmail.com<mailto:langdonorr@gmail.com>> Subject: Predictability Framework Hi all, I think Donna's suggestion to run through GNSO Council if request comes from Board or from Councilor FIRST to determine whether an issue is policy or is implementation and should be addressed by SPIRT makes perfect sense. (Jeff may disagree with this.) If issue is raised by staff, it should be reviewed by SPIRT and SPIRT should make a recommendation to GNSO Council as to whether it is policy or implementation. (Any Council member could challenge and invoke a process that is in the Annexes. This is true even if SPIRT treats the issue as implementation but someone on Council believes it is policy.) I still believe it may be prudent to limit requests to the SPIRT team on which it commences work to those coming from either (a) staff or from (b) GNSO Council. Community members can still give input to the Board, the GNSO Council, and/or staff. It's just chatter until a written request comes (a) From the Board to the GNSO Council and from GNSO Council to the SPIRT OR (b) from staff to the SPIRT with a recommendation from SPIRT to the GNSO Council. That would be my view of a possible compromise - not sure Jeff would agree. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D5B198.C08589A0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lrrc.com_&d=DwMFAw&c=MOp...> [cid:image003.jpg@01D5B198.C08589A0] 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. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMFAw&c...> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>