(Derived from paper delivered in Bern 2013 )
Further development of the paper
Relevant aspects of the multistakeholder model
When it comes to to definitions of what is or is not a multistakeholder organization, one must first of all give up the notion that the TA provides the last word on the definition of what it means to be a stakeholder, or on the division of the world into stakeholder groups. It provides an entry point to that discussion, but work its needed beyond that beginning.
Part of the analysis involves looking at the word stakeholder separate from the context in which is usually used and to attempt a basic definition. (The use and [abuse] of Multistakeholderism in Internet governance)
One proposition I will challenge its that one is only a stakeholder of a particular group when they are acting within the group. The issue of individual participants who do not accept being tagged as members of any fixed stakeholder group will also be explored.
Another assumption that will be challenged, is that the assignment of roles and responsibilities to stakeholder groups by governments in the precursors to the Tunis Agenda and the agenda itself are in any sense authoritative.
The chapter will look at the IETF multi-stakeholder form of participatory Internet governance (Ig). It will not focus on “multi-stakeholdergroupism,” and the group dynamics being played out in the Ig environment among the government (TA) defined stakeholder groups.
IETF as a multi stakeholder organization
It has become popular to criticize the first multistakeholder example in Ig as being insufficiently multistakeholder. Some in the IETF ask us not to subject them to the straightjacket that has resulted from government’s unilateral stakeholder group diremption. Some outside the IETF try to mark them as being a seperate category of their own because they speak geek in addition to other languages and jargons.
The paper will argue that the IETF is most definitely a multi stakeholder organization as all stakeholders may, can and do participate. If they so choose they can caucus as they please or not as their stakeholder groups, however they may conceive of these groups.
These participants are stakeholders because these are people who have a stake, a material or other concern with the outcomes and outputs in a process where they can affect the outcome. These participants, the IETF does not have members or membership criteria, come from all of the well known stakeholder groups and bring the perspectives and concerns of those groups into the tussle. And while all participants need to understand technology, or at least some aspects of some technology, they do not need to be technologists or even particularly technical community oriented – they can be, human rights activists fighting for privacy in the language of technology, or they can be intellectual propertyists working for property in the language of technology. Many stakeholders from many stakeholder groups contribute to the IETF and will be discussed.
IETF stakeholder groups
Though somewhat speculative at this point, if one looks inside the IETF and its internal structures, one can find those that appear silo-like. Normally, within other contexts in Ig, silos are seen as a failure indication of stakeholder group organization models. In the IETF, the silozation, if indeed it can be called that, is topical in rough reference to layers in the Internet architecture. One of the calls being heard in some multistakeholder oriented organizations, is that organizing work efforts along topical lines instead of stakeholder group lines would be a preferable model that would avoid silos. Looking at the IETF structural divisions, called areas, may give indications on the risks and opportunities of organizing work along topics or issues.
IETF Rough consensus Decision making
Much has been made of the rough consensus model used by the IETF. This section will look at that decision making process, often referred, both affectionately and in derision as “humming.” It will describe an ongoing discussion within the IETF to explore the meaning and processes of rough consensus.
This section will also attempt to touch on some of the mythology surrounding rough consensus as used in the IETF, e.g. that it only works because the issues are technical issues.
Alternate decision making processes
Rough consensus doesn’t always to result in a decision. Whenever this happens, there are those who consider alternate decision procedures. The IETF is currently going through one of these procedures in the processes of deciding which RTCWeb codec [ad1] will be mandatory to implement (MTI)[ad2] .
I am still digesting this ongoing discussion, and include some quotes that will be considered in the discussion of what happens when rough consensus can’t be reached.
From IETF list on 28 November 2013, Sam Hartman:
The issue I’m most concerned about is confirming that there is rough consensus to make a decision. I think any variance from rough consensus for decision making must itself meet a fairly high consensus bar.
“But we can’t make a decision; we have to make a decision, so of course we’re going to do something alternative,” you might say.
You don’t have to make a decision though. You can decide the IETF is not the right forum for your decision. You can decide not to standardize. You can decide to run experiments, get data, try to implement. You can give up. You can redefine the problem. You can for example decide to have two mandatory-to-implement options, or require receivers to implement both and not mandate which senders must pick.
In many cases it does turn out to be easier to get consensus that a decision must be made than it is to get consensus on a decision. However without chairs being able to clearly show that consensus to decide has been reached I’d expect an appeal and expect that appeal to be successful.
Excerpts from the RTCWeb discussion
On 11/28/2013 7:34 AM, Dave Crocker Brandenburg InternetWorking
Ted Lemon wrote: if the working group has consensus to vote, it’s probably because interested parties have some reason to believe the vote will go their way. … So if the working group is willing to agree to a vote, and unwilling to agree to a coin toss, that says something _very important_ about the status of consensus in the working group.
No it doesn’t. Or at least, not what you indicate, above, that it says.
The thinking you describe is possible, of course, but it’s not guaranteed. People’s motives and expectations and logic can vary quite a bit in a situation like this.
As merely one obvious example, people can simply be tired of the impasse and eagerly seek progress and be willing to settle on any mechanism they think will fairly break it — even if it works against the outcome they prefer.
Let’s not confuse ‘possible’ with ‘certain’
On Nov 30, 2013, at 8:54 AM, Melinda Shore <melinda.shore@gmail.com> wrote:
On 11/30/13 4:45 AM, Roger Jørgensen wrote:
And if the problem is that bad, that it’s impossible to reach consensus in the WG, what about replacing the chairs? …
Not for failure to gain consensus, by any means. “No consensus, do nothing” is a legitimate (if frustrating) outcome. I think they showed really questionable judgment in calling for a vote and laying out eligibility criteria, and for me that’s a huge issue (congratulations, guys – just like that you changed us into a member organization) but failure to gain consensus is a valid outcome.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
[ad1]both H.264 and VP8 – but I do think there are significant chunks of the market unhappy with one or the other.
Dave Cropland 131128 IETF list
[ad2]MTI mandatory to implement :
IETF – Internet Engineering Task Force
Of the three multistakeholder organizations being discussed in this chapter, the IETF is the oldest. While it currently has a defined existence as part of the Internet Society, for many years, it was just a collection of engineers who self-organized so as to cooperate on building and maintaining the interoperable Internet. While some would describe it as collection of individuals and not of stakeholders, I believe that it is indeed composed of stakeholders. In one way of looking at the organization, the participants come from all stakeholder groups and participate without any recognition of the fact, participating as technical contributors without conscious regard to their original stakeholder group, though the self selected affinity to those external stakeholder groups can never be completely avoided. In another sense they are members of a single stakeholder group, the technical community. Beyond that, for scalability and process issues, it divides participation according to the layer of the protocol stack one works on: Applications, Internet, Operations and Management, Real-time Applications and Infrastructure, Routing, Security and Transport. While participants may participate in more that one of the areas, generally each participant focuses their efforts in just one of these stakeholder groups by a different name[12].. In a sense, the technical area one works in, is the definition of one’s stakeholder groups within the IETF.
One important point about the IETF is the elaborate organizational structure that has been created in response to participant capacities and needs, and that continues to evolve to give all of the participants fair access to its processes. It has developed a well formed process for picking leadership from a very fluid population base: those who have participated recently. It has a selected leadership that has decision making abilities that have been granted by the community and has a multilayer appeals mechanism. As one of the crucibles of multistakeholder activity, it has created a stable but evolving structure. While being fully stakeholder driven, as there is not other way for work to get done. the organization has invested its leadership with great power, even giving a virtual veto to its Steering Group members, which they can use when necessary to protect the architectural and protocol stability of the Internet.
For most of its history, the IETF considered itself a purely technical organization with no policy responsibilities. While that is still largely the case, members of the community have begun to realize that while policy should not be instantiated in protocols, the protocols must enable various policy options and that policy issues might provide requirements for protocol design. A major effort, for example, has recently been completed in creating a set of guidelines for protocol designers on privacy considerations in their protocols (Cooper et al 2013).
Another policy aspect of the IETF in its recent development has been its activity in promoting its protocols such as IPv6 and DNSSEC. Originally, the IETF had focused on creating protocols and leaving it to the market to decide which ones would be used and which would get left behind. With the advent of IPv6, the IETF decided that it was such an important effort that it needed to become active in promoting the technology. It still remains to be seen whether this is an effective strategy for the Internet’s future and how making such policy decisions, that is the importance of deploying a particular solution, affects its technical mission.
Another aspect of the future of the IETF relates to the community that participates in the IETF. It is a community consisting of the elite of the technical world. Recently the IETF has begun working on international diversity and on attracting a younger population.
http://www.ietf.org/mail-archive/web/ietf/current/msg82981.html
Multistakeholderism: nature and practice 