ICANN has just published a paper that attempts to frame what is policy and what is implementation. Now, if you’re a normal person, your natural response would be “who cares?”.
But if you’re an Icannite, chances are you’re already in a bit of a state. Because the question of what, within the ICANN decision-making process constitutes policy development, and what should be considered implementation of policies that have already been developed, is one that has grown contentious indeed in recent times.
The theory behind ICANN is that it works by bringing together groups of people from various backgrounds or with various interests and then waiting until they all take a decision. That can then become part of the sets of official guidelines that govern the way the Internet’s addressing and numbering system works.
In this obvious oversimplification of the ICANN model, the group of people are called stakeholders and the decisions they take are policies. The way they arrive at those decisions goes by the sweet name of “bottom-up, consensus-driven, policy development process”.
This is what makes ICANN such a unique governance body. One that (in theory) takes into account the opinions and inputs of all interested parties.
It is designed to prevent one view from dominating all others, be it the opinion of industry insiders, politicians or even free-speech advocates — all groups with legitimate interests, but all groups that, when they find themselves in the ICANN fish pond, have to listen to the other fish.
Except that they don’t always want to. And in recent years, as the pressure on the ICANN model has increased because of the new gTLD program, there have been several occasions when some thought it would be better to cut through (or go around) the policy development process to get things done.
This is where the policy versus implementation debate comes from. It’s a boring one to most balanced human beings, but a crucial one for those who rate ICANN and the work that goes on there as a major interest.
The new staff paper is a welcome initiative by ICANN to try and make real progress on a debate that has, up until now, simply exacerbated tensions within the ICANN community.
It’s a first step. A kind of “state of play” view of what can at present be considered policy within the ICANN system, and a first attempt at separating that from implementation.
It’s only eight pages long (and if that seems long to you, believe me, as far as ICANN papers go, this is the equivalent of a 140-character tweet), but if you can’t be bothered to read it, I’ll break it down for you in just one word: complexity.
A first step towards much needed simplification
The real issue behind this debate is the overly complex thing that ICANN has become. Don’t agree? Even though staff need to write an eight-page report just to help everyone, including themselves, understand what “policy” means?
Read the paper and marvel at the number of different processes that could be termed policy within ICANN, including something called “little p policies”, as opposed to “Capital P Policies”. Then there’s “formal policies”, “operational policies” and even “consensus policies”.
Just in setting that scene, the staff paper is useful!
Let’s hope it leads all ICANN stakeholders to the clear realization that this can’t go on any longer. ICANN must simplify its processes so that there is no longer a need to spend time and energy splitting hairs on deciding things like: when in the ICANN universe is policy making actually making policy, and when is it implementing policies that have already been made?
This is a guest post by domain name industry consultant Stephane Van Gelder of Stephane Van Gelder Consulting. He has served as chair of the GNSO Council and is currently a member of ICANN’s Nominating Committee.