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 problem as we see it

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.

A confusion of a policy development with a policy enforcement structure, coupled with a failure to develop a coherent policy enforcement structure in the gTLD space, and
A lack of clear or agreed processes for how issues are to proceed through the DNSO, or the GA, to the Board.

Both of these issues problems need to be rectified, and can be addressed by the implementation committee.

The Proposed Solutions accepted by the Board so far

The substance of the ERC s proposals[1] regarding the GNSO is to

Put the country codes in a separate group;
Use the existing set of constituencies, minus the country codes, as the basis of the GNSO (viz. IP, Business, ISPs, non-commercial, registrars, registries);
Add some more members of the GNSO steering committee appointed by the Nominating Committee to break any logjams;
Work more closely to timetables;
Permit ICANN staff to support the process;
Appoint the Chairman of the GNSO by the Board of ICANN; and
Place ultimate responsibility for policy development with the Board of ICANN.

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.

But this will not be enough

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

Procedures are consistent across issues, so that, for instance, the WLS, transfers, and grace period issues would be treated in fundamentally similar ways and with useful rapidity;
Processes are known, coherent, and move at timetables through the GNSO to the Board;
The work of task forces, which frequently represent careful compromises among interested parties, can get to the Board intact for consideration, in addition to whatever reports of the GNSO are subsequently made on the subject and,

In our view, perhaps the most important

Commercial disputes among contracted parties (registrars and registries in the top level domains) are treated differently within the ICANN structure than policy development, and are settled in a forum different from the GNSO.

Tucows laid out the basic elements of a commercial dispute resolution procedure in our comments of June 26[2]. We continue to think that the ICANN reform process should

Expand the focus of reform to consider ways to resolve contractual disputes among contracted parties;
Elevate the status of contracted parties by recognizing their needs for adjudicatory procedures within the ICANN structure;
Make appropriate changes within ICANN s staffing and management to accommodate these concepts and procedures.

Our comments will deal with the GNSO and with commercial dispute resolution processes (CDRP) in turn.

Issues Management Process within ICANN, the GNSO, and task forces

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.

The addition of appointees from a Nominations Committee will not change the fact that some constituencies sitting on the Names Council or its successor have little interest in issues that are of great importance to a few of the constituencies. The composition of the GNSO Board will perpetuate the automatic participation of parties uninterested in issues vital to others.
Parties contracted to ICANN are treated in the same way as parties without contracts with ICANN.

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:

There is no known, agreed process for moving an issue through ICANN s bodies to a resolution. For example, should an issue move through a constituency, to the Names Council, to a Task Force of the Names Council, and up to the Board? Or should it be sent directly to a committee of the Board? To the President for assignment to the Names Council? To the Names Council directly? Who knows? And who has the right to initiate a policy document? A company? A constituency?
No set of procedures exists, with accompanying fixed delays in which a body is required to deal with an issue, or declare it cannot find agreement.
By-laws of some of the Names Council and some of the constituent bodies of the DNSO are primitive or unclear.
The term consensus has no agreed meaning. Much of the confusion and impasse would be removed if procedural rules defined the majorities necessary for certain types of votes.

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.

Needed: an Issues Management Process

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:

The right of parties (constituencies, particular businesses, groups) to propose a problem and solutions to it;
A structure for recognizing issues, assigning issues to deliberative bodies or task forces, and of setting timetables for consultation, study, debate and possible compromise to take place;
The right of parties opposed to a particular proposal to debate, consider and put forth their own interpretations of the problems and solutions to them;
A documents management process that charts the progress of issues;
A record of decision that sets forth the decision of the Board.

Such a system is not intended to prevent political activity, but to effectively limit the time that political activity will take by

specifying the course of action, the timetable of study and consultation and
returning the issue thus considered to the Board for decision.

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.

A policy proposal can be sent to the ICANN secretariat by any individual, company, constituency, or group;
The proposal would correspond to a format that ICANN devises (e.g. length, summary, issue defined, alternatives, consultations, various considerations);
Consultations with all relevant groups would not need to be completed at the time of being sent forward to ICANN. It would be enough that the document outlines the position of the parties and seek a decision of the Board. Clearly, the more the document reflects a consensus among parties, the better. But it would not be necessary to achieve a consensus before an issue paper is launched into the ICANN process, in fact it would be unlikely to have already occurred.
The President and the staff of ICANN would receive the document, and take it to the Board (or some committee thereof) for decision on how to handle it, which could include any of the following:

To accept the issue
To decide which groups should be consulted;
To reject the issue as premature;
Whether it should be sent to the GNSO council, and whether a task force be created to study it;
The timetable for action and return.

Action and return to ICANN staff and Board

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

A memorandum to the Board which is relatively impartial, and which conforms to the format decreed by the Board;
The report of the task force or study group
Any advice of the GNSO it wishes to commit to paper
Any submissions of interested parties.

Key Features of the Issues Management System

It would be an issues management system serving the decision-making of the Board of ICANN;
It would be centrally managed as to process;
It would be relatively clear as to what procedures are to be followed and what stage the issue has reached;
It would not eliminate the politics of issues but confine the amount of time that needs to be spent on them;
The GNSO Policy Council would ensure that consultation had taken place, that the issue had been studied, and would advise the Board of its views, but would not act to block opinion, study, or recommendations from its Task Forces from reaching the Board.

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.

Constituency By-laws

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.

The Commercial Disputes Resolution Process (CDRP)

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[3]. 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:

A contracted party could initiate the process of arbitration;
Several contracted parties could be involved;
A special set of procedural rules will be developed, borrowed or adapted from somewhere;
An arbitrator will be selected according to those rules;
The parties will seek arbitration rather than contesting issues in the courts;
The rules setting up the CDRP will be drafted in such a way that the invocation of "policy" will not be enough to drag it back to the GNSO forums;
Evidence will be presented
A ruling will be made
The ruling will be confirmed by the Board of ICANN, or denied or modified.
Thereafter the ruling, as finally determined by the ICANN Board, will become a policy of ICANN on that issue.

The distinctions between the policy process described above and the process described here are:

Only parties contracted to ICANN could initiate the process, though other constituencies could intervene to make their views known;
It would offer contract interpretation, and, in the manner of the common law, some ability to clarify policy implicit in ICANN s contracts;
The right to go to adjudication would be separate from the policy process, so that ICANN s Board could not prevent parties going to arbitration;
Adjudicators would be chosen by the parties to the dispute.

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.

Conclusions on the CDRP

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.

[1] http://www.icann.org/committees/evol-reform/blueprint-20jun02.htm