[EXTERNAL]

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[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:

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.

 

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

 

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

 

[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.)

 

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

 

3. 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?

 

3. 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.[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.

 

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

 

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

 

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

 

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

 

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

 

7. 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!”

 

 

Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com http://jjnsolutions.com