Help Save the Multi-stakeholder Model (Part 3)
Updated: Sep 4, 2020
Please read Part 2 before proceeding.
Now that we have established that one of the fundamental problems with Enhancing the Effectiveness of the Multi-Stakeholder Model (MSM) is that members of the community may not have the incentive, willingness, and/or authority to come to a consensus and compromise on policies, what can be done?
1. Not every policy process needs to result in a “Consensus Policy.”
This sounds illogical when first reading. When is a policy supported by a consensus of stakeholders not a Consensus Policy? In ICANN-land, the term Consensus Policy has a very specific meaning. A Consensus Policy is a policy that is approved which becomes binding on the Contracted Parties (gTLD domain name registries and gTLD registrars). This means that as a result of a Consensus Policy, domain name registries and registrars are forced by their contracts to take (or not take) certain actions. It also means that ICANN’s contract compliance department can enforce those requirements and ultimately terminate a Contracted Party for breaching those new obligations.
Most Policy Development Processes (PDPs) are structured or designed in a manner where the expected outcome is one or more Consensus Policies. Non-contracted parties engage in PDPs because they want to force Contracted Parties to do (or not do) certain things that those participants believe are in their interest. This construct creates an “us” vs. “them” environment. It automatically puts Contracted Parties in a defensive position. With already tight margins, Contracted Parties view these PDPs as something that will increase their costs and/or liability, tie up constrained resources, decrease their profitability, and result in yet another headache to worry about ICANN’s contractual compliance department. Non-contracted parties on the other hand are usually of the mindset that their issues can only be resolved with the binding contractual commitment from the contracted parties.
Therefore, from the outset, we have created and adversarial process: a zero-sum game. If however, there was an understanding from the outset that the purpose of new policies were to create best practices accompanied by real incentives to adopt those best practices, perhaps the adversarial nature would change. Those that adopt the best practices could be rewarded by the marketplace (or possibly by ICANN) while others failing to meet those best practices would not. In addition, if failure to follow some minimum set of practices would objectively cause consumer’s harm, then and only then should the contracted parties risk losing their accreditation.
For example, with respect to domain name abuse, a set of best practices could be developed for types of abuses, verification of those abuses, and remedial actions by contracted parties. Those best practices can be accompanied by objective key performance indicators (KPIs) that can be measured by independent third parties and the results published for community inspection. Lists can be made of those contracted parties that meet or exceed those KPIs, and consumers can utilize that information for purchasing decisions. In addition to developing best practices, a set of minimum standards could also be developed. Those minimum standards would be the only part of that policy process that would result in a Consensus Policy. However, it is important that these minimum standards are treated as such. These would be standards below which we all agree would be deemed harmful or negligent. Although the latter may be adversarial, hopefully focus on non-contractually binding best practices will be collaborative.
2. Do not let the perfect stand in the way of improvement
In far too many PDPs, community members approach problems to determine the perfect solution. And, if those members do not get exactly what they want, they oppose the ultimate policy conclusions. But at the end of the day, the real question should be, "would we be better off with these policies than without them?" Small improvements are still improvements and should be viewed as a successful policy outcome. For example, in the closed generic debate (discussed in Part 2), if we ended up allowing closed generics subject to a determination by an independent panel that the use of those TLDs would serve a public interest goal, will that leave users in a better position than either not allowing closed generics at all or allowing all applications for closed generics.
Take the example of a .disaster. Let’s suppose that the International Red Cross (IRC) wanted to apply for a .disaster TLD. And, they propose to use the TLD in connection with environmental, humanitarian, and other crises that require relief. When a disaster occurs, a second level domain is created and operated by either the international Red Cross or one of its affiliates. The goal of the TLD would be to establish a single authoritative place for the receipt of financial and other contributions. We have seen that with a disaster comes fraudulent sites and organizations set up to capitalize on users sympathy and redirect charitable contributions to themselves. An end user would know that if it followed the instructions contained on a .disaster second level domain, it would be legitimate and their contributions would be received by the intended beneficiaries.
Most people in the community probably would admit that this purpose would serve legitimate public interest goal. However, there are many that believe that no one organization should control a dictionary word TLD, and that other organizations should have a right to use that TLD as well. They argue that no one should be able to "monopolize” a truly generic word. They also ask if we could only give the TLD to one entity, why would the IRC be the best choice.
I would argue, however, that the question whether the IRC is the best or most appropriate organization to run a .disaster TLD, is not the right question. It should not matter whether the IRC is the best organization to run this TLD, or whether it would be better for the TLD to be open. Rather, the question should be, "Does the proposed use of the TLD serve a public interest goal?" If the answer is yes, then perhaps we should let it move forward. It may not be the best proposed use (or the perfect use) to serve the public interest goal, but would its use in the manner proposed be better for end-users than not allowing it? Alternatively, are end-users better off with the implementation of this TLD than waiting for others (who may never come) to propose using this TLD in the traditional manner where anyone can register second level names whether authenticated or not. In the latter case, end users could be subjected to fraud and abuse.
3. The “Neuman Rule”
I am not sure how this ended up being called the “Neuman Rule”, but it has been attributed to me. Namely, that PDPs should only address issues where there is actual evidence of the problem. It’s a corollary to the “If its not broke, don’t fix it” rule. PDPs should not be engaging in philosophical or academic discussions. We should only be looking towards resolving issues that actually exist or that are reasonably foreseeable as indicated by real life situations. Too often PDPs are guided by paranoia of what they can imagine happening as opposed to what has actually happened in the past. This does not mean that you have to ignore issues that have not occurred in the past but if you want to address those issues, they should be grounded by past actions that could reasonably be foreseeable to result in new issues.
For example, I do not believe that anyone applied for TLDs in the 2012 round with the intention that they would lose the TLD in a private auction in order to make money. I believe everyone that applied for their TLDs have a good faith intent to actually win the TLD and operate it. At the end of the day, it turned out that some applicants did make money by losing private auctions and either pocket that money or used that money to fund auctions for other desirable strings. In fact, although the results of private auctions were confidential, through public filings of listed companies, we learned will that some applicants made millions of dollars by losing private auctions. Therefore, although no one applied for TLDs in the 2012 round with the intention that they would lose the TLD in a private auction, the Neuman Rule would not preclude looking into this issue because the facts of what did occur in 2012 make it reasonably foreseeable that it would likely occur in the next round.
4. What is the Default?
This is perhaps one of the most difficult issues. In a number of cases failure to reach consensus without understanding what would happen in the absence of a new policy could lead to an even bigger problem. On the other hand, if it is predetermined what will happen if there is a failure to reach consensus, and there are members of the community that like the predetermined solution, as reported in Part 2, we create a lack of incentive or willingness to compromise. So, what do we do?
The answer is: it depends. If there is ample evidence establishing that staying with the status quo would be problematic for users, then the status quo should never be the default. In other words, if it is clear that continuing the status quo would harm users, then a failure to come to consensus should not result in maintaining the status quo.
This means that in circumstances where maintaining the status quo would be harmful, and a working group is going to be unable to come to a consensus on addressing the issues, the GNSO Council should have the ability to accept proposals that have strong support (as opposed to just Consensus or Full Consensus). Although such proposals will not meet the contractual definition of Consensus Policies, if they are ultimately approved by the ICANN Board, and they will require contractual changes, the ICANN CEO should be directed to enter into contractual negotiations with the impacted contracted parties to negotiate appropriate provisions required to implement those policies. Under the Registry and Registrar Agreements, ICANN's CEO may initiate contractual discussions at any time (though there are limits as to how many times it may do this within a given period). Although there may be some trade-offs that happen during these negotiations, and that may result in slight deviations from the ICANN Board Approved policies, everyone would be required to negotiate in good faith to at a minimum resolve the continuing harm being caused during the status quo. Failure to come to a consensus should never result in ignoring demonstrable harm.
Of course, if maintaining the status quo will not result in continuing harm for users, then maintaining the status quo could very well be appropriate.
5. Other Improvements: Although I will not go into detail on some of the next proposals, they should be self-explanatory.
All participants in a PDP working group must be required to disclose who they are representing in that working group. This means that consultants must disclose whether they are being paid by any client to participate in the working group discussions on that client’s behalf. If the consultant or even attorney is unable or unwilling to disclose the name of their clients that are paying for their participation in the group, that consultant or attorney must become an observer instead of an active participant.
All participants should sign an affirmation stating that if they are representing a disclosed client, they nonetheless have been given the authority to negotiate compromises. This would not preclude the client ultimately from opposing the compromise. Participants need to have sufficient discretion to find a beneficial solution.
PDP working groups should also recognize that certain issues may be more appropriately addressed by third parties than by the ICANN Contracted Parties. Just because a contracted party can address a specific problem, does not mean that that contracted party is the most appropriate party to address the problem. In other words, non-contracted parties that are unable to resolve their issues outside of ICANN should not force contracted parties to implement solutions they otherwise could not get. This is especially clear in cases where the content of a website is at issue. Yes, a domain name registrar could remove the domain name from the zone (thereby making the potentially infringing material unviewable), but it would also cut off any and all of the legitimate content. That type of solution is not narrowly tailored to address that particular content harm. The question must always be asked by working groups whether the contracted parties are the most appropriate parties to resolve the issues. If not, the PDP working group should not try to force the Contracted Parties to solve the problem. Rather, it should make every effort to bring the right parties into the room. Yes, the result may then not be enforceable against registries and registrars, but may lead to better and more appropriate practices and results.
Finally, being an active member of the ICANN community for more than 20 years has taught me a lot. It has taught me that despite constant paranoia and conspiracy theories, the reality is that almost all of the participants are trying to do what they believe is right. Whether I agree or disagree with their positions, I have always believed that everyone is acting in good faith and truly wants to do the right thing. It is through ICANN and the community that I have found some of my longest lasting and best friendships. Though I often disagree with their positions, I have the utmost respect for all of them.
When people ask me why I stick around for all these years, the answer is simple: I believe in this little experiment we created 22 years ago and want to see the multi-stakeholder model succeed long after I am gone. And I believe it will.