[Gnso-newgtld-wg] Items on Predictability we did not get to on last WG Call
jeff at jjnsolutions.com
Tue Oct 27 16:58:12 UTC 2020
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
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.
* 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.
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.
* 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.
* 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.
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.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
[cid:image002.png at 01D6AC60.D41D3490]
Jeffrey J. Neuman
Founder & CEO
JJN Solutions, LLC
E: jeff at jjnsolutions.com<mailto:jeff at jjnsolutions.com>
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 20555 bytes
More information about the Gnso-newgtld-wg