Response to Anne and Donna on Predictability (Renamed Thread)
In an attempt to shorten the thread and not force everyone to read the entire chain, I am starting a new one: 1, Question from Donna: Is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. * Jeff Response: As a Working Group I don't think we can force the Board to refer relevant GAC Advice to the SPIRT even if we wanted to. I would hope that if the SPIRT is working as intended that the Board would do so not because it is required to, but because there is a benefit from doing so. This is sort of akin to the Board waiting for GNSO input on GAC Consensus Advice on GNSO issues prior to it making a decision on GAC Advice. I don't believe anything requires the Board to wait for GNSO input, but by practice, it generally does. 2. Regarding the Ability of GAC to Refer items directly to the SPIRT * Donna: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Jeff: I find this argument persuasive, but would like to hear from others especially those that we afraid of lobbying. 3. Regarding a GAC (or other SO/AC Liaison to the SPIRT * Donna: I have no objection to a Liaison, but the role would need to be defined. * Anne - I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. * Jeff: Just to double check, would these also support Liaisons from the other SOs and ACs? 4. Regarding a Time Frame by which the SPIRT must finalize its Recommendations / Advice * Donna: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. * Anne: I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * Jeff: We have a very high level flow chart which I will ask ICANN policy staff to provide the link again. I agree that it is hard in advance to set a mandatory time limit for a response. But what if we say that all referrals to the SPIRT must indicate the expected turn around time as to when a response is needed. And upon acceptance of the referral the SPIRT should either agree with that timeline or provide an agreed upon counter to the referral on the time it likely would take? This would also help the GNSO Council in its supervision over the SPIRT.? 5. On the ability for the Board to Respond to Emergency Situations * Donna: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. * Anne: If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? * Jeff: I think the board is not asking us, but rather telling us that they will always need to reserve for itself the ability to take action in an emergency and I do not believe they will want us / or let us define what constitutes that emergency. Certainly Transparency as Donna points out will be critical and I think required disclosure is a great idea. If the Board's action impacts contracted parties that have already executed an RA, then yes, it will need to be in the form of a Temp Spec (if done unilaterally). But if it just impacts applicants, then a Temp Spec if not required. ALL - Is transparency the only check and balance? 6. On the Role of Precedent within the SPIRT * Donna: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. * Anne: GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * Jeff: Anne, I think it is fair to give the GNSO the final say on whether something should be precedent or not, but not everything will need a GNSO Council resolution. Remember that the GNSO can always choose not to comment on, or approve, a SPIRT Recommendation. So, in cases where they do not, then are we saying that shouldn't act as precedent? 7. On Level of Detail in Change Log * Donna: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. 8. On ICANN's Ability to Act Quickly * Donna The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. * Anne: Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * Jeff: It is hard to see how any issue that materially impacts applicants will need to be resolved so quickly as to not allow the SPIRT to be brought into the loop to make a recommendation. Excluding true "emergencies" [See Above], the goal is to involve the SPIRT early to ensure that all possible consequences are considered. And if something must have a fast turnaround, well then the SPIRT will have to accommodate. Its easy in the abstract to say that things will come up that will require quick action, but the reality is that had things (like Digital Archery) been considered by those outside of ICANN staff, in theory also it is possible some of those issues would never have arisen. 9. Re Membership of the SPIRT being limited * Donna: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. * Anne Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z?SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" * Jeff: I believe both can be true. We can have a limited membership that represents the various ICANN stakeholders. Remember we are also looking for qualified members that know and understand the issues. Would love some more comments on this one. [cid:image003.png@01D6ADE0.26DA5250] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jeff Neuman Sent: Tuesday, October 27, 2020 9:58 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Items on Predictability we did not get to on last WG Call Notice: This email is from an external sender. All, Notes from the meeting that occurred at 03:00 UTC on Tuesday will be out shortly. With this e-mail, however, I want to raise some issues that we did not necessarily have time to discuss on the call, but which I think we may need to address. Remember, that discussions on this e-mail list are going to be critical to getting our work done. Quick note on caution: As described on the call, we are not relitigating any of these issues. The purpose here is to evaluate the questions raised and determime whether we should respond by updating the recommendations. Also, please make sure that you refer to the Predictability Section of the Draft Final Report when responding. On the Topic of Predictability - For some of these I have proposed a path forward in line with other recommendations. Please feel free to disagree. Ultimately it is not my view that matters, but rather the will of the group. 1. The GAC has asked the following: * Should they be able to refer things directly to the SPIRT? We started this discussion on the call. The recommendation in the draft final report states that only the GNSO Council, ICANN Board, and ICANN staff should be able to refer things to the SPIRT. This was to avoid lobbying and to keep the work of the SPIRT focused and as free as possible from interference. Remember, not even the SPIRT can take up issues on its own. It must come from one of the 3 sources. Our choices are: i. To stick with our original position, pointing out that if the GAC issues Consensus Advice to the Board, the Board can bring it to the attention of the SPIRT. Alternatively, if the GAC can convince ICANN staff about the importance of an issue, then ICANN staff can bring it to the attention of the SPIRT. OR[Aikman-Scalese, Anne] I believe the IPC would support the original position. DA: I have a question-is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. ii. Allow the GAC to refer items to the SPIRT. This could lessen delay if the GAC issues consensus advice. Rather than having to wait for the ICANN Board to address the issue only to refer it to the SPIRT could waste precious time. If we go down this path, then the following questions could arise: * Must the referral only be accepted if there is a GAC Consensus? * If we allow the GAC to refer items to the SPIRT, do we allow each of the other ACs (particularly the ALAC and SSAC)? If not, why are we making treating the GAC any differently. DA: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Perhaps an easier question, should we recommend that the GAC have a Liaison on the SPIRT? We state that the composition of the SPIRT should be open so long as they possess the requisite skills (I am paraphrasing). So, I would think that offering the ACs, including the GAC, liaison positions on the SPIRT, does not seem like a huge issue. We should again, however, stress that they must have the qualifications that we require of all others. DA: I have no objection to a Liaison, but the role would need to be defined. [Aikman-Scalese, Anne] I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. 1. The ICANN Board has raised the following questions that I believe are important to thing about: * Do we want to recommend a timeframe by which the SPIRT must make a recommendation? We have discussed this briefly before and did not decide to include one because each issue is different and it may not be possible to dictate a timeframe. DA: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. [Aikman-Scalese, Anne] I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * What role does precedent play? For this one, I would think that because predictability is one of our main goals, that there really needs to be a good reason to not follow precedent. We don't want issues to keep being re-litigated at the SPIRT level just because there may be different members on the SPIRT or they may involve different applications. So, I would state that once a recommendation has been issued (and accepted), then absent a substantial change in facts or circumstances, that issue should not be taken up again by the SPIRT. DA: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. [Aikman-Scalese, Anne] GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * The ICANN Board wants to make sure that it has the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities. This is repeated in the ICANN Org comments. Recommendation: So long as there is truly an emergency situation, I can see no reason why we would not make it clear that ICANN Has a right to act. We could state, however, that such action must be narrowly tailored to address the emergency situation and use the least restrictive means to achieve their purpose. To allow otherwise, could circumvent the Predictability Framework. DA: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. [Aikman-Scalese, Anne] If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? 1. ICANN Org has raised the following: * They have asked how the Predictability Framework fits in with Recommendations 3.6 and 3.7. Those Recs address future reviews and state that any material changes stemming from future reviews should not be implemented until the round following the round in which the results of the review were adopted. Recommendation: We should state that it is the specific intent of the Working Group that the Predictability Model should address issues as they arise and not stop future rounds. When addressing issues, the SPIRT, ICANN, and the community must decide whether any resulting changes apply to the current round or only to the next subsequent round. However, any formal reviews (like the CCT-RT or any other one the community decides to do) follow the Recommendations in 3.6 and 3.7.[Aikman-Scalese, Anne] It seems this question would have to turn on whether or not GNSO Council rules that a PDP or EPDP is necessary. If so, you don't want folks rushing to file applications before the policy is adequately developed. If the issue raised necessitates a PDP or EPDP, the GNSO Council would need to scope which applications are prohibited until the policy matter is settled via PDP or EPDP. The SPIRT can't decide policy matters and cannot make this determination. Only GNSO Council can do that unless the ICANN Board intervenes for some Security, Stability, Resiliency reason or else the ICANN Board might have to act on GAC Advice not to allow another round to proceed until the issue is settled. * ICANN states that the level of detail in change logs may not to be determined by other considerations such as security, confidentiality, privacy, or other considerations. Recommendation. Perhaps we state that the level of detail must be sufficient for the community to understand the scope and nature of the change without compromising security, the privacy of individuals, or confidentiality obligations owed to applicants or other third parties. DA: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. * We state that where a significant issue arises and it requires resolution via the Predictability Framework, applicants should be afforded the opportunity to withdraw their application and receive an appropriate refund. The question is whether all such refunds should follow the standard refund schedule or whether they should be refunded a different amount? Recommendation: If the issue would still allow the application to proceed, then it should be the standard refund schedule. If, however, the issue makes it impossible for the applications to proceed, then consideration should be given for a full refund. DA: In the event that a change in the program after applications have been submitted makes it difficult for the applicant to remain true to their business plan or makes their application largely ineligible without change, then a full refund should be available. [Aikman-Scalese, Anne] Personal Opinion: I think this depends on what stage the application is at. For example, if applicant proceeded with full knowledge that there was no Closed Generic policy that was final and proceeded to file Closed Generic applications, I think the Board would have to determine the level of refund. If this WG doesn't come up with Closed Generic policy, I think we face the risk that the Board will send that result back to GNSO Council and say "try again" and "we won't allow ICANN org to process those applications until you get the policy work done". And of course based on the policy we have now, no new applications for that string for an open TLD would be permitted either. * ICANN has made the assumption that the SPIRT will not allow ICANN to act quickly and points the Draw as an example where they created "Proxy Lawyers" to take their place. My take: However, what ICANN did not mention in their comments is that it took several months to come up with the proposal for the draw and therefore perhaps a SPIRT would have brought this issue to ICANN sooner, thereby REDUCING the time it took to figure this issue out. Recommendation: No change to existing language. DA: The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. [Aikman-Scalese, Anne] Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * ICANN would like for us to develop more guidance as to when someone should recuse themselves from the recommendation. There is a Conflict section in Appendix E. Recommendation: This is a level of detail perhaps that an IRT may want to weigh in on. I don't believe we need to address. DA: Given we discussed this at length, perhaps the IRT can develop more specificity on this based on other examples available. However, we should specify this in the Final Report.[Aikman-Scalese, Anne] IRT needs to develop a more detailed SOI questionnaire for the purposes of the SPIRT. The tough issue will be when recusal is "required" versus voluntary - can't remember how this works. * Use of the word "Subcontractors" should be changed to vendors / contractors. - Recommendation. This is a very minor point and we should just accept this change. DA: Agree we should change. * Do we want to limit the size of the SPIRT (Which does not include experts)? Recommendation. Will leave this to the group, but note that it can be addressed by the IRT and/or even the GNSO Council when the SPIRT is initially set up. DA: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. [Aikman-Scalese, Anne] Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z? "SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" [cid:image004.png@01D6ADDD.52670830] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com ________________________________ 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.
All, just a follow up on 1. Below: 1, Question from Donna: Is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. * Jeff Response: As a Working Group I don't think we can force the Board to refer relevant GAC Advice to the SPIRT even if we wanted to. I would hope that if the SPIRT is working as intended that the Board would do so not because it is required to, but because there is a benefit from doing so. This is sort of akin to the Board waiting for GNSO input on GAC Consensus Advice on GNSO issues prior to it making a decision on GAC Advice. I don't believe anything requires the Board to wait for GNSO input, but by practice, it generally does. DA: My concern is that many applicants in the 2012 round experienced considerable delays because of GAC advice provided in the Beijing Communique<https://gac.icann.org/contentMigrated/icann46-beijing-communique>. The Predictability Framework is an attempt to overcome these delays and while we all hope the Board would use SPIRT because of the benefit from doing so it would be good to have this confirmed by the Board. I also don't think we've addressed what would happen in the event that recommendations or guidance provided the SPIRT is ultimately rejected, but I stand to be corrected on this. The Board has encouraged us " ... to provide as much detail as possible to ensure clarity around the roles and responsibilities of the GNSO Council, ICANN org, applicants, objectors, other SO/ACs as well as the Board vis-a-vis the predictability framework. To inform implementation, the PDP WG may find it useful to provide case studies to illustrate roles and responsibilities of these different actors if and when changes to future application round processes are proposed and/or required." I wonder if there would be value in doing a case study on how the process would have played out if there had been a SPIRT in 2012. Would that have impacted the Board's consideration of the GAC advice contained in the Beijing Communique? If it is the case that the Board would not forward GAC advice to the SPIRT for consideration and recommendation; then perhaps we could include language that encourages the Board to engage with the SPIRT in some meaningful way to address potential concerns about top-down decisions. Donna From: Jeff Neuman <jeff@jjnsolutions.com> Sent: Thursday, October 29, 2020 7:42 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com>; Donna Austin <Donna@registry.godaddy>; gnso-newgtld-wg@icann.org Subject: Response to Anne and Donna on Predictability (Renamed Thread) Notice: This email is from an external sender. In an attempt to shorten the thread and not force everyone to read the entire chain, I am starting a new one: 1, Question from Donna: Is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. * Jeff Response: As a Working Group I don't think we can force the Board to refer relevant GAC Advice to the SPIRT even if we wanted to. I would hope that if the SPIRT is working as intended that the Board would do so not because it is required to, but because there is a benefit from doing so. This is sort of akin to the Board waiting for GNSO input on GAC Consensus Advice on GNSO issues prior to it making a decision on GAC Advice. I don't believe anything requires the Board to wait for GNSO input, but by practice, it generally does. DA: My concern is that many applicants in the 2012 round experienced considerable delays because of GAC advice provided in the Beijing Communique<https://gac.icann.org/contentMigrated/icann46-beijing-communique>. The Predictability Framework is an attempt to overcome these delays and while we all hope the Board would use SPIRT because of the benefit from doing so it would be good to have this confirmed by the Board. I also don't think we've addressed what would happen in the event that recommendations or guidance provided the SPIRT is ultimately rejected, but I stand to be corrected on this. The Board has encouraged us " ... to provide as much detail as possible to ensure clarity around the roles and responsibilities of the GNSO Council, ICANN org, applicants, objectors, other SO/ACs as well as the Board vis-a-vis the predictability framework. To inform implementation, the PDP WG may find it useful to provide case studies to illustrate roles and responsibilities of these different actors if and when changes to future application round processes are proposed and/or required." I wonder if there would be value in doing a case study on how the process would have played out if there had been a SPIRT in 2012. Would that have impacted the Board's consideration of the GAC advice contained in the Beijing Communique? 2. Regarding the Ability of GAC to Refer items directly to the SPIRT * Donna: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Jeff: I find this argument persuasive, but would like to hear from others especially those that we afraid of lobbying. 3. Regarding a GAC (or other SO/AC Liaison to the SPIRT * Donna: I have no objection to a Liaison, but the role would need to be defined. * Anne - I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. * Jeff: Just to double check, would these also support Liaisons from the other SOs and ACs? 4. Regarding a Time Frame by which the SPIRT must finalize its Recommendations / Advice * Donna: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. * Anne: I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * Jeff: We have a very high level flow chart which I will ask ICANN policy staff to provide the link again. I agree that it is hard in advance to set a mandatory time limit for a response. But what if we say that all referrals to the SPIRT must indicate the expected turn around time as to when a response is needed. And upon acceptance of the referral the SPIRT should either agree with that timeline or provide an agreed upon counter to the referral on the time it likely would take? This would also help the GNSO Council in its supervision over the SPIRT.? 5. On the ability for the Board to Respond to Emergency Situations * Donna: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. * Anne: If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? * Jeff: I think the board is not asking us, but rather telling us that they will always need to reserve for itself the ability to take action in an emergency and I do not believe they will want us / or let us define what constitutes that emergency. Certainly Transparency as Donna points out will be critical and I think required disclosure is a great idea. If the Board's action impacts contracted parties that have already executed an RA, then yes, it will need to be in the form of a Temp Spec (if done unilaterally). But if it just impacts applicants, then a Temp Spec if not required. ALL - Is transparency the only check and balance? 6. On the Role of Precedent within the SPIRT * Donna: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. * Anne: GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * Jeff: Anne, I think it is fair to give the GNSO the final say on whether something should be precedent or not, but not everything will need a GNSO Council resolution. Remember that the GNSO can always choose not to comment on, or approve, a SPIRT Recommendation. So, in cases where they do not, then are we saying that shouldn't act as precedent? 7. On Level of Detail in Change Log * Donna: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. 8. On ICANN's Ability to Act Quickly * Donna The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. * Anne: Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * Jeff: It is hard to see how any issue that materially impacts applicants will need to be resolved so quickly as to not allow the SPIRT to be brought into the loop to make a recommendation. Excluding true "emergencies" [See Above], the goal is to involve the SPIRT early to ensure that all possible consequences are considered. And if something must have a fast turnaround, well then the SPIRT will have to accommodate. Its easy in the abstract to say that things will come up that will require quick action, but the reality is that had things (like Digital Archery) been considered by those outside of ICANN staff, in theory also it is possible some of those issues would never have arisen. 9. Re Membership of the SPIRT being limited * Donna: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. * Anne Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z?SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" * Jeff: I believe both can be true. We can have a limited membership that represents the various ICANN stakeholders. Remember we are also looking for qualified members that know and understand the issues. Would love some more comments on this one. [cid:image003.png@01D6ADE0.26DA5250] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jeff Neuman Sent: Tuesday, October 27, 2020 9:58 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Items on Predictability we did not get to on last WG Call Notice: This email is from an external sender. All, Notes from the meeting that occurred at 03:00 UTC on Tuesday will be out shortly. With this e-mail, however, I want to raise some issues that we did not necessarily have time to discuss on the call, but which I think we may need to address. Remember, that discussions on this e-mail list are going to be critical to getting our work done. Quick note on caution: As described on the call, we are not relitigating any of these issues. The purpose here is to evaluate the questions raised and determime whether we should respond by updating the recommendations. Also, please make sure that you refer to the Predictability Section of the Draft Final Report when responding. On the Topic of Predictability - For some of these I have proposed a path forward in line with other recommendations. Please feel free to disagree. Ultimately it is not my view that matters, but rather the will of the group. 1. The GAC has asked the following: * Should they be able to refer things directly to the SPIRT? We started this discussion on the call. The recommendation in the draft final report states that only the GNSO Council, ICANN Board, and ICANN staff should be able to refer things to the SPIRT. This was to avoid lobbying and to keep the work of the SPIRT focused and as free as possible from interference. Remember, not even the SPIRT can take up issues on its own. It must come from one of the 3 sources. Our choices are: i. To stick with our original position, pointing out that if the GAC issues Consensus Advice to the Board, the Board can bring it to the attention of the SPIRT. Alternatively, if the GAC can convince ICANN staff about the importance of an issue, then ICANN staff can bring it to the attention of the SPIRT. OR[Aikman-Scalese, Anne] I believe the IPC would support the original position. DA: I have a question-is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. ii. Allow the GAC to refer items to the SPIRT. This could lessen delay if the GAC issues consensus advice. Rather than having to wait for the ICANN Board to address the issue only to refer it to the SPIRT could waste precious time. If we go down this path, then the following questions could arise: * Must the referral only be accepted if there is a GAC Consensus? * If we allow the GAC to refer items to the SPIRT, do we allow each of the other ACs (particularly the ALAC and SSAC)? If not, why are we making treating the GAC any differently. DA: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Perhaps an easier question, should we recommend that the GAC have a Liaison on the SPIRT? We state that the composition of the SPIRT should be open so long as they possess the requisite skills (I am paraphrasing). So, I would think that offering the ACs, including the GAC, liaison positions on the SPIRT, does not seem like a huge issue. We should again, however, stress that they must have the qualifications that we require of all others. DA: I have no objection to a Liaison, but the role would need to be defined. [Aikman-Scalese, Anne] I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. 1. The ICANN Board has raised the following questions that I believe are important to thing about: * Do we want to recommend a timeframe by which the SPIRT must make a recommendation? We have discussed this briefly before and did not decide to include one because each issue is different and it may not be possible to dictate a timeframe. DA: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. [Aikman-Scalese, Anne] I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * What role does precedent play? For this one, I would think that because predictability is one of our main goals, that there really needs to be a good reason to not follow precedent. We don't want issues to keep being re-litigated at the SPIRT level just because there may be different members on the SPIRT or they may involve different applications. So, I would state that once a recommendation has been issued (and accepted), then absent a substantial change in facts or circumstances, that issue should not be taken up again by the SPIRT. DA: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. [Aikman-Scalese, Anne] GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * The ICANN Board wants to make sure that it has the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities. This is repeated in the ICANN Org comments. Recommendation: So long as there is truly an emergency situation, I can see no reason why we would not make it clear that ICANN Has a right to act. We could state, however, that such action must be narrowly tailored to address the emergency situation and use the least restrictive means to achieve their purpose. To allow otherwise, could circumvent the Predictability Framework. DA: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. [Aikman-Scalese, Anne] If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? 1. ICANN Org has raised the following: * They have asked how the Predictability Framework fits in with Recommendations 3.6 and 3.7. Those Recs address future reviews and state that any material changes stemming from future reviews should not be implemented until the round following the round in which the results of the review were adopted. Recommendation: We should state that it is the specific intent of the Working Group that the Predictability Model should address issues as they arise and not stop future rounds. When addressing issues, the SPIRT, ICANN, and the community must decide whether any resulting changes apply to the current round or only to the next subsequent round. However, any formal reviews (like the CCT-RT or any other one the community decides to do) follow the Recommendations in 3.6 and 3.7.[Aikman-Scalese, Anne] It seems this question would have to turn on whether or not GNSO Council rules that a PDP or EPDP is necessary. If so, you don't want folks rushing to file applications before the policy is adequately developed. If the issue raised necessitates a PDP or EPDP, the GNSO Council would need to scope which applications are prohibited until the policy matter is settled via PDP or EPDP. The SPIRT can't decide policy matters and cannot make this determination. Only GNSO Council can do that unless the ICANN Board intervenes for some Security, Stability, Resiliency reason or else the ICANN Board might have to act on GAC Advice not to allow another round to proceed until the issue is settled. * ICANN states that the level of detail in change logs may not to be determined by other considerations such as security, confidentiality, privacy, or other considerations. Recommendation. Perhaps we state that the level of detail must be sufficient for the community to understand the scope and nature of the change without compromising security, the privacy of individuals, or confidentiality obligations owed to applicants or other third parties. DA: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. * We state that where a significant issue arises and it requires resolution via the Predictability Framework, applicants should be afforded the opportunity to withdraw their application and receive an appropriate refund. The question is whether all such refunds should follow the standard refund schedule or whether they should be refunded a different amount? Recommendation: If the issue would still allow the application to proceed, then it should be the standard refund schedule. If, however, the issue makes it impossible for the applications to proceed, then consideration should be given for a full refund. DA: In the event that a change in the program after applications have been submitted makes it difficult for the applicant to remain true to their business plan or makes their application largely ineligible without change, then a full refund should be available. [Aikman-Scalese, Anne] Personal Opinion: I think this depends on what stage the application is at. For example, if applicant proceeded with full knowledge that there was no Closed Generic policy that was final and proceeded to file Closed Generic applications, I think the Board would have to determine the level of refund. If this WG doesn't come up with Closed Generic policy, I think we face the risk that the Board will send that result back to GNSO Council and say "try again" and "we won't allow ICANN org to process those applications until you get the policy work done". And of course based on the policy we have now, no new applications for that string for an open TLD would be permitted either. * ICANN has made the assumption that the SPIRT will not allow ICANN to act quickly and points the Draw as an example where they created "Proxy Lawyers" to take their place. My take: However, what ICANN did not mention in their comments is that it took several months to come up with the proposal for the draw and therefore perhaps a SPIRT would have brought this issue to ICANN sooner, thereby REDUCING the time it took to figure this issue out. Recommendation: No change to existing language. DA: The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. [Aikman-Scalese, Anne] Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * ICANN would like for us to develop more guidance as to when someone should recuse themselves from the recommendation. There is a Conflict section in Appendix E. Recommendation: This is a level of detail perhaps that an IRT may want to weigh in on. I don't believe we need to address. DA: Given we discussed this at length, perhaps the IRT can develop more specificity on this based on other examples available. However, we should specify this in the Final Report.[Aikman-Scalese, Anne] IRT needs to develop a more detailed SOI questionnaire for the purposes of the SPIRT. The tough issue will be when recusal is "required" versus voluntary - can't remember how this works. * Use of the word "Subcontractors" should be changed to vendors / contractors. - Recommendation. This is a very minor point and we should just accept this change. DA: Agree we should change. * Do we want to limit the size of the SPIRT (Which does not include experts)? Recommendation. Will leave this to the group, but note that it can be addressed by the IRT and/or even the GNSO Council when the SPIRT is initially set up. DA: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. [Aikman-Scalese, Anne] Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z? "SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" [cid:image003.png@01D6AEA8.E35E5FC0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com ________________________________ 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.
Thanks Donna. Some comments below yours. In Green [cid:image003.png@01D6AED2.D9FB0440] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com From: Donna@registry.godaddy <Donna@registry.godaddy> Sent: Friday, October 30, 2020 2:19 PM To: Jeff Neuman <jeff@jjnsolutions.com>; Aikman-Scalese, Anne <AAikman@lrrc.com>; gnso-newgtld-wg@icann.org Subject: RE: Response to Anne and Donna on Predictability (Renamed Thread) All, just a follow up on 1. Below: 1, Question from Donna: Is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. * Jeff Response: As a Working Group I don't think we can force the Board to refer relevant GAC Advice to the SPIRT even if we wanted to. I would hope that if the SPIRT is working as intended that the Board would do so not because it is required to, but because there is a benefit from doing so. This is sort of akin to the Board waiting for GNSO input on GAC Consensus Advice on GNSO issues prior to it making a decision on GAC Advice. I don't believe anything requires the Board to wait for GNSO input, but by practice, it generally does. Donna: My concern is that many applicants in the 2012 round experienced considerable delays because of GAC advice provided in the Beijing Communique<https://gac.icann.org/contentMigrated/icann46-beijing-communique>. Jeff: We need to be careful here. The applicants did not experience delay because of GAC Advice, but rather the time it took for the ICANN Board (and ICANN Org) to figure out what to do with that advice. And it is precisely this distinction where the SPIRT will help. Remember the Board met perhaps once or twice a month so issues dragged on and on until Board members could get together and discuss. We have no real insight into how the Board actually went about trying to come up with solutions because that information is just not available. Donna: I also don't think we've addressed what would happen in the event that recommendations or guidance provided the SPIRT is ultimately rejected, but I stand to be corrected on this. Jeff: There are several places where recommendations can get 'rejected'. If the GNSO does not want to accept the recommendations, then it is free to do so and can start its own process. Presumably then the Board would choose whether or not to work with the GNSO. I don't know if we can state anything for certain to either restrict the Board from rejecting the SPIRT team advice or requiring them to accept it. And not sure we can go into any more detail on that. Donna: The Board has encouraged us " ... to provide as much detail as possible to ensure clarity around the roles and responsibilities of the GNSO Council, ICANN org, applicants, objectors, other SO/ACs as well as the Board vis-a-vis the predictability framework. To inform implementation, the PDP WG may find it useful to provide case studies to illustrate roles and responsibilities of these different actors if and when changes to future application round processes are proposed and/or required." I wonder if there would be value in doing a case study on how the process would have played out if there had been a SPIRT in 2012. Would that have impacted the Board's consideration of the GAC advice contained in the Beijing Communique? Jeff: We did some of that with examples in the Guidebook. I suppose we can take try to do a hypothetical case study, but it would be impossible to show whether it would or would not have impacted what happened in 2012 other than potentially with respect to timelines. Donna; If it is the case that the Board would not forward GAC advice to the SPIRT for consideration and recommendation; then perhaps we could include language that encourages the Board to engage with the SPIRT in some meaningful way to address potential concerns about top-down decisions. Jeff: Do you want to draft some text for the working group covering this scenario? Donna From: Jeff Neuman <jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com>> Sent: Thursday, October 29, 2020 7:42 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>>; Donna Austin <Donna@registry.godaddy<mailto:Donna@registry.godaddy>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Response to Anne and Donna on Predictability (Renamed Thread) Notice: This email is from an external sender. In an attempt to shorten the thread and not force everyone to read the entire chain, I am starting a new one: 1, Question from Donna: Is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. * Jeff Response: As a Working Group I don't think we can force the Board to refer relevant GAC Advice to the SPIRT even if we wanted to. I would hope that if the SPIRT is working as intended that the Board would do so not because it is required to, but because there is a benefit from doing so. This is sort of akin to the Board waiting for GNSO input on GAC Consensus Advice on GNSO issues prior to it making a decision on GAC Advice. I don't believe anything requires the Board to wait for GNSO input, but by practice, it generally does. DA: My concern is that many applicants in the 2012 round experienced considerable delays because of GAC advice provided in the Beijing Communique<https://gac.icann.org/contentMigrated/icann46-beijing-communique>. The Predictability Framework is an attempt to overcome these delays and while we all hope the Board would use SPIRT because of the benefit from doing so it would be good to have this confirmed by the Board. I also don't think we've addressed what would happen in the event that recommendations or guidance provided the SPIRT is ultimately rejected, but I stand to be corrected on this. The Board has encouraged us " ... to provide as much detail as possible to ensure clarity around the roles and responsibilities of the GNSO Council, ICANN org, applicants, objectors, other SO/ACs as well as the Board vis-a-vis the predictability framework. To inform implementation, the PDP WG may find it useful to provide case studies to illustrate roles and responsibilities of these different actors if and when changes to future application round processes are proposed and/or required." I wonder if there would be value in doing a case study on how the process would have played out if there had been a SPIRT in 2012. Would that have impacted the Board's consideration of the GAC advice contained in the Beijing Communique? 2. Regarding the Ability of GAC to Refer items directly to the SPIRT * Donna: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Jeff: I find this argument persuasive, but would like to hear from others especially those that we afraid of lobbying. 3. Regarding a GAC (or other SO/AC Liaison to the SPIRT * Donna: I have no objection to a Liaison, but the role would need to be defined. * Anne - I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. * Jeff: Just to double check, would these also support Liaisons from the other SOs and ACs? 4. Regarding a Time Frame by which the SPIRT must finalize its Recommendations / Advice * Donna: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. * Anne: I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * Jeff: We have a very high level flow chart which I will ask ICANN policy staff to provide the link again. I agree that it is hard in advance to set a mandatory time limit for a response. But what if we say that all referrals to the SPIRT must indicate the expected turn around time as to when a response is needed. And upon acceptance of the referral the SPIRT should either agree with that timeline or provide an agreed upon counter to the referral on the time it likely would take? This would also help the GNSO Council in its supervision over the SPIRT.? 5. On the ability for the Board to Respond to Emergency Situations * Donna: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. * Anne: If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? * Jeff: I think the board is not asking us, but rather telling us that they will always need to reserve for itself the ability to take action in an emergency and I do not believe they will want us / or let us define what constitutes that emergency. Certainly Transparency as Donna points out will be critical and I think required disclosure is a great idea. If the Board's action impacts contracted parties that have already executed an RA, then yes, it will need to be in the form of a Temp Spec (if done unilaterally). But if it just impacts applicants, then a Temp Spec if not required. ALL - Is transparency the only check and balance? 6. On the Role of Precedent within the SPIRT * Donna: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. * Anne: GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * Jeff: Anne, I think it is fair to give the GNSO the final say on whether something should be precedent or not, but not everything will need a GNSO Council resolution. Remember that the GNSO can always choose not to comment on, or approve, a SPIRT Recommendation. So, in cases where they do not, then are we saying that shouldn't act as precedent? 7. On Level of Detail in Change Log * Donna: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. 8. On ICANN's Ability to Act Quickly * Donna The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. * Anne: Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * Jeff: It is hard to see how any issue that materially impacts applicants will need to be resolved so quickly as to not allow the SPIRT to be brought into the loop to make a recommendation. Excluding true "emergencies" [See Above], the goal is to involve the SPIRT early to ensure that all possible consequences are considered. And if something must have a fast turnaround, well then the SPIRT will have to accommodate. Its easy in the abstract to say that things will come up that will require quick action, but the reality is that had things (like Digital Archery) been considered by those outside of ICANN staff, in theory also it is possible some of those issues would never have arisen. 9. Re Membership of the SPIRT being limited * Donna: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. * Anne Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z?SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" * Jeff: I believe both can be true. We can have a limited membership that represents the various ICANN stakeholders. Remember we are also looking for qualified members that know and understand the issues. Would love some more comments on this one. [cid:image005.png@01D6AED1.F30AAF90] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jeff Neuman Sent: Tuesday, October 27, 2020 9:58 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Items on Predictability we did not get to on last WG Call Notice: This email is from an external sender. All, Notes from the meeting that occurred at 03:00 UTC on Tuesday will be out shortly. With this e-mail, however, I want to raise some issues that we did not necessarily have time to discuss on the call, but which I think we may need to address. Remember, that discussions on this e-mail list are going to be critical to getting our work done. Quick note on caution: As described on the call, we are not relitigating any of these issues. The purpose here is to evaluate the questions raised and determime whether we should respond by updating the recommendations. Also, please make sure that you refer to the Predictability Section of the Draft Final Report when responding. On the Topic of Predictability - For some of these I have proposed a path forward in line with other recommendations. Please feel free to disagree. Ultimately it is not my view that matters, but rather the will of the group. 1. The GAC has asked the following: * Should they be able to refer things directly to the SPIRT? We started this discussion on the call. The recommendation in the draft final report states that only the GNSO Council, ICANN Board, and ICANN staff should be able to refer things to the SPIRT. This was to avoid lobbying and to keep the work of the SPIRT focused and as free as possible from interference. Remember, not even the SPIRT can take up issues on its own. It must come from one of the 3 sources. Our choices are: i. To stick with our original position, pointing out that if the GAC issues Consensus Advice to the Board, the Board can bring it to the attention of the SPIRT. Alternatively, if the GAC can convince ICANN staff about the importance of an issue, then ICANN staff can bring it to the attention of the SPIRT. OR[Aikman-Scalese, Anne] I believe the IPC would support the original position. DA: I have a question-is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. ii. Allow the GAC to refer items to the SPIRT. This could lessen delay if the GAC issues consensus advice. Rather than having to wait for the ICANN Board to address the issue only to refer it to the SPIRT could waste precious time. If we go down this path, then the following questions could arise: * Must the referral only be accepted if there is a GAC Consensus? * If we allow the GAC to refer items to the SPIRT, do we allow each of the other ACs (particularly the ALAC and SSAC)? If not, why are we making treating the GAC any differently. DA: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Perhaps an easier question, should we recommend that the GAC have a Liaison on the SPIRT? We state that the composition of the SPIRT should be open so long as they possess the requisite skills (I am paraphrasing). So, I would think that offering the ACs, including the GAC, liaison positions on the SPIRT, does not seem like a huge issue. We should again, however, stress that they must have the qualifications that we require of all others. DA: I have no objection to a Liaison, but the role would need to be defined. [Aikman-Scalese, Anne] I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. 1. The ICANN Board has raised the following questions that I believe are important to thing about: * Do we want to recommend a timeframe by which the SPIRT must make a recommendation? We have discussed this briefly before and did not decide to include one because each issue is different and it may not be possible to dictate a timeframe. DA: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. [Aikman-Scalese, Anne] I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * What role does precedent play? For this one, I would think that because predictability is one of our main goals, that there really needs to be a good reason to not follow precedent. We don't want issues to keep being re-litigated at the SPIRT level just because there may be different members on the SPIRT or they may involve different applications. So, I would state that once a recommendation has been issued (and accepted), then absent a substantial change in facts or circumstances, that issue should not be taken up again by the SPIRT. DA: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. [Aikman-Scalese, Anne] GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * The ICANN Board wants to make sure that it has the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities. This is repeated in the ICANN Org comments. Recommendation: So long as there is truly an emergency situation, I can see no reason why we would not make it clear that ICANN Has a right to act. We could state, however, that such action must be narrowly tailored to address the emergency situation and use the least restrictive means to achieve their purpose. To allow otherwise, could circumvent the Predictability Framework. DA: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. [Aikman-Scalese, Anne] If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? 1. ICANN Org has raised the following: * They have asked how the Predictability Framework fits in with Recommendations 3.6 and 3.7. Those Recs address future reviews and state that any material changes stemming from future reviews should not be implemented until the round following the round in which the results of the review were adopted. Recommendation: We should state that it is the specific intent of the Working Group that the Predictability Model should address issues as they arise and not stop future rounds. When addressing issues, the SPIRT, ICANN, and the community must decide whether any resulting changes apply to the current round or only to the next subsequent round. However, any formal reviews (like the CCT-RT or any other one the community decides to do) follow the Recommendations in 3.6 and 3.7.[Aikman-Scalese, Anne] It seems this question would have to turn on whether or not GNSO Council rules that a PDP or EPDP is necessary. If so, you don't want folks rushing to file applications before the policy is adequately developed. If the issue raised necessitates a PDP or EPDP, the GNSO Council would need to scope which applications are prohibited until the policy matter is settled via PDP or EPDP. The SPIRT can't decide policy matters and cannot make this determination. Only GNSO Council can do that unless the ICANN Board intervenes for some Security, Stability, Resiliency reason or else the ICANN Board might have to act on GAC Advice not to allow another round to proceed until the issue is settled. * ICANN states that the level of detail in change logs may not to be determined by other considerations such as security, confidentiality, privacy, or other considerations. Recommendation. Perhaps we state that the level of detail must be sufficient for the community to understand the scope and nature of the change without compromising security, the privacy of individuals, or confidentiality obligations owed to applicants or other third parties. DA: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. * We state that where a significant issue arises and it requires resolution via the Predictability Framework, applicants should be afforded the opportunity to withdraw their application and receive an appropriate refund. The question is whether all such refunds should follow the standard refund schedule or whether they should be refunded a different amount? Recommendation: If the issue would still allow the application to proceed, then it should be the standard refund schedule. If, however, the issue makes it impossible for the applications to proceed, then consideration should be given for a full refund. DA: In the event that a change in the program after applications have been submitted makes it difficult for the applicant to remain true to their business plan or makes their application largely ineligible without change, then a full refund should be available. [Aikman-Scalese, Anne] Personal Opinion: I think this depends on what stage the application is at. For example, if applicant proceeded with full knowledge that there was no Closed Generic policy that was final and proceeded to file Closed Generic applications, I think the Board would have to determine the level of refund. If this WG doesn't come up with Closed Generic policy, I think we face the risk that the Board will send that result back to GNSO Council and say "try again" and "we won't allow ICANN org to process those applications until you get the policy work done". And of course based on the policy we have now, no new applications for that string for an open TLD would be permitted either. * ICANN has made the assumption that the SPIRT will not allow ICANN to act quickly and points the Draw as an example where they created "Proxy Lawyers" to take their place. My take: However, what ICANN did not mention in their comments is that it took several months to come up with the proposal for the draw and therefore perhaps a SPIRT would have brought this issue to ICANN sooner, thereby REDUCING the time it took to figure this issue out. Recommendation: No change to existing language. DA: The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. [Aikman-Scalese, Anne] Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * ICANN would like for us to develop more guidance as to when someone should recuse themselves from the recommendation. There is a Conflict section in Appendix E. Recommendation: This is a level of detail perhaps that an IRT may want to weigh in on. I don't believe we need to address. DA: Given we discussed this at length, perhaps the IRT can develop more specificity on this based on other examples available. However, we should specify this in the Final Report.[Aikman-Scalese, Anne] IRT needs to develop a more detailed SOI questionnaire for the purposes of the SPIRT. The tough issue will be when recusal is "required" versus voluntary - can't remember how this works. * Use of the word "Subcontractors" should be changed to vendors / contractors. - Recommendation. This is a very minor point and we should just accept this change. DA: Agree we should change. * Do we want to limit the size of the SPIRT (Which does not include experts)? Recommendation. Will leave this to the group, but note that it can be addressed by the IRT and/or even the GNSO Council when the SPIRT is initially set up. DA: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. [Aikman-Scalese, Anne] Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z? "SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" [cid:image006.png@01D6AED1.F30AAF90] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com ________________________________ 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.
participants (2)
-
Donna＠registry.godaddy -
Jeff Neuman