Sample Business Contracts


.Net Registry Agreement - Internet Corporation for Assigned Names and Numbers (ICANN) and VeriSign Inc.

Services Forms


                            .NET REGISTRY AGREEMENT
                            -----------------------

   This REGISTRY AGREEMENT ("Agreement") is by and between the Internet
   Corporation for Assigned Names and Numbers, a not-for-profit corporation, and
   VeriSign, Inc.

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

   1.1  The "Authoritative Root-Server System" means the constellation of DNS
   root-nameservers specified, from time to time, in the file
   [ftp://ftp.internic.net/domain/named.root].

   1.2  [Deliberately left blank]

   1.3  [Deliberately left blank]

   1.4  The "DNS" refers to the Internet domain name system.

   1.5  The "Effective Date" is the date specified as such in Section 3 of the
   Agreement for Restructured Relationship among ICANN, VeriSign, and Network
   Solutions, Inc.

   1.6  The "Expiration Date" is the date specified in Subsection 5.1.1.

   1.7  "ICANN" refers to the Internet Corporation for Assigned Names and
   Numbers, a party to this Agreement.

   1.8  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.9  "Personal Data" refers to data about any identified or identifiable
   natural person.

   1.10  [Deliberately left blank]

   1.11  "Registered Name" refers to a domain name within the domain of the
   Registry TLD, whether consisting of two or more (e.g., john.smith.name)
   levels, about which Registry Operator or an affiliate engaged in providing
   Registry Services maintains data in a Registry Database, arranges for such
   maintenance, or derives revenue from such maintenance. A name in a Registry
   Database may be a Registered Name even though it does not appear in a TLD
   zone file (e.g., a registered but inactive name).

   1.12  "Registry Data" means all Registry Database data maintained in
   electronic form, and shall include TLD Zone-File Data, all data used to
   provide Registry Services submitted by registrars in electronic form, and all
   other data used to provide Registry Services concerning particular domain
   name registrations or nameservers maintained in electronic form in the
   Registry Database.

                                       1
<PAGE>

   1.13  "Registry Database" means a database comprised of data about one or
   more DNS domain names within the domain of the Registry TLD that is used to
   generate either DNS resource records that are published authoritatively or
   responses to domain name availability lookup requests or Whois queries, for
   some or all of those names.

   1.14  "Registry Operator" refers to VeriSign, Inc., a party to this
   Agreement, or any assignee of it under Subsection 5.11.

   1.15  "Registry-Registrar Agreement" means an agreement between Registry
   Operator and an ICANN-Accredited Registrar with the provisions specified by
   Subsection 3.4.

   1.16  "Registry Services" means services provided as an integral part of the
   operation of the Registry TLD, including all subdomains in which Registered
   Names are registered. These services include: receipt of data concerning
   registration of domain names and nameservers from registrars, provision to
   registrars of status information relating to the Registry TLD, dissemination
   of TLD zone files, operation of the Registry TLD zone servers, dissemination
   of contact and other information concerning domain name and nameserver
   registrations in the Registry TLD, and such other services required by ICANN
   in the manner provided in Subsections 4.3 through 4.6. Registry Services
   shall not include the provision of nameservice for a domain used by a single
   entity under a Registered Name registered through an ICANN-Accredited
   Registrar

   1.17  "Registry TLD" refers to the .net TLD.

   1.18  [Deliberately left blank]

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

   1.20  "TLD" refers to a top-level domain in the DNS.

   1.21  "TLD Zone-File Data" means all data contained in a DNS zone file for
   the Registry TLD, or for any subdomain for which Registry Services are
   provided and that contains Registered Names, as provided to TLD nameservers
   on the Internet.

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

     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 continues to recognize
        --------------------------------
   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. Any such request must be made in a format, and otherwise meet
   technical requirements, specified from time to time by ICANN. The initial
   format and technical requirements are set forth in Appendix A. Changes to the
   format and technical requirements may be made only with the mutual written
   consent of ICANN and Registry Operator (which neither party shall withhold
   without reason) or in the manner provided in Subsections 4.3 through 4.6.
   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. Any such request must be made in a format, include the
   elements of contact data, and otherwise meet technical requirements,
   specified from time to time by ICANN. The initial requirements for these
   requests are set forth in Appendix B. Changes to the requirements for
   requests may be made only with the mutual written consent of ICANN and
   Registry Operator (which neither party shall withhold without reason) or in
   the manner provided in Subsections 4.3 through 4.6.

   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

                                       3
<PAGE>

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

   2.6  Use of ICANN Name. ICANN hereby grants to Registry Operator a non-
        -----------------
   exclusive, worldwide, royalty-free license during the term of this Agreement
   (i) to state that it is designated by ICANN as the registry operator for the
   Registry TLD, (ii) to use a logo specified by ICANN to signify that Registry
   Operator is an ICANN-designated registry operator, and (iii) to link to pages
   and documents within the ICANN web site. No other use of ICANN's name is
   licensed hereby. This license may not be assigned or sublicensed by Registry
   Operator.

   3.  REGISTRY OPERATOR OBLIGATIONS.
       -----------------------------

   3.1  Obligation to Provide Registry Services. During the Term of this
        ---------------------------------------
   Agreement, Registry Operator shall operate, or cause to be operated, a
   registry of Registered Names that meets the functional specifications
   described by Subsection 3.2 and the performance specifications described by
   Subsection 3.3. Throughout the Term of this Agreement, Registry Operator
   shall be obligated to enter into a Registry-Registrar Agreement with any
   ICANN-Accredited Registrar seeking such an agreement on the terms specified
   by Subsection 3.4. Throughout the Term of this Agreement, Registry Operator
   shall provide Registry Services in compliance with any Registry-Registrar
   Agreement as provided in Subsection 3.4 that is then in effect.

   3.2  Functional Specifications for Registry Services. All Registry Services
        -----------------------------------------------
   provided by Registry Operator shall be provided under this Agreement and
   shall meet the functional specifications established by ICANN. The initial
   functional specifications are set forth in Appendix C. Non-material changes
   and additions to the functional specifications may be made by Registry
   Operator with prior written notice to ICANN and any affected ICANN-Accredited
   Registrars. All other changes and additions to the functional specifications
   may be made only with the mutual written consent of ICANN and Registry
   Operator (which neither party shall withhold without reason) or in the manner
   provided in Subsections 4.3 through 4.6.

   3.3  Performance Specifications for Registry Services. All Registry Services
        ------------------------------------------------
   provided by Registry Operator shall meet the performance specifications and
   comply with the registrar service level agreement established by ICANN. The
   initial performance specifications are set forth in Appendix D and the
   initial service level agreement is set forth in Appendix E. Changes to the
   performance specifications or service level agreement may be made only with
   the mutual written consent of ICANN and Registry Operator (which neither
   party shall withhold without reason) or in the manner provided in Subsections
   4.3 through 4.6.

   3.4  Registry-Registrar Agreements. During the Term of this Agreement,
        -----------------------------
   Registry Operator shall enter a Registry-Registrar Agreement with any ICANN-
   Accredited Registrar desiring to enter such an agreement. All Registry
   Services provided by Registry Operator for the Registry TLD shall be provided
   strictly in accordance with that Registry-Registrar Agreement:

                                       4
<PAGE>

     3.4.1 Initially, the form of the Registry-Registrar Agreement shall be that
     attached as Appendix F.

     3.4.2 The form of the Registry-Registrar Agreement may be revised (a) by
     Registry Operator with the written consent of ICANN, (b) by ICANN in the
     manner provided in Subsections 4.3 through 4.6, provided that any
     additional terms are within the topics set forth in Subsection 4.2., or,
     (c) with respect to the price charged registrars by Registry Operator for
     Registry Services, according to Subsection 3.4.3.

     3.4.3 Registry Operator may, at its option and with thirty days written
     notice to ICANN and to all ICANN-Accredited Registrars, revise the prices
     charged to registrars under the Registry-Registrar Agreement, provided that
     (a) the same price shall be charged for services charged to all ICANN-
     Accredited Registrars (provided that volume adjustments may be made if the
     same opportunity to qualify for those adjustments is available to all
     ICANN-Accredited Registrars) and (b) the prices shall not exceed those set
     forth in Appendix G, as adjusted according to Subsection 4.4. Registry
     Operator shall charge no fee to anyone for Registry Services if such fee is
     not listed on Appendix G. For Registry Services (a) listed on Appendix G
     without a stated price, and (b) introduced more than six months after the
     Effective Date, Registry Operator may propose to ICANN, no later than
     thirty days before the commencement of that service, the inclusion in
     Appendix G of an offering price for the Registry Service. The offering
     price for the Registry Service shall be included in Appendix G only upon
     the written consent of ICANN, which shall not be unreasonably withheld or
     delayed.

3.5  Fair Treatment of ICANN-Accredited Registrars.
     ---------------------------------------------

     3.5.1 Registry Operator shall provide all ICANN-Accredited Registrars that
     have Registry-Registrar Agreements in effect, and that are in compliance
     with the terms of such agreements, equivalent access to Registry Operator's
     Registry Services, including to its shared registration system.

     3.5.2 Registry Operator shall certify to ICANN every six months, using the
     objective criteria set forth in Appendix H, that Registry Operator is
     providing all such ICANN-Accredited Registrars with equivalent access to
     its Registry Services, including to its shared registration system.

     3.5.3 Registry Operator shall not act as a registrar with respect to the
     Registry TLD. This shall not preclude Registry Operator from registering
     names within the domain of the Registry TLD in compliance with Subsection
     3.6. This also shall not preclude an affiliate of Registry Operator from
     acting as a registrar with respect to the Registry TLD, provided that
     Registry Operator complies with the provisions of Subsections 3.5.4 and
     3.5.5.

     3.5.4 Registry Operator shall comply with its Code of Conduct attached as
     Appendix I. Any changes to that Code of Conduct will require ICANN's
     approval.

                                       5
<PAGE>

     3.5.5 Registry Operator will ensure, in a form and through ways described
     in Appendix H, that the revenues and assets of Registry Operator are not
     utilized to advantage registrars that are affiliated with Registry Operator
     to the detriment of other ICANN-Accredited Registrars. For purposes of this
     Subsection 3.5.5, funds distributed to debt or equity participants in
     Registry Operator shall no longer be deemed revenues and assets of Registry
     Operator once they are distributed.

     3.5.6 With respect to its obligations under Subsections 3.5.1 through 3.5.5
     and Appendices H and I, Registry Operator agrees to participate in and
     comply with the sanctions program described in Appendix Y, provided that
     all other registry operators having registry agreements with ICANN for the
     operation of unsponsored top-level domains (i.e. top-level domains, other
     than country-code and infrastructure domains, not having a sponsoring
     organization) are obligated to participate in and comply with a sanctions
     program with substantially the same provisions as Appendix Y. Registry
     Operator agrees that the Sanctions Program described in Appendix Y shall be
     a non-exclusive and additional option ICANN to promote compliance with
     Subsections 3.5.1 through 3.5.5 and Appendices H and I, and that (except as
     stated in Appendix Y) the availability of that option does not limit or
     affect in any way ICANN's ability to employ any other compliance measures
     or remedies available under this Agreement. In the event that the gTLD
     Constituency of the Domain Name Supporting Organization proposes a
     substitute Appendix Y at any time prior to 1 May 2002, and ICANN determines
     (following an appropriate process of public notice and comment) that
     substitution by that Appendix Y would serve the interests of the Internet
     community, the substitution shall be made.

3.6  Registrations Not Sponsored by Registrars Under Registry-Registrar
     ------------------------------------------------------------------
Agreements. Registry Operator shall register domain names within the domain of
----------
the Registry TLD, other than on a request submitted by a registrar pursuant to
that registrar's Registry-Registrar Agreement, only as follows:

     3.6.1 Registry Operator may register the domain names listed on Appendix X
     (Part A) for its own use in operating the registry and providing Registry
     Services under this Agreement, provided the total number of domain names
     listed on Appendix X at any time does not exceed 5000. At the conclusion of
     its designation by ICANN as the operator for the Registry TLD, Registry
     Operator shall transfer all such domain name registrations to the entity or
     person specified by ICANN. Appendix X may be revised upon written notice by
     Registry Operator to ICANN and written consent by ICANN, which shall not be
     unreasonably withheld.

     3.6.2 Registry Operator may register the domain names listed on Appendix X
     (Part B) for its own use, provided the total number of domain names listed
     on Appendix X at any time does not exceed 5000. Registry Operator may
     retain registration of those names at the conclusion of its designation by
     ICANN as the operator for the Registry TLD, provided registration fees are
     paid and all other requirements for registration by third parties are met.
     Appendix X may be revised upon written notice by Registry Operator to ICANN
     and written consent by ICANN, which shall not be unreasonably withheld.

                                       6
<PAGE>

     3.6.3 As instructed from time to time by ICANN, Registry Operator shall
     maintain the registration of up to 5000 domain names within the domain of
     the Registry TLD for use by ICANN and other organizations responsible for
     coordination of the Internet's infrastructure.

     3.6.4 This Subsection 3.6 shall not preclude Registry Operator from
     registering domain names within the domain of the Registry TLD through an
     ICANN-Accredited Registrar pursuant to that registrar's Registry-Registrar
     Agreement.

3.7  [Deliberately left blank]

3.8  Registration Restrictions Within Registry TLD.
     ---------------------------------------------

     3.8.1 Except to the extent that ICANN otherwise expressly authorizes in
     writing, Registry Operator shall reserve from registration the domain names
     specified by a schedule established by ICANN. The initial schedule is
     attached as Appendix K. Changes to the schedule may be made only with the
     mutual written consent of ICANN and Registry Operator (which neither party
     shall withhold without reason) or in the manner provided in Subsections 4.3
     through 4.6.

     3.8.2  [Deliberately left blank]

3.9  Bulk Access to TLD Zone Files. Registry Operator shall provide bulk access
     -----------------------------
to the zone files for the Registry TLD as follows:

     3.9.1 to third parties on the terms set forth in the TLD zone file access
     agreement established by ICANN. The initial terms of the agreement are set
     forth as Appendix N to this Agreement. Changes to the terms of the TLD zone
     file access agreement may be made only with the mutual written consent of
     ICANN and Registry Operator (which neither party shall withhold without
     reason) or in the manner provided in Subsections 4.3 through 4.6.

     3.9.2 to ICANN on a continuous basis in the manner which ICANN may from
     time to time specify.

3.10 Publication by Registry Operator of Registry Data.
     -------------------------------------------------

     3.10.1 At its expense, Registry Operator shall provide free public query-
     based access to up-to-date data concerning domain name and nameserver
     registrations maintained by Registry Operator in connection with the
     Registry TLD. The data elements reported, format of responses to queries,
     data update frequency, query types supported, and protocols through which
     access is provided shall be as established by ICANN. The initial
     specification of the data elements reported, format of responses to
     queries, minimum data update frequency, query types supported, and
     protocols through which access is provided are set forth in Appendix O.
     Registry Operator may request supplementation of the specification to
     include additional data elements reported or query types supported, in
     which event ICANN shall act to supplement the specification in a reasonable
     manner within a reasonable time.

                                       7
<PAGE>

     Other changes to the specification may be made only with the mutual written
     consent of ICANN and Registry Operator (which neither party shall withhold
     without reason) or in the manner provided in Subsections 4.3 through 4.6.

     3.10.2 To ensure operational stability of the registry, Registry Operator
     may temporarily limit access under Subsection 3.10.1 in which case Registry
     Operator shall immediately notify ICANN of the nature of and reason for the
     limitation. Registry Operator shall not continue the limitation longer than
     a period established by ICANN if ICANN objects in writing, which objection
     shall not be unreasonably made. The period shall initially be five business
     days; changes to that period may be made only with the mutual written
     consent of ICANN and Registry Operator (which neither party shall withhold
     without reason) or in the manner provided in Subsections 4.3 through 4.6.
     Such temporary limitations shall be applied in a non-arbitrary manner and
     shall apply fairly to all ICANN-Accredited Registrars.

     3.10.3 In providing query-based public access to registration data as
     required by this Subsection 3.10, Registry Operator shall not impose terms
     and conditions on use of the data provided except as permitted by policy
     established by ICANN. Unless and until ICANN establishes a different
     policy, Registry Operator 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 by e-mail, telephone, or facsimile of
     mass unsolicited, commercial advertising or solicitations to entities other
     than the data recipient's own existing customers; or (b) enable high
     volume, automated, electronic processes that send queries or data to the
     systems of Registry Operator or any ICANN-Accredited Registrar, except as
     reasonably necessary to register domain names or modify existing
     registrations. Changes to that policy may be made only with the mutual
     written consent of ICANN and Registry Operator (which neither party shall
     withhold without reason) or in the manner provided in Subsections 4.3
     through 4.6.

     3.10.4 To comply with applicable statutes and regulations and for other
     reasons, ICANN may from time to time establish policies in the manner
     described by Subsections 4.3 through 4.6 establishing limits on the data
     concerning registrations that Registry Operator may make available to the
     public through a public-access service described in this Subsection 3.10
     and on the manner in which Registry Operator may make them available. In
     the event ICANN establishes any such policy, Registry Operator shall abide
     by it within the time allowed by Subsection 4.5.

     3.10.5 At its expense, Registry Operator shall provide bulk access to
     up-to-date data concerning domain name and nameserver registrations
     maintained by Registry Operator in connection with the Registry TLD in the
     following two ways:

          3.10.5.1 on a daily schedule, only for purposes of providing free
          public query-based access to up-to-date data concerning domain name
          and nameserver registrations in multiple TLDs, to a party designated
          from time to time in writing by ICANN. The content and format of this
          data, and the procedures for providing access, shall be as established
          by ICANN. The initial content, format, and

                                       8
<PAGE>

          procedures are set forth in Appendix P. Changes to that content and
          format and those procedures may be made only with the mutual written
          consent of ICANN and Registry Operator (which neither party shall
          withhold without reason) or in the manner provided in Subsections 4.3
          through 4.6.

          3.10.5.2 on a continuous basis, to ICANN in the manner which ICANN may
          from time to time reasonably specify, only for purposes of verifying
          and ensuring the operational stability of Registry Services, the DNS,
          and the Internet The content and format of this data, and the
          procedures for providing access, shall be as established by ICANN. The
          initial content, format, and procedures are set forth in Appendix Q.
          Changes to that content and format and those procedures may be made
          only with the mutual written consent of ICANN and Registry Operator
          (which neither party shall withhold without reason) or in the manner
          provided in Subsections 4.3 through 4.6.

     3.11 Data Escrow. Registry Operator shall periodically deposit into escrow
          -----------
     all Registry Data in an electronic format. 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. The schedule, content, format, and
     procedure for escrow deposits shall be as established by ICANN from time to
     time. The initial schedule, content, format, and procedure shall be as set
     forth in Appendix R. Changes to the schedule, content, format, and
     procedure may be made only with the mutual written consent of ICANN and
     Registry Operator (which neither party shall withhold without reason) or in
     the manner provided in Subsections 4.3 through 4.6. The escrow shall be
     held under an agreement, substantially in the form of Appendix S, among
     ICANN, Registry Operator, and the escrow agent.

     3.12 Registry Operator's Handling of Personal Data. Registry Operator shall
          ---------------------------------------------
     notify registrars sponsoring registrations in the registry for the Registry
     TLD of the purposes for which Personal Data submitted to Registry Operator
     by registrars is collected, the intended recipients (or categories of
     recipients) of such Personal Data, and the mechanism for access to and
     correction of such Personal Data. Registry Operator shall take reasonable
     steps to protect Personal Data from loss, misuse, unauthorized disclosure,
     alteration or destruction. Registry Operator shall not use or authorize the
     use of Personal Data in a way that is incompatible with the notice provided
     to registrars.

     3.13 Rights in Data. Except as permitted by the Registry-Registrar
          --------------
     Agreement, Registry Operator shall not be entitled to claim any
     intellectual property rights in data supplied by or through registrars. In
     the event that Registry Data is released from escrow under Subsection 3.11,
     any rights held by Registry Operator in the data shall automatically be
     transferred on a non-exclusive, irrevocable, royalty-free, paid-up basis to
     ICANN or to a party designated in writing by ICANN.

     3.14  Registry-Level Financial Support of ICANN.  During the Term of this
           -----------------------------------------
     Agreement, Registry Operator shall pay to ICANN the following fees:

                                       9
<PAGE>

     3.14.1 Fixed Registry-Level Fee. Registry Operator shall pay ICANN a
            ------------------------
     quarterly Fixed Registry-Level Fee in an amount established by the ICANN
     Board of Directors, in conformity with the ICANN bylaws and articles of
     incorporation, not to exceed one quarter of the annual Fixed Registry-Level
     Fee Cap described in Subsection 3.14.4.

     3.14.2  Variable Registry-Level Fee.  Registry Operator shall pay ICANN a
             ---------------------------
     quarterly Variable Registry-Level Fee in an amount calculated according to
     a formula and method established from time to time by the ICANN Board of
     Directors, in conformity with the ICANN bylaws and articles of
     incorporation. The formula and method shall allocate the total variable fee
     among all TLDs sponsored or operated under a sponsorship or registry
     agreement with ICANN (whether the fee is collected at the registry or
     registrar level) based on the relative size of the registries for those
     TLDs. It shall be permissible for the formula and method so established (a)
     to measure the size of a TLD's registry by the number of names under
     administration within the TLD by the registry's operator, (b) to deem the
     number of domain names under administration within the Registry TLD to be
     the number of Registered Names, and (c) to provide for a deduction in
     computing a sponsor's or operator's Variable Registry-Level Fee of some or
     all of that sponsor's or operator's Fixed Registry-Level Fee. It shall also
     be permissible for the formula and method to consider accreditation fees
     collected from registrars as a credit applied to the Variable Registry-
     Level Fee for the TLD to which the fees pertain. Groups of registries for
     two or more TLDs may, with the agreement of their sponsors or operators and
     ICANN, agree to allocate the variable fee collected from them in a manner
     not based on the relative size of the registries within the group, provided
     that the combined variable fees collected for all TLDs within the group is
     based on the combined size of the registries in the group.

     3.14.3  Payments Must Be Timely.  Registry Operator shall pay the quarterly
             -----------------------
     Fixed and Variable Registry-Level Fees within thirty days after the date of
     ICANN's invoice for those fees. These payments shall be made in a timely
     manner throughout the Term of this Agreement and notwithstanding the
     pendency of any dispute between Registry Operator and ICANN. Registry
     Operator shall pay interest on payments not timely made at the rate of 1%
     per month or, if less, the maximum rate permitted by California law.

     3.14.4 Fee Caps. The Fixed Registry-Level Fee Cap shall be US$100,000 per
            --------
     year until and including 30 June 2002; shall automatically increase by 15%
     on July 1 of each year beginning in 2002; and may be increased by a greater
     amount in the manner provided by Subsection 4.3. The sum of the Fixed
     Registry-Level Fees and the Variable Registry-Level Fees due to be paid in
     any year ending on any 30 June during or within one year after the Term of
     this Agreement by all TLD sponsors and registry operators having
     sponsorship or registry agreements with ICANN shall not exceed the Total
     Registry-Level Fee Cap described in the following sentence. The Total
     Registry-Level Fee Cap shall be US$5,500,000 for the fiscal year ending 30
     June 2002; shall increase by 15% each fiscal year thereafter; and may be
     increased by a greater amount in the manner provided by Subsection 4.3.

                                       10
<PAGE>

     3.14.5  Adjustments to Price. The maximum pricing for initial and renewal
             --------------------
     registrations set forth in Appendix G shall be adjusted at the beginning of
     each calendar quarter by adding, to the amount specified in that Appendix
     (after adjustment according to Subsection 4.4) as the applicable annual
     charge for initial or renewal registration of a domain name, an amount
     calculated according to the following three sentences. For calendar
     quarters in which the variable fee is collected at the registrar level, the
     amount shall be US$0.00. For the first two calendar quarters during the
     Term of this Agreement in which the variable fee is collected at the
     registry level, the amount shall be four times the per-name variable
     accreditation fee charged to registrars for the quarter beginning six
     months earlier. For subsequent calendar quarters, the amount shall be four
     times the quarterly Variable Registry-Level Fee reflected in the invoice to
     Registry Operator for such a fee for the quarter beginning six months
     earlier divided by the number of Registered Names that the invoice shows
     was used to calculate that quarterly Variable Registry-Level Fee. The
     adjustments permitted by this Subsection 3.14.5 shall only apply for
     periods of time as to which the Registry Operator does not have in effect a
     provision in its Registry-Registrar Agreement (see Subsection 3.4)
     permitting it to require ICANN-Accredited Registrars to pay to Registry
     Operator a portion of Registry Operator's payments of variable registry-
     level fees to ICANN.

3.15 Reports Provided to ICANN.
     -------------------------

     3.15.1 Within twenty days after the end of each month during the Term of
     this Agreement, Registry Operator shall provide ICANN a written report,
     giving information specified by ICANN, on operation of the registry during
     the month. The initial specification of information is set forth in
     Appendix T. Changes to that specification may be made only with the mutual
     written consent of ICANN and Registry Operator (which neither party shall
     withhold without reason) or in the manner provided in Subsections 4.3
     through 4.6.

     3.15.2  [Deliberately left blank]

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

4.1  Registry Operator's Ongoing Obligation to Comply With New or Revised
     --------------------------------------------------------------------
Specifications and 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 specifications (including forms of agreement to which
     Registry Operator is a party) and policies established by ICANN as
     Consensus Policies in the manner described in Subsection 4.3,

     4.1.2  in cases where:

                                       11
<PAGE>

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

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

4.2  Topics for New and Revised Specifications and Policies. New and revised
     ------------------------------------------------------
specifications and 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 the Registry Services, the DNS, or the Internet;

     4.2.2 functional and performance specifications for the provision of
     Registry Services;

     4.2.3  safety and integrity of the Registry Database;

     4.2.4  procedures to avoid disruptions of registration due to suspension or
     termination of operations by a registry operator or a registrar, including
     procedures for allocation of responsibility for serving Registered Names
     affected by such a suspension or termination;

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

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

     4.2.7  prohibitions on warehousing of or speculation in domain names by
     registries or registrars;

     4.2.8 maintenance of and access to accurate and up-to-date contact
     information for domain name registrants;

     4.2.9 reservation of Registered 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.,
     establishment of reservations of names from registration); and

     4.2.10 registry policies reasonably necessary to implement Consensus
     Policies relating to registrars.

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

                                       12
<PAGE>

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

     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.9; provided, however, that
     Registry Operator must continue to implement the policy unless it has
     obtained a stay or injunctive relief under Subsection 5.9 or a final
     decision is rendered in accordance with the provisions of Subsection 5.9
     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 specification or 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

                                       13
<PAGE>

     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 V 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  Pricing Adjustments Arising from New or Revised Specifications or Policies.
     --------------------------------------------------------------------------
The maximum prices stated in Appendix G shall be increased through an amendment
to this Agreement as approved by ICANN and Registry Operator, such approval not
to be unreasonably withheld, to reflect demonstrated increases in the net costs
of providing Registry Services arising from (A) new or revised ICANN
specifications or policies adopted after the Effective Date, or (B) legislation
specifically applicable to the provision of Registry Services adopted after the
Effective Date, to ensure that Registry Operator recovers such costs and a
reasonable profit thereon; provided that such increases exceed any reductions in
costs arising from (A) or (B) above.

4.5  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.6  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; except that Registry Operator shall not be
indemnified or held harmless hereunder to the extent that the

                                       14
<PAGE>

claims, damages or liabilities arise from the particular manner in which
Registry Operator has chosen to comply with the specification or policy, where
it was possible for Registry Operator to comply in a manner by which the claims,
damages, or liabilities would not arise. As an alternative to providing the
indemnity stated in this Subsection 4.6, ICANN may, at the time it establishes a
specification or policy after the Effective Date giving rise to an indemnity
obligation under this Subsection 4.6, state ICANN's election that the Registry
Operator shall bear the cost of insuring the claims, damages, liabilities,
costs, and expenses that would otherwise be indemnified by ICANN under this
Subsection 4.6, in which case the reasonable cost to Registry Operator of such
insurance shall be treated under Subsection 4.4 as a cost of providing Registry
Services arising from the newly established ICANN specification or policy.

5.  MISCELLANEOUS PROVISIONS.
    ------------------------

5.1  Expiration of this Agreement.
     ----------------------------

     5.1.1 The Expiration Date shall be 30 June 2005, provided, however, that
     the Expiration Date may be adjusted under the following circumstances:

          5.1.1.1  31 December  2002 Measurement Date.
                   ----------------------------------

               5.1.1.1.1 The total number of Registered Names for .biz, .info,
               .name and .pro TLDs as of 31 December 2002, as numerator, shall
               be compared to the total number of Registered Names for .biz,
               .info, .name, .pro, .com and .net TLDs as of 31 December 2002, as
               denominator.

               5.1.1.1.2 The net new registrations of Registered Names in the
               .com and .net TLDs (i.e., the net increase in the number of
               Registered Names sponsored in the registry) sponsored by the NSI
               Registrar for the period 1 January 2002 through 31 December 2002,
               as numerator, shall be compared to the total net new
               registrations of Registered Names sponsored by all ICANN-
               accredited registrars, including the NSI Registrar, in the .com
               and .net TLDsfor the same period, as denominator.

               5.1.1.1.3 The Expiration Date shall remain 30 June 2005 and no
               further measurements will be required if:

                    5.1.1.1.3.1 the share of Registered Names in the .biz,
                    .info, .name and .pro TLDs, measured pursuant to Subsection
                    5.1.1.1.1, is 15% or more, or


                    5.1.1.1.3.2 the NSI Registrar share of net new registrations
                    of Registered Names in .com and .net, measured pursuant to
                    Subsection 5.1.1.1.2, is 20% or less;

               and ICANN determines that the Registry Operator is in compliance
               with its obligations under Section 3.5 of this Registry
               Agreement, in accordance with paragraph 8 of Appendix I.

                                       15
<PAGE>

          5.1.1.1.4 The Expiration Date shall remain 30 June 2005, but a
          subsequent measurement will be required on 31 March 2004, as set forth
          in Subsection 5.1.1.1.1 if:

               5.1.1.1.4.1 the share of total Registered Names in the .biz,
               .info, .name and .proTLDs, measured pursuant to Subsection
               5.1.1.1.1, is 10% or more, or 5.1.1.1.4.2 the NSI Registrar share
               of net new registrations of Registered Names in .com and .net,
               measured pursuant to Subsection 5.1.1.1.2, is 25% or less;

          and ICANN determines that the Registry Operator is in compliance with
          its obligations under Section 3.5 of this Registry Agreement, in
          accordance with paragraph 8 of Appendix I.

               5.1.1.1.5 The Expiration Date shall be adjusted to 10 November
               2003 if:

               5.1.1.1.5.1 the share of total Registered Names in the .biz,
               .info, .name and .proTLDs, measured pursuant to Subsection
               5.1.1.1.1, is less than 10%, and

               5.1.1.1.5.2 the NSI Registrar's share of net new registrations of
               Registered Names in .com and .net, measured pursuant to
               Subsection 5.1.1.1.2, is more than 25%;

          or ICANN determines that Registry Operator is not in compliance with
          its obligations under Section 3.5 of this Registry Agreement, in
          accordance with paragraph 8 of Appendix I.

          5.1.1.2 31 March 2004 Measurement Date. In the event a subsequent
                  ------------------------------
          measurement as set forth in Subsection 5.1.1.1.4 is required, the
          subsequent measurement shall be calculated as follows:

               5.1.1.2.1 The total number of Registered Names in all unsponsored
               gTLDs introduced by ICANN after 1 January 2001, including but not
               limited to .biz, .info, .name and .pro but not including .com and
               .net, as numerator, shall be compared to the total number of
               Registered Names in all unsponsored gTLDs recognized by ICANN,
               including .com and .net but not including .org, as denominator.

               5.1.1.2.2 The net new registrations of Registered Names in the
               .com and .net TLDs (i.e., the net increase in the number of
               Registered Names sponsored in the registry) sponsored by the NSI
               Registrar for the period 1 April 2003 through 31 March

                                       16
<PAGE>

        2004, as numerator, shall be compared to the total net new registrations
        of Registered Names sponsored by all ICANN-accredited registrars,
        including the NSI Registrar, in the .com and .net TLDs for the same
        period, as denominator.

        5.1.1.2.3  The Expiration Date shall remain 30 June 2005 if:

          5.1.1.2.3.1  the share of Registered Names in all unsponsored gTLDs
          introduced by ICANN after 1 January 2001, measured pursuant to
          Subsection 5.1.1.2.1, is 13% or more, or

          5.1.1.2.3.2  the NSI Registrar share of net new registrations of
          Registered Names, measured pursuant to Subsection 5.1.1.2.2, is 22% or
          less;

     and ICANN determines that Registry Operator is in compliance with its
     obligations under Section 3.5 of this Registry Agreement, in accordance
     with paragraph 8 of Appendix I.

        5.1.1.2.4  The Expiration Date shall be adjusted to 1 January 2005 if:

          5.1.1.2.4.1  the share of Registered Names in all unsponsored gTLDs
          introduced by ICANN after 1 January 2001, measured pursuant to
          Subsection 5.1.1.2.1, is less than 13%, and

          5.1.1.2.4.2  the NSI Registrar share of net new registrations of
          Registered Names, measured pursuant to Subsection 5.1.1.1.2, is more
          than 22%;

     or ICANN determines that Registry Operator is not in compliance with its
     obligations under Section 3.5 of this Registry Agreement, in accordance
     with paragraph 8 of Appendix I.

     5.1.1.3  ICANN shall perform the measurements described in Subsections
     5.1.1.1.1 and 5.1.1.1.2 above on a quarterly basis, and report the results
     to Registry Operator on a confidential basis.

  5.1.2   Registry Operator acknowledges and agrees that upon the earlier of (i)
  the Expiration Date or (ii) termination of this Agreement by ICANN pursuant to
  Subsection 5.4, it will cease to be the operator of the Registry TLD unless
  ICANN and Registry Operator enter a new registry agreement continuing Registry
  Operator's status as operator of the Registry TLD.

  5.1.3   Upon conclusion of its status as operator of the Registry TLD,
  Registry Operator shall make all commercially reasonable efforts to cooperate
  with ICANN,

                                       17
<PAGE>

     and with any party designated by ICANN as successor operator, to facilitate
     prompt and smooth transition of the operation of the Registry TLD.

     5.1.4 Registry Operator acknowledges and agrees that, except as expressly
     provided by this Agreement, it shall not acquire any right in the Registry
     TLD by virtue of its operation of the Registry TLD or its provision of
     Registry Services hereunder.

5.2  Procedure for Subsequent Agreement.
     ----------------------------------

     5.2.1  Not later than one year prior to the end of the term of this
     Agreement, ICANN shall, in accordance with Section 2.1, adopt an open,
     transparent procedure for designating a successor Registry Operator. 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.

     5.2.2  Registry Operator or its assignee shall be eligible to serve as the
     successor Registry Operator and neither the procedure established in
     accordance with subsection 5.2.1 nor the fact that Registry Operator is the
     incumbent shall disadvantage Registry Operator in comparison to other
     entities seeking to serve as the successor Registry.

     5.2.3  If Registry Operator or its assignee is not designated as the
     successor Registry Operator, Registry Operator or its assignee shall
     cooperate with ICANN and with the successor Registry Operator in order to
     facilitate the smooth transition of operation of the registry to successor
     Registry Operator. Such cooperation shall include the timely transfer to
     the successor Registry Operator of an electronic copy of the Registry
     Database and of a full specification of the format of the data.

     5.2.4  ICANN shall select as the successor Registry Operator the eligible
     party that it reasonably determines is best qualified to perform the
     registry function under terms and conditions developed pursuant to
     Subsection 4.3 of this Agreement, 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, the relevant experience of the party,
     and the demonstrated ability of the party to manage domain name or similar
     databases at the required scale.

     5.2.5  In the event that a party other than Registry Operator or its
     assignee is designated as the successor Registry Operator, Registry
     Operator shall have the right to challenge the reasonableness of ICANN's
     failure to designate Registry Operator or its assignee as the successor
     Registry Operator pursuant to Section 5.9 below. Any such challenge must be
     filed within 10 business days following any such designation, and shall be
     decided on a schedule that will produce a final decision no later than 60
     days following any such challenge.

                                      18
<PAGE>

5.3  [Deliberately left blank]

5.4  Termination by ICANN. This Agreement may be terminated before its
     --------------------
expiration by ICANN in any of the following circumstances:

     5.4.1   [Deliberately left blank]

     5.4.2   Registry Operator:

        5.4.2.1 is convicted by a court of competent jurisdiction of a felony or
        other serious offense related to financial activities, or is the subject
        of a determination by a court of competent jurisdiction that ICANN
        reasonably deems as the substantive equivalent of those offenses ; or

        5.4.2.2 is disciplined by the government of its domicile for conduct
        involving dishonesty or misuse of funds of others.

     5.4.3   Any officer or director of Registry Operator is convicted of a
     felony or of a misdemeanor related to financial activities, or is judged by
     a court to have committed fraud or breach of fiduciary duty, or is the
     subject of a judicial determination that ICANN deems as the substantive
     equivalent of any of these, and such officer or director is not immediately
     removed in such circumstances.

     5.4.4   Registry Operator fails to cure any material breach of this
     Agreement (other than a failure to comply with a Consensus Policy adopted
     by ICANN during the Term of this Agreement as to which Registry Operator
     has obtained a stay under Subsection 5.9) within fifteen business days (or
     such longer reasonable period as may be necessary using best efforts to
     cure such breach) after ICANN gives Registry Operator written notice of the
     breach.

     5.4.5   Registry Operator's action or failure to act has been determined
     under Subsection 5.9 to be in violation of this Agreement and Registry
     Operator continues to act or fail to act in the manner that was determined
     to violate this Agreement for a period stated in the arbitration decision,
     or if no period is stated, fifteen business days.

     5.4.6   Registry Operator acts or continues acting in a manner that ICANN
     has reasonably determined endangers the operational stability of Registry
     Services, the DNS, or the Internet after receiving three days notice of
     that determination.

     5.4.7   Registry Operator fails to pay to ICANN the final amount of
     sanctions determined to be appropriate under the sanctions program
     described in Appendix Y within thirty days after the amount of sanctions is
     deemed final.

     5.4.8   Registry Operator becomes bankrupt or insolvent.

     5.4.9   This Agreement may be terminated in the circumstances described in
     Subsections 5.4.1 through 5.4.7 above only upon thirty calendar days
     written notice

                                       19
<PAGE>

     to Registry Operator (in the case of the circumstances described in
     Subsections 5.4.4, 5.4.5, and 5.4.6 occurring after Registry Operator's
     failure to cure), with Registry Operator being given an opportunity during
     that time to initiate arbitration under Subsection 5.9 to determine the
     appropriateness of termination under this Agreement. In the event Registry
     Operator initiates arbitration concerning the appropriateness of
     termination by ICANN, Registry Operator may at the same time request that
     the arbitration panel stay the termination until the arbitration decision
     is rendered, and that request shall have the effect of staying the
     requirement until the decision or until the arbitration panel has granted
     an ICANN request for lifting of the stay. If Registry Operator acts in a
     manner that ICANN reasonably determines endangers the operational stability
     of Registry Services, the DNS, or the Internet and upon notice does not
     immediately cure, ICANN may suspend this Agreement for five calendar days
     pending ICANN's application for more extended injunctive relief under
     Subsection 5.9. This Agreement may be terminated immediately upon notice to
     Registry Operator in the circumstance described in Subsection 5.4.8.

5.5  [Deliberately left blank]

5.6  Additional Covenants of Registry Operator. Throughout the Term of this
     -----------------------------------------
Agreement, Registry Operator shall abide by the covenants contained in Appendix
W.

5.7  Indemnification of ICANN. Registry Operator shall indemnify, defend, and
     ------------------------
hold harmless ICANN (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 out of or relating to: (a)
the selection of Registry Operator to operate the Registry TLD; (b) the entry of
this Agreement; (c) establishment or operation of the Registry TLD; (d) Registry
Services; (e) collection or handling of Personal Data by Registry Operator; (f)
any dispute concerning registration of a domain name within the domain of the
Registry TLD; and (g) duties and obligations of Registry Operator in operating
the Registry TLD; provided that, with respect to items (b) through (g) only,
Registry Operator shall not be obligated to indemnify, defend, or hold harmless
ICANN to the extent of ICANN's indemnification of Registry Operator under
Subsection 4.6 and provided further that, with respect to item (g) only,
Registry Operator shall not be obligated to indemnify, defend, or hold harmless
ICANN to the extent the claim, damage, liability, cost, or expense arose due to
a breach by ICANN of any obligation contained in this Agreement. For avoidance
of doubt, nothing in this Subsection 5.7 shall be deemed to require Registry
Operator to reimburse or otherwise indemnify ICANN for the costs associated with
the negotiation or execution of this Agreement, or with the monitoring of the
parties' respective obligations under this Agreement.

5.8  Indemnification Procedures. If any third-party claim is commenced that is
     --------------------------
indemnified under Subsections 4.6 or 5.7, notice thereof shall be given to the
indemnifying party as promptly as practicable. If, after such notice, the
indemnifying party acknowledges its obligation to indemnify with respect to such
claim, then the indemnifying party shall be entitled, if it so elects, in a
notice promptly delivered to the indemnified party, to immediately take control
of the defense and investigation of such

                                       20
<PAGE>

claim and to employ and engage attorneys reasonably acceptable to the
indemnified party to handle and defend the same, at the indemnifying party's
sole cost and expense, provided that in all events ICANN shall be entitled to
control at its sole cost and expense the litigation of issues concerning the
validity or interpretation of ICANN policies or conduct. The indemnified party
shall cooperate, at the cost of the indemnifying party, in all reasonable
respects with the indemnifying party and its attorneys in the investigation,
trial, and defense of such claim and any appeal arising therefrom; provided,
however, that the indemnified party may, at its own cost and expense,
participate, through its attorneys or otherwise, in such investigation, trial
and defense of such claim and any appeal arising therefrom. No settlement of a
claim that involves a remedy affecting the indemnifying party other than the
payment of money in an amount that is indemnified shall be entered into without
the consent of the indemnified party. If the indemnifying party does not assume
full control over the defense of a claim subject to such defense in accordance
with this Subsection, the indemnifying party may participate in such defense, at
its sole cost and expense, and the indemnified party shall have the right to
defend the claim in such manner as it may deem appropriate, at the cost and
expense of the indemnifying party.

5.9  Resolution of Disputes Under This Agreement. Disputes arising under or in
     -------------------------------------------
connection with this Agreement, including requests for specific performance,
shall be referred in the first instance to arbitration conducted as provided in
this Subsection 5.9 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. Either party, if dissatisfied with
the result of the arbitration, may challenge that result by bringing suit
against the other party in a court located in Los Angeles, California, USA to
enforce its rights under this Agreement. 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.10 Limitation of Liability. ICANN's aggregate monetary liability for
     -----------------------
violations of this Agreement shall not exceed the amount of Fixed or Variable
Registry-Level Fees paid by Registry Operator to ICANN within the preceding
twelve-month period under Subsection 3.14. Registry Operator's aggregate
monetary liability to ICANN for violations of this Agreement shall be limited to
fees and monetary sanctions due and

                                       21
<PAGE>

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.11 Assignment. Any assignment of this Agreement shall be effective only upon
     ----------
written agreement by the assignee with the other party to assume the assigning
party's obligations under this Agreement. Moreover, neither party may assign
this Agreement without the prior written approval of the other party.
Notwithstanding the foregoing, a party may assign this Agreement by giving
written notice to the other party in the following circumstances: (a) Registry
Operator may assign this Agreement as part of the transfer of its registry
business if such transfer and assignment are approved in advance by ICANN
pursuant to its procedures, and (b) ICANN may assign this Agreement, (i) in
conjunction with a reorganization or re-incorporation of ICANN, to another non-
profit corporation organized for the same or substantially the same purposes as
ICANN or (ii) as required by Section 5 of Amendment 1 (dated 10 November 1999)
to the 25 November 1998, Memorandum of Understanding between ICANN and the
United States Department of Commerce.

5.12 Subcontracting. Registry Operator shall not subcontract portions of the
     --------------
technical operations of the Registry TLD accounting for more than 80% of the
value of all Registry TLD operations without ICANN's written consent. When
ICANN's consent to subcontracting is requested, ICANN shall respond within
fifteen business days, and the consent shall not be unreasonably withheld. In
any subcontracting of the technical operations of the Registry TLD, the
subcontract shall state that the subcontractor shall not acquire any right in
the Registry TLD by virtue of its performance under the subcontract.

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

                                       22
<PAGE>

5.14 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 SLD holder.

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

     General Counsel
     VeriSign, Inc.
     1350 Charleston Road
     Mountain View, California 94043
     Telephone: 1/650/961/7500
     Facsimile:1/650/961/8853; and

     General Manager
     VeriSign Registry
     21345Ridgetop Circle
     Dulles, Virginia 20166
     Telephone: 1/703/948/3200
     Facsimile: 1/703/421/2129; and

     Deputy General Counsel
     VeriSign, Inc.
     505 Huntmar Park Drive
     Herndon, Virginia 20170
     Telephone: 1/703/742/0400
     Facsimile: 1/703/742/7916

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

                                       23
<PAGE>

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

5.18 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.19 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.20 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 any conflict between the
provisions in the body of this Agreement (Section 1 to Subsection 5.20) and any
provision in its appendices, the provisions in the body shall prevail.

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:__________________________
M. Stuart Lynn
President and CEO
Date:

VERISIGN, INC.

By:__________________________
Stratton Sclavos
President and CEO
Date:

                                       24
<PAGE>

                                                                      Appendix A
                                                                      ----------

                      Internet Assigned Numbers Authority
Format and Technical Requirements for Requests to Change TLD Nameservers in the
                                   Root Zone

(This document applies only to TLDs as to which a written agreement is in effect
between ICANN and the TLD delegee, sponsor, or operator.)

1. Requests for changes in TLD nameserver delegations to be reflected in the
root zone are to be submitted by e-mail to [email protected].

2. Requests should be submitted by filling out the template available at <URL>.

3. Nameserver change requests are subject to verification of authenticity and
authorization. Both the listed technical contact and the listed administrative
contact should be available to verify that the request is authentic and they
authorize the requested change. Except where a written agreement between ICANN
and the TLD delegee, sponsor, or operator expressly states to the contrary, the
IANA shall be entitled to rely on authorization of either the administrative or
technical contact as constituting a request for nameserver change by the TLD
delegee, sponsor, or operator.

4. Requests for changes to nameservice for ccTLDs (i.e. TLDs having two-letter
labels) must result in delegation to at least two nameservers, preferably on
different networks. Requests for changes to nameservice for other TLDs must
result in delegation to nameservers on at least five different networks.

5. Delegations of a TLD to more than thirteen nameservers are not supported.

6. Prior to submitting the request, nameservice should be set up at all the
nameservers to which delegation is to be made. Lame delegations will not
ordinarily be made.

7. The IANA must have zone file access.  Except where other arrangements are
made (such as for TLDs with large zones), this means that zone file transfers
must be enabled at all nameservers for transfers to at least 128.9.0.0/16 and
192.0.32.0/20.

(6 April 2001)

                                       25
<PAGE>

                                                                      Appendix B
                                                                      ----------

                      Internet Assigned Numbers Authority
Format, Content, and Technical Requirements for Requests to Change TLD Contact
Information


(This document applies only to TLDs as to which a written agreement is in effect
between ICANN and the TLD delegee, sponsor, or operator.)

1. Requests for changes in TLD contact data are to be submitted by e-mail to
[email protected]>.

2. Requests should be submitted by filling out the template available at <URL>.

3. Requests for changes to TLD contact data must include all applicable elements
of data requested in items 3-5 of the template. All information submitted must
be accurate.

4. Contact change requests are subject to verification of authenticity and
authorization. Both the listed technical contact and the listed administrative
contact should be available to verify that the request is authentic and they
authorize the requested change. Except where a contract between ICANN and the
TLD delegee, sponsor, or operator expressly states to the contrary, the IANA
shall be entitled to rely on authorization of either the administrative or
technical contact as constituting a request for a contact change by the TLD
delegee, sponsor, or operator, except that any change of the identity of the
sponsoring organization, administrative contact, or technical contact must
comply with notice requirements stated in the agreement.

(26 February 2001)

                                       26
<PAGE>

                                                                      Appendix C
                                                                      ----------

                             Functional Specification


This functional specification for the Registry TLD consists of the following
elements:

  1. Verisign Registry Registrar Protocol Version 1.1.0 (May 2000) (RFC 2832);

  2. Supported initial and renewal registration periods;

  3. Grace period policy;

  4. Nameserver functional specifications;

  5. Patch, update, and upgrade policy; and

  6. Migration to provreg standard.

In addition, functional specifications are set forth in other parts of the
registry agreement and its appendices.  For example, specifications for Whois
service are set forth in Appendix O.

                                       27
<PAGE>

1.  Verisign Registry Registrar Protocol Version 1.1.0 (May 2000)
    -------------------------------------------------------------


Network Working Group                                      S. Hollenbeck
Request for Comments: 2832                                 M. Srivastava
Category: Informational                 Network Solutions, Inc. Registry
                                                                May 2000


          NSI Registry Registrar Protocol (RRP) Version 1.1.0

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes a protocol for the registration and
   management of second level domain names and associated name servers
   in both generic Top Level Domains (gTLDs) and country code Top Level
   Domains (ccTLDs). This protocol was developed by the Network
   Solutions Registry for use within the Shared Registration System and
   is being published "as-is" to document the protocol implementation
   developed by the Network Solutions, Inc. Registry.

   Internet domain name registration typically involves three entities:
   a registrant who wishes to register a domain name, a registrar who
   provides services to the registrant, and a registry that provides
   services to the registrar while serving as the authoritative
   repository of all functional information required to resolve names
   registered in the registry's TLDs.  This document describes a
   protocol for registry-registrar communication only.  The protocol
   does not provide any registrant services.

   This document is being discussed on the "rrp" mailing list.  To join
   the list, send a message to [[email protected]] with the
   words "subscribe rrp" in the body of the message. There is also a web
   site for the mailing list archives at
   [http://www.NSIRegistry.net/maillist/rrp].

Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in [MUSTSHOULD]. Further,

                                       28
<PAGE>

   the term "implicit attribute" refers to an entity attribute whose
   value is derived either from another attribute or is dependent on an
   established RRP session.

   In examples, "C:" represents lines sent by the registrar client and
   "S:" represents lines sent by the registry server.

   The term "System" is used in this document to collectively refer to
   this protocol and the software and hardware that implements the
   protocol.

Table of Contents

   1. Introduction .................................................    3
   2. Security Services ............................................    4
   2.1 Connection Security .........................................    4
   2.2 System Data Security ........................................    5
   3. Connection Model .............................................    5
   4. Protocol Description .........................................    6
   4.1 Request Format ..............................................    7
   4.2 Response Format .............................................    8
   4.3 Protocol Commands ...........................................    8
   4.3.1 ADD .......................................................    8
   4.3.2 CHECK .....................................................   11
   4.3.3 DEL .......................................................   12
   4.3.4 DESCRIBE ..................................................   14
   4.3.5 MOD .......................................................   14
   4.3.6 QUIT ......................................................   16
   4.3.7 RENEW .....................................................   17
   4.3.8 SESSION ...................................................   18
   4.3.9 STATUS ....................................................   18
   4.3.10 TRANSFER .................................................   21
   5. Response Codes ...............................................   23
   5.1 Response Code Summary .......................................   23
   5.2 Command-Response Correspondence .............................   28
   6. Domain Status Codes ..........................................   29
   6.1 Domain Status Code Description ..............................   30
   7. Formal Syntax ................................................   30
   8. Internationalization .........................................   35
   9. Known Issues .................................................   35
   10. Security Considerations .....................................   37
   11. IANA Considerations .........................................   37
   12. References ..................................................   37
   13. Acknowledgments .............................................   38
   14. Authors' Addresses ..........................................   38
   15. Full Copyright Statement ....................................   39

                                       29
<PAGE>

1. Introduction

   This document describes the specifications for the NSI Registry
   Registrar Protocol (RRP) version 1.1.0, a TCP-based, 7-bit US-ASCII
   text protocol that permits multiple registrars to provide second
   level Internet domain name registration services in the top level
   domains (TLDs) administered by a TLD registry. RRP is specified using
   Augmented Backus-Nauer Form (ABNF) as described in [ABNF]. Note that
   all ABNF string literals are case-insensitive and the examples
   provided in this document may use mixed case to improve readability.

   RRP was developed by the Network Solutions, Inc. Registry under the
   auspices of the Shared Registration System program. The protocol was
   initially deployed in April 1999 as part of a test bed implementation
   of the Shared Registration System with five registrars. Additional
   registrars began using the protocol in July 1999. The operational
   experiences of both the registry and the registrars identified
   several "lessons learned" which have been documented here as "Known
   Issues".

   This document provides both a description of a protocol and notice of
   learned operational issues that may be useful as first steps in
   developing a standards track domain registration services protocol.
   This document and the protocol it describes may be modified in the
   future based on continued operational experience and community
   reaction.

   The registry stores information about registered domain names and
   associated name servers. A domain name's data includes its name, name
   servers, registrar, registration expiration date, and status. A name
   server's data includes its server name, IP addresses, and registrar.
   A registrar MAY perform the following registration service procedures
   using RRP:

   - Determine if a domain name has been registered.
   - Register a domain name.
   - Renew the registration of a domain name.
   - Cancel the registration of a domain name.
   - Update the name servers of a domain name.
   - Transfer a domain name from another registrar.
   - Examine the status of domain names that the registrar has
     registered.
   - Modify the status of domain names that the registrar has
     registered.
   - Determine if a name server has been registered.
   - Register a name server.
   - Update the IP addresses of a name server.

                                       30
<PAGE>

   - Delete a name server.
   - Examine the status of name servers that the registrar has
     registered.

   All RRP commands include features to provide idempotency.  That is,
   the effect of each command is the same if the command is executed
   once or if the command is executed multiple times. This property is
   extremely useful in situations when a command is retried due to an
   error condition that results in a missed command response and a
   command retry is attempted. Command retries will be caught by the
   System and rejected with an appropriate error response code. Command
   parameters that do not provide idempotency will be explained fully as
   part of the appropriate command description.

2. Security Services

   RRP provides only basic password-based registrar authentication
   services.  Additional security services, including privacy and
   registrar authentication using public key cryptography, are provided
   through other System features.

2.1 Connection Security

   Each RRP session MUST be encrypted using the Secure Socket Layer
   (SSL) v3.0 protocol as specified in [SSL]. SSL provides privacy
   services that reduce the risk of inadvertent disclosure of
   registrar-sensitive information, such as the registrar's user
   identifier and password.

   SSL supports mutual authentication of both the client and server
   using signed digital certificates. The Shared Registration System
   implemented by the NSI Registry requires digital certificates issued
   by a commercial certification authority for both registrar clients
   and public registry RRP servers. Both the registrar client and the
   public registry RRP server are authenticated when establishing an SSL
   connection. Further, a registrar MUST be authenticated when
   establishing an RRP connection via the RRP SESSION command by
   providing a registrar user identifier and password known only to the
   registrar and the System. Registrars may change their session
   password at any time using the RRP SESSION command.

   The SSL protocol is not an IETF Standards Track protocol. The
   Transport Layer Security protocol, specified in [TLS], is a Standards
   Track protocol that provides SSL v3.0 compatibility features.

                                       31
<PAGE>

2.2 System Data Security

   The System stores information about the registered domain names and
   their name servers.  Only the current registrar of a registered
   domain name is authorized to query it, update its name servers, and
   cancel or renew it. Any registrar can request a transfer of a domain
   name and its associated name servers from another registrar to the
   requesting registrar. Only the current sponsoring registrar can
   receive and explicitly approve or reject domain transfer requests.

   Only a name server's registrar can query, update, and delete it.  In
   general, name servers must be registered through the current
   registrar of the name server's parent domain name, though an
   implementation MAY allow use of name servers registered in other TLDs
   without specifying IP addresses or requiring parent domain
   registration. Use of ccTLD name servers for a gTLD domain name is one
   such example.

   Name servers are implicitly transferred by the System when their
   parent domain name is transferred. In addition, a name server cannot
   be deleted if it is hosting domain names.

3. Connection Model

   IANA has assigned TCP port 648 for RRP use. All RRP implementations
   MUST provide RRP services over SSL on TCP port 648. An RRP server
   MUST return a banner in the following format to confirm that a
   connection has been established:

   (registry name) RRP Server version (version)(crlf)
   (server build date and time)(crlf)

   Each line ends with carriage return and line feed characters. The
   server build date and time string includes the day, month, date, time
   (specified in hours, minutes, and seconds), the local time zone, and
   the four-digit year. A dot (".") in column one on a line by itself
   marks the end of banner text.

   Example

   A registrar successfully establishes a connection with the NSI
   Registry on TCP port 648:

   S:NSI RRP Server version 1.1.0
   S:Mon Oct 25 20:20:34 EDT 1999
   S:.

                                       32
<PAGE>

4. Protocol Description

   A typical RRP session will go through a number of states during its lifetime.
   Figure 1 illustrates the possible states of an RRP server.

   Initially, the server waits for a client connection and authentication (PRE).
   All client connections MUST be authenticated.

                                      |
                                      |
                                      v
                             +-----------------+   Timeout
                             |   Waiting for   |-------------------+
   Authentication Succeeded  |      Client     |                   |
                   +---------|  Authentication | Authentication    |
                   |         |      (PRE)      |-----+  Failed     |
                   |         +-----------------+     |             |
                   |                                 |             |
                   V                                 V             |
             +-----------+     Succeeded    +--------------------+ |
             |Waiting for|+-----------------|    Waiting for     | |
             |  Command  |----------+       |Authentication Retry| |
             |   (WFC)   |  Timeout |       |       (WFR)        | |
             +-----------+          |       +--------------------+ |
                 |   +              |           |         |        |
                 |   |              |   Timeout |         | Failed |
         Request V   |Response      |           |         |        |
             +-----------+          |           V         V        V
             | Executing |          |          +--------------------+
             |  Command  |          +---------+|    Disconnected    |
             |   (EXE)   |--------------------+|       (DIS)        |
             +-----------+          QUIT       +--------------------+

                   Figure 1: RRP Server Finite State Machine

   If the authentication fails, the server gives the client another chance to
   identify itself (WFR). If the authentication fails again, the server
   disconnects (DIS). Otherwise, the server waits for a request from the client
   (WFC). Upon receiving a request, the server executes it and responds to the
   client with the result (EXE). The server then waits again for another request
   from the client (WFC). If the client sends a QUIT command, the server ends
   the session and disconnects (DIS). To keep its state in sync with that of the
   server, the client SHOULD wait for a response from the server before sending
   another request on the same connection. The following table summarizes these
   states:

                                       33
<PAGE>

        PRE     Waiting for client connection and authentication
        WFR     Waiting for authentication retry
        WFC     Waiting for a command from an authenticated client
        EXE     Executing a command
        DIS     Disconnected

   The WFR and WFC states MAY time out. An implementation SHOULD define
   inactivity timeout periods for these states based on System-specific factors,
   including (but not limited to) resource availability and security risk. In
   the absence of other factors, a default timeout period of 10 minutes SHOULD
   be used. The server MAY disconnect if the server is in one of these states
   and no message is received from the client during the timeout period.

4.1 Request Format

   An RRP request nominally consists of a command name, an entity block, command
   options, and an end-of-command delimiter. Command options and entity blocks
   collectively define command parameters and their specification is order
   independent; examples provided in this document specify entity blocks before
   command options.

     CommandName [EntityBlock] [CommandOptions] EndOfCommand

   A command name specifies the type of an RRP request. A command is a word or
   abbreviation terminated by a carriage-return linefeed (crlf) sequence.

     CommandName<crlf>

   An entity block specifies the data in an RRP request. It consists of
   attribute name-value pairs specifying the entity and all of the attributes of
   the entity. Each attribute name-value pair starts with the attribute name,
   followed by a colon, the attribute value, and is finally terminated by a
   carriage-return linefeed sequence. Entity blocks are optional for some
   requests.

     entityName:entityValue<crlf>
     attributeName:attributeValue<crlf>

   Command options specify control parameters for an RRP request. A command
   option starts with a dash, followed by the option name, a colon, the option
   value, and is finally terminated by a carriage- return linefeed sequence.

     -commandOptionName:commandOptionValue<crlf>

                                       34
<PAGE>

   An EndOfCommand delimiter specifies the end of an RRP request. It consists of
   a dot (".") in column one followed by a carriage-return linefeed sequence.

     .<crlf>

4.2 Response Format

   An RRP response starts with a three-digit response code, followed by a space,
   an ASCII text description of the response, a carriage-return linefeed
   sequence, and zero or more attribute name-value pair lines. An RRP response
   is terminated by a dot in column one followed by a carriage-return linefeed
   sequence.

     ResponseCode<space>responseDescription<crlf>
     [attributeName:attributeValue<crlf>]
     .<crlf>

4.3 Protocol Commands

   Implementations of RRP commands MUST provide "all or nothing" success and
   failure operation. Failed command execution MUST leave the System in the same
   state it was in before the command was attempted and failed.

   All RRP commands include features to provide idempotency. Command features
   that are not idempotent are explained fully as needed as part of the
   appropriate command description.

4.3.1 ADD

   This command allows a registrar to register a domain name or a name server in
   the System.

4.3.1.1 Registering a Domain Name

   The request to register a domain name MUST contain the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

                                       35
<PAGE>

   The request to register a domain name MAY contain 1 or more, and a maximum of
   13, fully qualified name servers hosting the domain name in multiple
   instances of the "NameServer" parameter. The name servers MUST have already
   been registered in the registry. Implementations MAY allow specification of
   name servers associated with domains registered in other TLDs. For example,
   an implementation MAY allow use of ccTLD name servers for gTLD domain name
   registration.

   The request to register a domain name MAY contain the initial registration
   period in years for the domain being registered in a single instance of the
   "Period" parameter. The System MUST provide a default initial registration
   period in years if the "Period" parameter is not provided. The acceptable
   year values for the "Period" parameter are implementation specific.

   The System will register the domain name to the registrar for the period
   specified by the registrar. If the registrar does not specify a registration
   period, a System-specified default value MUST be used for the initial
   registration period. If the domain name is successfully registered, the
   System MUST return the registration expiration date in the "registration
   expiration date" attribute in the response.

   Authorized User: All registrars MAY use the ADD command to register
   domain names.

   Examples

   A registrar registers a domain name without specifying name servers:

   C:add<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:-Period:10<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:registration expiration date:2009-09-22 10:27:00.0<crlf>
   S:status:ACTIVE<crlf>
   S:.<crlf>

                                       36
<PAGE>

   A registrar registers a domain name using previously-registered name servers:

   C:add<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example2.com<crlf>
   C:-Period:10<crlf>
   C:NameServer:ns1.example.com<crlf>
   C:NameServer:ns2.example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:registration expiration date:2000-09-22 10:27:00.0<crlf>
   S:status:ACTIVE<crlf>
   S:.<crlf>

4.3.1.2 Registering a Name Server

   The request to register a name server MUST contain the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified server name of the name server in the "NameServer"
     parameter.

   If the name server being registered is the child of a registered domain name,
   the name server registration request MUST include one or more, and a maximum
   of 13, name server IP addresses in multiple instances of the "IPAddress"
   parameter. Name servers associated with domains registered in other TLDs
   SHOULD NOT be specified with IP addresses to reduce the possibility of
   duplicating DNS NS records for the name servers in multiple zone files.

   The registrar MUST register the name server in the System before using it to
   host domain names. Further, the name server MUST be registered through the
   same registrar that is the current registrar of its parent domain name. The
   System MAY allow any registrar to use the name server to host domain names.

   Authorized User: All registrars MAY use the ADD command to register
   name servers.

                                       37
<PAGE>

   Examples

   A registrar registers a new name server in an existing domain name:

   C:add<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.example.com<crlf>
   C:IPAddress:198.41.1.11<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.2 CHECK

   This command allows a registrar to determine if a domain name or name server
   has been registered in the System.

4.3.2.1 Domain Name Check

   The request to determine if a domain name is registered MUST contain the
   following data:

   - The "EntityName" parameter set to value "Domain".
     - Fully qualified second level domain name in the "DomainName" parameter.

   The System MUST provide a positive or negative response to document domain
   name availability at the moment the command is executed.

   Authorized User: All registrars MAY use the CHECK command to determine if a
   domain name has been registered or not.

   Examples

   A registrar checks the availability of a domain name in the System:

   C:check<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:211 Domain name not available<crlf>
   S:.<crlf>

                                       38
<PAGE>

4.3.2.2 Name Server Check

   The request to determine if a name server is registered MUST contain the
   following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified server name in the "NameServer" parameter.

   The System MUST provide a positive or negative response to document name
   server availability at the moment the command is executed. If the name server
   has been registered, the System MUST return the IP address(es) of the name
   server.

   Authorized User: All registrars MAY use the CHECK command to
   determine if a name server has been registered or not.

   Examples

   A registrar checks the availability of a server name in the System:

   C:check<crlf>
   C:EntityName:Nameserver<crlf>
   C:Nameserver:ns1.example.com<crlf>
   C:.<crlf>
   S:213 Name server not available<crlf>
   S:ipAddress:192.10.10.10<crlf>
   S:.<crlf>

4.3.3 DEL

   This command allows a registrar to delete (cancel the registration) of a
   domain name or delete a name server.

4.3.3.1 Deleting a Domain Name

   The request to cancel the registration of a domain name MUST contain the
   following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   A request to delete a domain name SHOULD cause the deletion of all name
   servers that are children of the domain name being deleted. The name servers
   SHOULD be deleted if they are not actively hosting other domains. A domain
   MUST not be deleted if it has child name servers hosting other domains.

                                       39
<PAGE>

   Authorized User: The current registrar of a domain name MAY use the
   DEL command to delete a domain name from the System.

   Examples

   A registrar deletes a domain name, implicitly deleting all name servers
   registered in the domain:

   C:del<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.3.2 Deleting a Name Server

   The request to delete a name server MUST contain the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified name of the name server in the "NameServer"
     parameter.

   A name server MUST not be deleted if it is hosting domains. Deleting such
   domains or name servers is prohibited because their deletion WILL result in
   orphaning the hosted domains.

   Authorized User: The current registrar of a name server MAY use the
   DEL command to delete a name server from the System.

   Examples

   A registrar deletes a name server that is not hosting domains:

   C:del<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

                                       40
<PAGE>

   A registrar tries to delete a name server that is hosting domains:

   C:del<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>
   S:532 Domain names linked with name server<crlf>
   S:.<crlf>

4.3.4 DESCRIBE

   This command allows a registrar to obtain general information about an RRP
   implementation. The command MAY contain the following parameters:

   - The "Target" parameter set to value "Protocol".

   The implementation MUST return the protocol version number whether or not the
   request contains the "Target" parameter.

   Authorized User: All registrars MAY use the DESCRIBE command.

   Examples

   A registrar obtains general information about an RRP implementation:

   C:describe<crlf>
   C:-Target:Protocol<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:Protocol:RRP 1.1.0<crlf>
   S:.<crlf>

4.3.5 MOD

   This command allows a registrar to update a registered domain name or a name
   server. The command allows the following operations on an attribute value for
   both single-valued and multi-valued attributes:

   - Add an attribute value. The value to be added MUST be unique among the
     values of the attribute. For a single-valued attribute, it replaces the
     current value.
   - Remove an attribute value. The value to be removed MUST exist. Further, an
     attribute value cannot be removed if it is the only value of a required
     attribute.

   Attribute values to be removed are identified by tagging with an "=" suffix.

                                       41
<PAGE>

4.3.5.1 Domain Modification

   The request to modify a registered domain name MUST contain the following
   data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   The registrar can perform the following update operations on the domain name:

   - Update the name servers of the domain name by setting one or more instances
     of the "NameServer" parameter.
   - Update the status of the domain name by setting one or more instances of
     the "Status" parameter. Valid values for the "Status" parameter are defined
     in Section 6.

   Authorized User: The current registrar of a domain name MAY use the
   MOD command to modify the attributes of a domain name.

   Examples

   A registrar removes one name server (ns1) from a domain and adds a new name
   server (ns3) to the same domain:

   C:mod<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:NameServer:ns3.registrarA.com<crlf>
   C:NameServer:ns1.registrarA.com=<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.5.2 Name Server Modification

   The request to update a name server MUST contain the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified server name of the name server in the "NameServer"
     parameter.

                                       42
<PAGE>

   The registrar can perform the following update operations on the name server:

   - Update the "NameServer" attribute of the name server. This allows a
     registrar to change the name of a name server while preserving all existing
     associations.
   - Update the IP addresses of the name server by setting one or more instances
     of the "IPAddress" parameter.

   Authorized User: The current registrar of a name server MAY use the
   MOD command to modify the attributes of a domain name.

   Examples

   A registrar changes the name and IP address of a name server:

   C:mod<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:NewNameServer:ns2.registrarA.com<crlf>
   C:IPAddress:198.42.1.11<crlf>
   C:IPAddress:198.41.1.11=<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.6 QUIT

   This command allows a registrar to close an RRP connection. A response MUST
   be sent before closing the connection.

   Authorized User: All registrars MAY use the QUIT command.

   Examples

   A registrar ends an RRP session and closes an existing connection:

   C:quit<crlf>
   C:.<crlf>
   S:220 Command completed successfully. Server closing connection<crlf>
   S:.<crlf>

                                       43
<PAGE>

4.3.7 RENEW

   This command allows a registrar to renew a domain name in the System. The
   request to renew a domain name MUST contain the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   The request to renew a domain name MAY contain the renewal period in years
   for the domain being renewed in a single instance of a "Period" parameter and
   a single instance of a "CurrentExpirationYear" parameter. These parameters
   MUST appear together if either is specified, though the order in which the
   parameters appear is insignificant. The "Period" parameter identifies the
   number of years to be added to the registration. The "CurrentExpirationYear"
   parameter identifies the current expiration year, and is required to ensure
   that repeated attempts to retry this command do not result in multiple
   successful renewals. The System MUST provide a default number of renewal
   years if the "Period" and "CurrentExpirationYear" parameters are not
   provided. Repeated use of this command without the "Period" and
   "CurrentExpirationYear" parameters may result in repeated successful renewals
   since idempotency is not provided when these parameters are not used. The
   acceptable year values for the "Period" parameter are implementation specific
   subject to syntax restrictions.

   The System renews the domain name for a period specified by the registrar. If
   the domain name renewal is completed successfully, the System MUST return the
   new registration expiration date in the "RegistrationExpirationDate"
   attribute in the response.

   Authorized User: The current registrar of a domain name MAY use the
   RENEW command.

   Examples

   A registrar renews a domain name using a specified renewal period:

   C:renew<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:-Period:9<crlf>
   C:-CurrentExpirationYear:2001<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:registration expiration date:2010-09-22 10:27:00.0<crlf>
   S:.<crlf>

                                       44
<PAGE>

4.3.8 SESSION

   This command allows a registrar to establish an RRP session. A registrar can
   also use this command to change their password. The request to establish an
   RRP connection MUST contain the following command parameters:

   - The "Id" parameter set to the registrar's System user ID.
   - The "Password" parameter set to the registrar's current System
     password.

   The request to establish an RRP session MAY contain a new password for the
   registrar in a single instance of the "NewPassword" parameter.

   The registrar MUST send this command to the System before any other command.
   If the command fails due to invalid information (such as an invalid registrar
   ID or password), the registrar can resend this request with corrected
   information. If the command fails a second time, the System SHOULD close the
   connection.

   Authorized User: All registrars MAY use the SESSION command.

   Examples

   A registrar establishes an RRP session:

   C:session<crlf>
   C:-Id:registrarA<crlf>
   C:-Password:i-am-registrarA<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.9 STATUS

   This command allows a registrar to determine the current status of a domain
   name or name server.

4.3.9.1 Domain Status

   The request to query a domain name MUST contain the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

                                       45
<PAGE>

   The response from the System MAY contain the following data:

   - Fully qualified server names of name servers hosting the domain name in
     multiple instances of the "nameserver" attribute.
   - Registration expiration date in the "registration expiration date"
     attribute.
   - ID of the current registrar of the domain name in the "registrar"
     attribute.
   - Date the domain name was transferred by the current registrar in the
     "registrar transfer date" attribute.
   - Current statuses of the domain name in multiple instances of the "status"
     attribute.
   - Date the domain name was originally registered in the "created date"
     attribute.
   - ID of the registrar that originally registered the domain name in the
     "created by" attribute.
   - Date the domain name was last updated in the "updated date" attribute.
   - ID of the entity (either a registrar or the registry) that last updated the
     domain name in the "updated by" attribute.

   Authorized User: The current registrar of a domain name MAY use the
   STATUS command to view current domain name attributes.

   Examples

   The current registrar of a domain name queries the domain name:

   C:status<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:nameserver:ns2.registrarA.com<crlf>
   S:nameserver:ns3.registrarA.com<crlf>
   S:registration expiration date:2010-09-22 10:27:00.0<crlf>
   S:registrar:registrarA<crlf>
   S:registrar transfer date:1999-09-22 10:27:00.0<crlf>
   S:status:ACTIVE<crlf>
   S:created date:1998-09-2 10:27:00.0<crlf>
   S:created by:registrarA<crlf>
   S:updated date:2002-09-22 10:27:00.0<crlf>
   S:updated by:registrarA<crlf>
   S:.<crlf>

                                       46
<PAGE>

   A registrar queries a domain name currently registered by another registrar:

   C:status<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:531 Authorization failed<crlf>
   S:.<crlf>

4.3.9.2 Name Server Status

   The request to query a name server MUST contain the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified name of the name server in the "NameServer"
     parameter.

   The response from the System MAY contain the following data:

   - Fully qualified name of the name server in the "nameserver" attribute.
   - IP addresses of the name server in multiple instances of the "ipaddress"
     attribute.
   - ID of the current registrar of the name server in the "registrar"
     attribute.
   - Date the name server was transferred by the current registrar in the
     "registrar transfer date" attribute.
   - Date the name server was registered in the "created date" attribute.
   - ID of the entity that registered the name server in the "created by"
     attribute.
   - Date the name server was last updated in the "updated date" attribute.
   - ID of the entity that last updated the name server in the "updated by"
     attribute.

   Authorized User: The current registrar of a name server MAY use the
   STATUS command to view current domain name attributes.

   Examples

   The current registrar of a name server queries the name server:

   C:status<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>

                                       47
<PAGE>

   S:200 Command completed successfully<crlf>
   S:ipaddress:198.42.1.11<crlf>
   S:registrar:registrarA<crlf>
   S:registrar transfer date:1999-09-22 10:27:00.0<crlf>
   S:CreatedDate:1998-09-22 10:27:00.0<crlf>
   S:CreatedBy:registrarA<crlf>
   S:UpdatedDate:2002-09-22 10:27:00.0<crlf>
   S:UpdatedBy:registrarA<crlf>
   S:.<crlf>

   A registrar queries a name server that was registered by another registrar:

   C:status<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>
   S:531 Authorization failed<crlf>
   S:.<crlf>

4.3.10 TRANSFER

   This command allows a registrar to request transfer of domain name
   sponsorship from a second registrar and to approve or reject transfer
   requests initiated by other registrars. The request to transfer a domain name
   MUST contain the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   The identity of the requesting registrar is derived from the current active
   session. The identity of the current sponsoring registrar (the registrar who
   must approve or reject the transfer request) is known by the registry and
   does not need to be known by the requesting registrar in advance of issuing
   the transfer request.

   The System MUST notify the potential losing registrar when a domain transfer
   request has been received using an out-of-band transport mechanism such as
   electronic mail and/or transaction reporting. The losing registrar SHOULD
   then explicitly approve or reject the transfer. A request to approve or
   reject a transfer request MUST contain a single instance of the "Approve"
   parameter with a value of "Yes" to approve the transfer or a value of "No" to
   reject the transfer. A server implementation MAY provide a default approval
   or rejection action to be taken if the losing registrar does not explicitly
   approve or reject the transfer request within a fixed amount of time. The
   criteria used by registrars to approve or deny

                                       48
<PAGE>

 requested transfers are typically based on business policies that are beyond
 the scope of this document.

 Approval of a transfer by the current sponsoring registrar results in a change
 of sponsorship to the original requesting registrar. Approval attempts by any
 other registrar MUST result in explicit failure of the attempted approval.
 Rejection of the transfer by the current sponsoring registrar results in an end
 to the transfer request with no change in sponsorship. Rejection attempts by
 any other registrar MUST result in explicit failure of the attempted rejection.

 Name servers MUST be implicitly transferred when their parent domain name is
 transferred.

 Authorized User: All registrars MAY use the TRANSFER command to request
 transfer of registration service authority to the requesting registrar. Only
 the current sponsoring registrar of a domain name may explicitly approve or
 reject a requested transfer. The registry MAY implicitly approve or reject
 requested transfers after a fixed amount of time.

 Examples

 A registrar requests transfer of a domain name from another
 registrar:

 C:transfer(crlf)
 C:EntityName:Domain(crlf)
 C:DomainName:example.com(crlf)
 C:.(crlf)
 S:200 Command completed successfully(crlf)
 S:.(crlf)

 The original registrar approves the transfer request:

 C:transfer(crlf)
 C:-Approve:Yes(crlf)
 C:EntityName:Domain(crlf)
 C:DomainName:example.com(crlf)
 C:.(crlf)
 S:200 Command completed successfully(crlf)
 S:.(crlf)

                                       49
<PAGE>

5. Response Codes

   RRP commands may return a variety of response codes to signify normal
   completion or error conditions. This section documents all of the defined RRP
   response codes.

5.1  Response Code Summary

   200 Command completed successfully
   This is the normal response for successful completion of most RRP commands.

   210 Domain name available
   This is the normal response for successful completion of an RRP CHECK command
   for a domain name that is not currently registered.

   211 Domain name not available
   This is the normal response for successful completion of an RRP CHECK command
   for a domain name that is currently registered.

   212 Name server available
   This is the normal response for successful completion of an RRP CHECK command
   for a name server that is not currently registered.

   213 Name server not available
   This is the normal response for successful completion of an RRP CHECK command
   for a name server that is currently registered.

   220 Command completed successfully. Server closing connection This is the
   normal response for successful completion of an RRP QUIT command. It may also
   be returned by other RRP commands if a transient situation is noted that
   requires closing the connection after successfully completing the RRP
   command.

   420 Command failed due to server error. Server closing connection A transient
   server error has caused RRP command failure and session termination. A new
   session must be established before continued processing can be attempted.

   421 Command failed due to server error. Client should try again A transient
   server error has caused RRP command failure. A subsequent retry may produce
   successful results.

   500 Invalid command name
   A client-specified RRP command name was not recognized as a valid RRP command
   name.

                                       50
<PAGE>


 501 Invalid command option
 A client-specified RRP command parameter was not recognized as a valid RRP
 command parameter.

 502 Invalid entity value
 The "value" of an entity name-value pair is invalid. Command blocks that
 require an "EntityName" parameter also require a value that specifies the
 entity name, and the provided value is invalid.

 503 Invalid attribute name
 A client-specified RRP command parameter was not recognized as a valid RRP
 command parameter.

 504 Missing required attribute
 A parameter required to execute the RRP command was not provided by the client.
 The command should be retried with all required parameters specified.

 505 Invalid attribute value syntax
 A supplied parameter value is syntactically incorrect. For example, a year
 value digit such as "5" may be required but the client provided a string of
 characters such as "five".

 506 Invalid option value
 A client-specified value for an RRP command parameter is out-of-bounds or
 otherwise not within acceptable System limits.

 507 Invalid command format
 The specified command does not resemble a well-formed RRP command. The command
 should be retried using the proper command structure and syntax.

 508 Missing required entity
 An entity required for command completion was not provided by the client. For
 example, the CHECK command requires specification of either a "Domain" entity
 or a "Nameserver" entity.

 509 Missing command option
 A command parameter that isn't really optional (such as the registrar ID in a
 SESSION command) was not provided by the client. The command should be retried
 with all needed parameters.

 520 Server closing connection. Client should try opening new connection; (why)
 A timeout event has been detected, and the client's session is being ended. The
 System SHOULD define timeout periods to begin a client

                                       51
<PAGE>


 command, complete a client command, and for the duration of an open session.
 The reason for the timeout MUST be provided at the end of the response code
 string.

 521 Too many sessions open. Server closing connection
 A System-defined limit on the number of open connections has been exceeded, and
 it is impossible to establish a new session at the moment. It may be possible
 to establish a session by waiting for a few moments or by closing existing
 unused sessions.

 530 Authentication failed
 The client-supplied registrar identifier or password was not recognized by the
 System. A subsequent retry with valid values may produce successful results.
 Repeated authorization failures MAY result in termination of the TCP
 connection.

 531 Authorization failed
 Registrars may not view or alter data associated with either the registry or
 another registrar. This response code is typically returned when a registrar
 attempts to view or modify data belonging to either the registry or another
 registrar. A typical situation includes doing a STATUS command for a domain
 registered to another registrar.

 532 Domain names linked with name server
 The name server is hosting active domains. This error occurs when a registrar
 is trying to delete a server that is the name server for active domains. The
 registry MUST not allow the registrar to delete this server. All of the domain
 names using this server MUST be modified to use a different name server before
 the name server can be deleted.

 533 Domain name has active name servers
 The domain name has active name servers. The registrar is trying to delete a
 domain name that is a parent domain of an active name server, i.e., a server
 that is hosting active domains. All of the name servers within the domain MUST
 be removed from service before the domain can be deleted.

 534 Domain name has not been flagged for transfer
 The registrar is trying to approve or reject a domain name transfer for a
 domain name that is not pending transfer.

 535 Restricted IP address
 IANA identifies certain IP address ranges that are not valid for normal use.
 The registrar is trying to use an IP address that is in a restricted IP address
 range as identified by IANA.

                                       52
<PAGE>


 536 Domain already flagged for transfer
 The registrar tried to perform a transfer command for a domain name that is
 awaiting approval of an earlier transfer request.

 540 Attribute value is not unique
 A supplied attribute value is not unique. This occurs when the registrar is
 adding a domain name that already exists in the registry, a server that already
 exists in the registry, or an IP address that is already being used by another
 server in the registry. Another possibility occurs when performing domain
 modifications and the registrar is adding a server that is already in the list
 of servers for the domain name or setting a domain name to a status to which it
 is already set. The RRP STATUS command MAY be used to determine current domain
 name status before attempting to change the status. When modifying or adding a
 name server, the IP address of the name server might not be unique. The
 registry MUST not allow IP addresses to be used by more than one server.

 541 Invalid attribute value
 A supplied parameter value is invalid. Examples of invalid attribute values
 include an invalid IP address, an invalid domain name, an invalid server name,
 or an invalid renewal period.

 542 Invalid old value for an attribute
 A current attribute value to be modified is invalid. The registrar is trying to
 modify an attribute of a server or a domain name that does not exist in the
 registry.

 543 Final or implicit attribute cannot be updated
 The registrar is attempting to modify an attribute that is only modifiable by
 the registry. Registrars can not modify final or implicit attribute values.

 544 Entity on hold
 The attempted operation was rejected because the entity is on HOLD status. If
 the HOLD status was set by the registrar, the status can be changed using the
 MOD command and the requested command can be retried. If the HOLD status was
 set by the registry, the registrar must contact the registry to change the
 status before the command can be successful.

 545 Entity reference not found
 A required entity reference was not found. This occurs when the registrar tries
 to add a new name server and the parent domain of the name server does not
 exist in the registry. It also occurs when the user is trying to add a new name
 server to a domain name when the name server does not exist in the registry.

                                       53
<PAGE>


 546 Credit limit exceeded
 The registrar's credit limit has been exceeded. This is an implementation
 specific error that occurs when a potentially billable operation, such as
 adding a domain name, renewing a domain name, or transferring a domain name, is
 attempted and the registrar does not have sufficient financial standing with
 the registry to complete the operation.

 547 Invalid command sequence
 RRP commands are issued using a well-formed syntax that requires entry of
 command structures in particular sequences. This response code indicates that
 an ill-formed command was received and rejected.

 548 Domain is not up for renewal
 A RENEW command was attempted during a period in which the domain can not be
 renewed. Implementations MAY limit renewal periods to particular time frames,
 such as within 90 days of the domain's expiration. This response indicates that
 the RENEW command was received outside of the System-defined domain renewal
 period.

 549 Command failed
 A System error prevented successful completion of the requested RRP command.
 Retrying the command might produce success, but a repeated failure indicates a
 System error condition.

 550 Parent domain not registered
 The parent domain of a name server being registered is not registered. This
 occurs when the registrar tries to add a new name server and the parent domain
 for the server does not exist in the registry.

 551 Parent domain status does not allow for operation
 The status of the parent domain does not allow the requested operation. This
 occurs when a registrar tries to modify a server whose parent domain is flagged
 as LOCK or HOLD in the registry.

 552 Domain status does not allow for operation
 The status of the domain does not allow the requested operation. This occurs
 when a registrar tries to modify or delete a domain that is flagged as LOCK or
 HOLD in the registry.

 553 Operation not allowed. Domain pending transfer
 The status of the domain does not allow the requested operation. The registrar
 is attempting to delete a domain that is pending approval or denial of a
 transfer request.

                                       54
<PAGE>

 554 Domain already registered
 A registrar tried to register a domain name that has already been registered by
 the same registrar.

 555 Domain already renewed
 A registrar tried to renew a domain using the same parameters as specified for
 an earlier, successful renewal. This will commonly occur when executing the
 same RENEW command more than once.

 556 Maximum registration period exceeded
 A registrar tried to renew a domain registration, and the resulting new
 registration period exceeds the System-defined maximum registration period. If
 there is renewal time available with the System-defined maximum registration
 period it may be possible to retry the RENEW command with specified renewal
 period parameters.

5.2 Command-Response Correspondence

 The session between the client and the server is intended to be an alternating
 dialogue. Each command issued by a client MUST be acted upon by the server,
 which MUST return a response code to document the success or failure of command
 execution. "Success" means that the command completed normal execution without
 error. "Failure" means that the System did not complete the command as
 requested. Failure may be due to either syntax, semantic, data, or System
 errors.

 A complete list of response codes for each RRP command is listed below.

 Command: ADD
 Success: 200, 220
 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
 540, 541, 545, 546, 547, 549, 550, 554

 Command: CHECK
 Success: 210, 211, 212, 213
 Failure: 220, 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 541,
 547, 549

 Command: DEL
 Success: 200, 220
 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532,
 533, 541, 544, 545, 547, 549, 551, 552, 553

 Command: DESCRIBE
 Success: 200, 220
 Failure: 420, 421, 500, 501, 506, 507, 509, 520, 547, 549

                                       55
<PAGE>

   Command: MOD
   Success: 200, 220
   Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
   540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553

   Command: QUIT
   Success: 220
   Failure: 420, 421, 500, 507, 520, 547, 549

   Command: RENEW
   Success: 200, 220
   Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 541,
   545, 546, 547, 548, 549, 552, 553, 555, 556

   Command: SESSION
   Success: 200, 220
   Failure: 420, 421, 500, 501, 506, 507, 508, 509, 520, 521, 530, 531,
   547, 549

   Command: STATUS
   Success: 200, 220
   Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
   531, 541, 545, 547, 549

   Command: TRANSFER
   Success: 200, 220
   Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
   531, 534, 536, 541, 544, 545, 546, 547, 549, 552, 553

6. Domain Status Codes

   The status of a domain can be viewed using the RRP STATUS command and
   modified using the RRP MOD command. Both the registry and the sponsoring
   registrar MAY view and change the status of a domain. The criteria for status
   changes are highly dependent on registry and registrar business models and
   are thus beyond the scope of this specification.

   The domain's status SHOULD have a direct bearing on whether or not the domain
   appears in the appropriate TLD zone file and whether or not the domain can be
   modified. A domain can have more than one assigned status, e.g., REGISTRAR-
   HOLD and REGISTRAR-LOCK. If a domain is in ACTIVE status, then the domain
   name can only be in this status. When a registrar sets a domain name to
   REGISTRAR-LOCK, the registry MUST automatically remove the ACTIVE status.
   When the registrar removes the REGISTRAR-LOCK and other domain statuses, the
   registry MUST automatically set the domain name status to ACTIVE.

                                       56
<PAGE>

6.1 Domain Status Code Description

    ACTIVE: This is the default status of a domain at registration time. The
    registry sets the domain to this status. The domain is modifiable by the
    registrar. The domain can be renewed. The domain SHALL be included in the
    zone file when in this status if the domain has at least one associated name
    server.

    REGISTRY-LOCK: The registry sets the domain to this status. The domain
    cannot be modified or deleted by the registrar. The registry MUST remove the
    REGISTRY-LOCK status for the registrar to modify the domain. The domain can
    be renewed. The domain SHALL be included in the zone file when in this
    status if the domain has at least one associated name server.

    REGISTRY-HOLD: The registry sets the domain to this status. The domain
    cannot be modified or deleted by the registrar. The registry MUST remove the
    REGISTRY-HOLD status for the registrar to modify the domain. The domain can
    be renewed. The domain SHALL NOT be included in the zone file when in this
    status.

    REGISTRAR-HOLD: The registrar of the domain sets the domain to this status.
    The domain can not be modified or deleted when in this status. The registrar
    MUST remove REGISTRAR-HOLD status to modify the domain. The domain can be
    renewed. The domain SHALL NOT be included in the zone file when in this
    status.

    REGISTRAR-LOCK: The registrar of the domain sets the domain to this status.
    The domain cannot be modified or deleted when in this status. The registrar
    MUST remove REGISTRAR-LOCK status to modify the domain. The domain can be
    renewed. The domain SHALL be included in the zone file when in this status.

    REGISTRY-DELETE-NOTIFY: A domain is set on this status if it has expired and
    has child name servers that are hosting other domains. Only the registry may
    set this status. The domain SHALL be included in the zone file when in this
    status if the domain has at least one associated name server.

7.  Formal Syntax

    The following syntax specification uses the augmented Backus-Naur Form (BNF)
    as described in [ABNF].

; ABNF specification for Registry Registrar Protocol (RRP) v1.1.0
; Note that character string literals are case insensitive.

                                       57
<PAGE>

; Lexical tokens
space = %x20 ; " "
dot = %x2E ; "."
dash = %x2D ; "-"
underscore = %x5F ; "_"
colon = %x3A ; ":"
cr = %x0D ; ASCII carriage return
lf = %x0A ; ASCII linefeed
crlf = cr lf
alpha = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
dns-char = alpha / digit / dash
id-char = alpha / digit / underscore / dash
id-prefix = alpha / digit
id-word = id-prefix (id-char
printable-char = %x20-7E ; ASCII " " - "~"

; Start of basic grammar.
year = 4digit
month = 2digit
day = 2digit
ymd = year dash month dash day
hour = 2digit
minute = 2digit
second = 2digit
split-second = 1digit
hms = hour colon minute colon second dot split-second
time-stamp = ymd space hms
ip-address = 1(3digit dot 1(3digit dot 1(3digit dot 1(3digit
password = 4(16printable-char
option-name = 1(128id-word
option-tag = dash option-name
option-value = 1(128id-word
attribute-name = 1(128id-word
attribute-value = 1(128printable-char
attribute-line = attribute-name colon attribute-value crlf
response = 3digit space 1(printable-char crlf
version-number = "RRP" space 1(digit dot 1(digit dot 1(digit
label = id-prefix [(61dns-char id-prefix]
sldn = label dot label
servername = ((label dot) sldn
period = %x31-39 / (%x31-39 %x30-39) ; "1" - "9" or "10" - "99"
period-option = dash "Period" colon period crlf
yesno = "Yes" / "No"
domainstatus = "Active" / "Registry-Lock" / "Registry-Hold" /
      "Registrar-Lock" / "Registrar-Hold" /
      "Registry-Delete-Notify"

                                       58
<PAGE>

; RRP commands and responses.
rrp = add / check / delete / describe / mod / quit / renew /
      session / status / transfer

add = add-request add-response
check = check-request check-response
delete = del-request del-response
describe = describe-request describe-response
mod = mod-request mod-response
quit = quit-request quit-response
renew = renew-request renew-response
session = session-request session-response
status = status-request status-response
transfer = transfer-request transfer-response

; ADD command.
add-request = add-domain-request / add-nameserver-request
add-response = add-domain-response / add-nameserver-response
add-domain-request = "add" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 [period-option]
 0(13("NameServer" colon servername crlf)
 dot crlf
add-nameserver-request = "add" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 1(("IPAddress" colon ip-address crlf)
 dot crlf
add-domain-response = response
 "RegistrationExpirationDate" colon time-stamp crlf
 "status" colon domainstatus crlf
 dot crlf
add-nameserver-response = response
 dot crlf

; CHECK command.
check-request = check-domain-request / check-nameserver-request
check-response = check-domain-response / check-nameserver-response
check-domain-request = "check" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
check-nameserver-request = "check" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 dot crlf
check-domain-response = response

                                       59
<PAGE>

 dot crlf
check-nameserver-response = available-check-nameserver-response /
                            notavailable-check-nameserver-response
available-check-nameserver-response = response
 dot crlf
notavailable-check-nameserver-response = response
 1*("IPAddress" colon ip-address crlf)
 dot crlf

; DEL command.
del-request = del-domain-request / del-nameserver-request
del-response = response
 dot crlf
del-domain-request = "del" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
del-nameserver-request = "del" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 dot crlf

; DESCRIBE command.
describe-request = "describe" crlf
 [target-option]
 *(option-tag colon option-value crlf)
 dot crlf
describe-response = response
 "Protocol" colon version-number crlf
 *attribute-line
 dot crlf
target-option = dash "Target" colon "Protocol" crlf

; MOD command.
mod-request = mod-domain-request / mod-nameserver-request
mod-response = response
 *attribute-line
 dot crlf
mod-domain-request = "mod" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 *(add-attribute-value-line /
 remove-attribute-value-line /
 replace-attribute-value-line)

                                       60
<PAGE>

 dot crlf
mod-nameserver-request = "mod" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 ["NewNameServer" colon attribute-value crlf]
 *(add-attribute-value-line /
 remove-attribute-value-line /
 replace-attribute-value-line)
 dot crlf
add-attribute-value-line =
 attribute-name colon new-attribute-value
remove-attribute-value-line =
 attribute-name colon old-attribute-value "="
replace-attribute-value-line =
 attribute-name colon old-attribute-value "="
 new-attribute-value
old-attribute-value = attribute-value
new-attribute-value = attribute-value

; QUIT command.
quit-request = "quit" crlf
 dot crlf
quit-response = response
 dot crlf

; RENEW command.
renew-request = "renew" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 [renew-period-option]
 dot crlf
expiration-year-option = dash "CurrentExpirationYear" colon year crlf
renew-period-option = period-option expiration-year-option /
                      expiration-year-option period-option
renew-response = response
 "RegistrationExpirationDate" colon time-stamp crlf
dot crlf

; SESSION command.
session-request = "session" crlf
 registrar-id-option
 registrar-password-option
 [registrar-newpassword-option]
 dot crlf
session-response = response
 dot crlf
registrar-id-option = dash "Id" colon option-value crlf
registrar-password-option =

                                       61
<PAGE>

 dash "Password" colon password crlf
registrar-newpassword-option =
 dash "NewPassword" colon password crlf

; STATUS command.
status-request = status-domain-request /
                 status-nameserver-request
status-response = response
 *attribute-line
 dot crlf
status-domain-request = "status" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
status-nameserver-request = "status" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 dot crlf

; TRANSFER command.
transfer-request = "transfer" crlf
 [approve-option]
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
transfer-response = response
 "RegistrationExpirationDate" colon time-stamp crlf
 dot crlf
approve-option = dash "Approve" colon yesno crlf

; End of grammar.

8. Internationalization

   RRP is defined using 7-bit US-ASCII characters. Other character sets and
   character codes are not currently supported.

9. Known Issues

   RRP was not designed to provide bulk data query features. The primary goal of
   the original protocol designers was to provide a fast, light weight
   transactional protocol that could be implemented with minimal need for
   database queries that would take a "long" time to complete or that would
   return a "large" amount of data. Implementers SHOULD consider developing
   offline reporting features to provide bulk data for registrar reporting in a
   fashion suitable for the given registry-registrar operating environment.

                                       62
<PAGE>

 This version of RRP does contain a few limitations noted over the course of
 several months of operational experience with live domain name registrars.
 Later versions of this protocol or its successors should strive to resolve or
 address each of the following issues:

 The DESCRIBE command should return information describing System-defined
 default implementation values.

 Use of the RENEW command without the "CurrentExpirationYear" and "Period"
 parameters does not provide idempotency. Repeated execution of a RENEW command
 without these parameters can result in multiple successful RENEW commands,
 which may not be the desired action if a registrar is retrying a RENEW command
 due to network connectivity problems.

 Time stamps returned by RRP do not include time zone identifiers and SHOULD be
 interpreted as local registry time.

 The protocol does not provide features for a registrar to become aware of
 domain transfer requests and responses. Systems must rely on means outside of
 the protocol, such as electronic mail and/or registry-provided reports, to
 inform registrars of transfer requests and responses.

 The protocol does not provide features for a registrar to determine all of the
 domains served by a name server. Systems must provide this information using a
 method outside of the protocol, such as through periodic extracts from a System
 database.

 The protocol does not provide features to manage lame delegation of name
 servers. Any registrar may "use" name servers registered by another registrar.
 When a registrar tries to delete a domain or name server it is quite possible
 that name servers in the domain to be deleted or the name server to be deleted
 will be associated with other live domains, precluding immediate deletion.
 Systems must rely on means outside of the protocol to manage lame delegation of
 name servers.

 The use of "=" within the MOD command to indicate a value to be removed is
 somewhat confusing. A more explicit means of identifying old and new attribute
 values within the protocol syntax could make this feature more obvious.

 The CHECK command also returns name server IP addresses when returning positive
 confirmation of the registration of a name server. This extra information may
 be useful, but it is inconsistent with the limited function of the command. The
 command should return a positive or negative response and nothing more.

                                       63
<PAGE>

     The formal protocol syntax described in this document requires a specific
     order for the elements of a command entity block and command options. The
     NSI Registry's server-side implementation of the protocol provides the
     additional flexibility of allowing order independent specification of
     options and entity block elements. Client-side implementers are strongly
     urged to observe the order of command elements as specified here to ensure
     compliance if the more restricted form is enforced in the future.

     RRP does not return time stamps or transaction identifiers to track
     transactions. The NSI Registry provides registrars with daily and weekly
     reports that include time stamps in local registry time to document and
     synchronize data on a per-registrar basis.

10. Security Considerations

     Misuse of the Registry Registrar Protocol can have catastrophic operational
     consequences for registrants, registrars, and registries. As such, all
     registrars must be authenticated prior to all interactions with the
     registry. In addition, all data exchanged between the registrar and the
     registry must be protected to avoid unintended disclosure of information.

11. IANA Considerations

     IANA assigned TCP port 648 for RRP use in November 1998. No other action is
     required of IANA to support operation of this protocol.

     IANA has reserved certain IPv4 address ranges as described in [ALLOCATION].
     Implementers MUST ensure that name server IP addresses do not fall into one
     of the reserved address ranges to avoid operational DNS errors.

12. References

     [ABNF]         Crocker, D. (Editor) and P. Overell, "Augmented BNF for
                    Syntax Specifications: ABNF", RFC 2234, November 1997.

     [ALLOCATION]   Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
                    Postel, "Internet Registry IP Allocation Guidelines", BCP
                    12, RFC 2050, November 1996.

     [MUSTSHOULD]   Bradner, S., "Key Words for Use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

                                       64
<PAGE>


    [SSL]      A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
               Netscape Communications Corp., November 18, 1996.

    [TLS]      Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
               January 1999.

13.  Acknowledgments

   Many people have contributed significantly to this document and the protocol
   it describes. Brad McMillen and Neeran Saraf deserve special mention as co-
   authors of an earlier internal protocol specification. Other content
   contributors to the earlier internal specification include Aristotle Balogh,
   Chris Bason, Mark Kosters, Jasdip Singh, and Yibing Wu. Finally, significant
   contributors to the review of this document include Steve Mahlstedt and Chris
   Smith.

14.  Authors' Addresses

   Scott Hollenbeck
   Network Solutions, Inc. Registry
   505 Huntmar Park Dr.
   Herndon, VA 20170
   USA

   EMail: [email protected]


   Manoj Srivastava
   Network Solutions, Inc. Registry
   505 Huntmar Park Dr.
   Herndon, VA 20170
   USA

   EMail: [email protected]


                                       65
<PAGE>


15.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to others,
   and derivative works that comment on or otherwise explain it or assist in its
   implementation may be prepared, copied, published and distributed, in whole
   or in part, without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such copies and
   derivative works. However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an "AS IS"
   basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
   ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
   RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the Internet
   Society.

                                       66
<PAGE>

2.  Supported initial and renewal registration periods
    --------------------------------------------------

a.  Initial registrations of Registered Names (where available according to
functional specifications and other requirements) may be made in the registry
for a minimum of one year or in multiples of one-year increments up to ten
years.

b.  Renewal registrations of Registered Names (where available according to
functional specifications and other requirements) may be made in the registry in
multiples of one-year increments, provided that the maximum unexpired (i.e. into
the future) term of the registration of an unexpired name shall not exceed ten
years.

c.  Upon change of sponsorship of the registration of a Registered Name from one
registrar to another, according to Part A of Exhibit B to Appendix F of the
registry agreement, the term of registration of the Registered Name shall be
extended by one year, provided that the maximum unexpired (i.e. into the future)
term of the registration of an unexpired name shall not exceed ten years.

d.  The change of sponsorship of registration of Registered Names from one
registrar to another, according to Part B of Exhibit B to Appendix F of the
registry agreement shall not result in the extension of the term of the
registrations.

                                       67
<PAGE>

3. Grace period policy
   -------------------

     1.  Introduction

This document describes VeriSign Global Registry Services (VGRS) practices for
operational "Grace" and "Pending" periods, including relationships among
sequential operations that occur within given time frames.  A Grace Period
refers to a specified number of calendar days following a Registry operation in
which the domain may be deleted and a credit may be issued to a registrar.
Relevant registry operations in this context are:

 .  Registration of a new domain,
 .  Extension of an existing domain,
 .  Auto-Renew of an existing domain;
 .  Transfer of an existing domain, and
 .  Deletion of an existing domain.

Extension of a registration period is accomplished using the RRP RENEW command
or by auto-renewal; registration is accomplished using the RRP ADD command;
deletion/removal is accomplished using the RRP DEL command; and transfer is
accomplished using the RRP TRANSFER command or, where ICANN approves a bulk
transfer under Part B of Exhibit B to the Registry-Registrar Agreement, using
the procedures specified in that Part.

There are four grace periods provided by the VGRS Shared Registration System:
Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period, and
Transfer Grace Period.

A Pending Period refers to a specified number of calendar days following a
Registry operation in which final Registry action is deferred before the
operation may be completed.  Relevant Registry operations in this context are:

 .  Transfer of an existing domain, and
 .  Deletion of an existing domain.

     2. Grace Periods

           2.1  Add Grace Period

The Add Grace Period is a specified number of calendar days following the
initial registration of a domain.  The current value of the Add Grace Period for
all registrars is

                                       68
<PAGE>

five calendar days. If a Delete, Extend (RRP Command Renew), or Transfer
operation occurs within the five calendar days, the following rules apply:

     Delete.  If a domain is deleted within the Add Grace Period, the sponsoring
     Registrar at the time of the deletion is credited for the amount of the
     registration.  The domain is deleted from the Registry database and is
     immediately available for registration by any Registrar.  See Section 3 for
     a description of overlapping grace period exceptions.

     Extend (RRP Command "Renew").  If a domain is extended within the Add Grace
     Period, there is no credit for the add.  The account of the sponsoring
     Registrar at the time of the extension will be charged for the initial add
     plus the number of years the registration is extended.  The expiration date
     of the domain is extended by the number of years, up to a total of ten
     years, as specified by the registrar's requested Extend operation.

     Transfer (other than ICANN-approved bulk transfer).  Transfers under Part A
     of Exhibit B to the Registry-Registrar Agreement may not occur during the
     Add Grace Period or at any other time within the first 60 days after the
     initial registration.  Enforcement is the responsibility of the Registrar
     sponsoring the domain name registration and is currently enforced by the
     SRS.

     Bulk Transfer (with ICANN approval).  Bulk transfers with ICANN approval
     may be made during the Add Grace Period according to the procedures in Part
     B of Exhibit B to the Registry-Registrar Agreement.  The expiration dates
     of transferred registrations are not affected.  The losing Registrar's
     account is charged for the initial add.

2.2  Renew/Extend Grace Period

The Renew/Extend Grace Period is a specified number of calendar days following
the renewal/extension of a domain name registration period through an RRP
Command Renew.  The current value of the Renew/Extend Grace Period is five
calendar days.  If a Delete, Extend, or Transfer occurs within that five
calendar days, the following rules apply:

     Delete. If a domain is deleted within the Renew/Extend Grace Period, the
     sponsoring Registrar at the time of the deletion receives a credit of the
     renew/extend fee.  The domain is deleted from the Registry database and is
     immediately available for registration by any Registrar.  See Section 3 for
     a description of overlapping grace period exceptions.

     Extend (RRP Command "Renew").  A domain can be extended within the
     Renew/Extend Grace Period for up to a total of ten years.  The account of
     the sponsoring Registrar at the time of the additional extension will be
     charged for the additional number of years the registration is extended.

                                       69
<PAGE>

     Transfer (other than ICANN-approved bulk transfer). If a domain is
     transferred within the Renew/Extend Grace Period, there is no credit.  The
     expiration date of the domain is extended by one year and the years added
     as a result of the Extend remain on the domain name up to a total of 10
     years.

     Bulk Transfer (with ICANN approval).  Bulk transfers with ICANN approval
     may be made during the Renew/Extend Grace Period according to the
     procedures in Part B of Exhibit B to the Registry-Registrar Agreement.  The
     expiration dates of transferred registrations are not affected.  The losing
     Registrar's account is charged for the Renew/Extend operation.

2.3  Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days following an
auto-renewal.  An auto-renewal occurs if a domain name registration is not
renewed by the expiration date; in this circumstance the registration will be
automatically renewed by the system the first day after the expiration date. The
current value of the Auto-Renew Grace Period is 45 calendar days.  If a Delete,
Extend, or Transfer occurs within the Auto-Renew Grace Period, the following
rules apply:

     Delete. If a domain is deleted within the Auto-Renew Grace Period, the
     sponsoring Registrar at the time of the deletion receives a credit of the
     Auto-Renew fee.  The domain is deleted from the Registry database and is
     immediately available for registration by any Registrar.  See Section 3 for
     a description of overlapping grace period exceptions.

     Extend (RRP Command "Renew").  A domain can be extended within the Auto-
     Renew Grace Period for up to a total of ten years.  The account of the
     sponsoring Registrar at the time of the additional extension will be
     charged for the additional number of years the registration is extended.

     Transfer (other than ICANN-approved bulk transfer). If a domain is
     transferred under Part A of Exhibit B to the Registry-Registrar Agreement
     within the Auto-Renew Grace Period, the losing Registrar is credited with
     the Auto-Renew charge and the year added by the Auto-Renew operation is
     cancelled.  The expiration date of the domain is extended by one year up to
     a total maximum of ten by virtue of the transfer and the gaining Registrar
     is charged for that additional year, even in cases where a full year is not
     added because of the 10-year maximum limitation.

     Bulk Transfer (with ICANN approval).  Bulk transfers with ICANN approval
     may be made during the Auto-Renew Grace Period according to the procedures
     in Part B of Exhibit B to the Registry-Registrar Agreement.  The expiration
     dates of transferred registrations are not affected.  The losing
     Registrar's account is charged for the Auto-Renew.

                                       70
<PAGE>

          2.4  Transfer Grace Period

The Transfer Grace Period is a specified number of calendar days following the
transfer of a domain according to Part A of Exhibit B to the Registry-Registrar
Agreement.  The current value of the Transfer Grace Period is five calendar
days.  If a Delete, Extend, or Transfer occurs within that five calendar days,
the following rules apply:

     Delete. If a domain is deleted within the Transfer Grace Period, the
     sponsoring Registrar at the time of the deletion receives a credit of the
     transfer fee.  The domain is deleted from the Registry database and is
     immediately available for registration by any Registrar.  See Section 3 for
     a description of overlapping grace period exceptions.

     Extend (RRP Command "Renew").  If a domain is extended within the Transfer
     Grace Period, there is no credit for the transfer.  The Registrar's account
     will be charged for the number of years the registration is extended.  The
     expiration date of the domain is extended by the number of years, up to a
     maximum of ten years, as specified by the registrar's requested Extend
     operation.

     Transfer (other than ICANN-approved bulk transfer). If a domain is
     transferred within the Transfer Grace Period, there is no credit.  The
     expiration date of the domain is extended by one year up to a maximum term
     of ten years.

     Bulk Transfer (with ICANN approval).  Bulk transfers with ICANN approval
     may be made during the Transfer Grace Period according to the procedures in
     Part B of Exhibit B to the Registry-Registrar Agreement.  The expiration
     dates of transferred registrations are not affected.  The losing
     Registrar's account is charged for the Transfer operation that occurred
     prior to the Bulk Transfer.

2.5  Bulk Transfer Grace Period

There is no grace period associated with Bulk Transfer operations according to
Part B of Exhibit B to the Registry-Registrar Agreement.  Upon completion of the
Bulk Transfer, any associated fee is not refundable.

     3.  Overlapping Grace Periods

If an operation is performed that falls into more that one grace period, the
actions appropriate for each grace period apply (with some exceptions as noted
below).

 .  If a domain is deleted within the Add Grace Period and the Extend Grace
   Period, then the Registrar is credited the registration and extend amounts,
   taking into account the number of years for which the registration and extend
   were done.

                                       71
<PAGE>

 .  If a domain is auto-renewed, then extended, and then deleted within the
   Extend Grace Period, the registrar will be credited for the Auto-Renew and
   the number of years for the extension.

               3.1  Overlap Exception

 .  If a domain is deleted within one or several Transfer Grace Periods, then
   only the current sponsoring Registrar is credited for the transfer amount.
   For example if a domain is transferred from Registrar A to Registrar B and
   then to Registrar C and finally deleted by Registrar C within the Transfer
   Grace Period of the first, second and third transfers, then only the last
   transfer is credited to Registrar C.

 .  If a domain is extended (through the RRP command "Renew") within the Transfer
   Grace Period, then the current Registrar's account is charged for the number
   of years the registration is extended.

Note: If several billable operations, including transfers, are performed on a
domain and the domain is deleted within the grace periods of each of those
operations, only those operations that were performed after the latest transfer,
including the latest transfer, are credited to the current Registrar.

       4.   Pending Periods

               4.1   Transfer Pending Period

The Transfer Pending Period is a specified number of calendar days following a
request from a registrar (registrar A) to transfer a domain in which the current
registrar of the domain (registrar B) may explicitly approve or reject the
transfer request.  The current value of the Transfer Pending Period is five
calendar days for all registrars.  The transfer will be finalized upon receipt
of explicit approval or rejection from the current registrar (registrar B).  If
the current registrar (registrar B) does not explicitly approve or reject the
request initiated by registrar A, the registry will approve the request
automatically after the end of the Transfer Pending Period.  During the Transfer
Pending Period:

   a.  RRP TRANSFER request or RRP RENEW request is denied.
   b.  AUTO-RENEW is allowed.
   c.  RRP DELETE request is denied.
   d.  Bulk Transfer operations are allowed.

               4.2  Delete Pending Period

The Delete Pending Period is a specified number of calendar days following a
request to delete a domain in which the domain is placed in REGISTRY-HOLD status
without removing the domain from the Registry database.  The current value of
the Delete

                                       72
<PAGE>

Pending Period for all registrars is five calendar days. Registrars may request
retraction of a Delete request by calling the VGRS Customer Support staff within
the Delete Pending Period. Retraction requests processed during the Delete
Pending Period will be at no cost to the registrar. If no action is taken within
the Delete Pending Period, the domain will be deleted from the Registry database
and returned to the pool of domain names available for registration by any
Registrar. During the Delete Pending Period:

   a.  RRP RENEW or AUTO-RENEW request is ignored.
   b.  RRP TRANSFER request is denied.
   c.  Bulk Transfer operations are allowed.

                                       73
<PAGE>

  4.  Nameserver functional specifications
      ------------------------------------

  Nameserver operations for the Registry TLD shall comply with RFC 1034, 1035,
  and 2182.

                                       74
<PAGE>

 5.  Patch, update, and upgrade policy
     ---------------------------------

VeriSign Global Registry Services (VGRS) may issue periodic patches, updates or
upgrades to the Software, RRP or APIs ("Licensed Product") licensed under the
Registry-Registrar Agreement (the "Agreement") that will enhance functionality
or otherwise improve the Shared Registration System under the Agreement. For the
purposes of this Part 5 of Appendix C, the following terms have the associated
meanings set forth herein. (1) A "Patch" means minor modifications to the
Licensed Product made by VGRS during the performance of error correction
services. A Patch does not constitute a Version. (2) An "Update" means a new
release of the Licensed Product which may contain error corrections, minor
enhancements, and, in certain circumstances, major enhancements, and which is
indicated by a change in the digit to right of the decimal point in the version
number of the Licensed Product. (3) An "Upgrade" means a new release of the
Licensed Product which involves the addition of substantial or substantially
enhanced functionality and which is indicated by a change in the digit to the
left of the decimal point in the version of the Licensed Product. (4) A
"Version" means the Licensed Product identified by any single version number.
Each Update and Upgrade causes a change in Version. Patches do not require
corresponding changes to client applications developed, implemented, and
maintained by each registrar. Updates may require changes to client applications
by each registrar in order to take advantage of the new features and/or
capabilities and continue to have access to the Shared Registration System.
Upgrades require changes to client applications by each registrar in order to
take advantage of the new features and/or capabilities and continue to have
access to the Shared Registration System.

VGRS, in its sole discretion, will deploy Patches during scheduled and announced
Shared Registration System maintenance periods.

For Updates and Upgrades, VGRS will give each registrar notice prior to
deploying the Updates and Upgrades into the production environment.  The notice
shall be at least sixty (60) days, except that if ICANN's registry agreements
with all other unsponsored TLDs provide that the operators of those TLDs will
provide at least ninety (90) days' notice, then VGRS will provide at least
ninety (90) days' notice.  Such notice (whether 60 or 90 days) will include an
initial thirty (30) days' notice before deploying the Update that requires
changes to client applications or the Upgrade into the Operational Test and
Evaluation ("OT&E") environment to which all registrars have access. VGRS will
maintain the Update or Upgrade in the OT&E environment for at least thirty (30)
days, to allow each registrar the opportunity to modify its client applications
and complete testing, before implementing the new code in the production
environment.

                                       75
<PAGE>

6. Migration to provreg standard

VeriSign Global Registry Services (VGRS) is committed to participating in and
supporting the work of the IETF's provreg working group.  VeriSign intends to
migrate the current Shared Registration System to the new standard if: (1) The
IETF working group defines a protocol standard; (2) the standard can be
implemented in a way that minimizes disruption to customers; and (3) the
standard provides a solution for which the potential advantages are reasonably
justifiable when weighed against the costs that VGRS and its registrar customers
would incur in implementing the new standard.

                                       76
<PAGE>

                                                                      Appendix D
                                                                      ----------


                          Performance Specifications



------------------------------------------------------------------------------
Monthly Metric                               Requirement
------------------------------------------------------------------------------
Total outage                                 8 hours
------------------------------------------------------------------------------
Unplanned outage                             4 hours
------------------------------------------------------------------------------
Major upgrade outage                         12 hours
------------------------------------------------------------------------------
Check domain average                         3 seconds
------------------------------------------------------------------------------
Add domain average                           5 seconds
------------------------------------------------------------------------------

Notes:

  .  Two "Major Upgrades" per year are allowed, each of which may last 12 hours.
  .  Registry Operator and ICANN will discuss in good faith addition of
     appropriate metrics for nameserver packet loss and round-trip times.

                                       77
<PAGE>

                                                                      Appendix E
                                                                      ----------

                         Service Level Agreement (SLA)

The VeriSign, Inc. ("VeriSign") Registry strives to provide a world-class level
of service to its customers.   This Service Level Agreement provides metrics and
remedies to measure performance of the VeriSign Registry and to provide
accredited and licensed Registrars with credits for certain substandard
performance by the VeriSign Registry under the parties' Registrar License and
Agreement.

A) DEFINITIONS:

   1)  Monthly Timeframe shall mean each single calendar month beginning and
       ending at 0000 Greenwich Mean Time (GMT).

   2)  Planned Outage shall mean the periodic pre-announced occurrences when the
       SRS will be taken out of service for maintenance or care. Planned Outages
       will be scheduled only during the following window period of time each
       week, 0100 to 0900 GMT on Sunday (the "Planned Outage Period"). This
       Planned Outage Period may be changed from time to time by the VeriSign
       Registry, in its sole discretion, upon prior notice to each Registrar.
       Planned Outages will not exceed 4 hours per calendar week beginning at
       12:00 am GMT Monday nor total more than 8 hours/per month.
       Notwithstanding the foregoing, each year VeriSign may incur 2 additional
       Planned Outages of up to 12 hrs in duration during the Planned Outage
       Period for major systems or software upgrades ("Extended Planned
       Outages"). These Extended Planned Outages represent total allowed Planned
       Outages for the month.

   3)  Shared Registration System ("SRS") Availability shall mean when the SRS
       is operational. By definition, this does not include Planned Outages or
       Extended Planned Outages.

   4)  SRS Unavailability shall mean when, as a result of a failure of systems
       within the VeriSign Registry's control, the Registrar is unable to
       either:

          a)   establish a session with the SRS gateway which shall be defined
               as:

                    1)   successfully complete a TCP session start,

                    2)   successfully complete the SSL authentication handshake,
                         and

                    3)   successfully complete the registry registrar protocol
                         ("RRP") session command.

          b)   execute a 3 second average round trip for 95% of the RRP check
               domain commands and/or less than 5 second average round trip for
               95% of the RRP add domain commands, from the SRS Gateway, through
               the SRS system, back to the SRS Gateway as measured during each
               Monthly Timeframe.

                                       78
<PAGE>

  5)  Unplanned Outage Time shall mean all of the following:

          a)   the amount of time recorded between a trouble ticket first being
               opened by the VeriSign Registry in response to a Registrar's
               claim of SRS Unavailability for that Registrar through the time
               when the Registrar and VeriSign Registry agree the SRS
               Unavailability has been resolved with a final fix or a temporary
               work around, and the trouble ticket has been closed. This will be
               considered SRS Unavailability only for those individual
               Registrars impacted by the outage.
          b)   the amount of time recorded between a trouble ticket first being
               opened by the VeriSign Registry in the event of SRS
               Unavailability that affects all Registrars through the time when
               the Registry resolves the problem with a final fix or a temporary
               work around, and the trouble ticket has been closed.
          c)   the amount of time that Planned Outage time exceeds the limits
               established in A.2 above.
          d)   the amount of time that Planned Outage time occurs outside the
               window of time established in A.2 above.

  6)  Monthly Unplanned Outage Time shall be the sum of minutes of all Unplanned
      Outage Time during the Monthly Timeframe. Each minute of Unplanned Outage
      Time subtracts from the available Monthly Planned Outage Time up to 4
      hours.

  7)  WHOIS Service shall mean the VeriSign Registry Whois server running on
      port 43 of whois.crsnic.net and whois.verisign-grs.net.

  8)   Global Top Level Domain ("GTLD") Name Server shall mean any GTLD Name
       Server under SLD GTLD-SERVERS.NET (e.g. A.GTLD-SERVERS.NET).

B) RESPONSIBILITIES OF THE PARTIES

  1)   Registrar must report each occurrence of alleged SRS Unavailability to
       the VeriSign Registry customer service help desk in the manner required
       by the VeriSign Registry (i.e., e-mail, fax, telephone) in order for an
       occurrence to be treated as SRS Unavailability for purposes of the SLA.

  2)   In the event that all Registrars are affected by SRS Unavailability, the
       VeriSign Registry is responsible for opening a blanket trouble ticket and
       immediately notifying all Registrars of the trouble ticket number and
       details.

  3)   Both Registrar and the VeriSign Registry agree to use reasonable
       commercial good faith efforts to establish the cause of any alleged SRS
       Unavailability. If it is mutually determined to be a VeriSign Registry
       problem, the issue will become part of the Unplanned Outage Time.

  4)   VeriSign Registry will perform monitoring from at least two external
       locations as a means to verify that a) sessions can effectively be
       established and b) all RRP commands can be successfully completed.

  5)   Registrar must inform the VeriSign Registry any time its estimated volume
       of transactions (excluding check domain commands), will exceed
       Registrar's previous month's volume by more than 25%. In the event that
       Registrar fails to inform VeriSign Registry of a forecasted increase of
       volume of transactions of 25% or more and the Registrar's volume
       increases 25% or more over the previous month, and should the total

                                       79
<PAGE>

       volume of transactions added by the VeriSign Registry for all Registrars
       for that month exceed the VeriSign Registry's actual volume of the
       previous month's transactions by more than 20%, then Registrar will not
       be eligible for any SLA credits (as defined in section C) in that Monthly
       Timeframe. The Registrar shall provide such forecast at least 30 days
       prior to the first day of the next month. In addition, the VeriSign
       Registry agrees to provide monthly transaction summary reports.

  6)   The VeriSign Registry will notify Registrar of Planned Outages outside
       the Planned Outage Period at least 7 days in advance of such Planned
       Outage. In addition, VeriSign Registry will use reasonable commercial
       good faith efforts to maintain an accurate 30-day advance schedule of
       possible upcoming Planned Outages.

  7)   The VeriSign Registry will update the WHOIS Service once per day
       beginning at 1200 GMT. The VeriSign Registry will notify Registrars in
       advance when changes to the WHOIS Service update schedule occur.

  8)   The VeriSign Registry will allow external monitoring of the SRS via an
       acceptable means to both parties.

  9)   The VeriSign Registry will initiate the Registry zone file transfer
       process twice daily at 1000 GMT and 2200 GMT. The VeriSign Registry will
       notify Registrar in advance when changes to the schedule occur. The
       VeriSign Registry will notify Registrars regarding any scheduled
       maintenance and unavailability of the GTLD ROOT-SERVERs.

  10)  The VeriSign Registry will use commercial reasonable efforts to restore
       the critical systems of the SRS within 24 hours in the event of a force
       majeure and restore full system functionality within 48 hours. Outages
       due to a force majeure will not be considered SRS Unavailability.

  11)  The VeriSign Registry will publish weekly system performance and
       availability reports. These reports will include average round trip for
       the RRP Check and RRP Add Domain commands for all Registrars as well as a
       summary of SRS Availability for the previous week

  12)  The VeriSign Registry will provide a 99.4% SRS Availability during each
       Monthly Timeframe.

C) CREDITS:

  1)   If SRS Availability is less than 99.4% in any Monthly Timeframe, the
       VeriSign Registry will provide a credit to affected Registrar(s) who have
       complied with Sections B.1 and B.5 above as follows:

       (i)  In the case of SRS Unavailability as described in A.4.b, a credit
       will be given for the combined % total RRP add and check commands that
       fall below the 95% performance threshold established in A.4.b. For each
       affected Registrar, this will be calculated by multiplying the % below
       95% by Registrar's monthly Add Domain volume x the average initial
       registration price charged to that Registrar during the month. The
       maximum credit to each Registrar shall not exceed 5% of the Registrar's
       total monthly Add Domain volume x that average registration price.

                                       80
<PAGE>

          (ii) In the case of SRS Unavailability as described in A.4.a, and
          following the Monthly Timeframe when the Unplanned Outage began,
          VeriSign Registry will provide a credit to Registrar by multiplying
          Registrar's monthly Add Domain volume x the average initial
          registration price charged to that Registrar during the month and
          multiplying that product by the percentage of time that the Monthly
          Unplanned Outage Time exceeded 0.6% of the minutes in the Monthly
          Timeframe. The maximum credit to each Registrar under this
          subparagraph shall not exceed 10% of the Registrar's total monthly Add
          Domain volume x that average registration price.

          Under no circumstances shall credits be applied when the availability
          problems are caused by network providers and/or the systems of
          individual Registrars.

D) MISCELLANEOUS:

     1)   As an addendum to the Registry-Registrar Agreement (RRA), no provision
          in this addendum is intended to replace any term or condition in the
          RRA.

     2)   Dispute Resolution will be handled per RRA Section 6.7.

     3)   Any interruption of SRS service that occurs, as a direct result of RRA
          Sections 2.12,, 5.4, or 6.3 or any other applicable RRA contract term,
          will not be determined SRS Unavailability per this SLA.

                                       81
<PAGE>

                                                                      Appendix F
                                                                      ----------
                          Registry-Registrar Agreement

Note:  The notice period in Section 3.3 shall be ninety (90) days only if a
notice period for implementation of material changes to the Registry-Registrar
Protocol, Application Program Interfaces, or reference client software applies
to all unsponsored TLDs under Registry Agreement with ICANN.  Otherwise, the
notice period of Section 3.3 shall be sixty (60) days.

********************************************************************************

REGISTRY-REGISTRAR AGREEMENT

This Registry-Registrar Agreement (the "Agreement") is dated as of __________,
____ ("Effective Date") by and between VeriSign, Inc., a Delaware corporation,
with a place of business located at 21345 Ridgetop Circle, Dulles, , Virginia
20166 ("VGRS"), and _________________, a _____________________ corporation, with
its principal place of business located at ___________________________________
("Registrar"). VeriSign and Registrar may be referred to individually as a
"Party" and collectively as the "Parties."

WHEREAS, multiple registrars provide Internet domain name registration services
within the .net top-level domain wherein VGRS operates and maintains certain TLD
servers and zone files;

WHEREAS, Registrar wishes to register second-level domain names in the multiple
registrar system for the .net TLD.

NOW, THEREFORE, for and in consideration of the mutual promises, benefits and
covenants contained herein and for other good and valuable consideration, the
receipt, adequacy and sufficiency of which are hereby acknowledged, VGRS and
Registrar, intending to be legally bound, hereby agree as follows:

1. DEFINITIONS
   -----------

1.1. "DNS" refers to the Internet domain name system.

1.2.  "ICANN" refers to the Internet Corporation for Assigned Names and Numbers.

1.3. "IP" means Internet Protocol.

1.4  "Registered Name" refers to a domain name within the domain of the Registry
TLD, whether consisting of two or more (e.g., john.smith.name) levels, about
which VGRS or an affiliate engaged in providing registry services maintains data
in a registry database, arranges for such maintenance, or derives revenue from
such maintenance. A name in

                                       82
<PAGE>

a registry database may be a Registered Name even though it does not appear in a
TLD zone file (e.g., a registered but inactive name).

1.5  "Registry TLD" means the .net TLD.

1.6. The "System" refers to the multiple registrar system operated by VGRS for
registration of Registered Names in the Registry TLD.

1.7. A "TLD" is a top-level domain of the DNS.

1.8. The "Licensed Product" refers to the RRP, APIs, and software, collectively.

2. OBLIGATIONS OF THE PARTIES
   --------------------------

2.1. System Operation and Access. Throughout the Term of this Agreement, VGRS
     ---------------------------
shall operate the System and provide Registrar with access to the System
enabling Registrar to transmit domain name registration information for the
Registry TLD to the System according to a protocol developed by VGRS and known
as the Registry Registrar Protocol ("RRP").

2.2. Distribution of RRP, APIs and Software. No later than three business days
     --------------------------------------
after the Effective Date of this Agreement, VGRS shall provide to Registrar (i)
full documentation of the RRP, (ii) "C" and "Java" application program
interfaces ("APIs") to the RRP with documentation, and (iii) reference client
software ("Software") that will enable Registrar to develop its system to
register second-level domain names through the System for the Registry TLD. If
VGRS elects to modify or upgrade the APIs and/or RRP, VGRS shall provide updated
APIs to the RRP with documentation and updated Software to Registrar promptly as
such updates become available.

2.3. Registrar Responsibility for Customer Support. Registrar shall be
     ---------------------------------------------
responsible for providing customer service (including domain name record
support), billing and technical support, and customer interface to accept
customer (the "Registered Name holder") orders.

2.4. Data Submission Requirements. As part of its registration of all Registered
     ----------------------------
Name registrations in the Registry TLD during the Term of this Agreement,
Registrar shall submit the following data elements using the RRP concerning
Registered Name registrations it processes:

     2.4.1. The Registered Name being registered;

     2.4.2. The IP addresses of the primary nameserver and secondary
     nameserver(s) for the Registered Name;

     2.4.3. The corresponding host names of those nameservers;

                                       83
<PAGE>

     2.4.4. Unless automatically generated by the registry system, the identity
     of the registrar;

     2.4.5. Unless automatically generated by the registry system, the
     expiration date of the registration; and

     2.4.6. Other data required as a result of further development of the
     registry system by the Registry.

2.5. License. Registrar grants VGRS as Registry a non-exclusive non-transferable
     -------
limited license to the data elements consisting of the Registered Name, the IP
addresses of nameservers, and the identity of the registering registrar for
propagation of and the provision of authorized access to the TLD zone files.

2.6. Registrar's Registration Agreement and Domain Name Dispute Policy.
     -----------------------------------------------------------------
Registrar shall have developed and employ in its domain name registration
business an electronic or paper registration agreement, including a domain name
dispute policy, a copy of which is attached to this Agreement as Exhibit A
(which may be amended from time to time by Registrar, provided a copy is
furnished to VGRS three (3) business days in advance of any such amendment), to
be entered into by Registrar with each Registered Name holder as a condition of
registration. Registrar shall include terms in its agreement with each
Registered Name holder that are consistent with Registrar's duties to VGRS
hereunder.

2.7. Secure Connection. Registrar agrees to develop and employ in its domain
     -----------------
name registration business all necessary technology and restrictions to ensure
that its connection to the System is secure. All data exchanged between
Registrar's system and the System shall be protected to avoid unintended
disclosure of information. Each RRP session shall be authenticated and encrypted
using two-way secure socket layer ("SSL") protocol. Registrar agrees to
authenticate every RRP client connection with the System using both an X.509
server certificate issued by a commercial Certification Authority identified by
the Registry and its Registrar password, which it shall disclose only to its
employees with a need to know. Registrar agrees to notify Registry within four
hours of learning that its Registrar password has been compromised in any way or
if its server certificate has been revoked by the issuing Certification
Authority or compromised in any way.

2.8. Domain Name Lookup Capability. Registrar agrees to employ in its domain
     -----------------------------
name registration business VGRS's registry domain name lookup capability to
determine if a requested domain name is available or currently unavailable for
registration.

2.9. Transfer of Sponsorship of Registrations. Registrar agrees to implement
     ----------------------------------------
transfers of Registered Name registrations from another registrar to Registrar
and vice versa pursuant to the Policy on Transfer of Sponsorship of
Registrations Between Registrars appended hereto as Exhibit B.

                                       84
<PAGE>

2.10. Time. Registrar agrees that in the event of any dispute concerning the
      ----
time of the entry of a domain name registration into the registry database, the
time shown in the VGRS records shall control.

2.11. Compliance with Terms and Conditions. Registrar agrees to comply with all
      ------------------------------------
other reasonable terms or conditions established from time to time, to assure
sound operation of the System, by VGRS in a non-arbitrary manner and applicable
to all registrars, including affiliates of VGRS, and consistent with VGRS's
Cooperative Agreement with the United States Government or VGRS's Registry
Agreement with ICANN, as applicable, upon VGRS's notification to Registrar of
the establishment of those terms and conditions.

2.12. Resolution of Technical Problems. Registrar agrees to employ necessary
      --------------------------------
employees, contractors, or agents with sufficient technical training and
experience to respond to and fix all technical problems concerning the use of
the RRP and the APIs in conjunction with Registrar's systems. Registrar agrees
that in the event of significant degradation of the System or other emergency,
VGRS may, in its sole discretion, temporarily suspend access to the System. Such
temporary suspensions shall be applied in a nonarbitrary manner and shall apply
fairly to any registrar similarly situated, including affiliates of VGRS.

2.13. Surety Instrument. During the Initial Term and any Renewal Terms,
      -----------------
Registrar shall have in place a performance bond, letter of credit or equivalent
instrument (the "Surety Instrument") from a surety acceptable to VGRS, in the
amount of $100,000 U.S. dollars. (A single such Surety Instrument shall satisfy
this obligation and Registrar's obligations under similar provisions of other
Registry-Registrar Agreements between Registrar and VGRS.)  The terms of the
Surety Instrument shall indemnify and hold harmless VGRS and its employees,
directors, officers, representatives, agents and affiliates from all costs and
damages (including reasonable attorneys' fees) which it may suffer by reason of
Registrar's failure to indemnify VGRS as provided in Section 6.16 by making
payment(s) up to the full amount of the bond within ten (10) days of VGRS's
having notified the surety of its claim(s) of damages, having identified the
basis for any such claim. VGRS shall not be entitled to payment under the Surety
Instrument until such time as it has certified that it has incurred expenses for
which it is entitled to reimbursement in accordance with the provisions of
Section 6.16 of this Agreement.

2.14. Prohibited Domain Name Registrations. Registrar agrees to comply with the
      ------------------------------------
policies of VGRS that will be applicable to all registrars and that will
prohibit the registration of certain domain names in the Registry TLD which are
not allowed to be registered by statute or regulation.

2.15. Indemnification Required of Registered Name Holders. Registrar shall
      ---------------------------------------------------
require each Registered Name holder to indemnify, defend and hold harmless VGRS,
and its directors, officers, employees, agents, and affiliates from and against
any and all claims, damages, liabilities, costs and expenses, including
reasonable legal fees and expenses arising out of or relating to the Registered
Name holder's domain name registration.

                                       85
<PAGE>

3. LICENSE
   -------

3.1. License Grant. Subject to the terms and conditions of this Agreement, VGRS
     -------------
hereby grants Registrar and Registrar accepts a non-exclusive, non-transferable,
worldwide limited license to use for the Term and purposes of this Agreement the
RRP, APIs and Software, as well as updates and redesigns thereof, to provide
domain name registration services in the  Registry TLD only and for no other
purpose. The RRP, APIs and Software, as well as updates and redesigns thereof,
will enable Registrar to register domain names in the Registry TLD with the
Registry on behalf of its Registered Name holders. Registrar, using the RRP,
APIs and Software, as well as updates and redesigns thereof, will be able to
invoke the following operations on the System: (i) check the availability of a
domain name, (ii) register a domain name, (iii) re-register a domain name, (iv)
cancel the registration of a domain name it has registered, (v) update the
nameservers of a domain name, (vi) transfer a domain name from another registrar
to itself with proper authorization, (vii) query a domain name registration
record, (viii) register a nameserver, (ix) update the IP addresses of a
nameserver, (x) delete a nameserver, (xi) query a nameserver, and (xii)
establish and end an authenticated session.

3.2. Limitations on Use. Notwithstanding any other provisions in this Agreement,
     ------------------
except with the written consent of VGRS, Registrar shall not: (i) sublicense the
RRP, APIs or Software or otherwise permit any use of the RRP, APIs or Software
by or for the benefit of any party other than Registrar, (ii) publish,
distribute or permit disclosure of the RRP, APIs or Software other than to
employees, contractors, and agents of Registrar for use in Registrar's domain
name registration business, (iii) decompile, reverse engineer, copy or re-
engineer the RRP, APIs or Software for any unauthorized purpose, or (iv) use or
permit use of the RRP, APIs or Software in violation of any federal, state or
local rule, regulation or law, or for any unlawful purpose.

Registrar agrees to employ the necessary measures to prevent its access to the
System granted hereunder from being used to (i) allow, enable, or otherwise
support the transmission by e-mail, telephone, or facsimile of mass unsolicited,
commercial advertising or solicitations to entities other than Registrar's
customers; or (ii) enable high volume, automated, electronic processes that send
queries or data to the systems of Registry Operator or any ICANN-Accredited
Registrar, except as reasonably necessary to register domain names or modify
existing registrations.

3.3. Changes to Licensed Materials. VGRS may from time to time make
     -----------------------------
modifications to the RRP, APIs or Software licensed hereunder that will enhance
functionality or otherwise improve the System. VGRS will provide Registrar with
at least ninety (90) days notice prior to the implementation of any material
changes to the RRP, APIs or software licensed hereunder.

4. SUPPORT SERVICES
   ----------------

                                       86
<PAGE>

4.1. Engineering Support. VGRS agrees to provide Registrar with reasonable
     -------------------
engineering telephone support (between the hours of 9 a.m. to 5 p.m. local
Herndon, Virginia time or at such other times as may be mutually agreed upon) to
address engineering issues arising in connection with Registrar's use of the
System.

4.2. Customer Service Support. During the Term of this Agreement, VGRS will
     ------------------------
provide reasonable telephone and e-mail customer service support to Registrar,
not Registered Name holders or prospective customers of Registrar, for non-
technical issues solely relating to the System and its operation. VGRS will
provide Registrar with a telephone number and e-mail address for such support
during implementation of the RRP, APIs and Software. First-level telephone
support will be available on a 7-day/24-hour basis. VGRS will provide a web-
based customer service capability in the future and such web-based support will
become the primary method of customer service support to Registrar at such time.

5. FEES
   ----

5.1. Registration Fees.
     -----------------

       (a) Registrar agrees to pay VGRS the non-refundable amounts of US$ 6 for
       each annual increment of an initial domain name registration and US$ 6
       for each annual increment of a domain name re-registration (collectively,
       the "Registration Fees") registered by Registrar through the System.

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

5.2. Change in Registrar Sponsoring Domain Name. Registrar may assume
     ------------------------------------------
sponsorship of an Registered Name holder's existing domain name registration
from another registrar by following the policy set forth in Exhibit B to this
Agreement.

       (a) For each transfer of the sponsorship of a domain-name registration
       under Part A of Exhibit B, Registrar agrees to pay VGRS the renewal
       registration fee associated with a one-year extension, as set forth
       above. The losing registrar's Registration Fees will not be refunded as a
       result of any such transfer.

       (b) For a transfer approved by ICANN under Part B of Exhibit B, Registrar
       agrees to pay VGRS US$ 0 (for transfers of 50,000 names or fewer) or US$
       50,000 (for transfers of more than 50,000 names).

                                       87
<PAGE>

Fees under this Section 5.2 shall be due immediately upon receipt of VGRS's
invoice pursuant to a letter of credit, deposit account, or other acceptable
credit terms agreed by the Parties.

5.3.  Pro-Rata Charges for ICANN Fees.  Registrar agrees to pay to VGRS, within
      -------------------------------
ten (10) days of VGRS's invoice, a portion of any variable registry-level fees
paid by VGRS to ICANN, pro-rated among all registrars sponsoring registrations
in the Registry TLD based on their relative numbers of domain-name registrations
sponsored.

5.4. Non-Payment of Fees. Timely payment of fees owing under this Section 5 is a
     -------------------
material condition of performance under this Agreement. In the event that
Registrar fails to pay its fees within five (5) days of the date when due, VGRS
may stop accepting new registrations and/or delete the domain names associated
with invoices not paid in full from the Registry database and give written
notice of termination of this Agreement pursuant to Section 6.1(b) below.

6. MISCELLANEOUS
   -------------

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 VGRS ceases to operate
     the registry for the Registry TLD. In the event that revisions to VGRS's
     Registry-Registrar 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 Registrar
     may, at its option exercised within fifteen (15) days, terminate this
     Agreement immediately by giving written notice to VGRS.

     (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 VGRS thirty (30) days notice of
     termination.

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

                                       88
<PAGE>

     (e) Termination in the Event that Successor Registry Operator is Named.
         ------------------------------------------------------------------
     This Agreement shall terminate in the event that the U.S. Department of
     Commerce or ICANN, as appropriate, designates another entity to operate the
     registry for the  Registry TLD.

     (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, VGRS will, to the extent it has the authority to do so, 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 VGRS for Registration Fees are current and timely. Immediately upon any
     expiration or termination of this Agreement, Registrar shall (i) transfer
     its sponsorship of Registered Name registrations to another licensed
     registrar(s) of the Registry, in compliance with Exhibit B, Part B, or any
     other procedures established or approved by the U.S. Department of Commerce
     or ICANN, as appropriate, and (ii) either return to VGRS or certify to VGRS
     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.5, 2.6, 6.1(g), 6.2, 6.6, 6.7, 6.10, 6.12,
     6.13, 6.14, and 6.16; (ii) the Registered Name holder's obligations to
     indemnify, defend, and hold harmless VGRS, as stated in Section 2.15; (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 with respect
     to fees incurred 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.

6.2. No Third Party Beneficiaries; Relationship of The Parties. This Agreement
     ---------------------------------------------------------
does not provide and shall not be construed to provide third parties (i.e., non-
parties to this Agreement), including any Registered Name holder, with any
remedy, claim, cause of action or privilege. Nothing in this Agreement shall be
construed as creating an employer-employee or agency relationship, a partnership
or a joint venture between the Parties.

6.3. Force Majeure. Neither Party shall be responsible for any failure to
     -------------
perform any obligation or provide service hereunder because of any Act of God,
strike, work

                                       89
<PAGE>

stoppage, governmental acts or directives, war, riot or civil commotion,
equipment or facilities shortages which are being experienced by providers of
telecommunications services generally, or other similar force beyond such
Party's reasonable control.

6.4. Further Assurances. Each Party hereto shall execute and/or cause to be
     ------------------
delivered to each other Party hereto such instruments and other documents, and
shall take such other actions, as such other Party may reasonably request for
the purpose of carrying out or evidencing any of the transactions contemplated
by this Agreement.

6.5. Amendment in Writing. Any amendment or supplement to this Agreement shall
     --------------------
be in writing and duly executed by both Parties.

6.6. Attorneys' Fees. If any legal action or other legal proceeding (including
     ---------------
arbitration) relating to the performance under this Agreement or the enforcement
of any provision of this Agreement is brought against either Party hereto, the
prevailing Party shall be entitled to recover reasonable attorneys' fees, costs
and disbursements (in addition to any other relief to which the prevailing Party
may be entitled).

6.7. Dispute Resolution; Choice of Law; Venue. The Parties shall attempt to
     ----------------------------------------
resolve any disputes between them prior to resorting to litigation. This
Agreement is to be construed in accordance with and governed by the internal
laws of the Commonwealth of Virginia, United States of America without giving
effect to any choice of law rule that would cause the application of the laws of
any jurisdiction other than the internal laws of the Commonwealth of Virginia to
the rights and duties of the Parties. Any legal action or other legal proceeding
relating to this Agreement or the enforcement of any provision of this Agreement
shall be brought or otherwise commenced in any state or federal court located in
the eastern district of the Commonwealth of Virginia. Each Party to this
Agreement expressly and irrevocably consents and submits to the jurisdiction and
venue of each state and federal court located in the eastern district of the
Commonwealth of Virginia (and each appellate court located in the Commonwealth
of Virginia) in connection with any such legal proceeding.

6.8. Notices. Any notice or other communication required or permitted to be
     -------
delivered to any Party under this Agreement shall be in writing and shall be
deemed properly delivered, given and received when delivered (by hand, by
registered mail, by courier or express delivery service, by e-mail or by
telecopier during business hours) to the address or telecopier number set forth
beneath the name of such Party below, unless party has given a notice of a
change of address in writing:

     if to Registrar:

     __________________________________________
     __________________________________________
     __________________________________________
     __________________________________________

                                       90
<PAGE>

     __________________________________________
     __________________________________________

     with a copy to:

     __________________________________________
     __________________________________________
     __________________________________________
     __________________________________________
     __________________________________________
     __________________________________________

     if to VGRS:

     General Counsel
     VeriSign, Inc.
     1350 Charleston Road
     Mountain View, California 94043
     Telephone: 1/650/961/7500
     Facsimile:1/650/961/8853; and

     Business Affairs Office
     VeriSign Registry
     21345 Ridgetop Circle
     Dulles, Virginia 20166
     Telephone: 1/703/948/3200
     Facsimile: 1/703/421/2129; and

     Deputy General Counsel
     VeriSign, Inc.
     505 Huntmar Park Drive
     Herndon, Virginia 20170
     Telephone: 1/703/742/0400
     Facsimile: 1/703/742/7916

6.9. Assignment/Sublicense. Except as otherwise expressly provided herein, the
     ---------------------
provisions of this Agreement shall inure to the benefit of and be binding upon,
the successors and permitted assigns of the Parties hereto. Registrar shall not
assign, sublicense or transfer its rights or obligations under this Agreement to
any third person without the prior written consent of VGRS.

6.10. Use of Confidential Information. The Parties' use and disclosure of
      -------------------------------
Confidential Information disclosed hereunder are subject to the terms and
conditions of the Parties' Confidentiality Agreement (Exhibit C) that will be
executed contemporaneously with this Agreement. Registrar agrees that the RRP,
APIs and Software are the Confidential Information of VGRS.

                                       91
<PAGE>

6.11. Delays or Omissions; Waivers. No failure on the part of either Party to
      ----------------------------
exercise any power, right, privilege or remedy under this Agreement, and no
delay on the part of either Party in exercising any power, right, privilege or
remedy under this Agreement, shall operate as a waiver of such power, right,
privilege or remedy; and no single or partial exercise or waiver of any such
power, right, privilege or remedy shall preclude any other or further exercise
thereof or of any other power, right, privilege or remedy. No Party shall be
deemed to have waived any claim arising out of this Agreement, or any power,
right, privilege or remedy under this Agreement, unless the waiver of such
claim, power, right, privilege or remedy is expressly set forth in a written
instrument duly executed and delivered on behalf of such Party; and any such
waiver shall not be applicable or have any effect except in the specific
instance in which it is given.

6.12. Limitation of Liability. IN NO EVENT WILL VGRS BE LIABLE TO REGISTRAR FOR
      -----------------------
ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES,
OR ANY DAMAGES RESULTING FROM LOSS OF PROFITS, ARISING OUT OF OR IN CONNECTION
WITH THIS AGREEMENT, EVEN IF VGRS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.

6.13. Construction. The Parties agree that any rule of construction to the
      ------------
effect that ambiguities are to be resolved against the drafting Party shall not
be applied in the construction or interpretation of this Agreement.

6.14. Intellectual Property. Subject to Section 2.5 above, each Party will
      ---------------------
continue to independently own its intellectual property, including all patents,
trademarks, trade names, service marks, copyrights, trade secrets, proprietary
processes and all other forms of intellectual property.

6.15. Representations and Warranties
      ------------------------------

     (a) Registrar. Registrar represents and warrants that: (1) it is a
         ---------
     corporation duly incorporated, validly existing and in good standing under
     the law of the ______________, (2) it has all requisite corporate power and
     authority to execute, deliver and perform its obligations under this
     Agreement, (3) it is, and during the Term of this Agreement will continue
     to be, accredited by ICANN or its successor, pursuant to an accreditation
     agreement dated after November 4, 1999, (4) the execution, performance and
     delivery of this Agreement has been duly authorized by Registrar, (5) no
     further approval, authorization or consent of any governmental or
     regulatory authority is required to be obtained or made by Registrar in
     order for it to enter into and perform its obligations under this
     Agreement, and (6) Registrar's Surety Instrument provided hereunder is a
     valid and enforceable obligation of the surety named on such Surety
     Instrument.

     (b) VGRS. VGRS represents and warrants that: (1) it is a corporation duly
         ----
     incorporated, validly existing and in good standing under the laws of the
     State of Delaware, (2) it has all requisite corporate power and authority
     to execute, deliver

                                       92
<PAGE>

     and perform its obligations under this Agreement, (3) the execution,
     performance and delivery of this Agreement has been duly authorized by
     VGRS, and (4) no further approval, authorization or consent of any
     governmental or regulatory authority is required to be obtained or made by
     VGRS in order for it to enter into and perform its obligations under this
     Agreement.

     (c) Disclaimer of Warranties. The RRP, APIs and Software are provided "as-
         ------------------------
     is" and without any warranty of any kind. VGRS EXPRESSLY DISCLAIMS ALL
     WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT
     LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR
     SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND
     NONINFRINGEMENT OF THIRD PARTY RIGHTS. VGRS DOES NOT WARRANT THAT THE
     FUNCTIONS CONTAINED IN THE RRP, APIs OR SOFTWARE WILL MEET REGISTRAR'S
     REQUIREMENTS, OR THAT THE OPERATION OF THE RRP, APIs OR SOFTWARE WILL BE
     UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE RRP, APIs OR SOFTWARE
     WILL BE CORRECTED. FURTHERMORE, VGRS DOES NOT WARRANT NOR MAKE ANY
     REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE RRP, APIs, SOFTWARE
     OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY,
     RELIABILITY, OR OTHERWISE. SHOULD THE RRP, APIs OR SOFTWARE PROVE
     DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING,
     REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE.

6.16. Indemnification. Registrar, at its own expense and within thirty (30) days
      ---------------
of presentation of a demand by VGRS under this paragraph, will indemnify, defend
and hold harmless VGRS and its employees, directors, officers, representatives,
agents and affiliates, against any claim, suit, action, or other proceeding
brought against VGRS or any affiliate of VGRS based on or arising from any claim
or alleged claim (i) relating to any product or service of Registrar; (ii)
relating to any agreement, including Registrar's dispute policy, with any
Registered Name holder of Registrar; or (iii) relating to Registrar's domain
name registration business, including, but not limited to, Registrar's
advertising, domain name application process, systems and other processes, fees
charged, billing practices and customer service; provided, however, that in any
such case: (a) VGRS provides Registrar with prompt notice of any such claim, and
(b) upon Registrar's written request, VGRS will provide to Registrar all
available information and assistance reasonably necessary for Registrar to
defend such claim, provided that Registrar reimburses VGRS for its actual and
reasonable costs. Registrar will not enter into any settlement or compromise of
any such indemnifiable claim without VGRS's prior written consent, which consent
shall not be unreasonably withheld. Registrar will pay any and all costs,
damages, and expenses, including, but not limited to, reasonable attorneys' fees
and costs awarded against or otherwise incurred by VGRS in connection with or
arising from any such indemnifiable claim, suit, action or proceeding.

                                       93
<PAGE>

6.17. Entire Agreement; Severability. This Agreement, which includes Exhibits A,
      ------------------------------
B, and C, constitutes the entire agreement between the Parties concerning the
subject matter hereof and supersedes any prior agreements, representations,
statements, negotiations, understandings, proposals or undertakings, oral or
written, with respect to the subject matter expressly set forth herein. If any
provision of this Agreement shall be held to be illegal, invalid or
unenforceable, each Party agrees that such provision shall be enforced to the
maximum extent permissible so as to effect the intent of the Parties, and the
validity, legality and enforceability of the remaining provisions of this
Agreement shall not in any way be affected or impaired thereby. If necessary to
effect the intent of the Parties, the Parties shall negotiate in good faith to
amend this Agreement to replace the unenforceable language with enforceable
language that reflects such intent as closely as possible.

IN WITNESS WHEREOF, the Parties hereto have executed this Agreement as of the
date set forth in the first paragraph hereof.

VeriSign, Inc.                              [Registrar]
By:_________________________               By:_________________________
Name:_______________________               Name:_______________________
Title:______________________               Title:______________________

                                       94
<PAGE>

                                   Exhibit A
                                   ---------

     Registrar's Dispute Policy


                [To be supplied from time to time by Registrar]


                                       95
<PAGE>

                                   Exhibit B
                                   ---------
     Policy on Transfer of Sponsorship of Registrations Between Registrars

A.  Holder-Authorized Transfers.
    ---------------------------

Registrar Requirements.

The registration agreement between each Registrar and its Registered Name holder
shall include a provision explaining that a Registered Name holder will be
prohibited from changing its Registrar during the first 60 days after initial
registration of the domain name with the Registrar. Beginning on the 61st day
after the initial registration with the Registrar, the procedures for change in
sponsoring registrar set forth in this policy shall apply. Enforcement shall be
the responsibility of the Registrar sponsoring the domain name registration.

For each instance where an Registered Name holder wants to change its Registrar
for an existing domain name (i.e., a domain name that appears in a particular
top-level domain zone file), the gaining Registrar shall:

     1) Obtain express authorization from an individual who has the apparent
     authority to legally bind the Registered Name holder (as reflected in the
     database of the losing Registrar).

          a) The form of the authorization is at the discretion of each gaining
          Registrar.

          b) The gaining Registrar shall retain a record of reliable evidence of
          the authorization.

     2) In those instances when the Registrar of record is being changed
     simultaneously with a transfer of a domain name from one party to another,
     the gaining Registrar shall also obtain appropriate authorization for the
     transfer. Such authorization shall include, but not be limited to, one of
     the following:

          a) A bilateral agreement between the parties.

          b) The final determination of a binding dispute resolution body.

          c) A court order.

     3) Request, by the transmission of a "transfer" command as specified in the
     Registry Registrar Protocol, that the Registry database be changed to
     reflect the new Registrar.

          a) Transmission of a "transfer" command constitutes a representation
          on the part of the gaining Registrar that:

                                       96
<PAGE>

               (1) the requisite authorization has been obtained from the
               Registered Name holder listed in the database of the losing
               Registrar, and

               (2) the losing Registrar will be provided with a copy of the
               authorization if and when requested.

In those instances when the Registrar of record denies the requested change of
Registrar, the Registrar of record shall notify the prospective gaining
Registrar that the request was denied and the reason for the denial.

Instances when the requested change of sponsoring Registrar may be denied
include, but are not limited to:

     1) Situations described in the Domain Name Dispute Resolution Policy

     2) A pending bankruptcy of the Registered Name holder

     3) Dispute over the identity of the Registered Name holder

     4) Request to transfer sponsorship occurs within the first 60 days after
     the initial registration with the Registrar

In all cases, the losing Registrar shall respond to the e-mail notice regarding
the "transfer" request within five (5) days. Failure to respond will result in a
default "approval" of the "transfer."

Registry Requirements.

Upon receipt of the "transfer" command from the gaining Registrar, VGRS will
transmit an e-mail notification to both Registrars.

VGRS shall complete the "transfer" if either:

     1) the losing Registrar expressly "approves" the request, or

     2) VGRS does not receive a response from the losing Registrar within five
     (5) days.

When the Registry's database has been updated to reflect the change to the
gaining Registrar, VGRS will transmit an email notification to both Registrars.

Records of Registration.

                                       97
<PAGE>

Each Registered Name holder shall maintain its own records appropriate to
document and prove the initial domain name registration date, regardless of the
number of Registrars with which the Registered Name holder enters into a
contract for registration services.

Effect on Term of Registration.

The completion by VGRS of a holder-authorized transfer under this Part A shall
result in a one-year extension of the existing registration, provided that in no
event shall the total unexpired term of a registration exceed ten (10) years.


B.  ICANN-Approved Transfers.
    ------------------------
Transfer of the sponsorship of all the registrations sponsored by one registrar
as the result of acquisition of that registrar or its assets by another
registrar may be made according to the following procedure:

     (a)  The gaining registrar must be accredited by ICANN for the Registry TLD
     and must have in effect a Registry-Registrar Agreement with VGRS for the
     Registry TLD.

     (b)  ICANN must certify in writing to VGRS that the transfer would promote
     the community interest, such as the interest in stability that may be
     threatened by the actual or imminent business failure of a registrar.

Upon satisfaction of these two conditions, VGRS will make the necessary one-time
changes in the registry database for no charge, for transfers involving 50,000
name registrations or fewer. If the transfer involves registrations of more than
50,000 names, VGRS will charge the gaining registrar a one-time flat fee of US$
50,000.

                                       98
<PAGE>

                                   Exhibit C
                                   ---------
                           Confidentiality Agreement

THIS CONFIDENTIALITY AGREEMENT is entered into by and between VeriSign, Inc., a
Delaware corporation, with a place of business located at 21345 Ridgetop Circle,
Dulles, , Virginia 20166 ("VGRS"),  and ________________________, a _________
corporation having its principal place of business in __________________
("Registrar"), through their authorized representatives, and takes effect on the
date executed by the final party (the "Effective Date").

Under this Confidentiality Agreement ("Confidentiality Agreement"), the Parties
intend to disclose to one another information which they consider to be
valuable, proprietary, and confidential.

NOW, THEREFORE, the parties agree as follows:

1. Confidential Information
   ------------------------

     1.1. "Confidential Information", as used in this Confidentiality Agreement,
     shall mean all information and materials including, without limitation,
     computer software, data, information, databases, protocols, reference
     implementation and documentation, and functional and interface
     specifications, provided by the disclosing party to the receiving party
     under this Confidentiality Agreement and marked or otherwise identified as
     Confidential, provided that if a communication is oral, the disclosing
     party will notify the receiving party in writing within 15 days of the
     disclosure.

2. Confidentiality Obligations
   ---------------------------

     2.1. In consideration of the disclosure of Confidential Information, the
     Parties agree that:

          (a) The receiving party shall treat as strictly confidential, and use
          all reasonable efforts to preserve the secrecy and confidentiality of,
          all Confidential Information received from the disclosing party,
          including implementing reasonable physical security measures and
          operating procedures.

          (b) The receiving party shall make no disclosures whatsoever of any
          Confidential Information to others, provided however, that if the
          receiving party is a corporation, partnership, or similar entity,
          disclosure is permitted to the receiving party's officers, employees,
          contractors and agents who have a demonstrable need to know such
          Confidential Information, provided the receiving party shall advise
          such personnel of the confidential nature of the Confidential
          Information and of the procedures required to maintain the
          confidentiality thereof, and shall require them to acknowledge in
          writing that they have read, understand, and

                                       99
<PAGE>

          agree to be individually bound by the terms of this Confidentiality
          Agreement.

          (c) The receiving party shall not modify or remove any Confidential
          legends and/or copyright notices appearing on any Confidential
          Information.

     2.2. The receiving party's duties under this section (2) shall expire five
     (5) years after the information is received or earlier, upon written
     agreement of the Parties.

3. Restrictions On Use
   -------------------

     3.1. The receiving party agrees that it will use any Confidential
     Information received under this Confidentiality Agreement solely for the
     purpose of providing domain name registration services as a registrar and
     for no other purposes whatsoever.

     3.2. No commercial use rights or any licenses under any patent, patent
     application, copyright, trademark, know-how, trade secret, or any other
     VGRS proprietary rights are granted by the disclosing party to the
     receiving party by this Confidentiality Agreement, or by any disclosure of
     any Confidential Information to the receiving party under this
     Confidentiality Agreement.

     3.3. The receiving party agrees not to prepare any derivative works based
     on the Confidential Information.

     3.4. The receiving party agrees that any Confidential Information which is
     in the form of computer software, data and/or databases shall be used on a
     computer system(s) that is owned or controlled by the receiving party.

4. Miscellaneous
   -------------

     4.1. This Confidentiality Agreement shall be governed by and construed in
     accordance with the laws of the Commonwealth of Virginia and all applicable
     federal laws. The Parties agree that, if a suit to enforce this
     Confidentiality Agreement is brought in the U.S. Federal District Court for
     the Eastern District of Virginia, they will be bound by any decision of the
     Court.

     4.2. The obligations set forth in this Confidentiality Agreement shall be
     continuing, provided, however, that this Confidentiality Agreement imposes
     no obligation upon the Parties with respect to information that (a) is
     disclosed with the disclosing party's prior written approval; or (b) is or
     has entered the public domain through no fault of the receiving party; or
     (c) is known by the receiving party prior to the time of disclosure; or (d)
     is independently developed by the receiving party without use of the

                                      100
<PAGE>

     Confidential Information; or (e) is made generally available by the
     disclosing party without restriction on disclosure.

     4.3. This Confidentiality Agreement may be terminated by either party upon
     breach by the other party of any its obligations hereunder and such breach
     is not cured within three (3) calendar days after the allegedly breaching
     party is notified by the disclosing party of the breach. In the event of
     any such termination for breach, all Confidential Information in the
     possession of the Parties shall be immediately returned to the disclosing
     party; the receiving party shall provide full voluntary disclosure to the
     disclosing party of any and all unauthorized disclosures and/or
     unauthorized uses of any Confidential Information; and the obligations of
     Sections 2 and 3 hereof shall survive such termination and remain in full
     force and effect. In the event that the Registrar License and Agreement
     between the Parties is terminated, the Parties shall immediately return all
     Confidential Information to the disclosing party and the receiving party
     shall remain subject to the obligations of Sections 2 and 3.

     4.4. The terms and conditions of this Confidentiality Agreement shall inure
     to the benefit of the Parties and their successors and assigns. The
     Parties' obligations under this Confidentiality Agreement may not be
     assigned or delegated.

     4.5. The Parties agree that they shall be entitled to seek all available
     legal and equitable remedies for the breach of this Confidentiality
     Agreement.

     4.6. The terms and conditions of this Confidentiality Agreement may be
     modified only in a writing signed by VGRS and Registrar.

     4.7. EXCEPT AS MAY OTHERWISE BE SET FORTH IN A SIGNED, WRITTEN AGREEMENT
     BETWEEN THE PARTIES, THE PARTIES MAKE NO REPRESENTATIONS OR WARRANTIES,
     EXPRESSED OR IMPLIED, AS TO THE ACCURACY, COMPLETENESS, CONDITION,
     SUITABILITY, PERFORMANCE, FITNESS FOR A PARTICULAR PURPOSE, OR
     MERCHANTABILITY OF ANY CONFIDENTIAL INFORMATION, AND THE PARTIES SHALL HAVE
     NO LIABILITY WHATSOEVER TO ONE ANOTHER RESULTING FROM RECEIPT OR USE OF THE
     CONFIDENTIAL INFORMATION.

     4.8. If any part of this Confidentiality Agreement is found invalid or
     unenforceable, such part shall be deemed stricken herefrom and the Parties
     agree: (a) to negotiate in good faith to amend this Confidentiality
     Agreement to achieve as nearly as legally possible the purpose or effect as
     the stricken part, and (b) that the remainder of this Confidentiality
     Agreement shall at all times remain in full force and effect.

                                      101
<PAGE>

     4.9. This Confidentiality Agreement contains the entire understanding and
     agreement of the Parties relating to the subject matter hereof.

     4.10. Any obligation imposed by this Confidentiality Agreement may be
     waived in writing by the disclosing party. Any such waiver shall have a
     one-time effect and shall not apply to any subsequent situation regardless
     of its similarity.

     4.11. Neither Party has an obligation under this Confidentiality Agreement
     to purchase, sell, or license any service or item from the other Party.

     4.12. The Parties do not intend that any agency or partnership relationship
     be created between them by this Confidentiality Agreement.

IN WITNESS WHEREOF, and intending to be legally bound, duly authorized
representatives of VGRS and Registrar have executed this Confidentiality
Agreement in Virginia on the dates indicated below.

  ("Registrar")                             VeriSign, Inc. ("VGRS")

  By:                                       By: ___________________________
  __________________________________        Title:_________________________
  Title:                                    Date:__________________________
  __________________________________
  Date:_____________________________


                                      102
<PAGE>

                                                                      Appendix G
                                                                      ----------

                   Registry Operator Maximum Price Schedule


This schedule specifies the maximum price Registry Operator may charge for
Registry Services. In a manner consistent with Subsection 3.4.3 of the Registry
Agreement, Registry Operator may charge a lower-than-specified rate for
services, including not charging for a specified service. Except as set forth
herein or otherwise agreed, Registry Operator shall not be entitled to charge
for any Registry Service not specified in this Appendix G.

1. Maximum Initial Registration Fee for Registered Names

Registry Operator may charge a maximum of US $6.00 per year for registration of
each Registered Name (the "Initial Registration Fee") in the Registry TLD.

2. Maximum Renewal Registration Fee for Registered Names

Registry Operator may charge a maximum of US $6.00 per year for renewal (or
extension) of registration of each Registered Name (the "Renewal Fee") in the
Registry TLD.

3. Fees for Transfers of Sponsorship of Domain-Name Registrations

Registrars may assume sponsorship of a Registered Name holder's existing domain
name registration from another registrar by following the policy set forth in
Exhibit B to Appendix F to the Registry Agreement.

For each transfer of the sponsorship of a domain-name registration under Part A
of Exhibit B, Registry Operator may charge the gaining registrar a maximum fee
equal to the renewal registration fee associated with a one-year extension, as
set forth in item 2 above. The losing registrar's registration fees will not be
refunded as a result of any such transfer.

For a transfer approved by ICANN under Part B of Exhibit B, Registry Operator
may charge the gaining registrar US$ 0 (for transfers of 50,000 names or fewer)
or US$ 50,000 (for transfers of more than 50,000 names).

                                      103
<PAGE>

                                                                      Appendix H
                                                                      ----------
                   VeriSign Equivalent Access Certification

VeriSign, as Registry Operator ("VGRS"), makes the following certification:

          1.   All registrars (including any registrar affiliated with VGRS)
               connect to the Shared Registration System Gateway via the
               Internet by utilizing the same maximum number of IP addresses and
               SSL certificate authentication.

          2.   VGRS has made the current version of the registrar toolkit
               software accessible to all registrars and has made any updates
               available to all registrars on the same schedule.

          3.   All registrars have the same level of access to VGRS customer
               support personnel via telephone, e-mail and the VGRS website.

          4.   All registrars have the same level of access to the VGRS registry
               resources to resolve registry/registrar or registrar/registrar
               disputes and technical and/or administrative customer service
               issues.

          5.   All registrars have the same level of access to VGRS-generated
               data to reconcile their registration activities from VGRS Web and
               ftp servers.

          6.   All registrars may perform basic automated registrar account
               management functions using the same registrar tool made available
               to all registrars by VGRS.

          7.   The Shared Registration System does not include any algorithms or
               protocols that differentiate among registrars with respect to
               functionality, including database access, system priorities and
               overall performance.

          8.   All VGRS-assigned personnel have been directed not to give
               preferential treatment to any particular registrar.

          9.   I have taken reasonable steps to verify that the foregoing
               representations are being complied with.

This Certificat ion is dated this the __ day of __________, _____.
VeriSign, Inc.


By: __________________________
Name: Bruce Chovnick
Title: General Manager, VeriSign Global Registry Services

                                      104
<PAGE>

                   VeriSign Global Registry Services (VGRS)
              Organizational Conflict of Interest Compliance Plan

VGRS has implemented the following organizational, physical and procedural
safeguards to ensure that revenues and assets of VGRS are not utilized to
advantage the registrar business of companies affiliated with VGRS to the
detriment of other competing registrars with regard to Registry Services
provided for the .com, .net, and .org TLDs.  VGRS recognizes the potential for
organizational conflicts of interest ("OCI") between its Registry Services
business and the ICANN-accredited Registrar business associated with VeriSign
and has placed these generally accepted, US Government recognized safeguards in
place to avoid operational issues.

I.  VGRS ORGANIZATIONAL STRUCTURE

In recognition of potential OCI, VeriSign, Inc. established organization
barriers by separating VeriSign's registry business and its registrar business
into separate profit and loss ("P&L") centers, each with its own General
Manager. Each General Manager reports directly to separate division heads who in
turn report directly to the Chief Executive Officer of VeriSign and has
dedicated direct reporting employees in the finance, marketing, engineering,
customer affairs and customer service functions, as appropriate. Each P&L
employee is dedicated to the line of business for which he/she directly works.

The corporate administrative support functions under the Chief Financial
Officer, Customer Experience Officer, Communications Officer, Business and
Corporate Development Officer and Chief Strategy Officer provide support to each
line of business on a cost allocated basis or a dedicated project accounting
basis. These officers and the Chief Executive Officer will be compensated based
on consolidated financial results, versus Registrar or Registry results.

The VGRS General Manager has authority over all operational decisions and is the
business owner of this compliance plan. VGRS employs a Compliance Officer to
administer day-to-day oversight and administration of this plan.

The VeriSign, Inc. General Counsel's office employs an overall OCI compliance
function to oversee corporate adherence to the Plan and to resolve potential
conflicts or actual conflicts among VeriSign functions.

II. FINANCIAL SEPARATION

The registry business accounts for its own costs, revenues, cash flow, etc. as a
separate P&L center, using separate and distinct systems and accounting
functions. Reasonable and independently auditable internal accounting controls
are in place to ensure the adequacy of these systems and functions. The
individual financial statements of each P&L center are then consolidated at the
corporate level for tax and SEC reporting.

                                      105
<PAGE>

III. LOCATION CHANGE

To further separate businesses and, among other things, ensure that the risk of
inadvertent disclosure of sensitive information is effectively mitigated,
VeriSign's Registry and Registrar businesses are located in separate facilities.

IV.  PHYSICAL BARRIERS

Each VeriSign business unit employee has a security badge that will provide
him/her access only to the facility he/she works in and the VeriSign
headquarters facilities. At the VGRS facility, only registry-assigned personnel
("Registry Personnel") and other personnel who are identified to have a
legitimate need for access (excluding "Registrar Personnel") will have regular
badge access to the premises and any other person will be treated as a visitor
to the facility and will gain access only through established visitor sign-in
and identification badge procedures.

V. ACCESS TO THE REGISTRY FACILITY

VGRS provides access to all VGRS customers through the following mechanisms and
separates VGRS systems and information from systems and information of any
affiliated registrar through these processes:

          1.   All registrars (including any registrar affiliated with VGRS)
          connect to the Shared Registration System Gateway via the Internet by
          utilizing the same maximum number of IP addresses and SSL certificate
          authentication.

          2.   All registrars have the same level of access to VGRS-generated
          data to reconcile their registration activities from VGRS Web and ftp
          servers. All registrars may perform basic automated registrar account
          management functions using the same registrar tool made available to
          all registrars by VGRS.

          3.   The Shared Registration System does not include any algorithms or
          protocols that differentiate among registrars with respect to
          functionality, including database access, system priorities and
          overall performance.

          4.   No registrar affiliated with VGRS will be given any access to the
          registry not available to any other registrar except with regard to
          information specific to their registrar.

          5.   Any information needed by registrars regarding the technical
          interface of registry/registrar operations will be made equally
          available to all registrars.

VI. INFORMATION CONTROL

                                      106
<PAGE>

VGRS has in place various procedural safeguards to ensure that data and
information of the registry business are not utilized to advantage the business
of any registrar affiliated with VGRS. VGRS has adopted a policy regarding the
marking, access and dissemination of business sensitive information (Exhibit A).
This policy requires employees to mark all Registry sensitive information as
"Registry Sensitive." Furthermore, the policy requires that all sensitive
information be limited in access and disseminated only to those VGRS Personnel
and other personnel who are identified to have a legitimate "need to know,"
which shall not include personnel assigned by any registrar affiliated with
VGRS. The Registry General Manager maintains a matrix that dictates who can
access particular categories of Registry Sensitive information. All sensitive
information is secured in an appropriate manner to ensure confidentiality and
security. Consent of the Registry General Manager is required prior to release
of financial or statistical information relating to the registry business.

VII. TRAINING

All VGRS Personnel and other employees who have a need to know Registry business
undergo a formal OCI Training Program, developed by the Registry Compliance
Officer, providing the staff members with a clear understanding of this Plan and
the staff members' responsibility under the plan. OCI training is required
before any potential staff member is given an assignment or access to Registry
Sensitive material. OCI refresher training is given on an annual basis.

VIII. NON-DISCLOSURE AGREEMENTS/OCI AVOIDANCE CERTIFICATIONS

Upon completion of the training program, all VGRS Personnel and other employees
who have a need to know registry business (which shall not include personnel
assigned by any registrar affiliated with VGRS), are required to sign a non-
disclosure agreement and a Registry Business OCI Avoidance Certification
acknowledging his/her understanding of the OCI requirements, and certifying that
he/she will strictly comply with the provisions of the OCI Plan. Examples of the
agreement and certification are attached as Exhibits B and C.  The signed
agreements are maintained in the program files and the individual's personnel
file. Each staff member acknowledges verification of the annual refresher
training required by this Plan.

                                      107
<PAGE>

                                   Exhibit A

              Access and Dissemination of Proprietary Information

Introduction

     The purpose of this "Use of Proprietary Information" is to protect
     Sensitive Information of the Registry Business to ensure that the revenue
     and assets of the Registry Business are not utilized to advantage the
     Registrar Business to the detriment of other competing registrars.  This
     document is also designed to establish policies for the protection of
     Proprietary Information developed by and/or in the possession of VeriSign,
     Inc. ("VeriSign").  This policy is applicable to all employees of VeriSign.

Definitions:

     Proprietary Information. Proprietary information includes financial,
     personnel, business or other information owned or possessed by VeriSign
     that has not been authorized for public release.  Proprietary Information
     also includes Technical Data, which is described in detail below.

     Examples of Proprietary Information include:

     A.   Financial information, such as:

          1.   Sales forecast data
          2.   Financial planning data
          3.   Budgets and pricing data, including labor rates, indirect rates
               or pricing guidelines
          4.   Operating or contract performance costs

     B.   Personnel information, such as:

          1.   Employee lists or resumes giving detailed professional background
          2.   Salaries of individual personnel
          3.   Lists of addresses or home telephone numbers of personnel
          4.   Information which would assist a competitor in the
               proselytization of VeriSign
          5.   Information from employees' personnel files
          6.   Medical information concerning individual employees

     C.   Marketing information, such as:

          1.   Specific proposals that VeriSign is submitting or considering
               submitting
          2.   List of customers seeking proposals
          3.   Customer list and contracts

                                      108
<PAGE>

     D.   Corporate Communication, such as:
          1.   Information posted on the Vault
          2.   The Style Guide

     Such information is frequently referred to as "Proprietary Data," "Trade
     Secret," "Confidential Information," "Privileged Information," "Private
     Data," and/or "Unpublished Data."

     (Proprietary Information does not include financial, administrative, cost
     and pricing, and management data, or other information incidental to
     contract administration.)

     Technical Data.  Technical Data is recorded information, regardless of form
     or characteristic, of a scientific or technical nature.  It may, for
     example, document research, experimental, developmental, or engineering
     work; or be usable or used to define a design process; or to procure,
     produce, support, maintain, or operate equipment/material.  The data may be
     graphic or pictorial delineations in media such as drawings or photographs,
     text in specifications or related performance, or design-type documents or
     computer printouts.

     Examples of Technical Data include:

          1.   Research and engineering data,
          2.   Engineering drawings
          3.   Products or process information
          4.   Corporate research plans or research results
          5.   Computer codes/programs
          6.   Internal reports or other work product such as notebooks, charts,
               drawings, notes of your employees and file material which
               employees compiled and used in performing duties as an employee
               of VeriSign.
          7.   Specifications, standards process sheets, manuals, technical
               reports, catalog item identifications and related information,
          8.   Computer software documentation (Computer Software Documentation
               includes computer listings and printouts, in human-readable form
               which (i) documents the design or details of computer software,
               (ii) explains the capabilities of the software, (iii) provides
               instructions for using the software to obtain desired results
               from a computer, or (iv) printed service code)

Registry v. Registrar Information:

     Registry Sensitive information includes Proprietary Information or other
     financial, personnel, technical, or business information owned or possessed
     by VeriSign relating to its Registry business which could be utilized to
     advantage the Registrar business to the detriment of other competing
     registrars.

                                      109
<PAGE>

     Registrar Sensitive information includes Proprietary Information or other
     financial, personnel, technical, or business information owned or possessed
     by VeriSign and/or its wholly owned subsidiaries relating to its Registrar
     business.

     Registry Sensitive information shall not be disclosed to Registrar
     personnel at any time.

     Examples of the distinction between Registry and Registrar information
     include:

          a.   Engineering information, including schematics, code, and
               engineering notes should be considered Registry Sensitive
               information.

          b.   Statistics, such as numbers of registrations, transfers, etc.,
               performed by each registrar, as well as processing times, numbers
               of failures or any information that is trending negative or
               contains negative performance factors not generally available to
               the public should be considered either Registry Sensitive
               information or Registrar Sensitive information, as applicable.
               Unless otherwise approved, registration activity information must
               be protected from disclosure to any registrar other than the
               registrar to which the information refers. Such protection
               extends to precluding VeriSign's Board of Directors, Chief
               Executive Officer, Chief Financial Officer, and the General
               Manager of the Registrar business from access to Registry
               Sensitive information pertaining to any registrar other than that
               owned or controlled by VeriSign.

          c.   Some statistical information will be available for public
               consumption. Such information does not require any special
               treatment, so long as neither the Registrar nor Registry does not
               receive any preferential treatment (e.g., early access to such
               information).

          d.   Financial information and data related to either the Registry or
               Registrar is Sensitive Information and will not be released
               without the express consent of the applicable General Manager,
               Chief Executive Officer or Chief Financial Officer. Monthly
               expenses and income shall be kept sensitive and restricted from
               disclosure to any party other than the appropriate Registry or
               Registrar staff and select members of the company's senior staff.

Procedures for Protection of Proprietary Information:

     Responsibility.  All employees are responsible for identifying Proprietary
     Information, Registry Sensitive information and Registrar Sensitive
     information developed, produced, or possessed by their organizational units
     and for instructing employees reporting to them regarding the proper
     handling and safeguarding of such Proprietary Information.

                                      110
<PAGE>

     Each VeriSign employee should exercise reasonable care to protect
     Proprietary Information, Registry Sensitive information and Registrar
     Sensitive information from unauthorized or inadvertent disclosure.

     Every VeriSign employee must exercise caution and discretion to insure that
     divulging such information will not compromise the competitive position of
     VeriSign nor infringe on personnel information about specific employees.

     Marking of Internal Documents.  Employees should, as a matter of routine,
     mark each document containing Proprietary Information, Registry Sensitive
     information and Registrar Sensitive information with the appropriate legend
     at the time the document is produced.

     Computer tapes and other recorded material should be identified by proper
     labeling which is visible to the ordinary person while the material is
     being stored.  In addition, all such material should have a warning notice
     at the beginning of the material to ensure the user is forewarned about the
     proprietary nature of its contents (as soon as access is afforded to a
     computer tape or at the beginning of a sound recording, etc.).

     For internal documents containing Proprietary Information, the following
     legend should appear on the first page of the document:

                          Copyright (C) 2001 VeriSign, Inc. All rights reserved.

                                                                  VeriSign, Inc.
                                                                   Division Name
                                                     PRIVILEGED AND CONFIDENTIAL
                                      INTERNAL WORKING DOCUMENT [if appropriate]

                                                                          [DATE]

     The following legend should appear at the top of every page of the internal
     document containing Proprietary Information:

                                                VERISIGN PROPRIETARY INFORMATION

                    The information on this document is proprietary to VeriSign.
               It may not be used, reproduced or disclosed without the written
               approval of VeriSign.

     The following legend should appear at the top of every page of the internal
     document containing Registry Sensitive information:

                                                              REGISTRY SENSITIVE

               The information on this document is proprietary to VeriSign and
               the VeriSign Registry business.
                         It may not be used, reproduced or disclosed without the
                         written approval of the
                              General Manager of VeriSign(R) Global Registry
                              Services.

     Not every piece of Proprietary Information in VeriSign's possession must be

                                      111
<PAGE>

     properly marked; for example, salary reviews or medical/insurance records
     do not need to be marked.  Nevertheless, all such documents must be
     protected from unauthorized disclosure.

     Policy Concerning Disclosure and Marking of External Documents.

          a.  Policy Concerning the External Disclosure of Proprietary
          Information

          As a general rule, no employee may disclose Proprietary Information to
          anyone outside of the company.  This general rule applies to business
          associates, affiliates of the company and personal contacts.

          As a general rule, VeriSign employees shall not disclose Proprietary
          Information to other VeriSign employees unless the recipient of the
          information has a "need to know" that information.

          VeriSign recognizes that there are occasions when it is necessary to
          disclose Proprietary Information to individuals who are not VeriSign's
          employees.  Such disclosure must have the prior written approval of
          the appropriate VeriSign manager.

          All documents containing Proprietary Information that are disclosed to
          third parties, must contain the following notice:

                          Copyright (C) 2001 VeriSign, Inc. All rights reserved.

  THIS DOCUMENT CONTAINS PROPRIETARY INFORMATION THAT IS OWNED BY VERISIGN. THIS
     DOCUMENT MAY ONLY BE USED BY THE RECIPIENT FOR THE PURPOSE FOR WHICH IT WAS
      TRANSMITTED. THIS DOCUMENT MUST BE RETURNED UPON REQUEST OR WHEN NO LONGER
  NEEDED BY RECIPIENT. IT MAY NOT BE COPIED OR ITS CONTENTS COMMUNICATED WITHOUT
                                                THE WRITTEN CONSENT OF VERISIGN.

                                          DISCLAIMER AND LIMITATION OF LIABILITY

  VeriSign, Inc. has made efforts to ensure the accuracy and completeness of the
    information in this document. However, VeriSign, Inc. makes no warranties of
any kind (whether express, implied or statutory) with respect to the information
 contained herein. VeriSign, Inc. assumes no liability to any party for any loss
       or damage (whether direct or indirect) caused by any errors, omissions or
     statements of any kind contained in this document.  Further, VeriSign, Inc.
      assumes no liability arising from the application or use of the product or
 service described herein and specifically disclaims any representation that the
      products or services described herein do not infringe upon any existing or
       future intellectual property rights. Nothing herein grants the reader any
   license to make, use, or sell equipment or products constructed in accordance
           with this document. Finally, all rights and privileges related to any
          intellectual property right described herein are vested in the patent,
  trademark, or service mark owner, and no other person may exercise such rights
      without express permission, authority, or license secured from the patent,
      trademark, or service mark owner. VeriSign Inc. reserves the right to make
                       changes to any information herein without further notice.

                                                              NOTICE AND CAUTION
                                     Concerning U.S.  Patent or Trademark Rights

  VeriSign, [insert the specific trademark that is the subject to the material],
    and other trademarks, service marks and logos are registered or unregistered
         trademarks of VeriSign and its subsidiaries in the United States and in
      foreign countries.  The inclusion in this document, the associated on-line

                                      112
<PAGE>

          file, or the associated software of any information covered by any
          other patent, trademark, or service mark rights does not constitute
          nor imply a grant of, or authority to exercise, any right or privilege
          protected by such patent, trademark, or service mark. All such rights
          and privileges are vested in the patent, trademark, or service mark
          owner, and no other person may exercise such rights without express
          permission, authority, or license secured from the patent, trademark,
          or service mark owner.

          As a general rule, all recipients of such information should first
          sign a Non-Disclosure Agreement.  When Proprietary Information is
          exchanged between VeriSign and another company with which VeriSign as
          a business relationship, the parties must execute a Non-Disclosure
          Agreement.

          b.  Policy Concerning the External Disclosure of Registry Sensitive
          Information.

          As a general rule, no employee may disclose Registry Sensitive
          information to anyone outside of the company.  This general rule
          applies to business associates, independent contractors, temporary
          employees, affiliates of the company and personal contacts.

          VeriSign recognizes that there are occasions when it is appropriate to
          disclose Registry Sensitive information to individuals who are not
          VeriSign's employees, such as independent contractors or temporary
          employees.  Such disclosure must have the prior approval of the
          appropriate VeriSign manager.

          No Registry Sensitive information shall be disclosed to any third
          party unless that third party has first agreed to a non-disclosure
          agreement or similar agreement restricting the third party's
          disclosure of the Registry Sensitive information in accordance with
          this policy.

          All documents containing Registry Sensitive information that are
          disclosed to such third parties, must contain the following notice:

          REGISTRY SENSITIVE
          The information on this document is proprietary to VeriSign and the
          VeriSign Registry business. It may not be used, reproduced or
          disclosed without the written approval of the General Manager of
          VeriSign(R) Global Registry Services.

     Procedure for Disclosing Proprietary Information and/or Registry Sensitive
     Information.  The procedure to disclose Proprietary Information is as
     follows:

          a.   affix the appropriate legend on the document
          b.   execute Non-Disclosure Agreement
          c.   send the Proprietary Information through a secure system, such as
               overnight courier
          d.   log or note your disclosure of the information
          e.   maintain a record of and track your disclosures

                                      113
<PAGE>

     Safekeeping:

     When not in use, Proprietary Information should be stored in a locked desk,
     cabinet or file.  Such material should not be left unattended during the
     workday and should be turned face down in the presence of visitors or
     employees who have no need to know.

     Destruction:

     Burning, shredding or comparable methods should be used for the destruction
     of Proprietary Information.

     Terminating Employees:

     Terminating employees should be reminded of their responsibilities and
     obligations in protecting Proprietary Information as outlined in the
     appropriate employee regulations and rules.  Permission to retain such
     information after termination must be in writing and approved by the
     VeriSign's General Counsel prior to removal.

     Third-Party Proprietary Information:

     Proprietary Information received from other companies through contractual
     or precontractual relationships will be afforded the same level of
     protection given to VeriSign private information.

     Questions:

     Questions concerning implementation or interpretation of this policy should
     be referred to VeriSign's Legal department.

                                      114
<PAGE>

--------------------------------------------------------------------------------

                                   EXHIBIT B
                           NON-DISCLOSURE AGREEMENT

I understand I am an employee assigned to VeriSign Global Registry Services
("VGRS") or another employee who has a need to know information related to the
VGRS business (but not an employee assigned by any registrar affiliated with
VGRS) which is proprietary, confidential or business sensitive, belonging to
VGRS, other companies or customers of VGRS ("Need to Know Employee"). I agree
not to disclose or otherwise disseminate such information to anyone other than
Need to Know Employees, except as directed, in writing, by the General Manager
of the Registry Business or his/her designee. This prohibition is specifically
intended to prevent the disclosure of any such information to personnel assigned
by any registrar affiliated with VGRS. I understand that disclosure of such
information to anyone other than a Need to Know Employee or use of such
information could result in personal liability for such unauthorized use or
disclosure.

I agree to use such proprietary, confidential and/or business sensitive
information only in the performance of requirements necessary to carry out my
duties as a Need to Know Employee, and I agree to take suitable precautions to
prevent the use or disclosure of such information to any party, other than Need
to Know Employees. I will report to the General Manager of the VGRS Business or
his/her designee any potential violation of this agreement. I further agree to
surrender any and all data and information, of any type whatsoever, to the
General Manager of the VGRS Business or his/her designee upon the termination of
my employment as an employee of VeriSign, or my assignment with VGRS.

I certify that I have read and fully understand this Non-Disclosure Agreement
and agree to abide by all requirements contained herein. I understand that my
strict compliance is essential to VGRS, and any violation of these requirements
may result in termination of my employment.

     Agreed to:                              Verified:
                                             __________________________
     __________________________              General Manager, Registry
     Employee                                Date
     Date

                                      115
<PAGE>

--------------------------------------------------------------------------------

                                   EXHIBIT C

                       REGISTRY BUSINESS ORGANIZATIONAL
                 CONFLICT OF INTEREST AVOIDANCE CERTIFICATION

I hereby certify that I have received training in and understand the
requirements of conflict of interest issues and the requirements of the
Organizational Conflict of Interest Compliance Plan of VGRS. I certify that I
will strictly comply with the provisions of this Plan. I understand my
obligation to (i) refrain from any activities which could pose a personal
conflict of interest and (ii) report to the General Manager of VGRS, any
conflict, whether personal or organizational, which is perceived or identified
during the course of my employment with VGRS.

CERTIFIED

_______________________________
signature date
________________________________
name

                                      116
<PAGE>

                                                                      Appendix I
                                                                      ----------

                           Registry Code of Conduct

VeriSign Global Registry Services (VGRS), the registry business of VeriSign,
Inc., will at all times strive to operate as a trusted and neutral third party
provider of Registry Services. VGRS recognizes that domain names are the means
by which businesses, individuals and consumers gain access to, navigate and
otherwise benefit from the global Internet.  These benefits cannot be fully
realized, however, unless the DNS resources are administered in a fair,
efficient and neutral manner that makes them available to all qualified parties
in the competitive DNS space.  To ensure the provision of neutral Registry
Services, VGRS will comply with the following Code of Conduct:

     1.   VGRS will not show any preference or provide any special consideration
          to any ICANN-accredited registrar with regard to Registry Services
          provided for the .net TLD.

     2.   All registrars accredited by ICANN who are authorized to register
          domain names in the .net registry shall have equivalent access to
          Registry Services provided by VGRS.

     3.   VGRS shall not in any way attempt to warehouse, or register domain
          names in its own right other than through an ICANN-accredited
          registrar, except for names designated for operational purposes in
          compliance with Subsections 3.6.1 and 3.6.2 of the Registry Agreement.
          VGRS will certify to ICANN every six months that it is abiding by this
          commitment.

     4.   Any subsidiary or affiliate of VGRS that operates as an ICANN-
          accredited registrar shall maintain separate books of account with
          respect to its registrar operations.

     5.   VGRS subsidiaries and affiliates engaged in providing Registry
          Services shall not have access to, and VGRS itself will not use,
          confidential user data or proprietary information of an ICANN-
          accredited registrar served by VGRS, received by VGRS in the course of
          providing Registry Services, except as necessary for registry
          management and operations.

     6.   VGRS will take appropriate precautions to prevent the disclosure of
          confidential user data or proprietary information from any ICANN-
          accredited registrar, received by VGRS in the course of providing
          Registry Services, to its affiliates or subsidiaries, except as
          necessary for registry management and operations.

     7.   Confidential information about VGRS's Registry Services for the .net
          TLD will not be shared with employees of any ICANN-accredited
          registrar, except as necessary for registry management and operations.

                                      117
<PAGE>

     8.   VGRS will conduct internal neutrality reviews on a regular basis. In
          addition, VGRS agrees that it will cooperate with an independent third
          party ("Auditor") performing Annual Independent Neutrality Audits
          ("AIN Audits"), to be conducted during the fourth quarter of each
          calendar year. The Auditor will be selected by ICANN, and will be an
          accounting firm with significant experience in the review of
          contractual and other legal commitments. All costs of the AIN Audits
          will be borne by VGRS. The AIN Audit is intended to determine whether
          VGRS has been in compliance with Section 3.5 of the Registry
          Agreement, and will utilize such tests and techniques as the auditor
          deems appropriate to determine that compliance. The terms of reference
          of the AIN Audit will be established by ICANN, subject to the approval
          of VGRS (such approval not to be unreasonably withheld), and provided
          to the Auditor by ICANN. A complete report of the results of each AIN
          Audit shall be provided by the Auditor to ICANN and VGRS no later than
          1 December of each calendar year (and by ICANN to the US Departments
          of Commerce and Justice promptly thereafter). ICANN shall determine
          that VGRS is in compliance with Section 3.5 if:

          (1)  any material breach(es) of Section 3.5 found by the audit that
               are susceptible to cure have been cured, or are cured within a
               reasonable time; and

          (2)  in addition and not as an alternative to subparagraph (1) above,
               any monetary sanction that ICANN chooses to impose under the
               Sanctions Program set forth in Appendix Y for any such breach(es)
               has been timely paid.

          A summary of each AIN Audit report, excluding any information that
          ICANN and VGRS agree (such agreement not to be unreasonably withheld)
          is confidential or proprietary, will be posted on the ICANN web site
          no later than 31 January of the calendar year immediately following
          the audit.

                                      118
<PAGE>

                                                                      Appendix K
                                                                      ----------

                          Schedule of Reserved Names

Except to the extent that ICANN otherwise expressly authorizes in writing, the
Registry Operator shall reserve names formed with the following labels from
initial (i.e. other than renewal) registration within the TLD:

A.   Labels Reserved at All Levels. The following names shall be reserved at the
     -----------------------------
second level and at all other levels within the TLD at which Registry Operator
makes registrations:

          ICANN-related names:
          -------------------
     .    aso

     .    dnso

     .    icann

     .    internic

     .    pso

          IANA-related names:
          ------------------

     .    afrinic

     .    apnic

     .    arin

     .    example

     .    gtld-servers

     .    iab

     .    iana

     .    iana-servers

     .    iesg

     .    ietf

     .    irtf

     .    istf

     .    lacnic

     .    latnic

                                      119
<PAGE>

     .    rfc-editor

     .    ripe

     .    root-servers

B.   Additional Second-Level Reservations. In addition, the following names
     ------------------------------------
shall be reserved at the second level:

     .    All single-character labels.

     .    All two-character labels shall be initially reserved. The reservation
          of a two-character label string shall be released to the extent that
          the Registry Operator reaches agreement with the government and
          country-code manager, or the ISO 3166 maintenance agency, whichever
          appropriate. The Registry Operator may also propose release of these
          reservations based on its implementation of measures to avoid
          confusion with the corresponding country codes.

     .    arpa

     .    biz

     .    com

     .    coop

     .    edu

     .    gov

     .    info

     .    int

     .    mil

     .    museum

     .    name

     .    net

     .    org

     .    pro

C.   Tagged Domain Names. All labels with hyphens in the third and fourth
     -------------------
character positions (e.g., "bq--1k2n4h4b")

D.   Second-Level Reservations for Registry Operations. The following names are
     -------------------------------------------------
reserved for use in connection with the operation of the registry for the
Registry TLD. They may be used by Registry Operator under Subsection 3.6.1, but
upon conclusion of

                                      120
<PAGE>

Registry Operator's designation as operator of the registry for the Registry TLD
they shall be transferred as specified by ICANN:

     .    nic

     .    whois

     .    www

                                      121
<PAGE>

                                                                      Appendix N
                                                                      ----------

                          Zone File Access Agreement


1. PARTIES

The User named in this Agreement hereby contracts with VeriSign, Inc.
("VeriSign") for a non-exclusive, non-transferable, limited right to access an
Internet host server or servers designated by VeriSign from time to time, and to
transfer a copy of the described Data to the User's Internet host machine
specified below, under the terms of this Agreement. Upon execution of this
Agreement by VeriSign, VeriSign will return a copy of this Agreement to you for
your records with your UserID and Password entered in the spaces set forth
below.

2. USER INFORMATION

     (a) User: _____________________________________________

     (b) Contact Person: ___________________________________

     (c) Street Address: ___________________________________

     (d) City, State or Province: __________________________

     (e) Country and Postal Code: __________________________

     (f) Telephone Number: _________________________________
     (including area/country code)

     (g) Fax Number: _______________________________________
     (including area/country code)

     (h) E-Mail Address: ___________________________________

     (i) Specific Internet host machine which will be used to access VeriSign's
     server to transfer copies of the Data:

     Name: _________________________________________________

     IP Address: ___________________________________________

     (j) Purpose(s) for which the Data will be used: During the term of this
     Agreement, you may use the data for any legal purpose, not prohibited under
     Section 4 below. You may incorporate some or all of the Data in your own
     products or

                                      122
<PAGE>

      services, and distribute those products or services for a purpose not
      prohibited under Section 4 below.

3. TERM

This Agreement is effective for a period of three (3) months from the date of
execution by VeriSign (the "Initial Term"). Upon conclusion of the Initial Term
this Agreement will automatically renew for successive three-month renewal terms
(each a "Renewal Term") until terminated by either party as set forth in Section
12 of this Agreement or one party provides the other party with a written notice
of termination at least seven (7) days prior to the end of the Initial Term or
the then current Renewal Term.

NOTICE TO USER: CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS. YOU MAY USE
THE USER ID AND ASSOCIATED PASSWORD PROVIDED IN CONJUNCTION WITH THIS AGREEMENT
ONLY TO OBTAIN A COPY OF .COM/.NET/.ORG TOP-LEVEL DOMAIN ("TLD") ZONE FILES, AND
ANY ASSOCIATED ENCRYPTED CHECKSUM FILES (COLLECTIVELY THE "DATA"), VIA THE FILE
TRANSFER PROTOCOL ("FTP") OR HYPERTEXT TRANSFER PROTOCOL ("HTTP") PURSUANT TO
THESE TERMS.

4. GRANT OF ACCESS

VeriSign grants to you a non-exclusive, non-transferable, limited right to
access an Internet host server or servers designated by VeriSign from time to
time, and to transfer a copy of the Data to the Internet host machine identified
in Section 2 of this Agreement no more than once per 24 hour period using FTP or
HTTP for the purposes described in this Section 4. You agree that you will:

     (a) use this Data only for lawful purposes but that under no circumstances
     will you use this Data to: (1) allow, enable, or otherwise support the
     transmission by e-mail, telephone, or facsimile of mass unsolicited,
     commercial advertising or solicitations to entities other than your own
     existing customers; or (2) enable high volume, automated, electronic
     processes that send queries or data to the systems of VeriSign or any
     ICANN-accredited registrar, except as reasonably necessary to register
     domain names or modify existing registrations. VeriSign reserves the right,
     with the approval of the Internet Corporation for Assigned Names and
     Numbers ("ICANN"), to specify additional specific categories of prohibited
     uses by giving you reasonable written notice at any time and upon receiving
     such notice you shall not make such prohibited use of the Data you obtain
     under this Agreement.

     (b) copy the Data you obtain under this Agreement into a machine-readable
     or printed form only as necessary to use it in accordance with this
     Agreement in support of your use of the Data.

     (c) comply with all applicable laws and regulations governing the use of
     the Data.

                                      123
<PAGE>

      (d) not distribute the Data you obtained under this Agreement or any copy
      thereof to any other party without the express prior written consent of
      VeriSign, except that you may redistribute the Data insofar as it has been
      incorporated by you into a value-added product or service that does not
      permit the extraction of a substantial portion of the Data from the value-
      added product or service, provided you prohibit the recipient of the Data
      from using the Data in a manner contrary to Section 4(a).

      (e) take all reasonable steps to protect against unauthorized access to,
      use, and disclosure of the Data you obtain under this Agreement.

5.  FEE

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

6.  PROPRIETARY RIGHTS

You agree that no ownership rights in the Data are transferred to you under this
Agreement. You agree that any copies of the Data that you make will contain the
same notice that appears on and in the Data obtained under this Agreement.

7.  METHOD OF ACCESS

VeriSign reserves the right, with the approval of ICANN, to change the method of
access to the Data at any time. You also agree that, in the event of significant
degradation of system processing or other emergency, VeriSign may, in its sole
discretion, temporarily suspend access under this Agreement in order to minimize
threats to the operational stability and security of the Internet.

8.  NO WARRANTIES

The Data is being provided "as-is." VeriSign disclaims all warranties with
respect to the Data, either expressed or implied, including but not limited to
the implied warranties of merchantability, fitness for a particular purpose, and
non-infringement of third party rights. Some jurisdictions do not allow the
exclusion of implied warranties or the exclusion or limitation of incidental or
consequential damages, so the above limitations or exclusions may not apply to
you.

9.  SEVERABILITY

In the event of invalidity of any provision of this Agreement, the parties agree
that such invalidity shall not affect the validity of the remaining provisions
of this Agreement.

                                      124
<PAGE>

10. NO CONSEQUENTIAL DAMAGES

In no event shall VeriSign be liable to you for any consequential, special,
incidental or indirect damages of any kind arising out of the use of the Data or
the termination of this Agreement, even if VeriSign has been advised of the
possibility of such damages.

11. GOVERNING LAW

This Agreement shall be governed and construed in accordance with the laws of
the Virginia, USA. You agree that any legal action or other legal proceeding
relating to this Agreement or the enforcement of any provision of this Agreement
shall be brought or otherwise commenced in the state or federal court in
Virginia, USA. You expressly and irrevocably agree and consent to the personal
jurisdiction and venue of the federal and states courts located Virginia, USA
(and each appellate court located therein) for maters arising in connection with
this Agreement or your obtaining, use, or distribution of the Data. The United
Nations Convention on Contracts for the International Sale of Goods is
specifically disclaimed.

12. TERMINATION

You may terminate this Agreement at any time by erasing the Data you obtained
under this Agreement from your Internet host machine together with all copies of
the Data and providing written notice of your termination to VeriSign at
[address of Registry Operator]. VeriSign has the right to terminate this
Agreement immediately if you fail to comply with any term or condition of this
Agreement. You agree upon receiving notice of such termination of this Agreement
by VeriSign or expiration of this Agreement to erase the Data you obtained under
this Agreement together with all copies of the Data.

13. DEFINITION

"Data" means all data contained in a DNS zone file for the Registry TLD as
provided to TLD nameservers on the Internet.

14. ENTIRE AGREEMENT

This is the entire agreement between you and VeriSign concerning access and use
of the Data, and it supersedes any prior agreements or understandings, whether
written or oral, relating to access and use of the Data.

[Full name of Registry Operator]


By:  (sign)
Name:  (print)
Title:

                                      125
<PAGE>

Date:


User:


By:  (sign)
Name: (print)
Title:
Date:

                                      126
<PAGE>

                                                                      Appendix O
                                                                      ----------



                       Whois Specification - Public Whois


VeriSign Global Registry Services (VeriSign GRS) Whois service is the
authoritative Whois service for all second-level Internet domain names
registered in the.net top-level domain and for all hosts registered using these
names. This service is available to anyone.  It is available via port 43 access
and via links at the VeriSign GRS web site.  It is updated daily.

To use Registry Whois via port 43 enter the applicable parameter on the command
line as illustrated below:

     .  For a domain name: whois "domain verisign.com"
     .  For a registrar name: whois "registrar Network Solutions, Inc."
     .  For a nameserver: whois "nameserver ns1.netsol.com" or whois "nameserver
        198.41.3.39"

By default, Whois performs a very broad search, looking in all record types for
matches to your query in these fields: domain name, nameserver name, nameserver
IP address, and registrar names. Use keywords to narrow the search (for example,
'domain root').  Specify only part of the search string to perform a "partial"
search on domain.  Every domain starting with the string will be found.  A
trailing dot (or dots) after your text or the partial keyword indicates a
partial search.  For example, entering 'mack.' will find "Mack", "Mackall",
"Mackay", and so on.

To use Registry Whois using the web interface:

     .  Go to www.verisign-grs.com
        --------------------------
     .  Click on the appropriate button ("domain," "registrar" or "nameserver")

     .  Enter the applicable parameter:
        .  Domain name including the TLD (e.g., verisign-grs.com)
        .  Full name of the registrar including punctuation, "Inc.", etc. (e.g.,
           America Online, Inc.)
        .  Full host name or the IP address (e.g., ns1.crsnic.net or
           198.41.3.39)
     .  Click on the "submit" button.

For all registered second-level domain names in .net, information as illustrated
in the following example is displayed, where the entry parameter is the domain
name (including the TLD):

     Domain Name: VERISIGN-GRS.COM
     Registrar: NETWORK SOLUTIONS, INC.
     Whois Server: whois.networksolutions.com

                                      127
<PAGE>

     Referral URL: www.networksolutions.com
     Name Server:  NS1.CRSNIC.NET
     Name Server:  NS2.NSIREGISTRY.NET
     Updated Date: 27-mar-2001

     ))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT (((

For all ICANN-accredited registrars who are authorized to register .net second-
level domain names through VeriSign GRS, information as illustrated in the
following example is displayed, where the entry parameter is the full name of
the registrar (including punctuation, "Inc.", etc.):

     Registrar Name: AMERICA ONLINE, INC. DBA AOL AND/OR COMPUSERVE-AOL
     Address: 22000 AOL Way, Dulles, VA 20166, US
     Phone Number: 703 265 5037
     Email: [email protected]
     Whois Server: whois.compuserve.com
     Referral URL: domain.compuserve.com
     Admin Contact: Juan C Perez
     Phone Number: 703 265 0918
     Email: [email protected]
     Admin Contact: Ryan M Morrow
     Phone Number: 703 265 0910
     Email: [email protected]
     Billing Contact: Mara A Perrone
     Phone Number: 703-265-1337
     Email: [email protected]
     Technical Contact: Juan C Perez
     Phone Number: 703 265 0918
     Email: [email protected]
     Technical Contact: Ryan M Morrow
     Phone Number: 703 265 0910
     Email: [email protected]

     ))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT (((


For all hosts registered using second-level domain names in .net, information as
illustrated in the following example is displayed, where the entry parameter is
either the full host name or the IP address:

     Server Name: NS1.CRSNIC.NET
     IP Address: 198.41.3.39
     Registrar: NETWORK SOLUTIONS, INC.
     Whois Server: whois.networksolutions.com
     Referral URL: www.networksolutions.com

                                      128
<PAGE>

     Referral URL: www.networksolutions.com

     ))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT (((

                                      129
<PAGE>

                                                                      Appendix P
                                                                      ----------


                       Whois Provider Data Specification

Registry Operator shall provide bulk access to up-to-date data concerning domain
name and nameserver registrations maintained by Registry Operator in connection
with the Registry TLD on a daily schedule, only for purposes of providing free
public query-based access to up-to-date data concerning domain name and
nameserver registrations in multiple TLDs, to a party designated from time to
time in writing by ICANN.  The specification of the content and format of this
data, and the procedures for providing access, shall be as stated below, until
changed according to the Registry Agreement.

Content


The data shall be provided in three files:

     A.   Domain file.  One file shall be provided reporting on the domains
          -----------
          sponsored by all registrars. For each domain, the file shall give the
          domainname, servername for each nameserver, registrarid, and
          updateddate.

     B.   Nameserver file.  One file shall be provided reporting on the
          ---------------
          nameservers sponsored by all registrars. For each registered
          nameserver, the file shall give the servername, each ipaddress,
          registrarid, and updateddate.

     C.   Registrar file.  A single file shall be provided reporting on the
          --------------
          registrars sponsoring registered domains and nameservers. For each
          registrar, the following data elements shall be given: registrarid,
          registrar address, registrar telephone number, registrar e-mail
          address, whois server, referral URL, updateddate and the name,
          telephone number, and e-mail address of all the registrar's
          administrative, billing, and technical contacts.

Format

The format for the above files shall be as specified by ICANN, after
consultation with Registry Operator.

Procedures for Providing Access

The procedures for providing daily access shall be as mutually agreed by ICANN
and Registry Operator.  In the absence of an agreement, the files shall be
provided by Registry Operator sending the files in encrypted form to the party
designated by ICANN by Internet File Transfer Protocol.

                                      130
<PAGE>

                                                                      Appendix Q
                                                                      ----------


                        Whois Data Specification--ICANN

Registry Operator shall provide bulk access by ICANN to up-to-date data
concerning domain name and nameserver registrations maintained by Registry
Operator in connection with the Registry TLD on a daily schedule, only for
purposes of verifying and ensuring the operational stability of Registry
Services, the DNS, and the Internet.  The specification of the content and
format of this data, and the procedures for providing access, shall be as stated
below, until changed according to the Registry Agreement.

Content


The data shall be provided in three files:

  A. Domain file.  One file shall be provided reporting on the domains sponsored
     -----------
     by all registrars.  For each domain, the file shall give the domainname,
     servername for each nameserver, registrarid, and updateddate.

  B. Nameserver file.  One file shall be provided reporting on the nameservers
     ---------------
     sponsored by all registrars.  For each registered nameserver, the file
     shall give the servername, each ipaddress, registrarid, and updateddate.

  C. Registrar file.  A single file shall be provided reporting on the
     --------------
     registrars sponsoring registered domains and nameservers.  For each
     registrar, the following data elements shall be given:  registrarid,
     registrar address, registrar telephone number, registrar e-mail address,
     whois server, referral URL, updateddate and the name, telephone number, and
     e-mail address of all the registrar's administrative, billing, and
     technical contacts.

Format

The format for the above files shall be as specified by ICANN, after
consultation with Registry Operator.

Procedures for Providing Access

The procedures for providing daily access shall be as mutually agreed by ICANN
and Registry Operator.  In the absence of an agreement, an up-to-date version
(encrypted using a public key supplied by ICANN) of the files shall be placed at
least once per day on a designated server and available for downloading by ICANN
by Internet File Transfer Protocol.

                                      131
<PAGE>

                                                                      Appendix R
                                                                      ----------
                           Data Escrow Specification

EXHIBIT A - Task Order and Statement of Work

TASK ORDER TITLE

Exhibit A to the Registry Data Escrow Agreement dated _______________.

COMPANY NAME

Data Escrow Provider

STATEMENT OF WORK

Establish an escrow account to deposit all Registry Data in an electronic format
mutually approved by VeriSign Global Registry Services, and ICANN. More
specifically, to meet the Data Escrow requirements outlined in the Registry
Agreement, VeriSign Global Registry Services will store in escrow with Data
Escrow Provider a complete set of Registry Data in an electronic format agreed
upon by VeriSign Global Registry Services, and ICANN. Data Escrow Provider will
verify that the data is complete, accurate, and delivered in the intended format
using scripts provided by VeriSign Global Registry Services. A phased approach
will be taken to implement the scripts required for verification. The short-term
escrow process will verify completeness and integrity (accuracy). A long-term
approach is required to create a script to verify that the file format sent is
the format received by Data Escrow Provider (correctness). Refer to Exhibits B1
and B2 to review the short and long-term verification processes. The
Introspection validation, defined in Exhibit B2, will be implemented in a later
phase, as mutually agreed by the parties hereto.


     Data will be securely and electronically transmitted on a daily and weekly
     basis as follows:


     Weekly Escrow Deposits:
     -----------------------

     VeriSign Global Registry Services will deposit a complete set of Registry
     Data into escrow on a weekly basis by electronically and securely
     transmitting a snapshot of each operational Registrar's data (the "Deposit
     Materials").  The snapshot captures the state of each Registrar's data at
     the time the snapshot was created.  Specific data elements contained in the
     Deposit Materials are identified in Table 1.

                                      132
<PAGE>

     Daily Escrow Deposits:
     ----------------------

     VeriSign Global Registry Services will securely and electronically deposit
     a transaction log for each operational Registrar representing transactions
     that occurred over the previous 24 hour period (the "Additional Deposit").
     The logs will be escrowed daily, being in the form of Additional Deposit
     each Tuesday through Sunday, and being in the form of the Weekly Deposit
     Materials each Monday, which shall capture that Sunday's data.  The Daily
     Additional Deposit will act as incremental updates to the Weekly Deposit
     Materials and will include all Registrar activity, such as add, delete, and
     transfer of a domain name.  Specific data elements contained in the
     Additional Deposit are identified in Table 2.


     Electronic Delivery Service Escrow Deposit Method:
     --------------------------------------------------

     The "Electronic Delivery Service" escrow deposit method shall mean and
     refer to the following.  VeriSign Global Registry Services shall transmit
     the Deposit Materials and Additional Deposit to a secure server on a weekly
     and daily basis, respectively.  VeriSign Global Registry Services shall
     provide a secure ID and password for Data Escrow Provider.  Data Escrow
     Provider shall pull the transmitted data from the server and store it in a
     secured location.  The transmitted data will be made available to Data
     Escrow Provider as follows:


     Daily Deposits:
     ---------------

     Daily transactional data will be made available at the close of business
     each Tuesday through Sunday for the previous calendar day.  For example,
     transactional data created on Monday would be available to the escrow
     company on Tuesday at the close of business. The results of transactions
     completed on Sunday will be made available in the Weekly Deposit Materials,
     thus no separate Daily Additional Deposit will be made for Sunday activity.


     Weekly Deposits:
     ----------------

     Weekly database snapshots taken at midnight on Sundays will be available
     not later than 6 p.m. each Monday.


     Data Transmission File Sizes:
     -----------------------------

     The Weekly Deposit Materials shall include 4 reports (see Table 1 for
     details of reports).

     Additional Deposits shall include 1 report (see Table 2 for details of
     report).


                              FILE SIZE ESTIMATES

-------------------------------------------------------------------------------
                                             Daily                Weekly
-------------------------------------------------------------------------------
Current Data Escrow Size              up to 10 Megabytes   up to 750 Megabytes
-------------------------------------------------------------------------------

                                      133
<PAGE>

-------------------------------------------------------------------------------
Forecasted 2001 Data Escrow Size      up to 75 Megabytes    up to 1 Gigabytes
-------------------------------------------------------------------------------
Total Forecasted Escrow Size          up to 110 Megabytes   up to 4 Gigabytes
-------------------------------------------------------------------------------

                   Table 1:  Weekly Deposit Materials Format

Registrar Weekly Reports

1.  Registrar Domain Report

--------------------------------------------------------------------------------
Title:      Registrar Domain Report

Report name:     rgr_domain

Description:  This report contains all domains associated with a specific
registrar.  The domain is listed once with each current status and
associated nameserver.

Fields:          domainname

              statusname

              servername

Examples:

     ALPHA.COM:REGISTRY-LOCK:NS1.ALPHA.COM

     ALPHA.COM:REGISTRY-LOCK:NS2.ALPHA.COM

     ALPHA.COM:REGISTRY-HOLD:NS1.ALPHA.COM

     ALPHA.COM:REGISTRY-HOLD:NS2.ALPHA.COM

     BETA.COM:ACTIVE:NS1.BETA.COM

     BETA.COM:ACTIVE:NS2.BETA.COM

     GAMMA.COM::NS1.GAMMA.COM

     DELTA.COM:ACTIVE:
--------------------------------------------------------------------------------

2.  Registrar Nameserver Report - Listed with IP Address

--------------------------------------------------------------------------------
Title:      Registrar Nameserver Report - Listed with IPAddress

Report name:     rgr_nameserver

Description:  This report contains all nameservers associated with a
specific registrar.  The nameserver is listed once with each associated
jpaddress.

Fields:          servername

              ipaddress

Examples:
--------------------------------------------------------------------------------

                                      134
<PAGE>

--------------------------------------------------------------------------------
     NS.ALPHA.COM:111.222.333.001

     NS.ALPHA.COM:111.222.333.002

     NS.BETA.COM:
--------------------------------------------------------------------------------


3.  Registrar Nameserver-Domain Hosting Report

--------------------------------------------------------------------------------
Title:    Registrar Nameserver Report - Listed with Domain

Report name:  rgr_nameserver_domain

Description:  This report contains domains hosted per nameservers associated
with a specific registrar. The nameserver is listed once with each associated
domainname.

Fields:       servername

          domainname

Examples:

     NS.ALPHA.COM:ALPHA1.COM

     NS.ALPHA.COM:ALPHA2.COM

     NS.ALPHA.COM:ALPHA3.COM

     NS.BETA.COM:BETA1.COM

     NS.BETA.COM:BETA2.COM

     NS.GAMMA.COM:

--------------------------------------------------------------------------------


4.  Registrar Common Report

--------------------------------------------------------------------------------
Title:    Registrars Report

Report name:  Registrars

Description:  This report contains one row for each registrar. Fields of the
report contain name, location, contact, financial, and business information.


Fields:       REGISTRARID

          REGISTRARNAME

          SECURITYPHRASE

          PHONENUMBER

          FAXNUMBER

          LICENSEEXPIRATIONDATE

          CREDITLIMIT

          AVAILABLECREDIT

          LOWERLIMITPCT
--------------------------------------------------------------------------------

                                      135
<PAGE>

          EMAIL

          GROSSAMOUNTDUE

          NETAMOUNTDUE

          ORIGINALDUEDATE

          DUEDATE

          ADDRESSLINE1

          ADDRESSLINE2

          ADDRESSLINE3

          CITY

          STATEPROVINCE

          POSTALCODE

          COUNTRYCODE

          STATUSNAME

          DESCRIPTION

          CANPLACEORDER

Examples:  123:Alpha Registrar:Gazpacho is a dish best served cold:(123)456-
7890:(123)456-
7891:2001.01.01.00.00.00:2000000:218990:.2:[email protected]:::::123 4th
Avenue, 7 1/2th Floor:::NY:NY:10018:US:ACTIVE:Registrar is active and can
use the Registry to issue RRP commands:Y
--------------------------------------------------------------------------------

                                      136
<PAGE>

                   Table 2: Daily Additional Deposit Format
                   -------

Registrar Daily Additional Deposits

1.  Registrar Transaction Report

--------------------------------------------------------------------------------
Title:    Registrar Transaction Report

Report name:  rgr_transaction

Description:  This report contains transactions associated with a specific
registrar.  Domain operations produce one row for each associated
nameserver.  Nameserver operations produce one row for each associated
ipaddress.  A transactionid is included to allow unique identification of
transactions.  The content of columns 3 and 4 is dependent on the operation
in the following ways:

     operation (sigma) (ADD_DOMAIN, MOD_DOMAIN, DEL_DOMAIN) =>
[domainname][servername]

     operation (sigma) (ADD_NAMESERVER, MOD_NAMESERVER, DEL_NAMESERVER) =>
[ipaddress][servername]

     operation (sigma) (TRANSFER_DOMAIN) => [domainname][null]


              Only the seven (7) operation types above are included in the
report.


Fields:       transactionid

          operationname

          domainname | ipaddress

          servername | null

          transactiondate

Examples:

     1000010:ADD-DOMAIN:ALPHA.COM:NS.ALPHA.COM:1999.04.25.00.01.08

     1000020:ADD-DOMAIN:BETA.COM:NS1.BETA.COM:1999.04.25.00.05.33

     1000020:ADD-DOMAIN:BETA.COM:NS2.BETA.COM:1999.04.25.00.05.33

     1000030:ADD-DOMAIN:GAMMA.COM::1999.04.25.00.05.34

     2000010:ADD-NAMESERVER:111.222.333.001:NS.DELTA.COM:1999.04.25.00.06.48

     2000020:ADD-NAMESERVER:444.555.666.001:NS.EPSILON.COM:1999.04.25.00.36.18
--------------------------------------------------------------------------------


                                      137
<PAGE>

     2000020:ADD-NAMESERVER:444.555.666.002:NS.EPSILON.COM:1999.04.25.00.36.18

     2000030:ADD-NAMESERVER::NS.ZETA.COM:1999.04.25.00.37.31

     3000010:TRANSFER_DOMAIN:ETA.COM::1999.04.25.01.37.31

     3000020:TRANSFER_DOMAIN:THETA.COM::1999.04.25.02.37.31

     3000030:TRANSFER_DOMAIN:IOTA.COM::1999.04.25.03.37.31

     3000040:TRANSFER_DOMAIN:KAPPA.COM::1999.04.25.03.37.31
--------------------------------------------------------------------------------


1.  ADDITIONAL TERMS AND CONDITIONS


     For .com agreement:


     Registry Operator shall periodically deposit into escrow all Registry Data
     on a schedule (not more frequently than weekly for a complete set of
     Registry Data, and daily for incremental updates) and in an electronic
     format mutually approved from time to time by Registry Operator and ICANN,
     such approval not to be unreasonably withheld by either party. 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. The schedule, content,
     format, and procedure for escrow deposits shall be as established by ICANN
     from time to time. The initial schedule, content, format, and procedure
     shall be as set forth in Appendix R. Changes to the schedule, content,
     format, and procedure may be made only with the mutual written consent of
     ICANN and Registry Operator (which neither party shall unreasonably
     withhold) or through the establishment of Consensus Policies as set forth
     in Definition 1 of this Agreement. The escrow shall be held under an
     agreement, substantially in the form of Appendix S, among ICANN, Registry
     Operator, and the escrow agent.

     For .net and .org agreements:

     Registry Operator shall periodically deposit into escrow all Registry Data
     in an electronic format. 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. The schedule, content, format, and procedure for
     escrow deposits shall be as established by ICANN from time to time. The
     initial schedule, content, format, and procedure shall be as set forth in
     Appendix R. Changes to the schedule, content, format, and procedure may be
     made only with the mutual written

                                      138
<PAGE>

     consent of ICANN and Registry Operator (which neither party shall withhold
     without reason) or in the manner provided in Subsections 4.3 through 4.6.
     The escrow shall be held under an agreement, substantially in the form of
     Appendix S, among ICANN, Registry Operator, and the escrow agent.


2.   PERIOD OF PERFORMANCE


3.   Period of Performance shall be as defined by section 7(a) of this Escrow
     Agreement. FEE SCHEDULE


          Fees to be paid by VeriSign Global Registry Services shall be as
          follows:


          Initialization fee (one time only)                $ _________


          *Annual maintenance/storage fee                   $ _________
               *includes two cubic feet of storage space

--------------------------------------------------------------------------------

  Additional Services Available:

  Electronic Updates
  Transmitted once daily                     $  ________
  Price quoted is limited to 650 MB per update.

  Electronic Updates over 650 MB             $  ________

  Fee incurred for updates over 650 MB will be billed on a monthly basis.

  Additional Services
  Verification / File Listing Services       $  ________
  (This includes up to one hour of service
  for each deposit)

  Additional Storage Space                   $  ________

  Payable by Licensee or Producer Only Upon Release Request:

  Due Only Upon Licensee's or Producer's
  Request for Release of Deposit Materials   $  ________
                                             $  ________

--------------------------------------------------------------------------------

                                      139
<PAGE>

     Fees due in full, in US dollars, upon receipt of signed contract or deposit
material, whichever comes first.  Thereafter, fees shall be subject to their
current pricing, provided that such prices shall not increase by more than 10%
per year.  The renewal date for this Agreement will occur on the anniversary of
the first invoice.  If other currency acceptance is necessary, please contact
your Account Manager to make arrangements.

                                      140
<PAGE>

Exhibit B1: Phase I Escrow Process


The goal of the Escrow Process is to periodically encapsulate all Registrar-
specific information into a single Escrow_File and to make this file available
to a third party for escrow storage. Existing Daily and Weekly reports as well
as a Registrars Report/a/ will be used to construct the Escrow File because
these reports, when taken together, describe completely the entire set of
domains, nameservers, and Registrars. The Escrow Process employs a method of
encapsulation whereby the Daily, Weekly, and Registrar reports are concatenated,
compressed, digitally signed, and digested into a single file. The format of
this encapsulation enables the single file to be verified for Completeness/b/
and Integrity/c/ by a third party.


Exhibit B1: Phase I Verification Process

The goal of the Verification Process is to verify Completeness/b/ and
Integrity/c/ of an Escrow File. The Verification Process uses layers of meta-
data encapsulated in the Escrow File to construct a Verification Report. The
verification report produced by the Verification Process indicates whether the
data file meets the authentication requirements. The report has 2 sections,
action and results. Actions describe each of the actions taken against the data
file and whether those actions met success or failure. Results describe the
results of the verification process. If there was a failure in the Actions
section then the Results section will describe details of the failure and
indicate that the Data File is corrupt and cannot be verified. If no errors are
present the Results section will indicate that the file is valid.



Notes


a.  Registrar Report
The existing Daily and Weekly reports associate Registry data and transactions
to specific Registrars by naming each report with a specific Registrar Id.  The
Registrar report provides a mapping between these Registrar Ids and other
associated Registrar information such as name, credit, billing address, contact
info, and location.

b.  Completeness
A data file transfer is complete if all data files transferred from the source
machine are present on the destination machine.

c.  Integrity
A data file transfer has integrity if no data file was altered by a third party
while in transit.

                                      141
<PAGE>

Exhibit B2: Phase II Escrow Process

The goal of the Escrow Process is to periodically encapsulate all Registrar-
specific information into a single Escrow_File and to make this file available
to a third party for escrow storage. Existing Daily and Weekly reports as well
as a Registrars Report/a/ will be used to construct the Escrow File because
these reports, when taken together, describe completely the entire set of
domains, nameservers, and Registrars.

The Escrow Process employs a method of encapsulation whereby the Daily, Weekly,
and Registrar reports are concatenated, compressed, signed, and digested into a
single file. The format of this encapsulation enables the single file to be
verified for Completeness/b/, Correctness/c/, and Integrity/d/ by a third party.
The Escrow Process includes data format specification for each report file using
regular expression algebra. This format specification is stored with the report
file itself and is used for format verification later. The report file along
with data format specification is then digitally signed for authentication, non-
repudiation and message integrity verification.


Exhibit B2: Phase II Verification Process

The goal of the Verification Process is to verify Completeness/b/,
Correctness/c/, and Integrity/d/ of an Escrow File. The Verification Process
uses layers of meta-data encapsulated in the Escrow File to construct a
Verification Reportf. The verification report produced by the verification
process indicates whether the data file meets the authentication requirements.
The report has 2 sections actions and results. Actions section describes each of
the actions taken against the data file and whether those actions met success or
failure. Results section describes the results of the Verification Process. If
there was a failure in the Actions section then the Results section will
describe details of the failure and indicate that the Data File is corrupt and
cannot be verified. If no errors are present the Results section will indicate
that the file is valid. As part of verification the data format specification is
used to verify the correctness of the format of each record in the file. To
ensure that the Reports are self-consistent, introspection will be implemented
in a later phase. Introspection will analyze Weekly Reports across all
Registrars to verify that fields referenced from outside the report are indeed
valid entries in other weekly reports.


Notes

a. Registrars Report
The existing Daily and Weekly reports associate Registry data and transactions
to specific Registrars by naming each report with a specific Registrar Id.  The
Registrar report provides a mapping between these Registrar Ids and other
associated Registrar information such as name, credit, billing address, contact
info, and location.

b. Completeness
A data file transfer is complete if all data files transferred from the source
machine are present on the destination machine.

c. Correctness

                                      142
<PAGE>

A data file transfer is correct if each data file on the destination machine has
the same information content as that on source machine.

d. Integrity
A data file transfer has integrity if no data file was altered by a third party
while in transit.

e. Regular Expression Algebra
The regular expression algebra is a powerful data description language.  The
data structure description can be as specific or generic as necessary.

f. Verification Report
The verification report produced by the Verification Process indicates whether a
Data File meets the authentication requirements.  The report has 2 sections:

     Actions
     -------
     This section describes each of the actions taken against the Data File and
     whether those actions met "SUCCESS" or "FAILURE".

     Results
     -------
     This section describes the results of the Verification Process. If there
     was a "FAILURE" in the Actions section then the Results section will
     describe details of the failure and indicate that the Data File is corrupt
     and cannot be verified. If no errors are present the Results section will
     enumerate the Report Files contained within the Data File and indicate that
     the file is valid.

                                      143
<PAGE>

                                                                      Appendix S
                                                                      ----------

                                Escrow Agreement

     This Escrow Agreement ("Agreement") is made as of this ___ day of
_________________, _____, by and between  VeriSign, Inc., doing business as
VeriSign Global Registry Services  ("VGRS" ), [Escrow Agent] ("Escrow Agent"),
and the Internet Corporation for Assigned Names and Numbers ("ICANN").

     Preliminary Statement.  VGRS intends to deliver the "Deposit Materials" and
     ---------------------
any "Additional Deposit" to Escrow Agent as defined and provided for herein.
VGRS desires Escrow Agent to hold the Deposit Materials and, upon certain events
described herein, deliver the Deposit Materials (or a copy thereof) to ICANN in
accordance with the terms hereof.

     Now, therefore, in consideration of the foregoing, of the mutual promises
hereinafter set forth, and for other good and valuable consideration, the
receipt and sufficiency of which are hereby acknowledged, the parties agree as
follows:

     1.   Delivery by VGRS.  VGRS shall be solely responsible for delivering to
          ----------------
Escrow Agent the Deposit Materials, as defined and described in Exhibit A, the
"Task Order and Statement of Work," attached to Appendix R and incorporated
herein by reference.  VGRS may elect to deliver the Deposit Materials by the
"Electronic Delivery Service," also defined in Exhibits A and B to Appendix R or
in a manner mutually agreed upon by Escrow Agent and VGRS.  Upon receipt of the
Deposit Materials via Electronic Delivery Service, Escrow Agent shall download
the Deposit Materials onto CD-ROM and generate a file listing which Escrow Agent
shall, within ten (10) business days, forward to VGRS, via email.  Within two
(2) business days after receiving them, Escrow Agent shall verify that any
Deposit Materials are in the proper format and appear to be complete by
performing the verification procedures specified in Exhibit B1 and B2 of
Appendix R.  Escrow Agent shall deliver, on the last business day of each month,
a written certification to ICANN that it has performed those verification
procedures on all Deposit Materials received during the last month and shall
deliver to ICANN a copy of the verification reports generated by those
procedures.  If Escrow Agent discovers that any Deposit Materials fail the
verification procedures, Escrow Agent shall notify ICANN of such nonconformity
within forty-eight (48) hours.  Escrow Agent shall then hold the Deposit
Materials in accordance with the terms and conditions hereof.

     2.   Duplication; Periodic Updates
          -----------------------------

          (a)  Escrow Agent may duplicate the Deposit Materials by any means in
order to comply with the terms and provisions of this Agreement. Alternatively,
Escrow Agent, by notice to VGRS, may reasonably require VGRS to promptly
duplicate the Deposit Materials and forward the same to Escrow Agent.

          (b)  VGRS shall deposit with Escrow Agent the "Additional Deposit," as
defined and described in the attached Exhibit A of Appendix R. Within two (2)
business days after receiving them, Escrow Agent shall verify that any
Additional Deposits are in the proper format and appear to be complete by
performing the verification procedures specified in Exhibit B1 and B2 of
Appendix R. Escrow Agent shall deliver, on the last business day of each month,
a written certification to ICANN that it has performed those verification
procedures on all Additional Deposits received during the last month and shall
deliver to ICANN a copy of the verification reports generated by those
procedures. If Escrow Agent discovers that any Additional Deposits fail the
verification procedures, Escrow Agent shall notify ICANN of such nonconformity
within forty-eight (48) hours.

                                      144
<PAGE>

     3.   Notification of Deposits.  Simultaneous with the delivery to Escrow
          -------------------------
Agent of the Deposit Materials or any Additional Deposit, as the case may be,
VGRS shall deliver to Escrow Agent a written statement, via email, specifically
identifying all items deposited and stating that the Deposit Materials and/or
any Additional Deposit have been inspected by VGRS and are complete and
accurate. Escrow Agent shall, within ten (10) business days of receipt of any
Deposit Materials or Additional Deposit, send notification to VGRS, via email,
that it has received from VGRS such Deposit Materials and/or any such Additional
Deposit. In addition, Escrow Agent shall also include a copy of the verification
report as confirmation that it has run the verification process.

     4.   Delivery by Escrow Agent
          ------------------------

          4.1  Delivery by Escrow Agent to ICANN.  Escrow Agent shall deliver
               ---------------------------------
the Deposit Materials and any Additional Deposits received since the last
submission of Deposit Material ("Outstanding Additional Deposits"), or a
complete copy thereof, to ICANN only in the event that:

              (a)   VGRS notifies Escrow Agent to effect such delivery to ICANN
at a specific address, the notification being accompanied by a check payable to
Escrow Agent in the amount of one hundred dollars ($100.00); or

               (b)  Escrow Agent receives from ICANN:

                    (i) Written notification that the Registry Agreement between
                          VGRS and ICANN dated [April ____, 2001] ("Registry
                          Agreement") has been validly and legally terminated by
                          ICANN under Subsection 5.4 of the Registry Agreement
                          or, if not sooner terminated, written notification
                          that the Registry Agreement has expired and that it
                          has been finally determined by the ICANN Board (and no
                          injunction obtained pursuant to Subsection 5.9 of the
                          Registry Agreement has been obtained) that VGRS will
                          not be designated as the successor registry under
                          Subsection 5.2 of the Registry Agreement (either event
                          generically referred to herein as the "Registry
                          Termination");

                    (ii)  evidence satisfactory to Escrow Agent that ICANN has
                          previously notified VGRS of such Registry Termination
                          in writing;

                    (iii) a written demand that the Deposit Materials and
                          Outstanding Additional Deposits be released and
                          delivered to ICANN;

                    (iv)  a written undertaking from ICANN that the Deposit
                          Materials and Outstanding Additional Deposits being
                          supplied to ICANN will be used only as permitted under
                          the terms of the Registry Agreement;

                    (v)   specific instructions from ICANN for this delivery;
                          and

                    (vi)  a check from VGRS, or from ICANN (who will then be
                          reimbursed by VGRS), payable to Escrow Agent in the
                          amount of one hundred dollars ($100.00); or

                    (c) Release occurs according to Paragraph 8(b).

          4.2  Delivery at VGRS's Request.  If the provisions of 4.1(a) are
               ---------------------------
satisfied, Escrow Agent shall, within five (5) business days after receipt of
the notification and check specified in paragraph 4.1(a), deliver the Deposit
Materials and Outstanding Additional Deposits in accordance with the applicable
instructions.

                                      145
<PAGE>

        4.3    Delivery at ICANN's  Request.  If the provisions of paragraphs
               ----------------------------
4.1(b) or 4.1(c) are satisfied, Escrow Agent, within five (5) business days
after receipt of all the documents specified in these paragraphs, shall deliver
the following: (i) to VGRS, a photostatic copy of all such documents; (ii) to
ICANN, as specifically instructed by ICANN, electronic copies of the Deposit
Materials and electronic copies of the Outstanding Additional Deposits. VGRS
shall then have thirty (30) days from the date on which VGRS receives such
documents ("Objection Period") to notify Escrow Agent of its objection
("Objection Notice") to the release of the Deposit Materials to ICANN and
request that the issue of entitlement to a copy of the Deposit Materials be
submitted to arbitration in accordance with the following provisions:

               (a)  The sending of an Objection Notice shall not delay delivery
of Deposit Materials and Outstanding Additional Deposits to ICANN.

               (b)  If VGRS shall send an Objection Notice to Escrow Agent
during the Objection Period, the matter shall be submitted to and settled by
arbitration by a panel of three (3) arbitrators chosen by the American
Arbitration Association in accordance with the rules of the American Arbitration
Association. The arbitrators shall apply the law of California exclusive of its
conflicts of laws rules. At least one (1) arbitrator shall be reasonably
familiar with the Internet industry. The decision of the arbitrators shall be
binding and conclusive on all parties involved, and judgment upon their decision
may be entered in a court of competent jurisdiction. All costs of the
arbitration incurred by Escrow Agent, including reasonable attorneys' fees and
costs, shall be paid by the party which does not prevail in the arbitration;
provided, however, if the arbitration is settled prior to a decision by the
arbitrators, the parties involved in the arbitration shall each pay an equal
percentage of all such costs.

               (c)  Notwithstanding Paragraph 4.3(b), the parties agree that any
arbitration brought pursuant to Paragraph 4.3 shall be conducted consistently
and in accordance with any prior arbitration or court decisions involving the
Registry Agreement. The parties further agree that any arbitration brought
pursuant to Paragraph 4.3 shall not examine, re-evaluate, reconsider, or
otherwise be subject to review by any issues, causes of action, or other claims
which were decided, or which a party had a reasonable opportunity to raise, in
an arbitration or court decision involving the Registry Agreement and/or the
Cooperative Agreement, and that any decision regarding such issues or claims in
an arbitration brought pursuant to Paragraph 4.3 would be invalid,
unenforceable, and not binding. The propriety, validity, legality, or
effectiveness of any terminations or actions under the Registry Agreement [or
Cooperative Agreement] shall be determined solely through procedures and
remedies provided for by those respective agreements, not through any
arbitration brought pursuant to Paragraph 4.3. Any arbitration proceeding
brought pursuant to Paragraph 4.3 shall be limited to a determination of whether
Paragraph 4.1(b) has been satisfied.

               (d)  VGRS may, at any time prior to the commencement of
arbitration proceedings, notify Escrow Agent that VGRS has withdrawn the
Objection Notice. Upon receipt of any such notice from VGRS, Escrow Agent shall
promptly deliver any Deposit Materials and Outstanding Additional Deposits to
ICANN in accordance with the instructions provided by ICANN, to the extent such
Deposit Materials and Outstanding Additional Deposits have not already been
delivered.

               (e)  If the release of materials to ICANN pursuant to Paragraph
4.3 is judged to be proper in any arbitration brought in accordance with
Paragraph 4.3, Escrow Agent shall promptly deliver to ICANN, in accordance with
the instructions specified in paragraph 4.1(b)(v) above, any Deposit Materials
and Outstanding Additional Deposits that have not previously been delivered
(such as those that were received by Escrow Agent after Escrow Agent's initial
delivery of materials to ICANN pursuant to Paragraph 4.3). All parties agree
that Escrow Agent shall not be
                                      146
<PAGE>

required to deliver such Deposit Materials and Outstanding Additional Deposits
until all such fees then due to Escrow Agent have been paid.

          (f)  If the release of the Deposit Materials and Outstanding
Additional Deposits to ICANN pursuant to Paragraph 4.3 is judged to have been
improper in any arbitration brought in accordance with Paragraph 4.3, ICANN
shall promptly return or destroy, at VGRS's discretion, those Deposit Materials
and Outstanding Additional Deposits that were received by ICANN pursuant to
Paragraph 4.3

        4.4    Delivery by Escrow Agent to VGRS.  Escrow Agent shall release
               --------------------------------
and deliver the Deposit Materials and any Additional Deposit to VGRS upon
termination of this Agreement in accordance with paragraph 7(a) or 7(b) hereof.

     5.   Indemnity.  VGRS and ICANN shall jointly and severally indemnify and
          ---------
hold harmless Escrow Agent and each of its directors, officers, agents,
employees and stockholders ("Escrow Agent Indemnitees") absolutely and forever,
from and against any and all claims, actions, damages, suits, liabilities,
obligations, costs, fees, charges, and any other expenses whatsoever, including
reasonable attorneys' fees and costs, that may be asserted by a third party
against any Escrow Agent Indemnitee in connection with this Agreement or the
performance of Escrow Agent or any Escrow Agent Indemnitee hereunder. Escrow
Agent shall likewise indemnify VGRS, ICANN, and each of their directors,
officers, agents, employees and stockholders ("Indemnitees") absolutely and
forever, from and against any and all claims, actions, damages, suits,
liabilities, obligations, costs, fees, charges, and any other expenses
whatsoever, including reasonable attorneys' fees and costs, that may be asserted
by a third party against any Indemnitee in connection with the
misrepresentation, negligence or misconduct of Escrow Agent, its employees, or
contractors in satisfying Escrow Agent's obligations under this Agreement.

     6.   Disputes and Interpleader.
          -------------------------

          (a) Escrow Agent may submit any dispute under this Agreement to any
court of competent jurisdiction in an interpleader or similar action other than
a matter submitted to arbitration after Escrow Agent's receipt of an Objection
Notice under Paragraph 4 and the parties under this Agreement submit the matter
to such arbitration as described in Paragraph 4 of this Agreement. Any and all
costs incurred by Escrow Agent in connection therewith, including reasonable
attorneys' fees and costs, shall be borne 50% by each of VGRS and ICANN.

          (b) Escrow Agent shall perform any acts ordered by any court of
competent jurisdiction, without any liability or obligation to any party
hereunder by reason of such act.

     7.   Term and Renewal.
          ----------------

          (a) The initial term of this Agreement shall be two (2) years,
commencing on the date hereof (the "Initial Term"). This Agreement shall be
automatically extended for an additional term of one year ("Additional Term") at
the end of the Initial Term and at the end of each Additional Term hereunder
unless, on or before ninety (90) days prior to the end of the Initial Term or an
Additional Term, as the case may be, either (i) Escrow Agent or (ii) VGRS, with
the concurrence of ICANN, notifies the other parties that it wishes to terminate
the Agreement at the end of such term.

          (b) In the event VGRS gives notice of its intent to terminate pursuant
to Paragraph 7(a), and ICANN fails to concur according to Paragraph 7(a), ICANN
shall be responsible for payment of all subsequent fees in accordance with
Exhibit A of Appendix R and shall have the right to terminate this Agreement at
the end of the Initial Term or any Additional Term upon giving the other parties
ninety (90) days notice.

                                      147
<PAGE>

          (c) In the event of termination of this Agreement in accordance with
Paragraph 7(a) or 7(b) hereof, VGRS shall pay all fees due Escrow Agent and
shall promptly notify ICANN that this Agreement has been terminated and that
Escrow Agent shall return to VGRS all copies of the Deposit Materials and any
Additional Deposit then in its possession.

     8.   Fees. VGRS shall pay to Escrow Agent the applicable fees in accordance
          ----
with Exhibit A of Appendix R as compensation for Escrow Agent's services under
this Agreement.  The first year's fees are due upon receipt of the signed
contract or Deposit Materials, whichever comes first, and shall be paid in U.S.
Dollars.

          (a)  Payment.  Escrow Agent shall issue an invoice to VGRS following
               -------
execution of this Agreement ("Initial Invoice"), on the commencement of any
Additional Term hereunder, and in connection with the performance of any
additional services hereunder.  Payment is due upon receipt of an invoice.  All
fees and charges are exclusive of, and VGRS is responsible for the payment of,
all sales, use and like taxes.  Escrow Agent shall have no obligations under
this Agreement until the Initial Invoice has been paid in full by VGRS.

          (b)  Nonpayment.  In the event of non-payment of any fees or charges
               ----------
invoiced by Escrow Agent, Escrow Agent shall give notice of non-payment of any
fee due and payable hereunder to VGRS and, in such an event, VGRS shall have the
right to pay the unpaid fee within ten (10) days after receipt of notice from
Escrow Agent. If VGRS fails to pay in full all fees due during such ten (10) day
period, Escrow Agent shall give notice of non-payment of any fee due and payable
hereunder to ICANN and, in such event, ICANN shall have the right to pay the
unpaid fee within ten (10) days of receipt of such notice from Escrow Agent.
Upon payment of the unpaid fee by either VGRS or ICANN, as the case may be, this
Agreement shall continue in full force and effect until the end of the
applicable term. Failure to pay the unpaid fee under this paragraph 8(b) by
either VGRS or ICANN shall result in termination of this Agreement and the
delivery to ICANN, as specifically instructed by ICANN, of the Deposit Materials
and any Additional Deposits held in escrow by Escrow Agent pursuant to this
Agreement.

     9.   Ownership of Deposit Materials.  The parties recognize and acknowledge
          ------------------------------
that ownership of the Deposit Materials during the effective term of this
Agreement shall remain with VGRS at all times.

     10.  Miscellaneous.
          -------------

          (a)  Remedies. Except for misrepresentation, negligence or misconduct
               --------
by Escrow Agent, its employees, or contractors, Escrow Agent shall not be liable
to VGRS or to ICANN for any act, or failure to act, by Escrow Agent in
connection with this Agreement. Any liability of Escrow Agent regardless of the
cause shall be limited to the fees exchanged under this Agreement. Escrow Agent
will not be liable for special, indirect, incidental or consequential damages
hereunder.

          (b)  Permitted Reliance and Abstention. Escrow Agent may rely and
               ---------------------------------
shall be fully protected in acting or refraining from acting upon any notice or
other document believed by Escrow Agent in good faith to be genuine and to have
been signed or presented by the proper person or entity. Escrow Agent shall have
no duties or responsibilities except those expressly set forth herein.

          (c)  Independent Contractor. Escrow Agent is an independent contractor
               ----------------------
and is not an employee or agent of either VGRS or ICANN.

          (d)  Amendments. This Agreement shall not be modified or amended
               ----------
except by another agreement in writing executed by each of the parties hereto.

                                      148
<PAGE>

          (e)  Assignment.  Neither VGRS nor ICANN may assign or transfer this
               ----------
Agreement (by merger, sale of assets, operation of law, or otherwise), except
that the rights and obligations of VGRS or ICANN automatically shall be
transferred to the assignee of one of those parties' rights and obligations
under the Registry Agreement.  Escrow Agent may not assign or transfer this
Agreement without the prior written consent of both VGRS and ICANN.

          (f)  Entire Agreement.  This Agreement, including all exhibits hereto,
               ----------------
supersedes all prior discussions, understandings and agreements between Escrow
Agent and the other parties with respect to the matters contained herein, and
constitutes the entire agreement between Escrow Agent and the other parties with
respect to the matters contemplated herein. All exhibits attached to Appendix R,
specifically, Exhibit A (consisting of Task Order and Statement of Work, File
Size Estimates, Table 1, Table 2, and Additional Terms and Conditions), Exhibit
B1 and Exhibit B2, are by this reference made a part of this Agreement and are
incorporated herein.

          (g)  Counterparts; Governing Law.  This Agreement may be executed in
               ---------------------------
counterparts, each of which when so executed shall be deemed to be an original
and all of which when taken together shall constitute one and the same
Agreement.  This Agreement shall be governed by and interpreted in accordance
with the laws of California, without regard to its conflicts of law principles.
Except as specifically provided for herein, all of the parties additionally
consent to the personal jurisdiction of California, acknowledge that venue is
proper in any state and Federal court in California, agree to any action related
to this Agreement properly brought in one of these courts, and waive any
objection it has or may have in the future with respect to any of the foregoing.

          (h)  Confidentiality.  Escrow Agent will hold and release the Deposit
               ---------------
Materials only in accordance with the terms and conditions hereof, and will
maintain the confidentiality of the Deposit Materials at all times.

          (i)  Notices.  All notices, requests, demands or other communications
               -------
required or permitted to be given or made under this Agreement shall be in
writing and shall be delivered by hand or by commercial overnight delivery
service which provides for evidence of receipt, or mailed by certified mail,
return receipt requested, postage prepaid. If delivered personally or by
commercial overnight delivery service, the date on which the notice, request,
instruction or document is delivered shall be the date on which delivery is
deemed to be made, and if delivered by mail, the date on which such notice,
request, instruction or document is received shall be the date on which delivery
is deemed to be made. Any party may change its address for the purpose of this
Agreement by notice in writing to the other parties as provided herein.

          (j)  Survival. Paragraphs 5, 6, 8, 9 and 10 shall survive any
               --------
termination of this Agreement.

          (k)  No Waiver. No failure on the part of any party hereto to
               ---------
exercise, and no delay in exercising any right, power or single or partial
exercise of any right, power or remedy by any party will preclude any other or
further exercise thereof or the exercise of any other right, power or remedy. No
express waiver or assent by any party hereto to any breach of or default in any
term or condition of this Agreement shall constitute a waiver of or an assent to
any succeeding breach of or default in the same or any other term or condition
hereof.

                                      149
<PAGE>

     IN WITNESS WHEREOF each of the parties has caused its duly authorized
officer to execute this Agreement as of the date and year first above
written.



Escrow Agent

                    By:  _____________________  Title:____________________

                    Print

Name:____________________________________________________

          Address:______________________________________________________

          _______________________________________________________


          _______________________________________________________


                    Phone:
Fax:_______________________________

                  E-mail:
          _______________________________________________________

VeriSign, Inc.

                   By:  _____________________  Title:____________________

                   Print

Name:___________________________________________________


          Address:______________________________________________________


          _______________________________________________________


          _______________________________________________________

                   Phone:

Fax:_______________________________

                   E-mail:

          _______________________________________________________

Internet Corporation for Assigned Names and Numbers

                   By:
Title:___________________________

                                      150
<PAGE>

                  Print

Name:______________________________________________________


          Address:_________________________________________________________

          _________________________________________________________

          _________________________________________________________

                  Phone:

Fax:_________________________________

                  E-mail:
          _________________________________________________________

                                      151
<PAGE>

                                                                      Appendix T
                                                                      ----------


                      Registry Operator's Monthly Report

Registry Operator shall provide the following information in its monthly
reports. Information reported in response to items 5-12 shall be kept
confidential by ICANN until three months after the end of the month to which the
report relates.

     1.  Accredited Registrar Status.  State the number of registrars for whom
     the Registry Operator had received accreditation notification from ICANN at
     the end of the reporting month, grouped into the following three status
     categories:

          1.1 Operational registrars are those who have authorized access into
          the System for processing domain name registrations. It should be
          noted that operational registrars are not listed on the InterNIC.net
          web site until they specifically request to be listed. This means that
          a registrar may be operational from the point of view of the Registry
          Operator but not listed on the InterNIC site.

          1.2 Registrars in the ramp-up period represent those who have received
          a password to access the Registry operational test and evaluation
          (OT&E) environment. The OT&E environment is provided to allow
          registrars to develop and test their systems with the System.

          1.3 Registrars in the pre-ramp-up period are those who have been sent
          information regarding the Registry TLD, but have not yet entered the
          Ramp-up Period.

     2. Service Level Agreement Performance. Compare Service Level Agreement
     ("SLA") requirements with actual performance measures for the reporting
     month.

     3. TLD Zone File Access Activity. State the zone file access activity for
     the current reporting month including:

          3.1  Total # of zone file access passwords at end of previous month

          3.2  # of new zone file access passwords issued during the reporting
          month

          3.3  Total # of zone file access approvals at end of reporting month

     4. Completed SRS/System Software Releases. State significant releases that
     have occurred since the Effective Date, including:

                                      152
<PAGE>

          4.1  Release Name

          4.2  Features

          4.3  Target Date

          4.4  Complete Date

     5.  Domain Names Under Sponsorship - Per Registrar.  State the number of
     domain names sponsored by each live ICANN-Accredited Registrar in the TLD
     for the current reporting month.

     6.  Nameservers Registered - Per Registrar.  State the number of
     nameservers registered by each ICANN-Accredited Registrar in the TLD for
     the current reporting month.

     7.  Domain Names Registered by Registry Operator.  Provide a list of all
     domain names registered by Registry Operator, other than on a request
     submitted by a registrar pursuant to that registrar's Registry-Registrar
     Agreement, in the Registry TLD.  The list should be broken down in
     accordance with Subsections 3.6.1 and 3.6.2 of the Registry Agreement.

     8.  Whois Service Activity.  State the number of Whois queries during the
     current reporting month.  For registries with fee-based enhanced Whois
     Service, state the number of queries for each service (i.e. basic, xWhois,
     etc.).

     9.  Monthly Growth Trends.  Tabulate the monthly growth trend in total
     Registry transactions.  Transactions should be divided into three
     categories:

          9.1 Write Domain - This category includes the following transactions:
          domain, modify domain, delete domain, renew domain, auto-renew domain
          (if any) and transfer domain.

          9.2 Query Domain - This category includes the following transactions:
          query domain and query domain transfer status.

          9.3 Check Domain - This category includes the following transaction:
          check domain.

          9.4 Write Server - This category includes the following transactions:
          add name server, modify name server, and delete name server.

          9.5 Query Server - This category includes the following transaction:
          query name server.

          9.6 Check Server - This category includes the following transaction:
          check name server.

                                      153
<PAGE>

          9.7 Write Contact (where contact information is maintained under
          registry model) - This category includes the following transactions:
          add contact, modify contact, delete contact, transfer contact.

          9.8 Query Contact (where contact information is maintained under
          registry model) - This category includes the following transactions:
          query contact and query contact transfer status.

          9.9 Check Contact (where contact information is maintained under
          registry model) - This category includes the following transaction:
          check contact.

     10. Total Number of Transactions by Subcategory by Month.  Tabulate the
     monthly growth trend for each transaction in subcategories of the Write
     Domain, Write Server, and Write Contact categories described in Subsection
     9.1 as follows:

          10.1  Add Domain

          10.2  Delete Domain

          10.3  Modify Domain

          10.4  Check Domain

          10.5  Renew Domain

          10.6  Transfer Domain

     11. Daily Transaction Range. Tabulate the number of total daily
     transactions. The range of transaction volume should be shown for each
     month along with the average daily transaction volume.

     12. TLD Geographical Registrations Distribution. Tabulate the number and
     percent of total and new domain name registrations in the Registry TLD
     broken down by geographical location (country code) as of the end of the
     current reporting month. (Only applies where contact information is
     maintained under registry model.)

                                      154
<PAGE>

                                                                      Appendix V
                                                                      ----------


                              Consensus Policies

The Registry Agreement requires Registry Operators to abide by various
specifically stated procedures and also Consensus Policies. Policies adopted
before the date of the Registry Agreement are deemed to be Consensus Policies.
Policies adopted after the date of the Registry Agreement are applicable to
Registry Operator if those policies meet certain requirements regarding the
demonstration of consensus.

The following policies are specifically identified as having been adopted by the
ICANN Board of Directors as of the dates shown below. As such, they are deemed
Consensus Policies:

  . Uniform Domain Name Dispute Resolution Policy - adopted August 26, 1999;
    form of implementation documents approved October 24, 1999.

                                      155
<PAGE>

                                                                      Appendix W
                                                                      ----------

                   Additional Covenants of Registry Operator

1.  Centralized Whois

Registry Operator shall develop and deploy a centralized Whois for the .com,
 .net, and .org TLDs if mandated by ICANN insofar as reasonably feasible,
particularly in view of Registry Operator's dependence on cooperation of third
parties.

2.  Research, Development and Infrastructure Improvements

During the period between the Effective Date of this Agreement and 31 December
2010, Registry Operator agrees to expend a minimum of US$200,000,000 for
research, development, and infrastructure improvements to the .com, .net, and
 .org Registries (the "Improvements"). The intent of the Improvements is to
increase the efficiency and stability of the .com, .net and .org Registries.
Registry Operator shall ensure that a substantial portion of expenditures for
the Improvements occurs prior to 10 November 2007. Registry Operator shall
provide ICANN with an annual report on this research and development activity.

Registry Operator agrees that one of the early goals of the Improvements is to
design and develop a Universal Whois Service that will allow public access and
effective use of Whois across all Registries and all TLDs. Registry Operator
shall commence research and development of the Universal Whois Service no later
than 31 December 2001. Registry Operator shall, insofar as is reasonably
possible in view of Registry Operator's dependence on the cooperation of third
parties, strive to achieve significant progress in implementing the Universal
Whois Service by 31 December 2002.

Registry Operator further agrees that if it successfully designs and develops
the Universal Whois Service it will (a) make the Application Program Interfaces
necessary to produce software which can efficiently deploy and use the Universal
Whois Service available to applications developers on an open, non-proprietary,
standards-based and royalty-free basis, and (b) make the Universal Whois Service
available at a standardized reasonable fee to be negotiated with ICANN.

3.  Limits on Volume Discounts

Registry Operator will not grant any volume adjustment to pricing under
Subsection 3.4.3 until such time as ICANN authorizes Registry Operator to do so.

                                      156
<PAGE>

                                                                      Appendix X
                                                                      ----------


                     Names Registered to Registry Operator
                     -------------------------------------


The domains to be registered by Registry Operator, other than on a request
submitted by a registrar pursuant to that registrar's Registry-Registrar
Agreement, are as follows:

None at this time.

                                      157
<PAGE>

                                                                      Appendix Y
                                                                      ----------

                               Sanctions Program
                               -----------------


This document describes a program (the "Sanctions Program") under which
violations of Subsections 3.5.1 through 3.5.5 and Appendix H (certification and
separation requirements) and Appendix I (Registry Operator's Code of Conduct) of
the Registry Agreement may be addressed, at ICANN's option, by a separate and
additional set of specific monetary sanctions. The Sanctions Program is intended
to allow ICANN flexibility to address violations of those Subsections and
Appendices by means less extreme than proceedings to terminate the Registry
Agreement. Registry Operator agrees that the Sanctions Program is a non-
exclusive and additional option for promoting compliance with Appendices H and
I, and does not (except as stated below) limit or affect in any way ICANN's
ability to employ any other compliance measures or remedies available under the
Registry Agreement.

Registry Operator agrees to participate in and comply with the Sanctions Program
described in this document, provided that all other registry operators having
registry agreements with ICANN for the operation of unsponsored top-level
domains (i.e., top-level domains, other than country-code and infrastructure
domains, not having a sponsoring organization) are obligated to participate in
and comply with a sanctions program with substantially the same provisions.
Failure by Registry Operator to participate in and comply with this sanctions
program according to the terms of this document constitutes a ground for ICANN
to terminate the Registry Agreement.

ICANN and Registry Operator agree that, should the gTLD Constituency of the
Domain Name Supporting Organization propose a substitute Appendix Y at any time
prior to May 1, 2002, and ICANN determines (following an appropriate process of
public notice and comment) that substitution by that Appendix Y would serve the
interests of the Internet community, the substitution will be made.

Investigation:

ICANN may elect to employ the Sanctions Program by sending Registry Operator a
Confidential Notice of Investigation. Should ICANN choose to initiate an
investigation with regard to any particular activity or conduct, it must do so
(a) within 90 days of the time that such activity or conduct is brought to the
attention of the appropriate ICANN employee, and (b) in any event no later than
one year after the episode in question. The Confidential Notice of Investigation
must be given in the manner described by the Registry Agreement, but shall not
be publicly disclosed or commented upon by ICANN unless Registry Operator has
previously disclosed or confirmed its existence. The Confidential Notice of
Investigation must include all of the following:

          1. A statement that an investigation under the Sanctions Program is
          being initiated;

                                      158
<PAGE>

          2. A statement of the possible violation of Subsections 3.5.1 through
          3.5.5 and Appendices H and I being investigated and the reasons for
          believing such violation may have occurred;

          3. A request to Registry Operator to provide to ICANN the information,
          including copies of any documentation, that ICANN believes is
          necessary for it to conduct the investigation, which information must
          be reasonably related to the alleged violation; and

          4. A specification of the ICANN investigator to whom a response should
          be made and the form in which the response should be transmitted.

Registry Operator shall have thirty days (or such larger period as ICANN may
allow) after the date of the Confidential Notice of Investigation to send a
response to the specified ICANN investigator.  The response, which shall be
transmitted to the ICANN investigator in the manner stated in the Confidential
Notice of Investigation, shall include:

     1.   An acknowledgement that an investigation has been initiated;

     2.   Any of the information requested in the Confidential Notice of
          Investigation that Registry Operator chooses to provide in accordance
          with clause 3 above;

     3.   If Registry Operator does not provide any or all of the information
          sought by the Confidential Notice of Investigation, the Registry
          Operator may state its reason(s) for not providing the information,
          and ICANN is free to draw any reasonable inferences from the failure
          to provide such information;

     4.   Any request by the Registry Operator for confidential treatment of any
          of the information supplied, and the reason for such confidential
          treatment; and

     5.   A specification of the name and address of the person appointed by the
          Registry Operator to receive communications concerning the
          investigation ("Authorized Representative").

Any such response shall be treated as confidential by ICANN unless disclosed or
confirmed by Registry Operator.  Within thirty days after transmission of the
Registry Operator's response to the Notice of Investigation, ICANN shall do one
of the following:

     1.   If ICANN chooses to commence a sanctions proceeding based on the
          information it has received from the Registry Operator and otherwise,
          send the Authorized Representative a Statement of Evidence of
          Violation meeting the requirements stated below;

                                      159
<PAGE>

     2.   If ICANN chooses not to proceed with the sanctions proceeding or a
          renewed investigation, send the Authorized Representative a notice
          that the Investigation is closed without further action; or

     3.   If ICANN chooses to seek additional information, send an additional
          Confidential Notice of Investigation to the Registry Operator meeting
          the requirements stated above.

Statement of Evidence of Violation


If ICANN has reason to believe that a violation has occurred, it shall send the
Authorized Representative a Statement of Evidence of Violation. The Statement of
Evidence of Violation shall not be publicly disclosed or commented on by ICANN
unless Registry Operator has previously disclosed or confirmed its existence.
The Statement of Evidence of Violation shall:

1.     Specify the provision(s) of Subsections 3.5.1 through 3.5.5 and
       Appendices H and I of the Registry Agreement that ICANN has reason to
       believe Registry Operator has violated;

2.     Provide a reasonably specific statement of the factual basis of the
       apparent violation;

3.     Include all evidence on which ICANN has relied in concluding it has
       reason to believe that a violation has occurred;

4.     Give the legal and factual basis for ICANN's conclusion that it has
       reason to believe that a violation has occurred, based on a discussion of
       the provisions of the Registry Agreement, the included evidence, and any
       reasonable inferences drawn therefrom; and

5.     State whether the alleged violation would, if established, be a major
       violation or a minor violation (see below) and why.

Within thirty days (or such longer period as ICANN may allow) after the
Statement of Evidence of Violation is sent, the Registry Operator shall send a
response to the ICANN investigator.

Finding of Violation

At least thirty days after the Statement of Evidence of Violation is sent, and
after considering any Registry Operator's response to the Statement of Evidence
of Violation, ICANN may issue a Finding of Violation. A Finding of Violation
must be sent to the person appointed by the Registry Operator to receive
communications concerning the investigation, and shall be posted on ICANN's
website, with appropriate redactions for

                                      160
<PAGE>

material that ICANN and Registry Operator agree is confidential. If no Finding
of Violation is sent within ninety days after the Registry Operator's response
to the Statement of Evidence of Violation, the sanctions proceeding shall be
deemed closed without action.

Any Finding of Violation must:

     1. Specify the provision(s) of Subsections 3.5.1 through 3.5.5 and
     Appendices H and I of the Registry Agreement that ICANN finds Registry
     Operator has violated;

     2. Provide a specific detailed description of the evidence upon which ICANN
     relies in making the finding;

     3. Specifically state any inferences that ICANN draws based on the
     evidence, upon Registry Operator's failure to provide information requested
     in the investigation, or otherwise;

     4. Provide a specific detailed description of the nature of the violation
     found, and state whether the violation is found to be major or minor and
     why; and

     5. State the amount of monetary sanctions assessed for each distinct
     violation found and reasons why the amount is deemed reasonable.

In finding a violation, ICANN may rely on information provided in response to a
Confidential Notice of Investigation, on any evidence included in the Statement
of Evidence of Violation, and on any information provided in response to the
Statement of Evidence. ICANN may draw inferences from any failure by the
Registry Operator to provide information requested in the investigation,
provided those inferences are reasonable in the circumstances. Only one Finding
of Violation may be issued with respect to any particular episode of activity or
conduct.

A violation shall be classified as major or minor based on (a) the effects of
the violation on competition and competitors, (b) the extent to which the
violation appears to be intentional by Registry Operator, considering the level
of the employees or agents involved, prior notice to the Registry Operator of
the circumstances, and other relevant factors, (c) the extent to which the
Registry Operator has established and effectively enforces policies that
prohibit such violations (where the violation involves actions by employees or
agents of Registry Operator that have not been approved by senior management
that has authority to change such policies), (d) prior findings of violations by
the Registry Operator, and (e) any other relevant circumstances.

Sanctions of up to US$10,000 for each violation may be assessed for each minor
violation found and sanctions of up to US$100,000 for each violation may be
assessed for each major violation found. The amount of the financial sanction
shall be proportionate to the violation and other relevant facts.

                                      161
<PAGE>

In the event ICANN makes a Finding of Violation and seeks to impose a monetary
sanction, it may not thereafter issue a cure notice or seek any other remedy on
the basis of the assertion that the same specific episode on which the Finding
of Violation is based constitutes a breach of this Agreement, but it may take
into account the fact of the Finding and sanction in determining that another
violation should be dealt with in a particular way, including by deeming it a
material breach of this Agreement

Review of Finding of Violation

Findings of Violation may be reviewed only by ICANN's Reconsideration Policy or
by arbitration under Subsection 5.9 of the Registry Agreement.

Registry Operator may seek review of any aspect of any Finding of Violation by a
request for reconsideration under ICANN's Reconsideration Policy (as it may be
amended from time to time), provided that the request is submitted within the
time allowed by the policy after the sending of the Finding of Violation.  The
submission of a request for reconsideration shall not be a prerequisite for
seeking review of the Finding of Violation by arbitration.

Registry Operator may also appeal the assessment of sanctions in the Finding of
Violation by giving ICANN written notice of its intention to arbitrate (the
"Arbitration Notice") under Subsection 5.9 of the Registry Agreement. Registry
Operator shall deliver the Arbitration Notice no later than fifteen days after
the Finding of Violation is sent, except that if a timely request for
reconsideration is submitted under ICANN's Reconsideration Policy (as it may be
amended from time to time) the deadline shall be fifteen calendar days after
ICANN has provided contractual notice that the ICANN Board has voted to act or
not to act on the request. If Registry Operator does not deliver an Arbitration
Notice within the time described above, or the Registry Operator causes the
arbitration to be discontinued before decision, the amount of the sanctions
assessed in the Finding of Violation shall be deemed final.

If a timely Arbitration Notice is delivered, the arbitration shall determine,
based on the record, whether the Finding of Violation is warranted and the
amount of sanctions is reasonable. The amount of sanctions as determined
appropriate according to the arbitration decision shall be deemed final.

Payment of Sanctions

Registry Operator shall pay to ICANN the final amount of sanctions within thirty
days after the amount of sanctions is deemed final. Failure to do so shall be a
ground for termination under Subsection 5.4.7 of the Registry Agreement.

                                      162

ClubJuris.Com