Thanks Elaine. I agree with your assessment for the most part. Here is where it gets tricky....and I will use actual examples from the 2012 round....so we have to pretend we didnt solve some of these issues for this upcoming round. Also, I remember and felt the pain as well with over 350 applications we supported and hundreds of TLDs we launched 😉
Example 1: Digital Archery
In the original final Applicant Guidebook, it said something to the effect that in order to determine the queue of applications, we would use a "secondary-time stamp" skills-based method to determine the order to review of applications. That resulted in the creation of "Digital Archery". This was designed to avoid the randomness of a lottery because ICANN did not at the time have a license to run a lottery and even with a California license to run a lottery, not all states allowed participation. However, as we all know, through a bug a number of us found, the system set up by ICANN was subject to gaming and the ICANN Board realized it could not be used.
OK, so a change needed to be made. The Applicant Guidebook contained a statement saying it needed to be a "secondary-time stamp" method and not randomized. But ICANN thought it would be best if we could develop a compliant lottery system. ICANN Org nor the ICANN Board sought feedback from the GNSO Council. It did have a limited public comment period, but let's face it, no changes were made because of it. And as a result, applicants now had to pay an additional $100 per application and show up in person in California or pay a proxy to show up there on the applicant's behalf.
1.
Question: Was the original statement in the Applicant Guidebook Policy or Implementation? Honest answer: Depends. One person's policy is another person's implementation. It is a never-ending age-old debate. The answer to was it policy or implementation is YES, it is both or it is either. There is no right or wrong answer. One thing we do know is that if it is policy and we want to implement something other than a "time-stamping system", the it is "inconsistent with the policy to recommend a lottery-based system". And that would then fall into this bucket we are talking about.
2.
Lets add another fun fact. Lets say we are 5 days before a council meeting (past the document/resolution deadline) and the next council meeting after that is 35 days away.
3.
Under Anne's theory: We would have to ask the GNSO Council first to authorize the SPIRT to be involved. But its too late for a resolution for the meeting in 5 days, so we have to wait 35 days just to get the Council to "authorize the SPIRT to be involved". So despite the SPIRT having "experts" and most-likely being comprised of those most impacted", the SPIRT can do nothing for 35 days to get authorized. The Council can then authorize the SPIRT to be involved at the subsequent meeting (but we have wasted 35 days). And if the Council believes it is policy, do we have to set up a PDP or ePDP just to decide how the queuing process will work? So, now we add another 12 months.
4.
Under my theory: We bring the SPIRT and the GNSO Council in right away and have discussions to find a quicker solution and involve those most impacted. The GNSO Council can always de-authorize the SPIRT, but lets be honest, why would they as they are the most impacted. And if it is policy, we have created just a temporary solution to let this current round move forward, but the GNSO Can always create a new solution for ongoing rounds. But we cannot stop the current round because some believe it is policy.
Example 2: Centralized vs. Decentralized TMCH
@Elaine - since you brought it up 🙂
Not sure if you recall, but ICANN's proposal for the TMCH was a decentralized system whereby each registry would have its own implementation of the TMCH rather than relying on a centralized system provided by ICANN.
Chris Wright (AusRegistry) and I realized right away that this system would never work, would be clunky, and would create inconsistent results between TLDs and even within TLDs depending on how registrars implemented that decentralized system. Therefore, after the Applicant Guidebook was finalized, Chris and I submitted a proposal for a centralized system along with the notion of an SMD file, etc. We convinced ICANN Org that they needed to change their thinking about the decentralized model and ultimately with our help (and others that supported our proposal), ICANN made that change.
Was that change (for the better) a change in "policy" or a change in "implementation."? You and I may argue that that is just implementation. But I knew others that argued that it was a change in policy. (In fact, ICANN Org initially thought it was a policy change). Again, the answer is probably depending on where you stand, it was both policy and implementation. No one was right and no one was wrong.
But if it was policy that we have a decentralized system, is that something we would need to stop the program over and have a full-blown PDP? Do we have to even wait a month or more for the council to "authorize" the SPIRT to be involved?
My points are:
1. It sounds nice to say, if it is implementation, then the SPIRT is involved. If it is policy, then it is not. But we all know that it is impossible to draw the line and each person's line will be in a different place.
2. These are 2 real examples that happened in 2012. Both of which needed changes immediately because the continuation of the program was "at risk" If some people believed the temporary solution involved "policy" than are we saying that (a) The Council would need to authorize the SPIRT to be involved, which could take a month or so to even do, and (b) would we really say that we need a PDP on these?
3. The SPIRT will be comprised of "experts" and likely those most knowledgeable and impacted by the changes. We are not saying that the SPIRT alone determines what to do. We are just saying that they will be involved in the collaboration in helping to find a temporary solution.
4. The Council can always step in a remove the SPIRT from being involved (though I am not sure why it would). And the council can do a PDP to determine a final solution for subsequent rounds.
5. ICANN Org, Applicants and the Community need some flexibility to carry out the program.
Sincerely,
Jeff
[cid:7e935119-fa9e-48d9-9b6b-094700268204]
________________________________
From: Pruis, Elaine <epruis(a)verisign.com>
Sent: Thursday, July 11, 2024 5:22 PM
To: jeff(a)jjnsolutions.com <jeff(a)jjnsolutions.com>; anneicanngnso(a)gmail.com <anneicanngnso(a)gmail.com>; compsoftnet(a)gmail.com <compsoftnet(a)gmail.com>
Cc: subpro-irt(a)icann.org <subpro-irt(a)icann.org>; greenberg.alan(a)gmail.com <greenberg.alan(a)gmail.com>; gnso-spirt-dt(a)icann.org <gnso-spirt-dt(a)icann.org>; nitin(a)data.in <nitin(a)data.in>; council(a)gnso.icann.org <council(a)gnso.icann.org>
Subject: Re: Re: [SubPro-IRT] [council] Re: SPIRT Presentation to Council
HI Jeff
I hope your vacation is going well. Thanks for the reply and an opportunity for me to gain a better understanding and further express my concerns. Hopefully they are just a misunderstanding of what is being proposed. I’m putting my commentary in purple to make it easier to follow.
This is what I understand from the work done by the SubPro IRT and email threads on this topic:
1. SPIRT is meant to provide predictability by being ready to address implementation items during an open round
2. It is not a policy development body, and the GAC and others specifically expressed concerns that it not become a policy making body
3. SPIRT as currently proposed would be an advisory group of “experts” that have a 2 year term, similar to the advisory (not policy making) SSAC.
For context for my questions, I’ll quote you:
A policy change is a change during the ongoing round of the program that, if implemented, would be inconsistent with existing policy recommendations. Therefore, policy changes for ongoing rounds would only occur in extraordinary circumstances where the continuation of the program is at risk if the change were not executed. If a policy change is necessary the Board, ICANN org, and the GNSO Council in consultation with the SPIRT, will identify an appropriate solution to secure the continuation of the program as well as an appropriate process to implement it.
I read this as “something happened that forces/forced the community to make policy that contradicts current policy, and the SPIRT would be involved in solving for and planning the implementation of that new policy.”
Is that correct, are you saying that SPIRT could under the guidance of the GNSO Council also participate by identifying an appropriate policy change/solution to secure the continuation of the program (as well as an appropriate process to implement it)?
Regarding:
“Whereas Anne believes that the SPIRT should only be involved if the Council specifically authorizes it to be involved, why can it not be that the SPIRT is involved unless the Council specifically says it should not be involved? I, for one, propose the later interpretation because the GNSO Council takes several months to authorize anything. “
This issue should be fixed within the GNSO Council rather than creation of a special group to work around those obstacles.
Regarding:
And, since this part of the Framework only gets triggered in “EXTRAORDINARY CIRCUMSTANCES WHERE THE CONTINUATION OF THE PROGRAM IS AT RISK” and the SPIRT is comprised of the experts, I would prefer the SPIRT having some role by default as opposed to Anne’s interpretation of having no role unless specifically authorized.
I agree with you if the SPIRT is limited to proposing IMPLEMENTATION solutions and not policy. If there is policy involved, we need to follow the proper PDP channels.
Regarding:
“In the last round, ICANN made these decisions up on the fly by having all issues go to the ICANN Board. Yes, there was often a public comment period, but very few comments resulted in any changes, and the process could hardly be called collaborative. “
I remember this all too well having spent a good 8 months building a TMCH solution on the fly as policy was finalized well after delegation of my TLDs and implementation remained a black hole. I agree there is a need for the SPIRT.
“Decisions came from on high and we were all forced to deal with them. Here, there is a collaboration that involved the Board, Org, the Council and the SPIRT for a “temporary solution” to ensure continuation of the ongoing round which is “at risk”. A more permanent solution for subsequent rounds can only be developed through the normal Policy Development channels.”
--I’m good with this as long as the “temporary solution” is implementation and not policy.
If it is a policy solution, it needs to be follow the PDP process and be open to the community for participation.
Thanks for considering my input.
Elaine
From: Jeff Neuman <jeff(a)jjnsolutions.com>
Date: Wednesday, July 10, 2024 at 6:41 AM
To: Elaine Pruis <epruis(a)verisign.com>, "anneicanngnso(a)gmail.com" <anneicanngnso(a)gmail.com>, "compsoftnet(a)gmail.com" <compsoftnet(a)gmail.com>
Cc: "subpro-irt(a)icann.org" <subpro-irt(a)icann.org>, "greenberg.alan(a)gmail.com" <greenberg.alan(a)gmail.com>, "gnso-spirt-dt(a)icann.org" <gnso-spirt-dt(a)icann.org>, "nitin(a)data.in" <nitin(a)data.in>, "council(a)gnso.icann.org" <council(a)gnso.icann.org>
Subject: [EXTERNAL] Re: [SubPro-IRT] [council] Re: SPIRT Presentation to Council
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Elaine,
I apologize for missing yesterday’s meeting as I am on vacation with my extended family for the week. However, I have been in the discussions about this issue with SPIRT charter drafting team.
With the caveat that I was not on the IRT call, and have not listened to the recording yet, so I am not sure how the issue was framed. But I wanted to draw everyone’s attention to Section 3 of the Framework which precedes the Change Execution section that Anne has been commenting on. Section 3 describes the context for the types of changes. More specifically, the types of changes we are talking about fit into the last category of changes, namely,
* A policy change is a change during the ongoing round of the program that, if implemented, would be inconsistent with existing policy recommendations. Therefore, policy changes for ongoing rounds would only occur in extraordinary circumstances where the continuation of the program is at risk if the change were not executed. If a policy change is necessary the Board, ICANN org, and the GNSO Council in consultation with the SPIRT, will identify an appropriate solution to secure the continuation of the program as well as an appropriate process to implement it. In this context, any collaboration that may take place between the Council and SPIRT, is outside this framework and a matter for the SPIRT Charter.
Unfortunately flow charts have a habit of abbreviating written descriptions. Re-Reading the chart in the context of Section 3 means the following:
1. A policy change for a current round would only occur in extraordinary circumstances.
2. ICANN would have to demonstrate that the “program is at risk if the change were not executed.”
3. If a change is necessary the Board, ICANN, and the GNSO Council in consultation with the SPIRT will identify the appropriate solution to “secure the continuation of the program as well as an appropriate process to implement it.”
Also, keep in mind that (a) The SPIRT is an open group that anyone can join (albeit at certain time intervals), (b) The SPIRT is subject to Oversight by the GNSO Council, (c) The SPIRT is advisory in nature, and (d) the SPIRT is supposed to contain “experts” in issues involving new gTLDs.
Whereas Anne believes that the SPIRT should only be involved if the Council specifically authorizes it to be involved, why can it not be that the SPIRT is involved unless the Council specifically says it should not be involved? I, for one, propose the later interpretation because the GNSO Council takes several months to authorize anything. And, since this part of the Framework only gets triggered in “EXTRAORDINARY CIRCUMSTANCES WHERE THE CONTINUATION OF THE PROGRAM IS AT RISK” and the SPIRT is comprised of the experts, I would prefer the SPIRT having some role by default as opposed to Anne’s interpretation of having no role unless specifically authorized.
In the last round, ICANN made these decisions up on the fly by having all issues go to the ICANN Board. Yes, there was often a public comment period, but very few comments resulted in any changes, and the process could hardly be called collaborative. Decisions came from on high and we were all forced to deal with them. Here, there is a collaboration that involved the Board, Org, the Council and the SPIRT for a “temporary solution” to ensure continuation of the ongoing round which is “at risk”. A more permanent solution for subsequent rounds can only be developed through the normal Policy Development channels.
But that is just my view.
Sincerely,
Jeffrey J. Neuman
Founder & CEO
JJN Solutions, LLC
+1.202.549.5079
Jeff(a)jjnsolutions.com
________________________________
From: SubPro-IRT <subpro-irt-bounces(a)icann.org> on behalf of Pruis, Elaine via SubPro-IRT <subpro-irt(a)icann.org>
Sent: Tuesday, July 9, 2024 1:11 PM
To: anneicanngnso(a)gmail.com <anneicanngnso(a)gmail.com>; compsoftnet(a)gmail.com <compsoftnet(a)gmail.com>
Cc: subpro-irt(a)icann.org <subpro-irt(a)icann.org>; greenberg.alan(a)gmail.com <greenberg.alan(a)gmail.com>; gnso-spirt-dt(a)icann.org <gnso-spirt-dt(a)icann.org>; nitin(a)data.in <nitin(a)data.in>; council(a)gnso.icann.org <council(a)gnso.icann.org>
Subject: Re: [SubPro-IRT] [council] Re: SPIRT Presentation to Council
Dear All
I also expressed concern on the SubPro IRT call this morning regarding SPIRT taking on a policy making role.
I specifically remember concerns from the GAC about the formulation of the SPIRT becoming a defacto policy making that could skirt the multi-stakeholder model of community engagement in formulated and chartered WGs.
Please revisit the GAC input on this issue as well as the SubPro final report guidance (accepted by the Board) as to the limits of the role of the SPIRT.
Elaine
From: Anne ICANN via council <council(a)icann.org>
Reply-To: Anne ICANN <anneicanngnso(a)gmail.com>
Date: Tuesday, July 9, 2024 at 8:39 AM
To: Akinremi Peter Taiwo <compsoftnet(a)gmail.com>
Cc: Nitin Walia <nitin(a)data.in>, Alan Greenberg <greenberg.alan(a)gmail.com>, "gnso-spirt-dt(a)icann.org" <gnso-spirt-dt(a)icann.org>, "Terri Agnew via cou." <council(a)gnso.icann.org>
Subject: [EXTERNAL] [council] Re: SPIRT Presentation to Council
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Peter,
Again, thank you for your feedback on the SPIRT presentation provided in the June Council meeting. By way of further update to my email response below, in the July 8 SPIRT meeting, I raised an issue regarding the recent redline in the Predictability Framework which added the SPIRT to the group that can develop temporary solutions to policy issues that arise during the implementation phase.
The Sub Pro Final Report states clearly on page 16 that the Predictability Framework is not a tool for developing new policy. (See excerpt at the bottom of this email.) Accordingly, in my capacity as Council Liaison to the SPIRT, I have added a proposed revision to our draft SPIRT Charter text stating that SPIRT may only be involved in the development of a temporary solution to an issue that falls in the category of requiring new policy development if Council specifically authorizes the SPIRT to take up that task. (To my mind, this would be on a case-by-case basis and not "pre-authorized" by the terms of the Predictability Framework and the SPIRT Charter since Council may choose a different mechanism for developing temporary solutions to policy issues depending on the nature of the policy issue.)
I do not know at this point whether the SPIRT team will accept the suggested revision to the draft since SPIRT Drafting Team Leadership took the view in our July 8 meeting that the existing text was ready to be approved "as-is" and that:
(1) If it is a temporary solution, it is not policy and
2) It's ok for the SPIRT to develop temporary policy solutions in collaboration with the Council, the Board, and ICANN Org "on the fly" when needed.
I understand that Leadership is motivated by a strong desire to finish the drafting work. However, I believe the work must accurately reflect the Sub Pro Final Report which contains the language excerpted below.
Accordingly, after having sent several emails to the IRT and the SPIRT lists expressing this concern during the past week, I raised this issue in person at the Sub Pro IRT meeting today. Lars has been on vacation and will review the issue in the coming days. Following the IRT meeting, another IRT member contacted me privately to say that SPIRT should not be involved at all in the development of temporary solutions to address policy issues that arise in the then-current round because that would be contrary to the Sub Pro Final Report. Hopefully the IRT and the SPIRT will be willing to address this jointly before the draft Charter is presented to Council. If not, I won't be able to recommend the Charter to the Council for a yes vote and have so advised the SPIRT team Leadership.
Again, thanks for your concern previously expressed. Given those concerns from you as a voting Council member, I wanted to keep you up to date on further developments. (All Council members are copied on this email.) Hoping to report good news in the near future...
Anne
From the Sub Pro Final Report - page 16.
"The Predictability Framework is principally: • A framework for analyzing the type/scope/context of an issue and if already known, the proposed or required Program change, to assist in determining the impact of the change and the process/mechanism that should be followed to address the issue. The framework is therefore a tool to help the community understand how an issue should be addressed as opposed to determining what the solution to the issue should be; the framework is not a mechanism to develop policy. The Framework is not intended to identify the solution to an issue but rather, to identify the proper mechanism to reach a solution in a consistent and procedurally sound manner. Therefore, this Framework complements the existing GNSO processes and procedures. It is not intended to be a substitute or replacement for those, nor should the Framework be seen as supplanting the GNSO Council’s decision-making authority.
On Sat, Jul 6, 2024 at 8:14 AM Anne ICANN <anneicanngnso(a)gmail.com<mailto:anneicanngnso@gmail.com>> wrote:
Thank you Peter. Apologies for the delayed reply but there has been a lot happening on the SPIRT team and in the Sub Pro IRT in relation to the issue you have raised re Annex E.
Actually the attached slides presented at Council were designed to point out the very specific areas where the SPIRT Charter differs from Annex E. In general, the team views Annex E as Implementation Guidance and felt it was necessary to conform that guidance to the procedural steps reflected in the Predictability Framework that was published for comment at the IRT Level.
In fact, there is now a new sentence in our draft that states that in the event of a conflict between the methodology specified in the SPIRT Charter and the procedures specified in the Predictability Framework, the Predictability Framework procedures will govern.
Having said that, the team has also clarified that ICANN Org is not the only body that can classify or "triage" an issue that arises. If the issue arises at the ICANN Org level, ICANN Org will make an initial classification. However, both the SPIRT Charter and the Predictability Framework now make clear that if an issue is raised by the Council or by the Board and brought to the SPIRT, then the SPIRT will make an initial classification of the issue in one of the categories relative to (1) whether or not the issue will have a material impact on Applicants and (2) whether or not it can be solved inside existing policy or else new policy is required.
The slides presented at Council say that ICANN Org will perform all triage, but again, that has been corrected in the current draft of the SPIRT Charter.
Thank you for taking the time to comment. Our last meeting (hopefully) is this coming Monday. Please let me know if you have additional questions and of course Council meetings are for open discussion on these matters. At this point, I am not sure whether the SPIRT Charter will be brought forward in July or later.
Please do reply all with any additional comments or questions you may have.
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2024
anneicanngnso(a)gmail.com<mailto:anneicanngnso@gmail.com>
On Tue, Jun 25, 2024 at 7:52 PM Akinremi Peter Taiwo <compsoftnet(a)gmail.com<mailto:compsoftnet@gmail.com>> wrote:
Dear Anne,
Thank you for your excellent presentation on the SPIRT charter during the council session. I noticed that the presentation did not touch on the inconsistency between Annex E and the proposed charter during the council meeting. I understand that time constraints may have limited a more detailed discussion.
I wanted to know if there is an ongoing conversation concerning resolving the inconsistency in Annex E and the proposed charter to prevent potential conflict and confusion.
And thank you for the follow-up, Anne.
Kind regards.
Peter
On Mon, Jun 24, 2024 at 12:57 PM Anne ICANN <anneicanngnso(a)gmail.com<mailto:anneicanngnso@gmail.com>> wrote:
Peter,
I wanted to follow up with you as to any questions you may have with respect to the SPIRT Charter presentation. We need to act quickly on this in order to get your feedback.
The SPIRT Chair and Vice Chair are copied as well as ICANN staff in charge of supporting the drafting team. We only have two more meetings at this point over the next two weeks.
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2024
anneicanngnso(a)gmail.com<mailto:anneicanngnso@gmail.com>
--
Best regards
Taiwo Peter Akinremi
------ ------ ------- ------ ------ ------- ------ ------ ------- ------ ------ ------- ------ ------
Policy Advisory | Data Governance and Privacy Consultant | Information Security & Cybersecurity | Certified Salesforce Administrator
Phone; +2348117714345, +2347063830177 Skype: akinremi.taiwo
Email: compsoftnet(a)gmail.com<mailto:compsoftnet@gmail.com>, peterexecute(a)gmail.com<mailto:peterexecute@gmail.com>
___________________________________________
