At a recent meeting in Nairobi, the ICANN Board decided not to press ahead with a process to allow people to pre-apply for new Internet extensions.
This process was called “Expressions of Interest”, which was sadly but inevitably shortened to EOI within hours of being out for discussion.
Ultimately the Board decided that there wasn’t sufficient consensus in the community about allowing people to pre-apply before the full process for decided new “top-level domains” is finalized: an EOI process would use up valuable time and resources, better spent finishing up the remaining issues; and it was not certain what the process would achieve. So, prodded by many to make a decision, the Board did so – and said No.
Most people think this was the smart move – it didn’t create a new process, a clear decision was made, we can move forward.
I, on the other hand, think that the decision is the reflection of a much bigger problem: ICANN doesn’t learn its own lessons. And if the organization as a whole doesn’t start reflecting on what it has learnt over 10 years of activity – and start applying what it learns – then it is going to continue to waste time and energy and resources, to the detriment of itself and the Internet.
What do I mean that ICANN doesn’t learn lessons?
In response to comments on my blog post about the EOI process, I put down what I believe are three major lessons that have resulted from the unique multi-stakeholder decision-making process that ICANN represents.
Each time something has successfully moved forward in ICANN, one or more of these threads have been present. And, conversely, every time something has faltered or failed, it’s because one or more of these threads had been broken or ignored:
- Lesson One: Relative deadlines are more effective than absolute deadlines.
- Lesson Two: Wherever possible allow voluntary over compulsory contribution.
- Lesson Three: The results of ICANN processes, no matter how broadly structured, represent a minority view.
In this case, a huge amount of time, energy and resources was wasted on the EOI because of a failure to follow lesson two: voluntary over compulsory. I’ll stick examples of where each lesson has appeared at the bottom of this post.
Down the wrong path
As soon as I read the staff analysis of public comments [pdf] to the EOI process, I knew the Board was doomed to take the most conservative route – which in this case was to say No and throw the process away. How come? Because the voluntary aspect was dismissed out of hand and without any real analysis.
One of the main conclusions in the document (p15):
“Of three options: a ‘mandatory’ EOI is preferred, not conducting the EOI is the second choice and a ‘voluntary’ EOI is a distant third. That is because a vouluntary [sic] EOI will incur time and expense (more than a mandatory EOI) and not achieve any of the program objectives.”
Of course if ICANN learnt its own lessons, it would realize that any program’s “objectives” are secondary to the larger realities of the multi-stakeholder model. The prime objective of an EOI process must surely have been that it won community approval. But that was never going to happen while the process was mandatory.
In that respect, the staff made a bad miscalculation by recommending that the Board go ahead with the EOI process – something that the Board felt compelled to strike down because there was not community consensus. This is a bad dynamic – staff making recommendations that the Board does not feel it can approve.
If on the other hand, ICANN’s own lessons has been taken into account and the start-point for the EOI process had been that it would be voluntary, then you would have seen much more fruitful discussion as people tried to figure out whether and how they could make it work, rather than be forced to come down on one side or the other.
By trying to achieve everything by making the EOI process compulsory; ICANN instead achieved nothing.
This is why ICANN – the staff, the Board, and the community – need to recognise the broader lessons and the patterns in their complex interactions. Everyone needs to take a higher-level reflection on the work that has been done over 10 years, rather than constantly fight in the trenches and so lose sight of the larger picture.
If these lessons are then applied, we should see much more effective and efficient work planning and discussions.
Real-life examples of where these lessons or threads have come into play.
If you can think of more, add them as a comment below. I’m sure there are more lessons that can be drawn out if people put their minds to it. A clear one to my mind is: openness – make everything available.
Lesson One: Relative deadlines are more effective than absolute deadlines.
Successes: Comment periods that account for other external factors.
Failures: New gTLD process timelines that constantly fell over; GNSO PDP deadlines in the bylaws that have to be fudged; comment periods that keep being extended.
Lesson Two: Wherever possible allow voluntary over compulsory contribution
Successes: GAC membership; ccNSO accountability framework/exchange of letters; RAA adoption (prior to end of contract); comment periods.
Failures: EOI process; efforts to force ccNSO managers to sign contracts with ICANN.
Lesson Three: The results of ICANN processes, no matter how broadly structured, represent a minority view
Failures: IRT process (trademark rules created by closed group of trademark lawyers); Whois; dot-xxx.