Jeff, all

 

Comments inline below.

 

Donna

 

From: Gnso-newgtld-wg <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
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:
    1. 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

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:

        1. Must the referral only be accepted if there is a GAC Consensus?
        2. 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.

 

    1. 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.

 

  1. The ICANN Board has raised the following questions that I believe are important to thing about:
    1. 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.

 

    1. 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.

 

    1. 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.

 

  1. ICANN Org has raised the following:
    1. 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.

 

    1. 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.

 

    1. 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.

 

    1. 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.

 

    1. 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.

 

    1. 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.

 

    1. 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.

 

 

Jeffrey J. Neuman

Founder & CEO

JJN Solutions, LLC

p: +1.202.549.5079

E: jeff@jjnsolutions.com

http://jjnsolutions.com