Thanks JeffThose are good examples. I would absolutely argue they are both “implementation” (how do we go about operationalizing these rules?) and not Policy with an upper case P.But I hear you- others may disagree.Since my main concern is that SPIrT as proposed wouldn’t be open and representative as other PDP WGs might be, could we compromise and say anyone with an interest and expertise can join the SPIRT if there is a topic being discussed that they would like to contribute to?If not, can I have a lifetime seat on the Spirt please? Only half joking.Elaine
On Jul 12, 2024, at 9:32 AM, Jeff Neuman <jeff@jjnsolutions.com> wrote:
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.
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.
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
<Outlook-d0xje5jd.png>
From: Pruis, Elaine <epruis@verisign.com>
Sent: Thursday, July 11, 2024 5:22 PM
To: jeff@jjnsolutions.com <jeff@jjnsolutions.com>; anneicanngnso@gmail.com <anneicanngnso@gmail.com>; compsoftnet@gmail.com <compsoftnet@gmail.com>
Cc: subpro-irt@icann.org <subpro-irt@icann.org>; greenberg.alan@gmail.com <greenberg.alan@gmail.com>; gnso-spirt-dt@icann.org <gnso-spirt-dt@icann.org>; nitin@data.in <nitin@data.in>; council@gnso.icann.org <council@gnso.icann.org>
Subject: Re: Re: [SubPro-IRT] [council] Re: SPIRT Presentation to CouncilHI 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:
- SPIRT is meant to provide predictability by being ready to address implementation items during an open round
- It is not a policy development body, and the GAC and others specifically expressed concerns that it not become a policy making body
- 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@jjnsolutions.com>
Date: Wednesday, July 10, 2024 at 6:41 AM
To: Elaine Pruis <epruis@verisign.com>, "anneicanngnso@gmail.com" <anneicanngnso@gmail.com>, "compsoftnet@gmail.com" <compsoftnet@gmail.com>
Cc: "subpro-irt@icann.org" <subpro-irt@icann.org>, "greenberg.alan@gmail.com" <greenberg.alan@gmail.com>, "gnso-spirt-dt@icann.org" <gnso-spirt-dt@icann.org>, "nitin@data.in" <nitin@data.in>, "council@gnso.icann.org" <council@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:
- A policy change for a current round would only occur in extraordinary circumstances.
- ICANN would have to demonstrate that the “program is at risk if the change were not executed.”
- 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.