[ga] Re: [ncdnhc-discuss] ICANN as a global regulator

[Jeff Williams <jwkckid1@ix.netcom.com>]

Jamie and all,

  It is obvious and has been for some time that a significant number
of the ICANN BoD including Alexandra and the "Board Squatters"
are frequently inconsistent or out right dishonest in their intent
in word as well as indeed.  Alejandro's recent statements made
publicly are blatant evidence of this as you rightly point out
here Jamie.  Of course many of us recognized this some time
ago now...

James Love wrote:

> Alejandro, I think the policy making document was by far the most radical.
> You are proposing to have ICANN be a substitute for national regulation of
> Internet activities.  This is basically taken right from Vint's Internet is
> for Everybody paper.  How can you put out stuff like this, and then at the
> same time take about a self elected board of directors?   Jamie
>
> --------------
> 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
>
> --------------------------------
> James Love mailto:james.love@cptech.org
> http://www.cptech.org +1.202.387.8030 mobile +1.202.361.3040
>
> --------------------------------
> James Love mailto:james.love@cptech.org
> http://www.cptech.org +1.202.387.8030 mobile +1.202.361.3040
>
> _______________________________________________
> Discuss mailing list
> Discuss@icann-ncc.org
> http://www.icann-ncc.org/mailman/listinfo/discuss

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 121k members/stakeholdes strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-244-3801 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


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