A current, important debate in internet governance and operation of the multi-stakeholder model asks: when do the bottom-up policy-making volunteers let go and when do the staff policy implementers take over?
Drawing that line to the satisfaction of everyone seems impossible. That is because there is no bright line — the development and implementation of policy is a task requiring the constant attention and cooperation of policy makers and implementation teams.
Is an ICANN action a policy position? Or is it a mere implementation detail? Labels almost never work, especially one-word labels. Since when are ICANN issues black or white?
We’ve stopped discussing the issues, it is easier to discuss the labels: is it “policy” or “implementation”?
The multi-stakeholder model depends on communication, consideration and collaboration
ICANN has a rich history of its stakeholders butting heads with the Board and both butting heads with the staff: long lines at microphones, speaking in hyperbole, and wringing of hands that the multi-stakeholder model has failed. ICANN also has a rich history of staff-stakeholder collaboration in the formulation of policy and in the implementation of policy.
The initial Inter-Registrar Transfer Policy was little more than a framework. Then a team of ICANN staff and TLD registry operators met over a period of months and developed the implementation model. It really didn’t matter where the policy making ended and the implementation started. There was a resolve that there should be an easy-to-follow way for registrants to transfer names and there was teamwork to get that accomplished.
There are parallels in the “real” world. In 1990, the United States enacted the American with Disabilities Act (ADA). The ADA itself was little more than a framework also: American employers should make “reasonable accommodation” for those with a “disability.” What was a reasonable accommodation? And what qualified as a disability?
Over a period of many years, those questions have been answered through a series of many court cases and regulations. But in 1990 employers were trying to figure that out.
At the time, we worked on developing clear criteria that would let our employees know what was covered by the ADA. After failing at that, we developed an approach to treat employees as you would your brother-in-law. You are deferential to your brother-in-law (because you have to face your sister) but not totally deferential (after all, he is making love to her). You just treat him better than the letter of the law requires.
So when your employee comes up to you and asks for better lighting at his workstation, you don’t try to parse whether you are required to accommodate near-sighted employees. You say, this is my brother-in-law, and I will listen to his request and carefully consider it.
This is how a public participation model works. The stakeholders are not strangers to one another and the model only works if there is mutual trust and respect.
If someone says, “I want to be heard,” she is generally listened to. (That doesn’t mean discussion is never ending. If that same person wants to be heard again, and says the same thing without change, she will be disregarded. If she continually repeats the same demand and content, she will be shunned.)
Policy versus Implementation should be Policy and Implementation
Take the example currently debated. There is a new gTLD policy element (approved in 2009) that states:
Strings must not infringe the existing legal rights of others that are recognized or enforceable under generally accepted and internationally recognized principles of law.
How does one implement that? The implementation of trademark rights protection mechanisms were developed after years of community/staff consultation, “implementability” studies, draft positions, memoranda describing potential solutions and the reasoning behind them, debate, and discussion.
When things were apparently settled, new parties joined the ICANN discussion — they were welcomed as were their opinions. ICANN was richer because there were new participants in the model. New implementation models were written. Finally, there was an indication the discussion was spent. The work was “said and done.”
Then, apparently, not all was said-and-done. After the gTLD program was launched, there were new suggestions and participants. ICANN decided to entertain those ideas. After a round of community feedback, a subset of the new suggestions was recommended by ICANN for inclusion into the implementation plan for new gTLDs.
ICANN’s policy makers, the GNSO, weighed in, agreeing with many of the conclusions but picking one of the recommendations and saying, “we’d like to talk a bit more about this one because we don’t fully understand its implications and effects.” (Unfortunately, the GNSO didn’t say exactly that, it sounded more to me like, “this item is policy and therefore it cannot be implemented without our consensus opinion.”)
Now, if my brother-in-law says he wants to talk about something some more, even if he doesn’t give a good reason, I am ready to indulge him. But ICANN did not indulge the GNSO. Now, we are in a policy versus implementation discussion: what work is the province of policy makers, and the province of implementers? The GNSO is considering ICANN Bylaw changes to ensure they are heeded.
Bylaw changes are not the lynchpin to multi-stakeholder model success. Putting rules in place for how and when to listen never work. There will always be exceptions. (Another whole piece can be written on how the rules governing communications between ICANN and its Governmental Advisory Committee have failed to facilitate the success of the multi-stakeholder model.)
Processes and procedures (as they are currently described in the Bylaws) are important. We must have clear rules for creation of consensus policy, with timelines and borders to ensure that issues are addressed and rights are respected.
But the operation of the multi-stakeholder model is more complicated than following those processes. The success of the model depends on the mutual trust and respect of the participants, and the ability to actively listen and to understand what is meant, even if that is not exactly what is said.
Rather than create new rules or discuss how one side can prevent the other from abusing its position, the volunteers, staff and Board should look inwardly to improve its own listening and communicating.
You’re my brother-in-law. I am ready (more than ready) to disagree with you, but first I am going to listen to what you have to say.
This is a guest post written by Kurt Pritz, ICANN’s former chief strategy officer. He is currently an independent consultant working with new gTLD applicants and others.