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

Our Mission
ICANN for Beginners
About Us
How To Use This Site
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)

    Registrars A Concrete 'Thin Contract' Proposal
    posted by michael on Tuesday August 19 2003, @08:43AM

    David Johnson and Susan Crawford send in their latest proposal to save ICANN from itself:

    A Concrete "Thin Contract" Proposal

    By David R. Johnson and Susan P. Crawford

    It looks as if ICANN is going to require applicants for new TLDs to agree (in advance) not to negotiate a changed contract with ICANN. We agree that streamlining the process is in everyone's interest. Along those lines, we are proposing a substantially thinner contract that ICANN and new registries could use. Existing registries should also be allowed to sign up to this contract, if they wish.

    We strongly believe that a thinner contract is needed -- for several reasons. First, registries under contract with ICANN are now in the position of needing to ask for permission before innovating in any way. This has led to near-death experiences for several of the registries, as business plans and the realities of the marketplace change. This cannot be a desirable result, and imposes a great deal of pressure on ICANN staff. Second, contracted registries are subject to many onerous provisions in the existing contract that were the inventions of ICANN's prior (and very well-meaning) General Counsel. We believe that these provisions (such as reporting obligations and performance specifications) are unnecessary. More open competition among registries would encourage innovation and better customer service, and the existing requirements have been unenforced (and are unenforceable). Third, the existing weighty contracts have led to serious questions about ICANN's legitimacy. An ICANN that does not pretend to be a regulatory agency (and recognizes that no one gave it the power to be one) will not be such a large target for criticism. An ICANN that retains the central consensus policy regime that gives it legitimacy will be a long-lived ICANN.

    Here is a list of deletions we have made from the current unsponsored agreement. If ICANN wants to put any of these items back in, they should be obligated to explain why they are necessary.

    (We are focusing on the unsponsored agreement because it is the model for the current sponsored agreement -- and we think the entire concept of "sponsored" TLDs has posed real problems for ICANN's legitimacy and makes little sense in reality. See "Old Delusions and New TLDs," posted on ICANNwatch on November 13, 2002. ICANN should be opening up TLDs that can find and create their own markets, and use their revenues however they want -- by the way, the idea set forth in the RFP that the new applicants must use all of their revenue for the benefit of their community underscores the silliness of this sponsored/unsponsored distinction and should be dropped as a requirement. Is buying phone service a "benefit to the community"?)

    Items removed from the main agreement
    (see here for model before deletions)

    1. Removed unnecessary definitions.
    2. Removed terms of license from ICANN to use the ICANN logo -- has led to unnecessary contractual amendments when registries change the logo slightly to fit their needs.
    3. Removed functional and performance specifications; registries should be allowed to operate registry in whatever manner they feel appropriate, subject to consensus policies mandating particular elements of the registry.
    4. Retained concept of ICANN Accredited Registrars; added concept of registry sales through parties who have agreed to abide by consensus policies under agreements that designate ICANN as a third-party beneficiary.
    5. Removed startup period language, which added complications without benefits.
    6. Removed ICANN as beneficiary of escrow; registry should be able to designate party to run registry if it fails to abide by this Agreement.
    7. Removed existing registry fee provision because unnecessarily complicated; substituted agreement to contribute to ICANN on an equitable scale.
    8. Revised scope of consensus policies to match revisions to the rest of the agreement.
    9. Removed price cap for registry services; substituted agreement not to charge more for renewals than for initial registrations.
    10. Removed whois and bulk access obligations; these issues should and will be the subject of consensus policies.
    11. Removed expiration provisions; substituted automatic renewal if not in breach.
    Items removed from appendices

    (To see the model appendices, go here for an unsponsored model, and here for a sponsored model):

    A: Format and Technical Requirements for Requests to Change TLD Nameservers

    This process could change from time to time, so there is no need to lock it down in the contract. The main agreement includes a duty to notify (and to process the change). The parties can easily agree on format and means from time to time. Refusal to accept a reasonable means for notice would in any event be a violation of the implied promise of good faith and fair dealing.

    B: Format and Technical Requirements for Requests to Change TLD Contact Information

    Same reasoning as for Appendix A above.

    C: Functional Specifications

    Each registry operates differently. Each must change continuously to keep up with technology and meet market demand. The only requirement ICANN should impose is that the registry run in compliance with key IETF specifications. All registries have incentives to comply with those, in any event, to make their registry succeed in the market. Registrars and registrants will adopt a registry based in part on whether it operates soundly. If it fails, the contract can be terminated.

    Registries have very different scales, so there is no one specification that all could be required to follow. If the specifications are different, what gets required is clearly a function of the bargaining leverage of staff at the time of renewal.

    This entire subject should be the same as whatever is required objectively for new TLDs -- and that is really a selection criteria rather than an appropriate subject for ongoing "enforcement" and contractual obligation. Each registry has the normal business incentive to operate as well as possible. The Board should not try to run these businesses. Escrow protects in event of failure.

    D: Performance Specifications

    Same response as for Appendix C above. This should be covered by objective "minimum requirements" for any registry and need not be part of the contract because ICANN will not in fact have (nor should have) resources to police this over time.

    E: Service-Level Agreement

    Some registries can offer this to entice loyalty from registrars. But why is it needed? It differs for each registry -- so only reflects relative bargaining leverage. Changes in technology will make it obsolete. If registrars want promises before they will promote a registry, they can negotiate for them separately. Will be out of sync with the new structure if non-registrar channels can be used (subject to compliance with consensus policies).

    F: Registry-Registrar Agreement

    Why should ICANN tell registries what they must offer registrars, or tell registrars what they must accept? ICANN "accredits" registrars and may insist that they follow consensus policies. But it is not itself in the business of being a registry and shouldn't tell other registries how to behave. The original competition concerns that gave rise to this agreement are gone (and will further disappear as new TLDs are opened more freely). This was just the way for DOC and ICANN staff to impose their own view of the business model. There is no equivalent for sTLDs and ccTLDs.

    G: Fees for Registry Services

    The market should regulate these fees. The only market failure would occur if a registry exploited the lock-in effect, where a registrant invests heavily in a name and then needs to renew. Setting renewal fees at no higher than initial registrations protects against that. There are serious antitrust questions with any other "regulation" of price by ICANN, a private entity that includes competitors.

    H: Equivalent Access Certification

    Registries should be able to be their own and only registrars if they want to be, or should be free to use multiple registrars if that is helpful to them. If registrars want to provide the service of creating a distribution channel, they will do so and registries will have incentives to do business fairly with those that do. The original problem that gave rise to the creation of registrars was the risk of NSI favoring its own registry to the exclusion of others. Thus, if this requirement is retained, it should be imposed only on .com and .net, and should be voluntary for all other registries under contract with ICANN.

    I: Registry Code of Conduct

    Raises substantial antitrust issues. No real reason for this. Many registries operate differently. There is no principled reason to require "neutrality" as between registrars. Different registries were able to draft their own codes of conduct during negotiations with Louis Touton. Most are meaningless. If meaningful, they need to be able to change.

    J: Transition Plan

    Complex and not relevant over the long term. Why lock this into the contract?

    K: Names Reserved from Registration

    This would keep anyone from reserving museum.aero, for example, and makes no sense over the long term There is no basis for these lists in any consensus or sound technical policy. If there is an IETF RFC that requires this, we can include lists in minimum qualifications for new TLDs. But semantic shaping of new TLDs has been soundly rejected by the GNSO and the rest of the community.

    N: TLD Zone-File Access Agreement

    Every registry already makes zone files widely available. They have to do this to make the TLD work. But registries should not be obligated to make zone files available to anyone who asks. No reason why ICANN must get these from particular source or in particular way. Locked in terms might conflict with consensus privacy policy.

    O: Whois Specification--Public Whois

    Whois should be a matter of consensus policy and/or local laws. The community clearly doesn't like the status quo that has been built into these clauses by staff.

    P: Whois Bulk Data Provisioning

    same as above

    Q: Whois Data Specification--ICANN

    same as above. The contract language has drifted away from actual technical practice and is not enforced -- and registries do things different ways (fat and thin etc.)

    R: Data Escrow Specification

    Core contract requires escrow agreement -- no need for separate appendix.

    S: Data Escrow Agreement

    No need for ICANN to be recipient of data. Core contract does call for an agreement -- but it is a separate document, no need to be an appendix. Wasn't actually ready in most cases anyway, so this is just a placeholder.

    T: Monthly Registry Reports

    While it is important to track the performance of the registries, the current reporting requirements are widely viewed as overly burdensome. The level of reporting appears to be more appropriate for a regulatory agency, but less so for a consensus policy forum, and must add significantly to ICANN staff's burden. Reporting should be boiled down to some necessary level.

    U: Proof-of-Concept Reports

    Same as above -- and many subjective elements.

    V: Initial Consensus Policies

    This is the new appendix A -- would list all four.

    W: Additional Covenants

    These were ridiculous and were aimed at VeriSign. For example, the current "sponsored" TLDs have been asked to promise never to merge into any regisy operator who had more than 10 million names under management -- a condition that fit only VeriSign as a potential partner.

    X: Registry Operator's Domain Names

    Risk here was warehousing -- contract allows consensus policy to prohibit that. It is silly for ICANN to get into particular strings.

    Y: Sanctions Program

    This was extorted by force -- sets up staff as police and prosecutor and judge and jury. ICANN should instead establish an independent review panel. The idea that lesser penalties will make it easier to enforce appears persuasive, until you think about large staff trying to make their quota of parking tickets. Market will police bad business practices. Failure to abide by consensus policies is more serious and should lead to serious disputes -- that's why contract provides for specific performance and termination for failure to abide by arbitrator's ruling. (It's a nuclear bomb, but both sides have the key to turn it off -- so it can be used by ICANN to enforce key provisions without concern about overreaction.) The monetary aspect just favors wrongdoers with deep pockets who can afford to pay fines. Specific elements put ICANN deep into analysis of how registries operate -- to no good effect. And it has never actually been used.

      ICANNWatch Login  


    [ 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  
  • VeriSign/NSI
  • CORE
  • ICANNWatch.org
  • IETF
  • current unsponsored agreement
  • current sponsored agreement
  • Old Delusions and New TLDs
  • see here for model before deletions
  • here for an unsponsored model
  • here for a sponsored model
  • a substantially thinner contract
  • More on Registrars
  • Also by michael
    This discussion has been archived. No new comments can be posted.
    A Concrete 'Thin Contract' Proposal | Log in/Create an Account | Top | 4 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    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.
    You might consider adding this iin lieu or escrow
    by KarlAuerbach on Tuesday August 19 2003, @10:59AM (#12092)
    User #3243 Info | http://www.cavebear.com/
    Escrow of registration information has been a failure - it simply never got started.

    An easier approach is to require that TLD operators engage in good business asset preservation practices. In other words, the TLD operator would have to do things that would allow it to survive a data disaster or, in the case of a business failure, ensure that enough information was around for a sucessor to pick up the pieces and continue.

    What those practices are would be left to the TLD operator. (It would, of course, be a necessary element of these practices that there be adequate documentation of how the data would be resurrected.)

    Every year the TLD operator must present to ICANN and to the public an letter from an outside auditor stating that in the opinion of the auditor that the TLD operator practices good asset preservation practices that provide adequate protection.

    The contract should clearly grant third party beneficiary status to the customers to enforce the asset preservation practices.
    [ Reply to This | Parent ]
    Re:Which Registries Were/Are "Near Death"?
    by michael (froomkin@lawUNSPAM.tm) on Wednesday August 20 2003, @09:02AM (#12098)
    User #4 Info | http://www.discourse.net/
    here's one [icann.blog.us].
    [ Reply to This | Parent ]
  • 1 reply 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