[ga] ICANN Reform Policy-Development Process working paper

["James Love" <james.love@cptech.org>]

On May 7, 2002, the Committee on ICANN Evolution and Reform issued "Working
Paper on the Policy-Development Process."  In the old days, ICANN denied it
was a policy making body.  Now it is more confident, and issued most
recently this working paper on the proposed new policy making process.  For
example, ICANN believes "national regulatory approaches" for the Internet
are not likely to be effective or efficient, but a "global private-sector
body" could be.  And ICANN should not have to limit itself to implementing
consensus recommendations, and indeed, with a 2/3 vote of its self
perpetuating board, it could make enforceable policy decisions that are
"significantly inconsistent" with "bottom up" consensus recommendations.
Here are a few highlights, followed by more of the text.  Jamie

*    "The fact is that the Internet, and its component part the Domain Name
System, is a global resource. It is not amenable to multiple national
regulatory approaches - at least if the goal is to allow the Internet to
continue to provide ever more opportunities to ever more people at a
relatively low cost. And in any event national regulation, given the nature
of the resource, is likely to be ineffective. Thus, the options are some
form of global governmental body, or a global private-sector body. There do
not appear to be any other workable alternatives."

*  ". . . a reasonable solution would be to have ICANN seek consensus
whenever possible in developing policies, through processes and procedures
that insure that all views of those affected are heard and that are open and
transparent, and then to allow the ICANN Board to decide the issue based on
its educated perception of the best interests of the whole community. To
ensure that the ICANN Board did not lightly disregard any policy
recommendation from a constituent entity, ICANN's bylaws could require only
a simple majority to accept a properly documented consensus recommendation
from such an entity, and a supermajority (two-thirds?) to take action that
was significantly inconsistent with such a recommendation."

*  "such a resolution would be effective (i.e. is enforceable) throughout
the global resource that is the Internet. But if we assume those conditions,
such an ICANN, it seems to us, would have great value to many (if not most)
of the members of the global Internet community, even if the resolution of
any particular issue may not be all to their liking."

  More below on the new global regulator:

http://www.icann.org/committees/evol-reform/working-paper-process-07may02.ht
m

[snip]

Of course, to those who believe that ICANN, having no governmental mandate,
should never act in the absence of consensus, this lack of ability to act is
a feature, not a bug. If there is no consensus, they would argue, the
"market" should be allowed to function freely without ICANN interference.
Only in this way, they argue, will the tendency toward over-regulation be
avoided. In addition, they argue that it is simply inappropriate for a
non-governmental body to, in effect, claim "regulatory" jurisdiction over a
private enterprise on the basis of the views of third parties, and over the
opposition of that enterprise. Absent some form of governmental action, they
argue, or the consent of the affected party or parties, there is no basis
for ICANN - by definition a private, non-governmental body - to force
compliance with anything, no matter how desirable it may be from the
perspective of others in the ICANN community.

This argument has merit. No rational person wants to see ICANN become the
"regulator" of the Internet. On the other hand, this begs the hard question:
if consensus is required for any action, doesn't that create perverse
incentives for those with narrow commercial interests to veto any consensus
that is not immediately in their interest? We believe that it can be
persuasively argued that a properly structured and functioning ICANN is the
ideal mechanism for resolving such debates, even if (and maybe especially
if) the parties with direct commercial interests cannot come to a consensus
view. Assuming it is properly structured and functioning (and those are
obviously critical assumptions), ICANN is both a desirable and potentially
an effective vehicle for global resolution of issues relating to the DNS
where today there is no global alternative.

The fact is that the Internet, and its component part the Domain Name
System, is a global resource. It is not amenable to multiple national
regulatory approaches - at least if the goal is to allow the Internet to
continue to provide ever more opportunities to ever more people at a
relatively low cost. And in any event national regulation, given the nature
of the resource, is likely to be ineffective. Thus, the options are some
form of global governmental body, or a global private-sector body. There do
not appear to be any other workable alternatives.

A reasonable argument can be made that, given the nature of the Internet and
the DNS - both their global character and the critical role of
interoperability and stability to their continuing function - a global,
private-sector organization like ICANN is the ideal vehicle for balancing
the legitimate private interests of individuals, groups, and entities, on
the one hand, and the enormous public interest in the continued effective
operation of the Internet on the other. We understand and accept that this
could only be the case if we assume (1) the proper structure and operation
of ICANN, including critically the proper limitation of the scope of its
activities to those that are reasonably necessary to maintain, promote, or
improve the continued effective operation (stability, interoperability, and
utility) of the DNS, (2) the ability of all interested parties to discuss
and debate in an open and transparent way, (3) the ability to have ICANN's
decisions produced through another open and transparent process, and (4)
that such a resolution would be effective (i.e. is enforceable) throughout
the global resource that is the Internet. But if we assume those conditions,
such an ICANN, it seems to us, would have great value to many (if not most)
of the members of the global Internet community, even if the resolution of
any particular issue may not be all to their liking.

      Q2. Comments Requested: We invite comments on the abovediscussion ,
including particularly our conclusion that a properly structured and
functioning ICANN that has the ability to make decisions in a properly
limited area even where there is no clear consensus would be a useful and
desirable entity.


C. A Practical Approach

ICANN is and always should be an organization focused on policy development
by consensus whenever possible. This is the most consistent practice with
the successes of the past, and the most likely to generate broad support and
compliance throughout the global Internet community in the future.

On the other hand, there is a growing sentiment that the desire for
consensus should not be allowed to create veto rights in community members
with private or very limited objectives that are inconsistent with the needs
or desires of the rest of the Internet community. The optimal system, in our
view, would recognize the enormous desirability of consensus whenever
attainable, but also accept the need in some circumstances to reach
decisions over the isolated and determined opposition of one or a few
members of the community.

      Q3. Comments Requested: We invite comment on this conclusion, and
specifically the particular circumstances in which this would be
appropriate.

      Q4. Comments Requested: We invite suggestions for how ICANN's scope of
authority could be reasonably limited to only those areas reasonably
necessary to maintain, promote or improve the continued effective operation
of the DNS. In the alternative, we invite suggestions on different standards
than that stated here, along with explanations for why that better meets the
needs of the global Internet community.


Thus, a reasonable solution would be to have ICANN seek consensus whenever
possible in developing policies, through processes and procedures that
insure that all views of those affected are heard and that are open and
transparent, and then to allow the ICANN Board to decide the issue based on
its educated perception of the best interests of the whole community. To
ensure that the ICANN Board did not lightly disregard any policy
recommendation from a constituent entity, ICANN's bylaws could require only
a simple majority to accept a properly documented consensus recommendation
from such an entity, and a supermajority (two-thirds?) to take action that
was significantly inconsistent with such a recommendation.

      Q5. Comments Requested: We invite comments on this concept of a
supermajority requirement if the Board does not accept a consensus
recommendation of one of its subordinate policy bodies, and if thought
desirable, what the precise requirement should be.


This would preserve the incentive of all parties to work toward consensus
solutions, but allow the Board (assuming a Board selection process that
produces a broadly representative Board) to exercise its good judgment. If a
supermajority provision was included in the bylaws, and if an independent
review process or some similar mechanism existed, there would be a review to
ensure that standard was met.

      Q6. Comments Requested: We invite comments on whether any such
limitations on Board action should be reviewable, and if so under what
standards and by whom?


II. PROCEDURES

A major problem in the policy-development process to date has been the lack
of an adequate policy-making structure. The Domain Name Supporting
Organization has been left to make up its own processes and schedules, with
no practical oversight or limits, and generally without dedicated staff
support. With entirely volunteer participants, the result has been at best
uneven, with the predominant outcomes slow or exceedingly general or both.
There have been only a few outcomes that could be called consensus policies
generated in the almost four years of ICANN's existence.

Dedicated staff focused on the policy-development effort, as suggested by
the Lynn proposal, is one critical way to help this problem. But in addition
to this, there is the need to develop a standard set of principles and
procedures for the development of those policies that are appropriately
related to ICANN's mission. [For an effort to generally describe ICANN's
mission, see the working paper on ICANN's mission and core values recently
released by the Committee.]

These principles and procedures should mandate outreach, ensure the
opportunity for input by all interested parties, require the development of
records that document both the input and the analysis that leads to the
recommendation, and set clear time periods for at least the production of
status reports. They should also leave the Board free to insist on
recommendations by a time certain where necessary or appropriate, and give
the Board the freedom to reach outside the existing institutional framework
for advice if necessary or desirable on a particular issue.

Such procedures could look something like this:

  a.. ICANN should continue to operate as a bottom-up policy-development
organization. This means that, as a general matter, it is preferable for
policy issues to be discussed and recommendations originated from the
community through the ICANN bodies established to manage such processes, or
in the case of policy initiatives coming from the staff or Board of
Trustees, for those initiatives to be referred for evaluation and
recommendation to such ICANN bodies prior to decision by the Board.
      Q7. Comments Requested: Is this assumption correct? Some have argued
that there is no need for intermediate policy bodies in ICANN, and that we
should simply rely on the inputs of particular interest groups or
individuals directly to the Board. We would be interested in any specific
analysis or suggestions on this point.


  a.. Those policy-development bodies should be charged with undertaking an
appropriate process of collecting community input, evaluating that input and
developing recommendations that are either consistent with that input or
clearly explain any inconsistencies. That process could involve working
groups, task forces, public comments or some mixture of these devices,
looking toward the production of a draft report and recommendation to the
ICANN Board. This process should have a set time period, probably no longer
than 30-45 days.
      Q8. Comments Requested: What is the "appropriate process" in this
environment? Should it be standardized or is there reason to use different
processes for different issues? What specific directions should be given to
the policy-development bodies in this respect, or put another way, how much
discretion should they have?

      Q9. Comments Requested: Should this process have set time deadlines?
If so, what? How should they be triggered?


  a.. Any such draft report should clearly state (1) the basis for any
recommendations, (2) the steps taken to generate community input and the
nature of that input, (3) the identity of and rationale for any dissents,
and (4) any special time considerations relevant to the recommendations
presented.
      Q10. Comments Requested: Is this correct? Are there other elements
that should be required of draft reports?


  a.. Any such draft reports should be posted for review and comment by the
public and/or any other ICANN entities for no less than thirty days, after
which the policy body should have no more than fifteen days to finalize its
report and recommendations and transmit them to the Board. The Board could
then either take an action, or seek further input, either from the ICANN
community or from outside consultants or bodies with particular expertise in
the area.
      Q11. Comments Requested: Is this the appropriate procedure? Are these
time limits appropriate? Is there any reason to limit the Board's ability to
seek advice from outside consultants, existing private or public bodies, or
others? Should any such advice have to be placed on the public record, or
are there some circumstances in which that might not be desirable or
appropriate?


  a.. Once the Board has reached a tentative decision, it would publish a
tentative decision and explanation, and allow a reasonable period of comment
on that tentative decision, after which it would finalize and promptly
publish both its decision and any appropriate explanation.
      Q12. Comments Requested: Is this the appropriate procedure, or does it
unnecessarily delay resolutions for no real benefit?


Strict time limits for the development of any report and recommendation by
an ICANN policy body, regardless of how the issue was initiated, are
critical in our view. In the absence of urgent conditions (in which case the
Board could establish time periods consistent with the nature of the
urgency), consideration of a particular policy initiative should be limited
to a total of ninety days after initiation or referral, at which time a
report to the Board would be required describing either (1) a recommendation
for Board action with appropriate documentation or (2) the reason why more
time is needed to produce such a recommendation. In the latter case, the
Board could establish some later date for a recommendation, as it saw
appropriate. In the absence of a recommendation by the required date, the
Board would be free to take any action it thought appropriate without regard
for the lack of a recommendation.

      Q13. Comments Requested: Is this concept correct? Is the suggested
time limit suitable? Any suggestions for improvements are welcome.


The Board would be free to deviate from any recommendation, but for a
properly documented consensus recommendation from an ICANN
policy-development body, forwarded with the support of two-thirds of the
appropriate Steering Committee and on which there was no opposition from
another ICANN policy-development body, such deviation would require a
two-thirds vote of those Board members voting on the matter. In all other
cases, the Board could act by a majority of those Board members voting.

      Q14. Comments Requested: Is this concept appropriate? Is the
two-thirds supermajority described appropriate, or would some other level be
appropriate? Would some different standard be better?


In our tentative view, these or similar procedures would encourage consensus
policy development, but not allow it to be captured or impeded by determined
opposition. They would allow the Board to make an independent decision, but
only to reject a clear consensus recommendation by a super-majority vote.
And they would insure that decisions could be made in a timely way.

Conclusion

The Committee offers these thoughts in an effort to encourage more detailed
community discussion of these issues. These may appear to be basic nuts and
bolts issues, but in our view they are important elements of ICANN evolution
and reform. To be effective, ICANN must have a policy-development process
that both invites and permits all interested parties to participate, but
also is designed to actually produce decisions in a timely way. The
Committee invites comments on this general approach to policy development.


Committee on ICANN Reform and Evolution
7 May 2002

--------------------------------
James Love mailto:james.love@cptech.org
http://www.cptech.org +1.202.387.8030 mobile +1.202.361.3040



--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html