ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    The Big Picture ICANN's Next Steps
    posted by michael on Monday September 23 2002, @11:17AM

    susan writes "By David R. Johnson and Susan P. Crawford

    The recent extension of the Memorandum of Understanding between the Department of Commerce and ICANN provides both parties with an opportunity to focus on what is most important about the ICANN experiment. DOC will be requiring ICANN to report quarterly on its progress, and will presumably be watching ICANN more closely than it has in the past. The following is a proposed roadmap for consideration of the key issues and a set of suggestions for immediate next steps."



    Scaling back the mission. DOC has said that it views ICANN's revised "mission statement" and core values to be a "significant refinement of the parameters of ICANN's activities." The GAC has suggested that ICANN restate its policy development mission to include policies "reasonably and appropriately related to its technical functions." As drafted, this statement is inappropriately broad, because almost anything could be viewed by someone within the ICANN structure as being "reasonably and appropriately related" to ICANN's enumerated technical work. As DOC has recognized, broad statements of mission only increase pressures on ICANN's resources and diminish its perceived legitimacy. Many of the calls for more At Large participation stem from fears that the ICANN Board will face increasing pressures to use the chokepoint represented by the root zone file to pursue increasingly adventuresome policy initiatives. So ICANN's top priority should be to put to rest concerns that ICANN will use whatever power it has (to control access to a domain name or IP address block or, indeed, entry into the domain name business) to support overly intrusive regulation.

    Reaffirming the consensus policy process. Two fundamental limits will prevent abuse of ICANN's claimed powers. First, it must only address certain subjects. Second, it must only impose mandatory rules under certain conditions: notably, when most of those substantially affected by the rules agree to go along (or don't object vigorously and rationally).

    After establishing its narrow mission, ICANN's next priority should be to reaffirm the role of the consensus policy process. DOC has noted that ICANN must improve its processes for transparency and accountability, and has stated that such improvements should include "clear policy development procedures." Clearer, more efficient, and timelier processes are undoubtedly necessary, and many have been suggested in the course of ERC's work. But such processes are a means to an end -- consensus policies -- rather than an end in themselves. The original answer to the question of ICANN's source of power, an answer present in the origins of ICANN and essential to its legitimacy, is that mandatory policies should be made when and only when most of those affected by such policies agree that they are necessary (or, at least, acceptable).

    ERC should recall that, under the express terms of contracts between ICANN and the gTLD registries and registrars, any mandatory ICANN policy must be the result of consensus as demonstrated by a written report documenting (a) the extent of agreement among impacted groups, (b) the outreach process used to obtain the views of groups likely to be impacted, and (c) the nature and intensity of reasoned support and opposition to the proposed policy. Under the express terms of all the contracts that give ICANN its power, the role of any cross-constituency council (and the Board itself) is not to act as a legislature but instead to facilitate and evaluate the results of the consensus policy development process. These contracts also spell out particular issues that may be the subject of mandatory consensus policies. The recommendations developed by the Names Policy Development Process Assistance Group expressly did not address the relationship between these existing contracts and the process the Assistance Group was recommending, because the Group viewed that analysis as outside their scope. The most cursory review of the proposed policy development process will reveal to ERC that, in fact, ERC has been presented with a process that is ineffective vis-à-vis the registries and registrars because it does not meet applicable contractual standards.

    As suggested by the Names Policy Development Process Assistance Group, ERC should immediately call for an analysis of the changes that would be required in the policy development process it is proposing in order for resulting policies to be enforceable as against gTLD registries and registrars. ERC will learn that some ICANN policies (non-mandatory or administrative policies) may certainly be developed through the process the Assistance Group has proposed. But mandatory consensus policies, binding on gTLD registries and registrars, cannot be. Reaffirmation of the need to demonstrate and document consensus in support of binding policies would fill this gap.

    Putting in place the Independent Review Panel. Greater assurance that ICANN really is staying within the scope of a narrowly defined mission and developing consensus policies, rather than merely claiming the existence of broad consensus for policies the Board itself has decided to adopt (or the staff has chosen to impose), can be achieved by prompt establishment of the Independent Review Panel that is itself required by ICANN's contracts and contemplated by its bylaws. Availability of a neutral forum for review of claims that ICANN had exceeded its core mission would reduce both suspicions about ICANN's legitimacy and resistance to participation in its processes. ERC has suggested the creation of an "ombudsman," and we think that is a fine idea. Whatever the function of the "ombudsman," however, he/she would not reduce the need for an Independent Review Panel, the "constitutional court" that, in order to ensure ICANN's accountability, must review challenged consensus policies before they can be imposed on registries and registrars. Current contracts provide that ICANN's policies are not binding on gTLD registries and registrars unless and until an IRP is created. To make itself "effective," ICANN should comply with this contract clause.

    DOC has required ICANN to implement accountability mechanisms to address claims by members of the ICANN community "that they have been adversely affected by decisions in conflict with ICANN's ... contractual obligations." Establishment of the IRP will go a long way towards satisfying this requirement.

    Establishing minimum criteria for new TLDs. DOC has instructed ICANN to "continue the process of implementing new top level domains (TLDs)," and to "develop criteria upon which to base its selection of gTLD operators." This is a subject on which ERC has not focused. ERC should recognize that it is essential to relieve the pressure created by the perception that ICANN has no plans to open up the name space to new competitors. Establishment of minimum technical and functional criteria (and publication of a schedule for acting on new applications) will make clear that ICANN does not seek to prevent competition or to create artificial scarcity on which it can base subjective rulemaking powers. One of ICANN's (and ERC's) top priorities should be to call for the "public articulation of the process, selection criteria, and the rationale for selection decisions" for new TLDs required by DOC, and to make each of these elements as objective and light-handed as possible.

    Developing "thin" contracts for ccTLDs. DOC specifically notes that "an agreement that would appeal to the majority of ccTLD operators has not yet been defined," and repeats its admonition (present in various forms in every other revision of the MOU) that "establishing stable agreements with country code top level domain operators is an important component of securing the future stability of the Internet." ICANN should focus its staff's efforts on developing "thin" contracts that would actually be attractive to ccTLDs. Such contracts would, among other things, allow ccTLDs to have a determinative say regarding which issues are properly local and which policies should be mandatory for all ccTLDs. We note, again, that building the consensus policy clause into the ccTLD contracts would have this effect. Eliminating the claim that IANA may hold off on database changes in order to force ccTLDs to accept a contract that (1) ignores their views in determining which policies are global, and (2) exposes ccTLDs to risks of redelegation over the opposition of the ccTLD community, would go a long way towards securing ccTLDs' agreement.

    Developing "thin" contracts for RIRs. DOC has underlined the importance of establishing stable relationships and formal legal agreements between the RIRs and ICANN. ICANN should focus its efforts on finalizing the draft "memorandum of understanding" between the RIRs and ICANN that was posted in April 2002. This agreement should not permit the RIRs to withdraw if they do not agree with an ICANN policy, but should respect their views by allowing ICANN to impose mandatory addressing rules only if significant opposition from the RIR community is not heard.

    Changing ICANN's vision of itself. The most fundamental change DOC should look for over the next few months is a modification of ICANN's views regarding its own importance. Recent responses by ICANN to statements by the RIRs and the ccTLDs have revealed a disturbing blindspot in ICANN's vision of its role. It appears that ICANN cannot imagine any circumstances in which its judgments regarding what is best for the net are unnecessary. The tragedy is that this ICANN-centric viewpoint obscures better ways to "coordinate" the net.

    ICANN's most recent expression of its self-perceived essentiality took the form of a response to the RIRs, who had had the temerity to suggest that they could develop policy and coordinate IP block allocation, cooperatively, themselves. In its response to the RIRs, ICANN staff patiently explained that the interests of the Global Internet Community could not possibly be "truly" reflected within the "regional" processes that have been implemented by the RIRs. ICANN completely discounted the RIRs' claim that "address allocation policies are best developed within the RIR process by those who understand and represent the needs of the interested constituencies," as well as the RIRs' concern that ICANN does not have the resources to carry out policy tasks with respect to address allocation.

    Similarly, when the ccTLDs claim a right to decide which policy issues are global and when global ICANN policies should be binding on them (and to otherwise be responsible for their own local decision-making in consultation with their "local internet communities"), ICANN has responded that only ICANN can decide what issues may be solved locally and what issues must be addressed by mandatory global rules. Along the same lines, when gTLDs explain that they are constrained by the market and should be free to run their businesses as they see fit (absent a consensus that new rules are needed), ICANN responds that it must approve any change in their operations. These approaches reflect ICANN's view that it alone can act to protect the interests of the Global Internet Community.

    The ICANN-centric worldview suffers from a critical blindspot: ICANN simply cannot see the possibility that local and decentralized organizations and actors may actually best reflect the views and values of all local actors. Particularly where the local organizations in question are open to broad participation or are constrained by market forces because customers can make choices among several options, deferring to actions by local organizations may produce optimal global solutions from the bottom up. Instead of reserving final approval powers to itself, ICANN could decide to increase potential competition, to delegate as much decision-making as possible to local or decentralized, autonomous groups that can more reliably reflect local values, and to allow these local groups to compete against each other to make policies attractive to participants.

    It is admirable that the staff takes its responsibilities so seriously -- less so that they cannot see the value of reducing the burdens placed on global policy-making by ICANN. The founding goals of ICANN were to create bottom up decision-making and increase competition. Those involved in creating ICANN assumed that it would make relatively few global rules and would do so only when there was broad agreement that such rules were necessary.

    There may be some need for some global rules. There is certainly a need to assure competition at all levels of a system that is capable of providing end users with too few choices or presenting risks of "lock in" to the choices they have made. But the need for competition would best be served by an ICANN decision to make it easier for new competitors to enter the business -- and for existing competitors to experiment with new business models and diverse terms and conditions.

    We need a kind of ICANN that believes in the same kind of decentralized, cooperative action that gave rise to the net in the first place. Above all, DOC should now be watching for this central change in attitude to begin to manifest itself in ICANN's day-to-day decisions.

    David R. Johnson is the founder of Graphical Groupware. Susan P. Crawford is a partner with Wilmer, Cutler & Pickering. This article was written in our personal capacities, and does not necessarily reflect the views of any client of Wilmer, Cutler & Pickering.

     
      ICANNWatch Login  
    Nickname:

    Password:

    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

     
      Related Links  
  • GAC
  •  
    This discussion has been archived. No new comments can be posted.
    ICANN's Next Steps | Log in/Create an Account | Top | 7 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Re: ICANN's Next Steps
    by rhill on Monday September 23 2002, @10:11PM (#9346)
    User #3320 Info | http://www.itu.int/ITU-T/
    Susan states:

    'The GAC has suggested that ICANN restate its policy development mission to include policies "reasonably and appropriately related to its technical functions."'

    This is not quite right. The language proposed by GAC was:

    "Coordinates policy-development as necessary to perform these technical functions."

    See http://www.icann.org/committees/gac/statement-on-reform-26jun02.htm

    It was the ERC who suggested that the language proposed by GAC may be "unwise" and "not sufficiently flexible" and instead proposed:

    "Coordinates policy-development reasonably and appropriately related to its technical functions"

    See http://www.icann.org/committees/evol-reform/first-implementation-report-01aug02.htm#1

    To date the GAC has not commented on the language proposed by the ERC.

    Richard Hill
    [ Reply to This | Parent ]
    Re: ICANN's Next Steps
    by fnord ({groy2k} {at} {yahoo.com}) on Tuesday September 24 2002, @08:03AM (#9366)
    User #2810 Info
    ICANN foresaw that end-users might organize and gave it a poison pill, via Esther Dyson and Joop Teernstra, icannatlarge.com is now in danger of burning down over a name change and website management. It managed to sign up about 1000 members (not very impressive with internet users now numbering in the hundreds of millions), and many of those may have and may yet drift away (depending partly on whether Joop will forward them on).

    And just in case that, or anything else, became a credible threat, they created at-large.org. If ever forced into having to deal with a union, they already have one in place. The setting up of so-called company unions is not new, in fact particularily in the US it has a long tradition. Getting in on the ground floor and making an otherwise non-docile union beholden to you from its inception in case your first choice isn't accepted is another timeworn tradition. So ICANN just went with tradition. The problem with that is that there is little in the traditional world that maps to the internet. We don't have to join unions, we can all act individually and independently, coalescing only around a particular issue as and when necessary and then freeing ourselves to move on in ever more unpredictable trajectories. That is, near-impossible to control. That is one strength of the internet. Use it, and ICANN can't win. -g

    [ Reply to This | Parent ]
  • 2 replies beneath your current threshold.

  • Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com