Comment on New Contracts

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. (A copy of this proposed thinner contract is pasted in at the end of this posting.) 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, http://www.icannwatch.org/article.pl?sid= 02/11/13/131931&mode=thread. 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 http://www.icann.org/tlds/agreements/unsponsored/registry-agmt-11may01.htm 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 to http://www.icann.org/tlds/agreements/biz/ for an unsponsored model, and http://www.icann.org/tlds/agreements/museum/ 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.

===[proposed contract follows]

Registry Agreement

This REGISTRY AGREEMENT ("Agreement") is by and between the Internet Corporation for Assigned Names and Numbers ("ICANN"), a not-for-profit corporation, and [insert Registry Operator's name]("Registry Operator"), a [insert jurisdiction and type of organization].

1. DEFINITIONS. For purposes of this Agreement, the following definitions shall apply:

1.1. "Registry Services" means services provided as an integral part of the operation of the Registry TLD.

1.2. "Registry TLD" refers to the [insert TLD label] TLD.

1.3. An "ICANN-Accredited Registrar" is an entity or person accredited by ICANN to act as a registrar for domain names within the domain of the Registry TLD.

1.4. "Term of this Agreement" begins on [insert the Effective Date] ("Effective Date")and continues until the earlier of (a) [insert the Expiration Date]("Expiration Date"), or (b) termination of this Agreement.

2. ICANN OBLIGATIONS.

2.1. General Obligations of ICANN. With respect to all matters that affect the rights, obligations, or role of Registry Operator, ICANN shall during the Term of this Agreement:

2.1.1. exercise its responsibilities in an open and transparent manner;

2.1.2. not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition;

2.1.3. not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause; and

2.1.4. ensure, through its reconsideration and independent review policies, adequate appeal procedures for Registry Operator, to the extent it is adversely affected by ICANN standards, policies, procedures or practices.

2.2. Designation of Registry Operator. ICANN hereby designates Registry Operator as the sole operator for the Registry TLD during the Term of this Agreement.

2.3. Recognition in Authoritative Root-Server System. During the Term of this Agreement, Registry Operator may, by notifying ICANN, request (a) delegation of the Registry TLD to specified DNS nameservers and (b) changes in that delegation. ICANN will use commercially reasonable efforts to have such requests implemented in the Authoritative Root-Server System within five business days of the submission.

2.4. Recognition in the Root-Zone Contact Database. To the extent ICANN publishes contact data regarding TLDs, during the Term of this Agreement it will show the Registry TLD's operator as Registry Operator and the Registry TLD's administrative and technical contacts as requested from time to time by Registry Operator.

2.5. Other Obligations of ICANN. During the Term of this Agreement, ICANN shall use commercially reasonable efforts to:

2.5.1. maintain, or cause to be maintained, a stable, secure, authoritative and publicly available database of relevant information regarding the delegation of the Registry TLD;

2.5.2. generate, or cause to be generated, authoritative and accurate root zone information from such database and operate, or cause to be operated, the Authoritative Root-Server System in a stable and secure manner;

2.5.3. maintain, or cause to be maintained, authoritative records and an audit trail regarding delegations of the Registry TLD and records related to these delegations; and

2.5.4. inform Registry Operator in a timely manner of any changes to ICANN's contact information.

3. REGISTRY OPERATOR OBLIGATIONS.

3.1. Obligation to Provide Registry Services. During the Service Term, Registry Operator shall operate, or cause to be operated, a registry of Registered Names for the Registry TLD, in conformance with the Consensus Policies identified in Appendix A and established in the manner and on the topics identified in Section 4. The maximum price charged by Registry Operator for renewal registrations may not exceed the pricing for initial registrations.

3.2. Parties Through Which Registry Operator May Provide Registry Services. Throughout the Term of this Agreement, Registry Operator shall be obligated to enter into a Registry-Registrar Agreement with ICANN Accredited Registrars. Registry Operator shall provide Registry Services only through (1) ICANN Accredited Registrars or (2) parties that have undertaken to abide by Consensus Policies pursuant to agreements that name ICANN as a third party beneficiary.

3.3. Data Escrow. Registry Operator shall periodically deposit into escrow all data reasonably necessary to allow relaunch of the Registry TLD in the event that the Registry Operator is no longer able to fulfill its operations under Subsection 3.1. The escrow shall be maintained, at Registry Operator's expense, by a reputable escrow agent mutually approved by Registry Operator and ICANN, such approval also not to be unreasonably withheld by either party.

3.4. Registry-Level Financial Support of ICANN. During the Term of this Agreement, Registry Operator shall contribute to ICANN's cost of operation in accordance with an equitable scale applicable to gTLDs in general, based on ICANN's total funding requirements (including reserves), with overall gTLD dues not to be greater, for any annual period, than levels approved by gTLDs accounting for three-quarters of funds to be supplied to ICANN by gTLDs during such annual period.

4. PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES.

4.1. Registry Operator's Ongoing Obligation to Comply With New or Revised Consensus Policies. During the Term of this Agreement, Registry Operator shall comply, in its provision of Registry Services, on the schedule provided in Subsection 4.5, with

4.1.1. new or revised policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3,

4.1.2. in cases where:

4.1.2.1. this Agreement expressly provides for compliance with revised policies established in the manner set forth in one or more subsections of this Section 4; or

4.1.2.2. the policy concerns one or more topics described in Subsection 4.2.

4.2. Topics for New and Revised Consensus Policies. New and revised consensus policies may be established on the following topics:

4.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registry Services;

4.2.2. resolution of disputes regarding whether particular parties may register or maintain registration of particular domain names;

4.2.3. prohibitions on warehousing of or speculation in domain names by registries; and

4.2.4. maintenance of and access to accurate and up-to-date contact information for domain-name registrants.

4.3. Manner of Establishment of New and Revised Specifications or Policies.

4.3.1. "Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of the ICANN Board of Directors establishing the specification or policy, (b) a recommendation, adopted by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, that the specification or policy should be established, and (c) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy.

4.3.2. In the event that Registry Operator disputes the presence of such a consensus, it shall seek review of that issue from an Independent Review Panel established under ICANN's bylaws. Such review must be sought within fifteen working days of the publication of the Board's action establishing the policy. The decision of the panel shall be based on the report and supporting materials required by Subsection 4.3.1. In the event that Registry Operator seeks review and the Independent Review Panel sustains the Board's determination that the policy is based on a consensus among Internet stakeholders represented in the ICANN process, then Registry Operator must implement such policy unless it promptly seeks and obtains a stay or injunctive relief under Subsection 5.4.

4.3.3. If, following a decision by the Independent Review Panel convened under Subsection 4.3.2, Registry Operator still disputes the presence of such a consensus, it may seek further review of that issue within fifteen working days of publication of the decision in accordance with the dispute resolution procedures set forth in Subsection 5.4; provided, however, that Registry Operator must continue to implement the policy unless it has obtained a stay or injunctive relief under Subsection 5.4 or a final decision is rendered in accordance with the provisions of Subsection 5.4 that relieves Registry Operator of such obligation. The decision in any such further review shall be based on the report and supporting materials required by Subsection 4.3.1.

4.3.4. A policy established by the ICANN Board of Directors on a temporary basis, without a prior recommendation by the council of an ICANN Supporting Organization, shall also be considered to be a Consensus Policy if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, so long as the Board reasonably determines that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the operational stability of Registry Services, the DNS, or the Internet, and that the proposed specification or policy is as narrowly tailored as feasible to achieve those objectives. In establishing any specification or policy under this provision, the ICANN Board of Directors shall state the period of time for which the specification or policy is temporarily adopted and shall immediately refer the matter to the appropriate Supporting Organization for its evaluation and review with a detailed explanation of its reasons for establishing the temporary specification or policy and why the Board believes the policy should receive the consensus support of Internet stakeholders. If the period of time for which the specification or policy is adopted exceeds ninety days, the Board shall reaffirm its temporary establishment every ninety days for a total period not to exceed one year, in order to maintain such specification or policy in effect until such time as it meets the standard set forth in Subsection 4.3.1. If the standard set forth in Subsection 4.3.1 is not met within the temporary period set by the Board, or the council of the Supporting Organization to which it has been referred votes to reject the temporary specification or policy, it will no longer be a "Consensus Policy."

4.3.5. For all purposes under this Agreement, the policies identified in Appendix A shall be treated in the same manner and have the same effect as "Consensus Policies."

4.3.6. In the event that, at the time the ICANN Board of Directors establishes a specification or policy under Subsection 4.3.1 during the Term of this Agreement, ICANN does not have in place an Independent Review Panel established under ICANN's bylaws, the fifteen-working-day period allowed under Subsection 4.3.2 to seek review shall be extended until fifteen working days after ICANN does have such an Independent Review Panel in place and Registry Operator shall not be obligated to comply ICANN with the specification or policy in the interim.

4.4. Time Allowed for Compliance. Registry Operator shall be afforded a reasonable period of time (not to exceed four months unless the nature of the specification or policy established under Subsection 4.3 reasonably requires, as agreed to by ICANN and Registry Operator, a longer period) after receiving notice of the establishment of a specification or policy under Subsection 4.3 in which to comply with that specification or policy, taking into account any urgency involved.

4.5. Indemnification of Registry Operator. ICANN shall indemnify, defend, and hold harmless Registry Operator (including its directors, officers, employees, and agents) from and against any and all claims, damages, liabilities, costs, and expenses, including reasonable legal fees and expenses, arising solely from Registry Operator's compliance as required by this Agreement with an ICANN specification or policy (including, without limitation, a Consensus Policy) established after the Effective Date.

5. MISCELLANEOUS PROVISIONS.

5.2. Termination

5.2.1. In the event an arbitration award or court judgment is rendered specifically enforcing any provision of this Agreement or declaring a party's rights or obligations under this Agreement, either party may, by giving written notice, demand that the other party comply with the award or judgment. In the event that the other party fails to comply with the order or judgment within ninety days after the giving of notice (unless relieved of the obligation to comply by a court or arbitration order before the end of that ninety-day period), the first party may terminate this Agreement immediately by giving the other party written notice of termination.

5.2.2. If Registry Operator becomes bankrupt or insolvent, ICANN may immediately terminate this Agreement upon notice to Registry Operator.

5.3 Renewal.

5.3.1 The initial Expiration Date of this Agreement shall be [date seven years from Effective Date].

5.3.2. This Agreement shall automatically renew for periods of seven years following the initial Expiration Date unless Registry Operator shall have given 3 months prior written notice that it does not intend to renew the Agreement and provided that Registry Operator has not been finally determined to be in uncured breach of this Agreement at the time of such renewal.

5.4. Resolution of Disputes Under This Agreement. Disputes arising under or in connection with this Agreement, including requests for specific performance, shall be resolved through binding arbitration conducted as provided in this Subsection 5.4 pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in Los Angeles County, California, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the arbitrators to reallocate the costs in their award as provided in the ICC rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the initiation of arbitration. In all litigation involving ICANN concerning this Agreement (as provided in the remainder of this Subsection), jurisdiction and exclusive venue for such litigation shall be in a court located in Los Angeles, California, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of the parties during the pendency of an arbitration, the parties shall have the right to seek a temporary stay or injunctive relief from the arbitration panel or a court located in Los Angeles, California, USA, which shall not be a waiver of this arbitration agreement.

5.5. Specific Performance. During the Term of this Agreement, either party may seek specific performance of any provision of this Agreement as provided by Subsection 5.4, provided the party seeking such performance is not in material breach of its obligations.

5.6. Limitation of Liability. ICANN's aggregate monetary liability for violations of this Agreement shall not exceed the amount of Fees paid by Registry Operator to ICANN within the preceding twelve-month period under Subsection 3.4. Registry Operator's aggregate monetary liability to ICANN for violations of this Agreement shall be limited to fees due and owing to ICANN under this Agreement. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages arising out of or in connection with this Agreement or the performance or nonperformance of obligations undertaken in this Agreement. EXCEPT AS OTHERWISE PROVIDED IN THIS AGREEMENT, REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.

5.7. Assignment. Neither party may assign this Agreement without the prior written approval of the other party, provided, however, that Registry Operator may assign this Agreement without ICANN’s consent (i) to a wholly-owned subsidiary of Registry Operator, or (ii) to any entity into which Registry Operator through a transaction or series of related transactions merges, consolidates, or reorganizes.

5.8. Force Majeure. Neither party shall be liable to the other for any loss or damage resulting from any cause beyond its reasonable control (a "Force Majeure Event") including, but not limited to, insurrection or civil disorder, war or military operations, national or local emergency, acts or omissions of government or other competent authority, compliance with any statutory obligation or executive order, industrial disputes of any kind (whether or not involving either party's employees), fire, lightning, explosion, flood, subsidence, weather of exceptional severity, and acts or omissions of persons for whom neither party is responsible. Upon occurrence of a Force Majeure Event and to the extent such occurrence interferes with either party's performance of this Agreement, such party shall be excused from performance of its obligations (other than payment obligations) during the first six months of such interference, provided that such party uses best efforts to avoid or remove such causes of nonperformance as soon as possible.

5.9. No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by either ICANN or Registry Operator to any non-party to this Agreement, including any registrar or Registered Name holder.

5.10. Notices, Designations, and Specifications. All notices (including determinations, designations, and specifications) to be given under this Agreement shall be given in writing at the address of the appropriate party as set forth below, unless that party has given a notice of change of address in writing. Any notice required by this Agreement shall be deemed to have been properly given when delivered in person, when sent by electronic facsimile, or when scheduled for delivery by an internationally recognized courier service. Designations and specifications by ICANN under this Agreement shall be effective when written notice of them is deemed given to Registry.

If to ICANN, addressed to:

Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina Del Rey, California 90292
Telephone: 1/310/823-9358
Facsimile: 1/310/823-8649
Attention: Chief Executive Officer

If to Registry Operator, addressed to:

[_____________________]
Telephone: _____________
Facsimile: ______________
Attention: ______________

5.11. Dates and Times. All dates and times relevant to this Agreement or its performance shall be computed based on the date and time observed in Los Angeles, California, USA.

5.12. Language. All notices, designations, determinations, and specifications made under this Agreement shall be in the English language.

5.13. Amendments and Waivers. No amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by the party waiving compliance with such provision. No waiver of any of the provisions of this Agreement shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly provided.

5.14. Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute one and the same instrument.

5.15. Entire Agreement. This Agreement (including its Appendices, which form a part of it) constitutes the entire agreement of the parties hereto pertaining to the operation of the Registry TLD and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, between the parties on that subject. In the event of a conflict between the provisions in the body of this Agreement and any provision in its Appendices, the provisions in the body of the Agreement shall control.

IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed in duplicate by their duly authorized representatives.

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

By:_____________________________
Date:

[insert name of Registry Operator]

By:_____________________________
[insert name of official]
[insert title of official]

Date:

Appendix A

Consensus Policies

1. UDRP

2. RGP

3. Deletes

4. Transfers