2002 Evolution and Reform Process: Difference between revisions

Line 44:

====Policy Development Process====

The results of ICANN's policy development process to date in 2002 was, in the view of the ERC, "at best uneven, with the predominant outcomes slow or exceedingly general or both."<ref name="pdpwp">[https://archive.icann.org/en/committees/evol-reform/working-paper-process-07may02.htm ERC Working Paper on ICANN's Policy Development Process], May 7, 2002</ref>

The results of ICANN's policy development process to date in 2002 was, in the view of the ERC, "at best uneven, with the predominant outcomes slow or exceedingly general or both."<ref name="pdpwp">[https://archive.icann.org/en/committees/evol-reform/working-paper-process-07may02.htm ERC Working Paper on ICANN's Policy Development Process], May 7, 2002</ref> In its discussion of the standards of decision-making, the ERC further described some of the issues facing ICANN's policy model to date:

<blockquote>The results to date are mixed. ICANN has been very effective in some areas, notably the introduction of competition at the registrar level, establishment of new TLDs, and the creation of an efficient, non-binding dispute resolution process. But in other areas ICANN has been less effective. In particular, ICANN has not always demonstrated the ability to come to decisions on issues of interest to some or all of its constituents, with the result that the consequence is often no action – by default rather than through a conscious choice of the Internet community.<ref name="pdpwp" /></blockquote>

The paper went on to identify the challenge of reaching consensus as a primary roadblock to efficient and effective decision-making. Noting that the word "consensus" did not appear in the ICANN bylaws until the March 1999 amendments that created the DNSO, the ERC nonetheless accepted that consensus policy was an important concept, both in the spirit of ICANN's multistakeholder model and in terms of ICANN's [[Registry Agreement]]s.<ref name="pdpwp" />

Balancing the equities, the ERC proposed an approach toward consensus that creates checks and balances against the exercise of either a ''de facto'' veto on the part of individual constituencies (by refusing to join a "consensus" proposal), and top-down imposition of policy by the board:

<blockquote>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.

<br />

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.<ref name="pdpwp" /></blockquote>

The ERC also outlined a uniform procedure for policy-making that is quite familiar to the modern-day policy development process:

* PDPs should be initiated by supporting organizations or at the request of the board, delegating the PDP to a specific SO or cross-community working group;

* A specific timeframe for the PDP working group or task force to gather input from the community and other relevant sources;

* A draft report, stating the basis for any recommendations, the steps taken to gather community input, the proposed policy or recommendations, along with a timeline regarding those recommendations, and an opportunity for dissenting opinions to present their rationales;

* A public comment period on the draft report; and

* A final report presented to the board for action.<ref name="pdpwp" />

==References==

@@ Line 44: / Line 44: @@
 ====Policy Development Process====
-The results of ICANN's policy development process to date in 2002 was, in the view of the ERC, "at best uneven, with the predominant outcomes slow or exceedingly general or both."<ref name="pdpwp">[https://archive.icann.org/en/committees/evol-reform/working-paper-process-07may02.htm ERC Working Paper on ICANN's Policy Development Process], May 7, 2002</ref>
+The results of ICANN's policy development process to date in 2002 was, in the view of the ERC, "at best uneven, with the predominant outcomes slow or exceedingly general or both."<ref name="pdpwp">[https://archive.icann.org/en/committees/evol-reform/working-paper-process-07may02.htm ERC Working Paper on ICANN's Policy Development Process], May 7, 2002</ref> In its discussion of the standards of decision-making, the ERC further described some of the issues facing ICANN's policy model to date:
+<blockquote>The results to date are mixed. ICANN has been very effective in some areas, notably the introduction of competition at the registrar level, establishment of new TLDs, and the creation of an efficient, non-binding dispute resolution process. But in other areas ICANN has been less effective. In particular, ICANN has not always demonstrated the ability to come to decisions on issues of interest to some or all of its constituents, with the result that the consequence is often no action – by default rather than through a conscious choice of the Internet community.<ref name="pdpwp" /></blockquote>
+The paper went on to identify the challenge of reaching consensus as a primary roadblock to efficient and effective decision-making. Noting that the word "consensus" did not appear in the ICANN bylaws until the March 1999 amendments that created the DNSO, the ERC nonetheless accepted that consensus policy was an important concept, both in the spirit of ICANN's multistakeholder model and in terms of ICANN's [[Registry Agreement]]s.<ref name="pdpwp" />
+Balancing the equities, the ERC proposed an approach toward consensus that creates checks and balances against the exercise of either a ''de facto'' veto on the part of individual constituencies (by refusing to join a "consensus" proposal), and top-down imposition of policy by the board:
+<blockquote>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.
+<br />
+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.<ref name="pdpwp" /></blockquote>
+The ERC also outlined a uniform procedure for policy-making that is quite familiar to the modern-day policy development process:
+* PDPs should be initiated by supporting organizations or at the request of the board, delegating the PDP to a specific SO or cross-community working group;
+* A specific timeframe for the PDP working group or task force to gather input from the community and other relevant sources;
+* A draft report, stating the basis for any recommendations, the steps taken to gather community input, the proposed policy or recommendations, along with a timeline regarding those recommendations, and an opportunity for dissenting opinions to present their rationales;
+* A public comment period on the draft report; and
+* A final report presented to the board for action.<ref name="pdpwp" />
 ==References==
 {{reflist}}