1. The threat to the bottom-up

    Rumors are flying that ICANN wants to move away from the bottom-up meme that has become its badge of legitimacy.  This is not a good thing.

    I have been researching the definition and roots of the term bottom-up for a while now, and it has a mixed background of definition and usage ranging from financial analysis and protein instrumentation to computer science.  IETF, a group whose decision making practices evolved from engineering and research practice, uses it to refer to the rough consensus process. In On consensus and humming in the IETF

    we strive to make our decisions by the consent of all participants, though allowing for some dissent (rough consensus), and to have the actual products of engineering (running code) trump theoretical designs. [RFC7282]

    I recommend RFC7282 to anyone interested in the meaning of rough consensus as it includes a very fine discussion of both the practice and of things that can be misunderstood about the process. There are three important elements in the IETF definition:

    • consent of all participants is the goal
    • some dissent on issues can occur
    • fact and experience based decision making

    ICANN also has its practice of bottom-up decision making though it is not described anywhere with the elegance of RFC7282. It is reflected in gory detail, however, in the policy development practices of groups like the GNSO. A review of these procedures will show that they are:

    • consent of all participants is the goal
    • some dissent on issues can occur
    • fact and experience based decision making

    For many years now ICANN has been referring to its private sector led methods as the multistakeholder bottom-up process. This has referred to the structures, both formal and in practice, that define the trust model for ICANN activities between the Stakeholder community and ICANN as a corporate entity composed of Board and Staff. 

    The threat referred to in the title of this blog comes from a misunderstanding of bottom-up. ICANN is currently engaged in a tussle between the community and the corporation. The root of this tussle is  a confounding of:

    • consent of all participants is the goal

    with

    • fact and experience based decision making

    The fact that all participants must consent to decisions, does not mean that all facts and experience, or ideas, must originate among the participants.  In the IETF  a protocol can come from anywhere, as an idea from the leadership, a university paper, or a corporate r&d development prototype. But while it may not matter where the idea for something comes from, it matters whether all participants come to a rough consensus on the protocol.  Beyond that, once the participants accept a protocol, it comes under their change control.  They can then twist it, fix it and render it completely unrecognizable according to the dictates of rough consensus.

    Similarly, in ICANN policy development process (PDP) the idea for a policy or practice can originate anywhere.  Most PDPs start with a staff analysis of the issues.  Most practices start with a staff rough proposal. Once presented though, what the community does with these raw materials is under the control of the various ICANN consensus processes.  Once they complete their work they send it on to the corporation, i.e the Board and staff, as a recommendation.

    But the process does not end there.  It continues. If the Board and staff have difficulty with the recommendation they must be sent back to the community for more work, they can’t just change it on it own, though they can offer suggestions. The process of ICANN consensus involves a cycle where any ICANN outcome must first achieve balance of the community and corporate concerns.

    A couple of rules in this process emerge:

    • No matter where a suggestion, experience or fact comes from, it is the participants who must come to consensus on the outcome.
    • Once a consensus is reached the corporation must review and it may even make further recommendations to improve the outcome.
    • Whenever an outcome is changed by the corporation, it must go back to the community.

    This cycle of ICANN community and corporate, the ICANN consensus, continues until the outcome is stable. When the ICANN system works, it reaches a homeostasis.  Those are the good times at ICANN when everyone is in harmony with trust abounding.

    With the sensitive and pressing nature of the work being done on new gTLDS, IANA Stewardship, ICANN accountability, and the pressures of the global Internet environment, the ICANN cycle of community and corporation has started wobbling.  As any cyclist knows, once a wheel starts to wobble, trust in the bike begins to ebb. Trust only returns once the wheel is trued.

    Recently the ICANN corporation has been worrying about the trust of the community. As is often the case in social dynamics, this has been understood in emotional terms.  Sometimes when people are emotional,  they start to look for radical solutions.  For example some might decide that the bottom-up processes no longer work, are not obligatory and can be circumvented.  Others decide that the corporation is no longer fit for purpose.

    And the wheel starts to wobble even more.

    And the emotional content increases.

    Perhaps what is needed is to stop, look at the wheel and take the time to true it.  At ICANN this means allowing that the community and corporation to cooperate in the upcoming accountability process. We need to review our structures and strengthen them so that the ICANN corporation can fulfill its commitments, so that the ICANN Community can again believe that ICANN is fit for purpose and so that we can convince the global Internet environment that ICANN deserves its role in the governance of critical Internet resources.

    We need to fix our bottom-up processes, not abandon or deprecate them.  If we don’t we will fail.