Public Discussion Draft
Implementation Committee on the Names Policy Development Process:
Comments of Tucows Inc.
July 30, 2002
Elliot Noss, (email@example.com),
Timothy M. Denton, (firstname.lastname@example.org),
Ross Wm. Rader, (email@example.com)
Table of Contents
Tucows is pleased to offer some observations and suggestions regarding the names policy development process, and in particular on the workings of the current DNSO and its proposed successor, the GNSO.
Tucows has previously published the Heathrow Declaration (www.byte.org/heathrow/) and two subsequent iterations of comments and proposals (http://www.byte.org/heathrow/comments-icann-reform-v0r1d5.doc of June 7, 2002 and http://www.byte.org/heathrow/icann-reform-cda-v0r0d1-062602.html of June 26, 2002. We shall summarize them here, to the extent they may be still relevant to the work of the committee, and make further and more specific suggestions as to how the future policy process can work better. Some of our proposals are reflected in the decisions of the ERC and the Board and need no further discussion in this paper. Others, such as the proposal for a commercial dispute resolution policy, have neither been taken up nor rejected, and we continue to think that the reform of ICANN s structure should not confined to improvements to its names policy, but should also encompass commercial dispute arbitration among contracted parties.
The principal problem for registrars has been that ICANN has proven incapable of making decisions or enforcing its contracts on matters of commercial practice. At the same time, issues have been treated in different ways, at different speeds, and there is no agreed process for getting issues through the DNSO up to the Board. The result is a perception that outcomes are governed by occult processes, are random, arbitrary, or depend on personal connections. Transparency is missing. Participation in ICANN feels like being inside a washing machine, with no idea when the cycle will end.
Tucows attributes the reasons for this failure to solve commercial disputes in a reasonable timeframe to two distinct but related causes.
Both of these issues problems need to be rectified, and can be addressed by the implementation committee.
The substance of the ERC s proposals regarding the GNSO is to
Tucows agrees that putting the country codes into logically and legally separate treatment makes sense, and that adding staff support and working more closely to timetables will improve the situation.
Nevertheless, the inability of the DNSO to address and resolve commercial issue in a timely fashion is not going to be fixed by these measures. The fundamental decision for ICANN s Board is to agree to fix the DNSO in such a way that
In our view, perhaps the most important
Tucows laid out the basic elements of a commercial dispute resolution procedure in our comments of June 26. We continue to think that the ICANN reform process should
Our comments will deal with the GNSO and with commercial dispute resolution processes (CDRP) in turn.
The problem of the DNSO has been the major driving force for the reform of ICANN. The DNSO was predicated on the idea that consensus of some kind would emerge from the Names Council, in a bottom-up process from constituencies, and that, with suitable horse-trading, issues would go up to the Board of ICANN, whose function would be to ascertain whether consensus had been achieved.
Tucows applauds the notion, fundamental to the reform of ICANN, that the Board would assume its traditional role of governing the corporation. Nevertheless, we believe this and the other reform measures are not going to be sufficient to fix the policy development process, as the proposals now stand.
These two concerns above will be better addressed in the section following on commercial dispute resolution procedures. However, even within the context of the future GNSO, the following critiques are relevant:
Tucows is of the view that a Code of Procedure is required for ICANN, and that the evolution of this Code of Procedure will induce the necessary clear thinking required to make ICANN work effectively. This Code of Procedure creates an issues management process and gives outsiders a clear idea of how it will work.
This Code of Procedure can appear as a set of by-laws of ICANN, by-laws of the GNSO policy Council, or in any public format that allows participants to have a reasonably clear idea of how an issue moves through the system.
Many organizations are designed around the problem of political issues management. The most obvious example is of governments, with departments and central agencies, cabinets and secretaries (ministers in parliamentary systems). ICANN, with its constituencies, interest groups, Board, and staff can be likened to the structure of a government. The trick in any government is to keep the different parts effective in their own domains while moving in an overall direction set by the center.
The foremost example of an issues management process in a rational government is the cabinet document system. This is the process whereby government deals with an issue, by ensuring that consultation has taken place among relevant parties, and that rational alternatives have been considered. At the end of the process, the cabinet document goes to the cabinet (analogously, the Board of ICANN) for approval, debate, and decision, the Board having final authority. In this case, departments of government are analogous to a constituency within ICANN. ICANN staff play the role of the cabinet secretariat, ensuring that the process if followed, which means that consultations have taken place, and that the proposal is ready for the Board s attention. The cabinet document is an issue paper outlining the question and proposing means to resolve it.
The champion of the cabinet memorandum is a minister (or secretary in the American system), the one who pushes it through. The analogy of ICANN to government is imperfect because there is no exact equivalent to the minister or cabinet secretary in the ICANN system, but the company, companies or the constituency most interested will provide the champion who wishes to push a policy through the system, and other constituencies or businesses will likely oppose it.
How can ICANN have an effective issues management system in the names policy space? (The kind of issues management spoken of here could apply to address or protocol issues as well.). A decision must be made that issues will be managed by a rational system. This would involve:
Such a system is not intended to prevent political activity, but to effectively limit the time that political activity will take by
It is Tucows view that the ICANN process is weakest in specifying the relations among the GNSO policy council, the Board, and task forces. Indeed it is largely a blank slate, where the work of the implementation committee in clarifying and formalizing these relations could be of great use.
Here we advance some suggestions how the issues management system could work. The critical step lies in defining the intake process, the process whereby ICANN becomes seized of an issue.
The GNSO Policy Council, assisted by staff, should have the same clear issues tracking process as ICANN s Board. The issues tracking process should be common across ICANN s dependent bodies.
Since the GNSO Policy Council is advisory in nature, its function is to ensure that proper consultation and vetting of the issue will take place before it is returned to the Board for decision.
Assuming the issue paper went to the GNSO council with instructions to have it studied by a Task Force, Tucows thinks it would be important that the Board of ICANN be able to receive, and the Task Force be able transmit, the study thus conducted without interference by the GNSO Council. Since the Board is making the ultimate decision, it has a right to receive its advice unvarnished, so to speak, and should be able to hear the voice of the proponents. It should also get the advice of the GNSO council, if it can arrive at a collective decision.
In the recent past, DNSO Task Forces have seen their carefully drafted compromises reduced to mush by the Names Council. Tucows thinks this is not useful, and the right of Task Forces to communicate to the Board their findings unedited should be one of the important advantages of the new system.
It may be that a Task Force (however called) cannot reach agreement on the issue. In that case, the policy document would lay out the arguments pro and con, and refer the matter back to the GNSO Council and the Board for action.
The GNSO should be under no obligation to take a position on an issue, but should be responsible for seeing that interested parties have been consulted and that task forces (study groups) have been constituted and done their work.
Once the issue has been returned to the ICANN Board, the papers might then consist of
Tucows considered whether there should be alternative avenues for getting issues through the GNSO policy council to the Board. It seemed to us that, since any group, including the GNSO policy council, could initiate a memorandum to the Board, there was no reason to have more than one receiving point for policy proposals. The function of ICANN staff would be partly secretarial, and partly procedural. This part of their functions would be a secretariat to a decision-making process.
The implementation committee and the constituencies should consider what changes would be necessary to the by-laws of constituencies in order to accommodate them to this process.
Tucows considers that the policy process as described above can significantly improve the current confusion in the DNSO and the proposed GNSO Policy Council. Nevertheless we believe that a distinct focus of the organization should be on contracted parties. These are the registrars and registries which have signed contracts with ICANN.
Together with ICANN, registrars and registries constitute the domain names business. Customers, carriers, intellectual property lawyers, and other constituencies have legitimate interests in how registrars and registries work, and we have no intention of excluding them from participation in ICANN s policy process. Nevertheless Tucows is persuaded that ICANN is too much focused on policy at the expense of business practices arising from the interpretation of its contracts with registrars and registries.
It was for this purpose that Tucows advanced the idea of a commercial dispute arbitration process in our earlier comments to the ERC. We advanced this idea in the hope that we could collaborate with others in fleshing out the details of how it would work, and we are still persuaded that such a process is needed and that it would benefit from collective consideration.
Here are some ideas of how we see it working:
The distinctions between the policy process described above and the process described here are:
The adjudication process would remain under the ultimate supervision of the ICANN Board in two ways. First, it would authorize the rules by which adjudications take place. Second, it could choose to ratify the decisions of the adjudicator, and adopt them for all comparable contracts.
We can think of a number of objections and concerns, and will try to deal with them here.
a) Commercial Dispute Arbitration is beyond the mandate of the implementation committee.
Commercial Dispute Arbitration did not form part of the deliberations of the ERC, though it may have been part of the discussion of the Board after it was raised by Tucows in the public comment section of the Bucharest meeting.
The mandate was given as;
The Blueprint for Reform makes clear that a structured policy development process is a critical element of ICANN reform. The Blueprint lays out some general parameters that such a process must meet, but deferred the details to the implementation process, suggesting that a task force of representatives of the broad ICANN community should be established to recommend the details of such a process. The ERC believes this must be done rapidly. Thus, the ERC has asked the following people to work with Ms. Rodin to provide suggestions to the ERC, which will then take account of that input in making its recommendations to the Board and the ICANN community.
Nothing prevents the implementation committee from taking up the issue, even if it does not have time to fill in all the details. Tucows envisages that the CDRP could take several months to be worked out. However, the idea needs to be taken up and considered.
Nothing prevents the ERC or the Board of ICANN from considering these proposals outside the context of the implementation committee.
b) Improvements to the policy development process will obviate the need for a CDRP
It is expected that the policy development process will be improved by the work of this committee and the ERC. Tucows is persuaded that the interpretation of contracts, and contract enforcement, are not best settled in a policy forum where the focus is wider and the parties involved have fewer direct connection to the business of transfers, registrations, delay periods: the actual business of domain names.
c) ICANN staff should provide contract interpretations rather than a CDRP
The record so far is that ICANN staff has been reluctant to make rulings and enforce them. In any case, it may suit the interests of ICANN to have qualified arbitrators make interpretations of the contracts rather than staff, just as courts interpret laws drafted by legislators.
d) Some contracts are unclear because the policy is unclear
We admit that some contracts are unclear, and can only be clarified by a policy choice, which an arbitrator could make. Would this not undermine the role of the policy process in the GNSO? No. First, the ICANN Board will have authority to accept or reject the arbitrator s findings, in our proposal, so that the entire process remains under the jurisdiction of ICANN, as long as the parties choose not to take the matter to the courts of competent jurisdiction. Second, since role of the GNSO Policy Council will be advisory in nature, the Board of ICANN is free to take advice from other quarters, which could include arbitration rulings.
e) Why should contracted parties have special status?
They have it already by virtue of their contracts with ICANN. Registrars and registries are the business. Everyone else is a consumer, supplier, or interested party. The mechanics of how the registration business will work are of vital interest to the participants in the industry, on which their profitability depends.
f) Other interest groups are excluded from the arbitrations
There is no reason why other constituencies or parties could not submit their opinions to the arbitrator.
g) The courts having jurisdiction should hear the case
Nothing prevents this. The idea behind arbitrations is to get rulings faster and at much less cost than the normal superior court costs.
Tucows thinks that, with the changes in the Board s role which are at the core of reform, other bodies, like the GNSO Policy Council, become one of a number of possible ways of formulating policy and of developing expert advice for the Board. The policy process as envisaged by the ERC and by our proposals above is not the One Big Answer to what is wrong with the DNSO.
We urge the Board, the ERC, and the implementation committee to take up the idea of a CDRP, begin a dialogue with ICANN constituencies and interested companies, and see whether a group can be formed to work out the principles and details of such a process in the next few months.
 http://www.byte.org/heathrow/comments-icann-reform-v0r1d5.doc of June 7, 2002 and http://www.byte.org/heathrow/icann-reform-cda-v0r0d1-062602.html of June 26, 2002.