NSI will recognize ICANN and agree to operate the registry in accordance with provisions of the Registry Agreement between ICANN and NSI and the policies established by ICANN in accordance with the terms of that agreement.

Amendment 19: I.B.1

NSI recognizes ICANN as NewCo in accordance with the provisions of Amendment 11. "ICANN" shall replace the term "NewCo" wherever such reference appears in Amendment 11 to the Cooperative Agreement.

Beginning January 15, 2000, NSI as registry will charge registrars $6 per registration-year for the remainder of the term of the Registry Agreement. (The fee will remain at $9 until January 15, 2000.) The fee may be increased to cover increases in the registry’s net costs resulting from ICANN policies or from legislation specifically applicable to the provision of registry services.

Registrar License and Agreement: 5.2.a, 5.2.b, 5.2.c

(a) From the Effective Date of this Agreement through January 15, 2000, Registrar agrees to pay NSI the non-refundable amounts of $18 United States dollars for each initial two-year domain name registration and $9 United States dollars for each one-year domain name re-registration (collectively, the "Registration Fees") registered by Registrar through the System.

(b) Thereafter, and for the balance of the term of this Agreement, Registrar agrees to pay NSI the non-refundable amounts of $6 United States dollars for each annual increment of an initial domain name registration and $6 United States dollars for each annual increment of a domain name re-registration (collectively, the "Registration Fees") registered by Registrar through the System.

(c) NSI reserves the right to adjust the Registration Fees prospectively upon thirty (30) days prior notice to Registrar, provided that such adjustments are consistent with NSI's Cooperative Agreement with the United States Government or its Registry Agreement with ICANN, as applicable, and are applicable to all registrars in the .com, .org and .net TLDs. NSI will invoice Registrar monthly in arrears for each month's Registration Fees. All Registration Fees are due immediately upon receipt of NSI's invoice pursuant to a letter of credit, deposit account, or other acceptable credit terms agreed by the Parties.

Registry Agreement: 20

20. Price for Registry Services. The price(s) to accredited registrars for entering initial and renewal SLD registrations into the registry database and for transferring a SLD registration from one accredited registrar to another will be as set forth in Section 5 of Appendix B, Registrar License and Agreement. These prices shall be increased through an amendment to this Agreement as approved by ICANN and NSI, such approval not to be unreasonably withheld, to reflect demonstrated increases in the net costs of operating the registry arising from (1) ICANN policies adopted after the date of this Agreement, or (2) legislation specifically applicable to the provision of Registry Services adopted after the date of this Agreement, to ensure that NSI recovers such costs and a reasonable profit thereon; provided that such increases exceed any reductions in costs arising from (1) or (2) above.

Amendment 19: II.7

7. Price for Registry Services The price to licensed registrars for entering initial and renewal SLD registrations into the registry and for transferring a SLD registration from one accredited registrar to another will be as set forth in the Registry Agreement at the time of its expiration or termination. These prices shall be increased to reflect demonstrated increases in costs of operating the registry arising from (1) changes or additions to the work provided under this Agreement directed by the Department of Commerce or (2) legislation specifically applicable to the Registry Services business of Registry adopted after the date of this Amendment to ensure that NSI recovers such increased costs and a reasonable profit thereon.

None of these texts states exactly what registry fee increases are acceptable; this could result in conflict later, i.e. if NSI seeks to increase the Registration Fee. We believe additional text should be added to more clearly state the conditions on which the price of registry services may be increased.

Changes to the registry fee seem to be governed by a "one-way ratchet" rule. If NSI's costs go up as a result of new policies governing its operations, these texts allow the company to pass those costs on to consumers through an increase in the registry fee. But if its costs go down - whether because new policies make it cheaper to run a registry, because the economies of scale of operating a registry (significant fixed cost and low marginal cost) continue to reduce the average cost of each registration as quantity increases, or for some other reason - NSI would seem to have no obligation, and indeed to lack the ability, to pass these savings on to customers.

Note that Registry Agreement: 20 and Amendment 19: II.7 seem functionally equivalent save for the final clause of the former which is not present in the latter. We think it probably makes more sense to include the clause in both places or in neither.

"Not to be unreasonably withhead" is legal term of art that would enable a judge to view the equities of the situation in the event of a lawsuit and approve--or not--an increase that ICANN had refused to allow. Threat of such a lawsuit, of course, might alone help NSI ensure that fee increases can be arranged even if there is conflict with ICANN on other fronts or a general disposition against such increases.

NSI will agree to use its best commercial efforts to implement by January 15, 2000 modifications to the Shared Registration System that will (a) enable a registrar to accept registrations and renewals in one-year increments; and (b) enable a registrar to add one year to a registrant’s registration period upon transfer of a registration from one registrar to another.

Registry Agreement: 12

18. Performance and Functional Specifications for Registry Services. Unless and until ICANN adopts different standards as a Consensus Policy pursuant to Section 4, NSI shall provide registry services to ICANN-accredited registrars meeting the performance and functional specifications set forth in SRS specification version 1.0.6 dated September 10, 1999, as supplemented by Appendix E. In the event ICANN adopts different performance and functional standards for the registry as a Consensus Policy in compliance with Section 4, NSI shall comply with those standards to the extent practicable, provided that compensation pursuant to the provisions of Section 20 has been resolved prior to implementation and provided further that NSI is given a reasonable time for implementation. In no event shall NSI be required to implement any such different standards before 3 years from the Effective Date of this Agreement.

Registrar License and Agreement: 2.3, Registry Agreement Appendix E: 3

2.3 New Architectural Features. NSI will use its best commercial efforts to develop and implement two additional modifications to the Licensed Product by January 15, 2000 as follows:

2.3.1 NSI will issue an upgrade to the Licensed Product that will enable a Registrar to accept initial domain name registrations or renewals of a minimum of one year in length, or in multiples of one year increments, up to a maximum of ten (10) years.

2.3.2 NSI will issue an upgrade to the Licensed Product that will enable registrars to accept the addition of one additional year to a registrant's "current" registration period when a registrant changes from one registrar to another.

Registrars will be able to offer these new features only for new registrations or renewals occurring after the Upgrade is deployed. Both Upgrades will be introduced into the Operational Test and Evaluation environment for testing prior to deployment.

"Best commercial efforts" would enable ICANN to prevail on NSI to make these modifications to the SRS under threat of a lawsuit--if indeed delays were due to foot-dragging. However, one could imagine a contract that was based on results rather than efforts, specifying deadlines and appropriate damages for missing them that don't worry so much about excuses for nonperformance. Imagine buying a new house and considering two possible contract clauses: "The contractor will make best efforts to have the house ready by New Year's" and "The contractor will have the house ready by New Year's; if it's not ready the buyer's rent will be covered for lodging in a similarly located and furnished dwelling until it's ready." When there's a risk, a good contract might be clear about on whose shoulders the risk rested should the danger materialize. This contract doesn't appear to do that, opening up possibility of litigation (or unexpected harm) later. Compare NSI's "best commercial efforts" for software development with Registry Agreement: Definitions 1.d which requires ICANN to take certain actions by specific deadlines.

Alternative development methodologies - potentially including open source "distributed community development" or at least review - might result in a more trusted final product than the closed, internal system NSI currently uses for SRS development.

NSI will be contractually obligated to provide equivalent access to the Shared Registration System to all registrars accredited by ICANN (including NSI acting as a registrar) and to ensure that the revenues and assets of the registry are not utilized to advantage NSI’s registrar activities to the detriment of other registrars.

Registry Agreement: 21

21. Additional NSI Obligations.

(A) NSI shall provide all licensed Accredited Registrars (including NSI acting as registrar) with equivalent access to the Shared Registration System. NSI further agrees that it will make a certification to ICANN every six months, using the objective criteria set forth in Appendix F that NSI is providing all licensed Accredited Registrars with equivalent access to its registry services.

(B) NSI will ensure, in a form and through ways described in Appendix F that the revenues and assets of the registry are not utilized to advantage NSI's registrar activities to the detriment of other registrars.

Amendment 19: I.6

A. The Department of Commerce hereby approves the form of certification (Appendix 3) to be submitted every six months in fulfillment of NSI's obligations under Amendment 11 regarding NSI's provision to all licensed Accredited Registrars of equivalent access to its registry.

B. The Department of Commerce hereby approves the separation of NSI's registry and registrar assets, as described in Appendix 4, in fulfillment of NSI's obligations under Amendment 11 to ensure that the revenues and assets of the registry are not used to financially advantage NSI's registrar activities to the detriment of other registrars.

The term of the Registry Agreement is four years from its signing. If ownership of NSI’s registry and registrar operations is fully separated within 18 months, and the registry functions are performed by an entity that is not affiliated with a registrar and promises never to affiliate with a registrar, the term would be extended for four additional years. Department of Commerce approval is required for the transfer of NSI’s registry operations and for the designation of a successor registry by ICANN.

Registry Agreement: 23

23. Expiration of this Agreement. The Expiration Date shall be four years after the Effective Date, unless extended as provided below. In the event that NSI completes the legal separation of ownership of its Registry Services business from its registrar business by divesting all the assets and operations of one of those businesses within 18 months after Effective Date to an unaffiliated third party that enters an agreement enforceable by ICANN and the Department of Commerce (i) not to be both a registry and a registrar in the Registry TLDs, and (ii) not to control, own or have as an affiliate any individual(s) or entity(ies) that, collectively, act as both a registry and a registrar in the Registry TLDs, the Expiration Date shall be extended for an additional four years, resulting in a total term of eight years. For the purposes of this Section, "unaffiliated third party" means any entity in which NSI (including its successors and assigns, subsidiaries and divisions, and their respective directors, officers, employees, agents and representatives) does not have majority equity ownership or the ability to exercise managerial or operational control, either directly or indirectly through one or more intermediaries. "Control," as used in this Section 23, means any of the following: (1) ownership, directly or indirectly, or other interest entitling NSI to exercise in the aggregate 25% or more of the voting power of an entity; (2) the power, directly or indirectly, to elect 25% or more of the board of directors (or equivalent governing body) of an entity; or (3) the ability, directly or indirectly, to direct or cause the direction of the management, operations, or policies of an entity.

Amendment 19: 10

10. The Expiration Date of this Agreement shall be four years after the date this Amendment is signed, unless extended as provided below. In the event that NSI completes the legal separation of the ownership of its Registry Services business from its registrar business by divesting all the assets and operations of one of those businesses, within 18 months after the date of this Amendment to an unaffiliated third party that enters an agreement enforceable by the Department of Commerce (i) not to be both a registry and a registrar in the Registry TLDs, and (ii) not to control, own or have as an affiliate any individual(s) or entity(ies) that, collectively, act as both a registry and a registrar in the Registry TLDs, the Expiration Date shall be extended for an additional four years, resulting in a total term of eight years. For the purposes of this Section, "unaffiliated third party" means an entity in which NSI (including its assigns, subdivisions, and divisions, and their respective directors, officers, employees, agents and representatives), does not have majority equity ownership or the ability to exercise managerial or operational control, either directly or indirectly through one or more intermediaries. "Control," as used in this Section I.B.10, means any of the following: (1) ownership, directly or indirectly, or other interest entitling NSI to exercise in the aggregate 25% or more of the voting power of an entity; (2) the power, directly or indirectly, to elect 25% or more of the board of directors (or equivalent governing body) of an entity; or (3) the ability, directly or indirectly, to direct or cause the direction of the management, operations, or policies of an entity.

What would it mean for NSI to transfer its registry to an "unaffiliated third party"? Hypothetically, suppose they made a new "NSI Registry" corporation (a Lucent Technologies-from-AT&T-like spinoff) and gave each NSI shareholder an appropriate ownership stake in the new company. NSI proper would then no longer own any of the NSI Registry. But would that be unaffiliated? We think not, yet it seems that such a spinoff would satisfy the requirements of this proposed text.

If NSI retained less than a majority interest, and no control, it would still have a clear financial interest in cross-promoting the business between the two--limited only by the other clauses of the agreement and, at the margins, antitrust law.

DoC oversight for another four years seems slower than the speed of transition to private DNS management originally contemplated by the White Paper. But it does provide additional protection against certain problems; for example, DoC oversight might lessen the threat to the stability of the Internet in case of misbehavior by ICANN.

Upon the expiration of the agreement, ICANN will conduct a process for selecting a successor registry, in which NSI may compete on an equal basis. If, during the term of the registry agreement, NSI fails to remedy its breach of the registry agreement it may be terminated as the registry for .com, .net, and .org.

Registry Agreement: 3.b

(B) NSI acknowledges and agrees that upon the earlier of (i) the Expiration Date or (ii) termination of this Agreement by ICANN pursuant to Section 14, it will cease to be the registry for the Registry TLDs, unless prior to the end of the term of this Agreement NSI is chosen as the Successor Registry in accordance with the provisions of this Agreement.

Registry Agreement: 14.b

(B) In the event of termination by DOC of its Cooperative Agreement with NSI pursuant to Section I.B.8 of that Agreement, ICANN shall, after receiving express notification of that fact from DOC and a request from DOC to terminate NSI as the operator of the registry database for the Registry TLDs, terminate NSI's rights under this Agreement, and shall cooperate with DOC to facilitate the transfer of the operation of the registry database to a successor registry.

Registry Agreement: 22

22. Designation of Successor Registry.

(A) Not later than one year prior to the end of the term of this Agreement, ICANN shall, in accordance with Section 4, adopt an open, transparent procedure for designating a Successor Registry. The requirement that this procedure be opened one year prior to the end of the Agreement shall be waived in the event that the Agreement is terminated prior to its expiration.

(B) NSI or its assignee shall be eligible to serve as the Successor Registry and neither the procedure established in accordance with subsection (A) nor the fact that NSI is the incumbent shall disadvantage NSI in comparison to other entities seeking to serve as the Successor Registry.

(C) If NSI or its assignee is not designated as the Successor Registry, NSI or its assignee shall cooperate with ICANN and with the Successor Registry in order to facilitate the smooth transition of operation of the registry to Successor Registry. Such cooperation shall include the timely transfer to the Successor Registry of an electronic copy of the registry database and of a full specification of the format of the data.

(D) ICANN shall select as the Successor Registry the eligible party that it reasonably determines is best qualified to perform the registry function under terms and conditions developed as a Consensus Policy, taking into account all factors relevant to the stability of the Internet, promotion of competition, and maximization of consumer choice, including without limitation: functional capabilities and performance specifications proposed by the eligible party for its operation of the registry, the price at which registry services are proposed to be provided by the party, relevant experience of the party, and demonstrated ability of the party to handle operations at the required scale. ICANN shall not charge any additional fee to the Successor Registry.

(E) In the event that a party other than NSI or its assignee is designated as the Successor Registry, NSI shall have the right to challenge the reasonableness of ICANN's failure to designate NSI or its assignee as the Successor Registry under the provisions of Section 13 of this Agreement.

Registrar License and Agreement: 6.1

6.1 Term of Agreement and Termination.

(a) Term of the Agreement. The duties and obligations of the Parties under this Agreement shall apply from the Effective Date through and including the last day of the calendar month sixty (60) months from the Effective Date (the "Initial Term"). Upon conclusion of the Initial Term, all provisions of this Agreement will automatically renew for successive five (5) year renewal periods until the Agreement has been terminated as provided herein, Registrar elects not to renew, or NSI ceases to operate as the registry for the .com, .org and .net TLDs. In the event that revisions to NSI's Registrar License and Agreement are approved or adopted by the U.S. Department of Commerce, or ICANN, as appropriate, Registrar will execute an amendment substituting the revised agreement in place of this Agreement, or, at Registrar's option, exercised within fifteen (15) days, may terminate this Agreement immediately by giving written notice to NSI.

(b) Termination For Cause. In the event that either Party materially breaches any term of this Agreement including any of its representations and warranties hereunder and such breach is not substantially cured within thirty (30) calendar days after written notice thereof is given by the other Party, then the non-breaching Party may, by giving written notice thereof to the other Party, terminate this Agreement as of the date specified in such notice of termination.

(c) Termination at Option of Registrar. Registrar may terminate this Agreement at any time by giving NSI thirty (30) days notice of termination.

(d) Termination Upon Loss of Registrar's Accreditation. This Agreement shall terminate in the event Registrar's accreditation by ICANN, or its successor, is terminated or expires without renewal.

(e) Termination in the Event that Successor Registry is Named. This Agreement shall terminate in the event that the U.S. Department of Commerce or ICANN, as appropriate, designates another entity to serve as the registry for the .com, .net. and .org TLDs (the "Successor Registry").

(f) Termination in the Event of Bankruptcy. Either Party may terminate this Agreement if the other Party is adjudged insolvent or bankrupt, or if proceedings are instituted by or against a Party seeking relief, reorganization or arrangement under any laws relating to insolvency, or seeking any assignment for the benefit of creditors, or seeking the appointment of a receiver, liquidator or trustee of a Party's property or assets or the liquidation, dissolution or winding up of a Party's business.

(g) Effect of Termination. Upon expiration or termination of this Agreement, NSI will complete the registration of all domain names processed by Registrar prior to the date of such expiration or termination, provided that Registrar's payments to NSI for Registration Fees are current and timely. Immediately upon any expiration or termination of this Agreement, Registrar shall (i) transfer its sponsorship of SLD name registrations to another licensed registrar(s) of the Registry, in compliance with any procedures established or approved by the U.S. Department of Commerce or ICANN, as appropriate, and (ii) either return to NSI or certify to NSI the destruction of all data, software and documentation it has received under this Agreement.

(h) Survival. In the event of termination of this Agreement, the following shall survive: (i) Sections 2.6, 2.7, 2.14, 6.1(g), 6.6, 6.7, 6.10, 6.12, 6.13, 6.14 and 6.16; (ii) the SLD holder's obligations to indemnify, defend, and hold harmless NSI, as stated in Section 2.16; (iii) the surety's obligations under the Surety Instrument described in Section 2.13 with respect to matters arising during the term of this Agreement; and (iv) Registrar's payment obligations as set forth in Section 5.2 with respect to initial registrations or re-registrations during the term of this Agreement. Neither Party shall be liable to the other for damages of any sort resulting solely from terminating this Agreement in accordance with its terms but each Party shall be liable for any damage arising from any breach by it of this Agreement.

In case of NSI breach of the registry agreement or MoU, it seems that existing texts contemplate that NSI still owns the SRS. That would make it considerably more difficult for ICANN/DoC to terminate NSI's contract and rebid the root should that be deemed appropriate. For, if NSI owns the SRS, it would then be necessary to design a functionally equivalent replacement for the SRS, but on a short timetable with a substantial installed SRS-aware infrastructure.

Even if NSI complies with its contractual obligations, there are reasons why it might be desirable for the SRS to be an "open standard." For, if the protocols of the SRS were publicly known, new gTLD registries (when created) could use a system that's interface-compatible with the SRS, making it possible for existing .com, .org, and .net registrars to use their existing infrastructure to register new domains in new gTLDS (assuming new gTLDs adopt a registry-registrar model, which we understand not to be a given). We realize that NSI claims proprietary rights in the SRS, but nevertheless the benefits of sharing the SRS standards and protocols might be thought compelling for the efficiency gains that would potentially result.

NSI will continue to provide third parties bulk access to TLD zone files.

Registry Agreement: 19

19. Bulk Access to Zone Files. NSI shall provide third parties bulk access to the zone files for .com, .net, and .org TLDs on the terms set forth in the zone file access agreement (attached as Appendix D). Such agreement may be revised by NSI, provided however, that any such changes must be approved in advance by ICANN.

Amendment 19: I.4.C

C. Notwithstanding any changes NSI may make in the manner in which it propagates Registry TLD Zone File Data to the Registry TLD zone servers NSI shall continue to provide a complete zone file for downloading at least once per day. If, in order to fulfill its obligation to provide bulk public access to zone file data, NSI is required to incur significant additional costs to distribute complete copies of the zone files to multiple third parties, NSI shall be entitled to charge a reasonable cost-based fee provided such fee has been approved in advance by the Department of Commerce, said approval not to be unreasonably withheld.

Amendment 19: I.6

NSI shall provide third parties bulk access to the zone files for the Registry TLDs on the terms set forth in the zone file access agreement then in effect under the Registry Agreement. NSI may not change the access agreement without the prior written approval of the Department of Commerce.

The Registrar License and Agreement has been modified to reflect various suggestions made by registrars during the testbed phase.

See Registrar License and Agreement: Exhibit B: Policy on Transfer of Sponsorship of Registrations Between Registrars.

Registrar License and Agreement: 2.3, Registry Agreement Appendix E: 3

2.3 New Architectural Features. NSI will use its best commercial efforts to develop and implement two additional modifications to the Licensed Product by January 15, 2000 as follows:

2.3.1 NSI will issue an upgrade to the Licensed Product that will enable a Registrar to accept initial domain name registrations or renewals of a minimum of one year in length, or in multiples of one year increments, up to a maximum of ten (10) years.

2.3.2 NSI will issue an upgrade to the Licensed Product that will enable registrars to accept the addition of one additional year to a registrant's "current" registration period when a registrant changes from one registrar to another.

Registrars will be able to offer these new features only for new registrations or renewals occurring after the Upgrade is deployed. Both Upgrades will be introduced into the Operational Test and Evaluation environment for testing prior to deployment.

NSI will be entitled to establish its own prices for registrar services (the Cooperative Agreement currently requires NSI to charge $35 per year for those services)

Amendment 19: III.4 (adding the following text to section Section G.4 of the Cooperative Agreement)

G.4.a. From the effective date of this Amendment, NSI, in its capacity as a registrar for the Registry TLDs, may establish the charge to SLD holders for registration of SLD names or for any other service provided by NSI as registrar at its own discretion.

ICANN will be contractually obligated, to the registry and to all accredited registrars, to comply with specified procedural requirements governing the exercise of its authority. These include (a) definition of the consensus required for action by ICANN and specification of the procedure for reviewing ICANN’s determination that a consensus exists; (b) a commitment to open, transparent, and pro-competitive processes; and (c) a prohibition against arbitrary, unjustifiable, or inequitable actions.

Registry Agreement: Definitions 1 and Registrar Accreditation Agreement: I.B

1. A "Consensus Policy" is one adopted by ICANN as follows:

(a) "Consensus Policies" are those adopted based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (1) the adoption of the policy by the ICANN Board of Directors, (2) a recommendation that the policy should be adopted by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, and (3) 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.

(b) In the event that NSI 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 adopting the policy. The decision of the panel shall be based on the report and supporting materials required by subsection (a) above. In the event that NSI seeks review and the Panel sustains the Board's determination that the policy is based on a consensus among Internet stakeholders represented in the ICANN process, then NSI must implement such policy unless it promptly seeks and obtains injunctive relief under Section 13 below.

(c) If, following a decision by the Independent Review Panel convened under subsection (b) above, NSI 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 Section 13 below; provided, however, that NSI must continue to implement the policy unless it has obtained injunctive relief under Section 13 below or a final decision is rendered in accordance with the provisions of Section 13 that relieves NSI of such obligation. The decision in any such further review shall be based on the report and supporting materials required by subsection (a) above.

(d) A policy adopted 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, and if immediate temporary adoption of a policy on the subject is necessary to maintain the stability of the Internet or the operation of the domain name system, and if the proposed policy is as narrowly tailored as feasible to achieve those objectives. In adopting any policy under this provision, the ICANN Board of Directors shall state the period of time for which the 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 adopting the temporary policy and why the Board believes the policy should receive the consensus support of Internet stakeholders. If the period of time for which the policy is adopted exceeds 45 days, the Board shall reaffirm its temporary adoption every 45 days for a total period not to exceed 180 days, in order to maintain such policy in effect until such time as it meets the standard set forth in subsection (a) above. If the standard set forth in subsection (a) above 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 policy, it will no longer be a "Consensus Policy."

(e) For all purposes under this Agreement, the policies identified in Appendix A adopted by the ICANN Board of Directors before the effective date of this Agreement shall be treated in the same manner and have the same effect as "Consensus Policies."

(f) In the event that, at the time the ICANN Board adopts a policy under subsection (a) above 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 (b) above to seek review shall be extended until fifteen working days after ICANN does have such an Independent Review Panel in place and NSI shall not be obligated to comply with the policy in the interim.

Registrar Accreditation Agreement: I.E

E. An "ICANN-adopted policy" (and references to ICANN "adopt[ing]" a policy or policies) refers to a Consensus Policy adopted by ICANN (i) in conformity with applicable provisions of its articles of incorporation and bylaws and Section II.C of this Agreement and (ii) of which Registrar has been given notice and a reasonable period in which to comply.

Registry Agreement: 4 and Registrar Accreditation Agreement: II.C

4. General Obligations of ICANN. With respect to all matters that impact the rights, obligations, or role of NSI, ICANN shall during the Term of this Agreement:

(A) exercise its responsibilities in an open and transparent manner;

(B) not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition;

(C) not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out NSI for disparate treatment unless justified by substantial and reasonable cause; and

(D) ensure, through its reconsideration and independent review policies, adequate appeal procedures for NSI, to the extent it is adversely affected by ICANN standards, policies, procedures or practices.

This text generally holds ICANN to its promise of being merely a consensus-generating and -implementing organization.

The text appears to prevent the ICANN Board from taking any permanent action without the study and approval of the appropriate supporting organization. The current ICANN bylaws only call for supporting organization involvement in matters that implicate their respective policy areas; it's not clear here whether other decisions--hiring a new President, other personnel matters, negotiating contracts, etc., are covered by this consensus requirement.

Indeed: would these very contracts, under the scheme they propose, have to pass the muster of these terms at the time of renewal? Would one want them to have to?

This should be clarified now one way or the other, as it's a likely point of contention later.

Any action taken by the Board without the official procedure is valid only for 45 days, renewable up to three times, after which the action no longer is in effect. While this accomplishes the goal of binding the Board to a formal open process, it might cause problems for highly controversial issues for which no consensus can readily be determined even with 180 days of negotiations among stakeholders. If one thinks that it might nevertheless be important that the Board be able to take appropriate action, this policy denies them that power and could therefore be troubling.

A hypothetical: Many want to add new gTLDs to the root; there may well be consensus on that. But one could imagine a stalemate whereby there is no consensus on any one particular plan. (Indeed, the creation of the DNSO itself seemed to face this--there was supposed to be one, but no consensus about what its structure would be.) In instances such as these, would ICANN be unable to produce new gTLDs, or would ICANN be able to say that there was consensus under these standards to add them generally, and that details of implementation approved only by the board are enough to add the names? Issues like these should be clarified now, as they are likely to be contentious later.

Note section 1.f which states that, until ICANN establishes its IRP, no ICANN policy binds NSI.

The agreements explicitly define the subjects within the scope of ICANN’s authority with respect to both the registry and registrars.

Registry Agreement: 4 and Registrar Accreditation Agreement: II.C (above)

Registrar Accreditation Agreement: II.D.1.b and Registry Agreement: 3.A.ii

1. During the Term of this Agreement:

a. Registrar agrees that it will operate as a registrar for TLDs for which it is accredited by ICANN in accordance with this Agreement;

b. Registrar shall comply, in such operations, with all ICANN-adopted Policies insofar as they:

i. relate to one or more of the following: (A) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability and/or stable operation of the Internet or domain-name system, (B) registrar policies reasonably necessary to implement Consensus Policies relating to the Registry, or (C) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names), and

ii. do not unreasonably restrain competition.

Registrar Accreditation Agreement: II.D.2 and Registry Agreement: 3.C

2. To the extent that Consensus Policies are adopted in conformance with Section II.C of this Agreement, the measures permissible under Section II.D.1.b.i shall include, without limitation:

i. principles for allocation of SLD names (e.g., first-come/first-served, timely renewal, holding period after expiration);

ii. prohibitions on warehousing of or speculation in domain names by registrars;

iii. reservation of SLD names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and single-letter/digit names);

iv. the allocation among continuing registrars of the SLD names sponsored in the registry by a registrar losing accreditation; and

v. the transfer of registration data upon a change in registrar sponsoring the registration.

These policies put some legal teeth into the desire to limit ICANN to consideration of only specifically enumerated and limited issue areas.

The particular text chosen here should be tested against possible ICANN activities to see if (1) the text clearly constraints or allows it, instead of being vague and (2) the result--ICANN is allowed to undertake the policy or not--is what one would want.

For example, an ICANN constituent could seek to generate consensus around a policy changing standards for registration in .edu. (One could suggest allowing .edu registrations by 4-year degree-granting educational institutions in all countries (not just in the US, as is currently the case).) But that policy is not needed to facilitate interoperability, reliability, or stability; not necessary (though, in this hypothetical, potentially consonant with consensus); nor related to disputes.

Another example: Suppose ICANN decided that, to increase competition among gTLD registries (once there are more, each with their own gTLD[s]), there was to be a "domain forwarder" feature for, say, 90 days, so that if, for example, yahoo.com got fed up with the .com's and moved to .biz, yahoo.com would automatically redirect DNS requests to the new yahoo.biz servers. Ignoring the questions of whether or not this is technically feasible, it seems like this might be a reasonable policy for ICANN to take, since it would promote competition as stipulated by the White Paper. But, again, this course of action would seem to fall outside that allowed by the proposed text.

ICANN’s authority to set policy for the registry may be terminated if (a) ICANN breaches the Registry Agreement and fails to remedy that breach; (b) the Department of Commerce withdraws its recognition of ICANN; or (c) the Department of Commerce concludes that ICANN has not made sufficient progress towards entering into agreements with other registries and NSI is competitively disadvantaged. In the event ICANN’s authority is terminated, the Department of Commerce will assume the policy-setting function for registry services for the .com, .net and .org top level domains. The same provisions regarding the term of the Registry Agreement will apply under Department of Commerce supervision.

Registry Agreement: 24

24. Withdrawal of Recognition of ICANN by the Department of Commerce. In the event that, prior to the expiration or termination of this Agreement under Section 14 or 16(C), the United States Department of Commerce withdraws its recognition of ICANN as NewCo under the Statement of Policy pursuant to the procedures set forth in Section 5 of Amendment 1 (dated November __, 1999) to the Memorandum of Understanding between ICANN and the Department of Commerce, this Agreement shall terminate.

Registry Agreement: 16.B

(B) If within a reasonable period of time ICANN has not made substantial progress towards having entered into agreements with competing registries and NSI is adversely affected from a competitive perspective, NSI may terminate this Agreement with the approval of the U.S. Department of Commerce. In such event, as provided in Section 16(A) above, the Cooperative Agreement shall replace this Agreement.

Registry Agreement: 2

2. Recognition in Authoritative Root Server System. In the event and to the extent that ICANN is authorized to set policy with regard to an authoritative root server system, it will ensure that (A) the authoritative root will point to the TLD zone servers designated by NSI for the Registry TLDs throughout the Term of this Agreement and (B) any changes to TLD zone server designation submitted to ICANN by NSI will be implemented by ICANN within five business days of submission. In the event that this Agreement is terminated (A) under Section 14 or 16(C) by NSI or (B) under Section 24 due to the withdrawal of recognition of ICANN by the United States Department of Commerce, ICANN's obligations concerning TLD zone server designations for the .com, .net, and .org TLDs in the authoritative root server system shall be as stated in a separate agreement between ICANN and the Department of Commerce.

Registrar fees must be equitably apportioned and approved by registrars that account for payment of two-thirds of registrar fees. NSI has agreed that it will approve an ICANN registrar fee policy so long as its share of the registrar fees does not exceed $2 million.

Registrar Accreditation Agreement: II.L.2

2. Registrar shall pay the on-going component of Registrar accreditation fees adopted by ICANN in accordance with the provisions of Section II.C above, provided such fees are reasonably allocated among all registrars that contract with ICANN and that any such fees must be expressly approved by registrars accounting, in aggregate, for payment of two-thirds of all registrar-level fees. Registrar shall pay such fees in a timely manner for so long as all material terms of this Agreement remain in full force and effect, and notwithstanding the pendency of any dispute between Registrar and ICANN.

Registrar Accreditation Agreement: Transition Agreement 4

4. NSI will approve the on-going component of Registrar accreditation fees, as provided in Section II.L.2 of the Accreditation Agreement, if its portion thereof does not exceed $2,000,000 annually. NSI agrees to prepay $1,000,000 toward its share of the on-going component of its Registrar accreditation fees at the time of signing of the Accreditation Agreement.

What happens if NSI's share, under the funding system reached by consensus of other stakeholders, is larger than $2 million? These clauses seem to place an arbitrary cap on NSI's financial obligations in its registrar capacity. However, should increased registrar competition result in NSI losing registrar market share, the copany would no longer have a "veto" on registrar funding once its market share fell below the stated two-thirds threshold.

While the proposed wording well protects the interests of large registrars, it may put at risk the interests of smaller registrars who would likely lack the collective two-thirds voice required to veto a fee

gTLD registry fees must be equitably apportioned among gTLD registries. NSI has agreed to pay up to $250,000 in gTLD registry fees. Any gTLD fee structure that requires a higher payment by NSI must be approved by registries accounting for two-thirds of the gTLD registry fees.

Registry Agreement: 6

6. NSI Registry-Level Financial Support of ICANN. NSI, in its role as operator of the registry for the Registry TLDs, shall pay the gTLD registry-level fees adopted by ICANN in conformance with Section 4 of this Agreement, provided such fees are reasonably allocated among all gTLD registries that contract with ICANN and provided further that, if NSI's share of the total gTLD registry-level fees are or are budgeted to be in excess of $250,000 in any given year, any such excess must be expressly approved by gTLD registries accounting, in aggregate, for payment of two-thirds of all gTLD registry-level fees. NSI shall pay such fees in a timely manner throughout the Term of this Agreement, and notwithstanding the pendency of any dispute between NSI and ICANN. NSI agrees to prepay $250,000 toward its share of gTLD registry-level fees at the time of signing of this Agreement.

NSI has a $250,000 cap on its registry fees that can only be overridden with the consent of the gTLD registries that account for 2/3 of the total fees paid, a formula that protects the market leaders. For the moment, this effectively gives NSI a veto on gTLD fees, a veto that could conceivably contradict the prevailing consensus of other stakeholders.

Caps such as these may help prevent ICANN from simply bloating its own budget because it can. However lucractive the domain name registration business is and remains, ICANN is due only a limited amount of money, enough to cover its own limited operations.

Upon signing of the agreements, NSI would prepay $1.25 million towards its share of ICANN fees.

Registrar Accreditation Agreement: Transition Agreement 4 (above)

Registry Agreement: 6 (above)

All accredited registrars would be obligated to provide query-based access to registration data and would be barred from placing conditions upon any legal use of that data, except to prohibit use of the data to enable the transmission of mass unsolicited commercial solicitations via e-mail (spam) and to enable high-speed processes for applying for registrations.

Registrar Accreditation Agreement: II.F.1, II.F.2, II.F.3, II.F.4, II.F.5

1. At its expense, Registrar shall provide interactive public access on a current basis (such as through a Whois service) to data concerning all active SLD registrations sponsored by Registrar in the registry for the .com, .net, and .org TLDs. The data accessible shall consist of elements that are designated from time to time according to an ICANN-adopted policy. Until ICANN otherwise specifies by means of an ICANN-adopted policy, this data shall consist of the following elements as contained in Registrar's database:

a. The name of the SLD being registered and the TLD for which registration is being requested;
b. The IP addresses of the primary nameserver and secondary nameserver(s) for the SLD;
c. The corresponding names of those nameservers;
d. The identity of Registrar (which may be provided through Registrar's website);
e. The original creation date of the registration;
f. The expiration date of the registration;
g. The name and postal address of the SLD holder;
h. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the SLD; and
i. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the SLD.

2. Upon receiving any updates to the data elements listed in Sections II.F.1.b through d and f through i from the SLD holder, Registrar shall promptly update its database used to provide the public access described in Section II.F.1.

3. Registrar may subcontract its obligation to provide the public access described in Section II.F.1 and the updating described in Section II.F.2, provided that Registrar shall remain fully responsible for the proper provision of the access and updating.

4. Registrar shall abide by any ICANN-adopted Policy that requires registrars to cooperatively implement a distributed capability that provides query-based Whois search functionality across all registrars. If the Whois service implemented by registrars does not in a reasonable time provide reasonably robust, reliable, and convenient access to accurate and up-to-date data, the Registrar shall abide by any ICANN-adopted Policy requiring Registrar, if reasonably determined by ICANN to be necessary (considering such possibilities as remedial action by specific registrars), to supply data from Registrar's database to facilitate the development of a centralized Whois database for the purpose of providing comprehensive Registrar Whois search capability.

5. In providing query-based public access to registration data as required by Sections II.F.1 and II.F.4, Registrar shall not impose terms and conditions on use of the data provided except as permitted by an ICANN-adopted policy. Unless and until ICANN adopts a different policy, Registrar shall permit use of data it provides in response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (b) enable high volume, automated, electronic processes that apply to Registrar (or its systems).

Note that Clause 9.C of the Registry Agreement contemplates failure of the distributed Whois system and obliges NSI to develop a centralized system if the distributed Whois proves to be too slow or unreliable.

The motivation for clause 5.b is not entirely clear. Perhaps it's intended to address the concern that hopeful registrants vying for a domain about to expire will submit multiple (potentially hundreds or thousands) registration requests in attempting to increase their chances of success relative to others trying to get the same domain. If this concern is in fact what motivates the clause, we think it might be better to remove the structural problem that causes the high volume registration attempts. In particular, a policy implemented in code -- whether a lottery, a first-request-first-served system, or some other method -- might reduce multiple registration attempts more effectively than a simple prohibition against them.

We understand ICANN to intend to use the existing Registrar Accredidation Agreement (perhaps modified or updated somewhat) for registrars of new gTLDs. What if the DNSO's process of recommending policy for new gTLDs were to advocate the creation of a ".private" gTLD where, at least by default, registration data was not publicly available? Would such a course of action be impossible under this RAA, since the RAA specifically requires registrars to make available the information the DNSO hypothetically recommends should be kept private for the .private gTLD?

All accredited registrars also would be required to provide third-party bulk access to registration data (subject to the restrictions discussed above) for an annual fee that may not exceed $10,000. This obligation would remain in effect until it is replaced by a different policy adopted by ICANN or a finding by the Department of Commerce that no individual or entity is able to exercise market power with respect to data used for development of third-party value added products and services.

Registrar Accreditation Agreement: II.F.6, II.F.7

6. In addition, Registrar shall provide third-party bulk access to the data subject to public access under Section II.F.1 under the following terms and conditions:

a. Registrar shall make a complete electronic copy of the data available at least one time per week for download by third parties who have entered into a bulk access agreement with Registrar.

b. Registrar may charge an annual fee, not to exceed US$10,000, for such bulk access to the data.

c. Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam).

d. Registrar's access agreement may require the third party to agree not to use the data to enable high-volume, automated, electronic processes that apply to Registrar (or its systems).

e. Registrar's access agreement may require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties.

f. Registrar may enable SLD holders to elect not to have data concerning their registrations available for bulk access based on Registrar's "Opt-Out" policy, and Registrar may require the third party to abide by the terms of that Opt-Out policy; provided, however, that Registrar may not use such data subject to opt-out in its own value-added product or service.

7. Registrar's obligations under Section II.F.6 shall remain in effect until the earlier of (a) replacement of this policy with a different ICANN-adopted policy governing bulk access to the data subject to public access under Section II.F.1, or (b) demonstration, to the satisfaction of the United States Department of Commerce, that no individual or entity is able to exercise market power with respect to registrations or with respect to registration data used for development of value-added products and services by third parties.

Zone File Access Agreement

You agree to remit in advance to Network Solutions a quarterly fee of $0 (USD) for the right to access the files during either the Initial Term or Renewal Term of this Agreement. Network Solutions reserves the right to adjust this fee on thirty days’ prior notice to reflect a change in the cost of providing access to the files.

Each registrar shall be required to offer bulk registration data to third parties, but may charge up to $10,000 per year for the information. (But note that the Fee section of the proposed Zone File Access Agreement limits such fees to "the cost of providing access to the file.") Any such sales may be severely restricted to prohibit use for spamming, further resale, or high-speed registration processes. Domain holders have a right to opt out of bulk databases. This policy is in effect until a new one is designed by ICANN or until the DOC is confident that there is no dominant player in this market. These provisions protect the registry's revenue stream from Whois data while still allowing competing use and avoiding disputes over ownership rights.

The motivation for clause II.F.6.d. is not entirely clear. Perhaps it's intended to address the concern that hopeful registrants vying for a domain about to expire will submit multiple (potentially hundreds or thousands) registration requests in attempting to increase their chances of success relative to others trying to get the same domain. If this concern is in fact what motivates the clause, we think it might be better to remove the structural problem that causes the high volume registration attempts. In particular, a policy implemented in code -- whether a lottery, a first-request-first-served system, or some other method -- might reduce multiple registration attempts more effectively than a simple prohibition against them.

We're concerned that there is no corresponding section mandating third-party bulk access to registry data. Registry Agreement clause 9A stiuplates only interactive access to registry data, and clause 19 applies only to zone file data, not to other registry data not contained in zone files. Certain value-added registration services seem to require bulk access to registry data, but we see no wording in the current text to assure that such access is available.

Within six months, the InterNIC website (as well as the internic.com, internic.org, and internic.net domain names) will be transferred to the Department of Commerce.

Amendment 19: I.3.A

A. Within six months from the effective date of this Amendment (the "Transition Period"), NSI shall transfer the internic.com, internic.org and internic.net SLD names to the Department of Commerce.

Amendment 19: I.3.E

E. During the Transition Period, NSI will cooperate with the Department of Commerce, or its designee, to ensure a seamless transition and continuous operation of the InterNIC websites.

There is no particular analytical significance to the three separate components. All three essentially amount to the retirement of the old "internic" site in recognition of the new distributed registration system. Whereas the internic site currently forwards to a NSI server, the new DoC-managed internic site would presumably be neutral, not favoring one registrar over others.

The new crsnic.net site seems to contain information of a "neutral" nature conceptually distinct from that of that suggested by the name nsiregistry.net (a page that currently displays the same content as crsnic.net). For, if NSI were at some point no longer the registry for .COM, .ORG, and .NET, it would perhaps remain entitled to the nsiregistry.net page, but the crsnic.net site would seem a logical address to assign to the new registry of those domains. So, perhaps the crsnic.net site should also be controlled by the DoC under terms similar to these for internic.*.

Until the transfer is completed, NSI will maintain the internic.net website as a public information site with a directory of accredited registrars for .com, .net, and .org, with hotlinks to those registrars

Amendment 19: I.3.B

B. Until such time as NSI has completed such transfer, NSI in its capacity as registry shall maintain and operate the InterNIC website on behalf of the Department of Commerce, with content approved by the Department of Commerce, as a neutral stand alone web page that shall provide a public directory of all accredited registrars and associated contact information (including hotlinks) and other information regarding domain name registration services as directed by the Department of Commerce. NSI shall activate any substitute web pages supplied in HTML format by the Department of Commerce, during this period, within three business days of its receipt of the substitute web pages.

Amendment 19: I.3.D

D. The Department of Commerce shall not transfer or grant a license for the internic.com, internic.org or internic.net SLD names, or the InterNIC mark, to any other registry or registrar for the purpose of competing with NSI.

Within nine months, NSI will modify all of its registration templates and otherwise migrate from the use of the term "InterNIC," or Internet addresses that reflect the term "InterNIC.

Amendment 19: I.3.C

C. During the period lasting until nine months after the date of this Amendment, the Department of Commerce will cooperate with NSI to assure the continued availability of the internic.net SLD name for purposes of email transmissions from registration templates to NSI. Prior to the end of such nine month period, NSI shall modify all of its registration templates and otherwise migrate from the use of the term "InterNIC," or Internet addresses that reflect the term "InterNIC," in connection with its provision of any product or service. Thereafter, the internic.net SLD name shall not be used for the provision of Registrar Services.

Management of the Authoritative Root Server

Nothing in these agreements affects the current arrangements regarding management of the authoritative root server. NSI will continue to manage the authoritative root server in accordance with the direction of the Department of Commerce. The Department of Commerce expects to receive a technical proposal from ICANN for management of the authoritative root and this management responsibility may be transferred to ICANN at some point in the future. The Department of Commerce has no plans to transfer to any entity its policy authority to direct the authoritative root server.

Registry Agreement: 2

2. Recognition in Authoritative Root Server System. In the event and to the extent that ICANN is authorized to set policy with regard to an authoritative root server system, it will ensure that (A) the authoritative root will point to the TLD zone servers designated by NSI for the Registry TLDs throughout the Term of this Agreement and (B) any changes to TLD zone server designation submitted to ICANN by NSI will be implemented by ICANN within five business days of submission. In the event that this Agreement is terminated (A) under Section 14 or 16(C) by NSI or (B) under Section 24 due to the withdrawal of recognition of ICANN by the United States Department of Commerce, ICANN's obligations concerning TLD zone server designations for the .com, .net, and .org TLDs in the authoritative root server system shall be as stated in a separate agreement between ICANN and the Department of Commerce.

Amendment 19: I.4.A

A. The Department of Commerce will ensure that the authoritative root will point to the TLD zone servers designated by NSI for the Registry TLDs (Registry TLD zone server) until the earlier of the termination of this Agreement by the Department of Commerce or termination for cause of the Registry Agreement by ICANN pursuant to Section 14 of that agreement.

Amendment 19: I.4.E

E. In the interest of the smooth, reliable and consistent functioning of the Internet, for so long as the Cooperative Agreement is in effect, NSI agrees not to deploy alternative DNS root server systems.

Amendment 19: I.4.A makes clear that NSI will continue to operate the primary root zone server, meaning that ICANN will not take over operation of the primary root zone server as has been discussed at times.

ICANN has not yet been granted control over the authoritative root. It is not clear whether this language gives DOC not only authority to veto ICANN policies with respect to new TLDs, but also the ability to insist that its own new TLDs be added. (Could the U.S. Congress simply instruct the DOC to add certain new TLDs, wholly independent of ICANN processes?)

NSI gains specific protection against discrimination by ICANN should it be given responsibility for the root file. If ICANN is displaced, or the agreements are terminated under certain conditions, then authority over the root shall revert to the terms of the DOC-NSI Cooperative Agreement.