Does the subject of Vertical Integration require a policy process?
For the last several months people in and around the GNSO have been discussing Vertical Integration and its cousins; joint marketing, cross/joint ownership, registrars owning registries, registrars selling the names of affiliated registries, etc. This discussion has been full of claims and of counter claims of possible and expected harm, or advantages, to ICANN’s 3Rs - Registrants, Registrars and Registries.
Some have called it the fifth overarching issue. And some have indicated that even though it is such an overarching issue it should be left to the ICANN Staff implementation team to sort out. This does not make sense to me. Certainly it is the ICANN Staff that figures out the implementation once the policy is well understood and there is consensus on that policy. And everyone understands that implementation cannot be totally separated from the policy making process, that there is a give and take. But when implementation encounters policy issues that have not yet been solved, those problems should kicked back to the policy process, not solved with free-form implementation.
With such fundamental disagreements on an issue, even to the point where the analysis of the current policy and its implications is a point of disagreement, how can the ICANN Staff be asked to sort out the proper policy for Vertical Integration and Joint Marketing etc? That is not their job. That is the job of the GNSO.
Again, while talking about implementation detail, we find ourselves in the realm of policy making, or more accurately policy clarification, confirmation and perhaps modification. We have an 11 year policy that has been interpreted and reinterpreted by people making decisions to try and maximize their business propositions. At this point we find ourselves trying to make future policy based on contradictory precedent and many conflicting normative interpretations. There is nothing wrong with this, but resolving the issue is essentially a policy activity and not an appropriate implementation activity. With the addition of new gTLDs, ICANN is facing many new variations on the registrar, registry, and registry services interrelationship, and needs to make sure that the policy which is implemented is one that is done for the public benefit and is such as to give a proper chance to new entrants. Again, that is the job of the GNSO’s policy development process.
The staff has recommended a blunt tool as a solution: Registrars would be able sell up to 100,000 names of an affiliated Registry’s new TLD. At first blush this seems simultaneously to be a decent idea and to be contrary to the rules. And I understand that arguments can be made that it is within the rules, outside the rules or against the rules, depending on your point of view.
The DAG is proposing to solve a multivariate problem with ball park figure. This does not seem appropriate as it is a one size fits all solution for a problem which all experts, including CRA, agree does not lend its self to a single size solution. Even the ICANN Policy Staff issues report points out that there is no solution fit for all cases. A reasonable assumption is, therefore, that a procedure has to be created for handling the issue in its complexity and not with a single blunt instrument.
The Issue report, indicates that while this issue is in scope for the GNSO, it also comments that perhaps the GNSO is too busy to work on it and should leave it to the staff to take of. To me, this, would seem to be an abdication by the GNSO of its responsibilities. If there are policy issues that are within scope, and there is an issue which need to be resolved, then the it is the GNSO’s job to take up the task. It is the GNSO Council’s job as a manager of the process to figure out how to do that. The GNSO reorganization was done with an eye to allowing the GNSO more ability to do work, because the council was no longer the the group that needed to do the work. But the council seems to be falling into the trap of thinking that if the GNSO Council is too busy to do the work, then it is better leave the work to the staff implementors.
It seems clear to me, is that there is an issue of a complex historical policy for which there is no consensus understanding. It also seems clear that the process defined in the DAG is a change in policy - and a change in policy can only be effected through a proper GNSO policy development process - the bylaws mandated PDP. That is, the GNSO has a PDP to do.
Some have argued that if the GNSO takes up the issue, it will play into the hands of those who want to stop new TLDs. I think this is just sowing FUD (Fear, Uncertainty and Doubt). There is no reason to beleive this because the GNSO has shown that when the problem is important enough, it can rise to the challenge and come to consensus on a solution within a reasonable time frame.
I personally believe that a solution is needed that will allow lower entry barriers for newcomers who deserve such consideration according to a predefined set of criteria. I also believe that there will be boutique or single user TLDs that would reasonably benefit from an exception from the rules regarding who can sell TLDs and when. I do not think, however, this is a policy that should be hacked* together by the implementation team.
*hacked used in the sense of a software engineer who decides to just ‘hack’ some code instead of going back to the designers for a rethink.
