Request for Proposals (RFP) for the Development and Operation of the Shared Domain Name Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). Prepared by the Ad Hoc RFP Team Kevin J. Connolly, Editor & Counsel Eaton & Van Winkle, New York, New York kconnolly@evw.com Kent J. Crispin, Co-Editor & Senior Technical Writer Songbird kent@songbird.com Jim Dixon EuroISPA jdd@vbc.net John Gilmore The Internet Society gnu@toad.com Trevor Hales Melbourne Information Technologies Australia Pty. Ltd. hales@MelbourneIT.com.au Javier Sola Asociacion de Usuarios de Internet, Madrid, Spain jsola@aui.es Advisors Dave Crocker Internet Mail Consortium dcrocker@imc.org Leni Mayo Top Level Registries Pty Ltd. Leni@toplevel.net 1. REQUEST FOR PROPOSAL Madam, Sir, You are invited to submit a proposal for the development and operation of the Shared Domain Name Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). Your proposal could form the basis for a contract between your firm and CORE. To enable you to submit a proposal, please find enclosed: (a) Annex I: Terms of Reference (TOR), containing a description of anticipated CORE requirements for which these services are being sought, and other documents in connection with the shared registration system. (b) Annex II: Letter of Acknowledgment; (c) Annex III: Proposal Submission Form, to be completed and returned with your proposal; and (d) Annex IV: certain pertinent terms of the anticipated contract under which the services would be performed. This letter is not to be construed in any way as an offer to contract with your firm/institution. Your attention is drawn in particular to the disclosure contained in this RFP that CORE may not, at the date hereof, have been legally formed or formally organized. Accordingly, your submission must acknowledge that neither CORE nor any person, firm or corporation involved in the preparation of this RFP or in receiving responses to it (collectively, the CORE RFP Team) may be held liable in any way or any circumstances for (i) any contract which may arise herefrom or (ii) any failure, for any reason, to award a contract, or (iii) from the award of a contract or contracts to one or more persons, except for liability upon and as expressly set forth in a formal written contract which CORE may or may not choose to award in connection with the SRS. This provision is not intended to limit, condition or qualify the liability of CORE upon any contract which may be entered into relating to the subject matter of this document. 1.1 SUBMISSION Your proposal shall be prepared in the English language. The authentic proposal shall be written on paper and submitted in accordance herewith. A true copy of the proposal shall be supplied by e-mail. In the event of variation between the paper and electronic copies, CORE or the CORE RFP Team may require a prospective vendor to conform its paper submission to the electronic copy, or it may, in its sole discretion, view the discrepancy as grounds for disqualification. Transmit the electronic copy by e-mail to . Electronic copy should be supplied in readable ASCII text, with any required graphics in JPEG. The technical proposal's Subject line should state "CORE DB Technical Proposal"; the price proposal's Subject line should state "CORE DB Price Proposal". The paper copies of your proposal shall be prepared in duplicate with one marked "Original" and the other marked "Copy". In the event of any discrepancy between them, the original shall govern. The proposal shall be sealed in one outer and two inner envelopes, as detailed below. The outer envelope shall be addressed as follows: Proposal for the Development of the Shared Registration System for the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). {Kevin J. Connolly, Esq. Attorney and Counselor at Law 39th Floor 600 Third Avenue New York, New York 10016 USA}. Mr. Connolly is acting purely as an agent of CORE or the approved registrars who may authorize the issuance of this RFP and the acceptance of proposals in accordance herewith. The approved registrars can be identified by reference to the CORE website: see http://www.gtld-mou.org/docs/reg-results.htm. Both inside envelopes should indicate your firm's name and address. The first inner envelope should be marked "Technical Proposal" and contain the Proposal Submission Form and Technical Component of your proposal. The second inner envelope should be marked "Price Proposal" and include your financial cover letter and Price Component. Proposals must be received by CORE at the above address on or before October 3, 1997 at 5:00 PM local time. Any proposal received after the deadline will be rejected. CORE may, at its discretion, extend the deadline for the submission of proposals, by posting a notice to that effect to the mailing list and on such other facilities of the Internet (including one or more websites and/or Usenet Newsgroups). The extension of the deadline may accompany a modification of the solicitation documents prepared by CORE at its own initiative or in response to a clarification requested by a prospective proposer. Facsimile proposals are not acceptable and will be rejected. You are requested to hold your proposal valid at least for 30 days from the deadline for submission. CORE will make its best effort to select a firm within this period. Assuming that a contract can be satisfactorily agreed to and executed by October 10, 1997, the assignment is expected to commence on October 20, 1997. The selected company must achieve substantial completion of the project by February 9, 1998. Substantial completion means that the Work has reached that stage of progress which permits CORE's members to (a) accept registrations for each of the seven Top Level Domains discussed in the gTLD-MoU, and (b) publish RFC- compliant zone files for the use of the Internet Domain Name System. Other requirements, such as a working WHOIS facility, are essential to the final completion of the work but, depending on the level of functionality achieved by the system as a whole, would not per se preclude a finding of substantial completion. It may well be that CORE will require the insertion of a provision for liquidated damages in the final contract, based on an amount to be paid for each day after the deadline that substantial completion is achieved. The criteria surrounding the establishment of an amount for such liquidated damages are so policy-bound and beyond the scope of the RFP Team's work that no provision is made for liquidated damages. Vendors should nevertheless be prepared to negotiate such terms with CORE if they are selected or close to being selected to perform all or part of the Work of the Project. Please note that the cost of preparing a proposal and of negotiating a contract, including any related travel, is not reimbursable nor can it be included as a direct cost of the assignment. Any queries concerning the Contract Form and the General Conditions(Annex III) should be directed by e-mail to , with a Subject line that begins with"Contract Query". Graphic materials incorporated into a query should be supplied in JPEG format. Written queries concerning the Terms of Reference (Annex I) and the technical aspects of this RFP should be directed by e-mail to , with a Subject line that begins with "Technical Query." A copy of each message received at rfp-submit, together with the answers, will be e-mailed to the mailing list . Queries and suggested revisions to the draft RFP must be received by CORE at the above addresses on or before September 17, 1997 in order to be incorporated into the final RFP. However, questions and issues for clarification may be submitted at any time, before or after the issuance of the RFP. If you intend to submit a proposal, we strongly encourage you to advise the RFP Team of that fact by e-mail to . Please set the subject of your e-mail message to "Potential Vendor." Designate an e-mail address within your firm to which electronic responses will be sent, together with the name, voice telephone number and fax number of the designated contact person within your firm. This is how you will be added to the mailing list, which will provide you with ongoing questions and clarifications from other vendors and the RFP Team. Given the short time permitted for responses to the RFP, we encourage you to begin creating your proposal immediately, and modify it as you receive the changes and clarifications to the Draft RFP via this mailing list. 1.2 DISCLAIMER AND EXCULPATION Interested parties are strongly cautioned that CORE is an organization still in the process of being formed. The Registrars which have already qualified under the GTLD process, and their business, technical, financial and legal consultants believe that CORE will have the means to underwrite the creation, startup and operation of the SRS, but no warranty or representation can be made with respect thereto. Moreover, since CORE has not yet held its organizational meetings, the terms and conditions of this RFP are wholly conditioned upon the approval of CORE at such time as it completes the process of its formal erection. The submission of a proposal by any vendor in response to this RFP shall constitute the Vendors acceptance of the exculpation provision which follows. Note that by its terms, this exculpation provision does not apply to any contract which may be awarded in connection with the subject matter of this RFP. Exculpation and other terms governing the submission of proposals. Vendor will not hold CORE, any member of CORE, or any person acting in connection with the preparation and distribution of this RFP, or receiving responses or other matters in response to this RFP (collectively, the CORE RFP Team ) liable in any way or upon any theory of fact or law whatsoever in connection with this RFP or any response hereto. No person receiving this RFP will acquire any expectancy or legal rights thereby until and unless a formal written contract is entered into between the successful vendor(s) and CORE. The right is reserved to CORE to reject all proposals made in response to this RFP, to change the terms and conditions of the Project, and/or to award a contract for the Project making use of the information and knowledge gleaned from one or more proposals without necessarily giving any one or more persons an opportunity to amend their proposals. All rights in and to any proposal made in response to this RFP shall, by virtue of submission to CORE or as otherwise directed in this RFP, vest in and become the absolute property of CORE. Notwithstanding the foregoing, any Vendor which is not selected to perform the Work or who does not enter into a contract for the performance of the Work before January 1, 1998, may re-use the content of its proposal. In no event, however, may a Vendor assert a claim against CORE, any member of CORE, or any member of the CORE RFP Team in the event that all or any of the ideas, concepts or other matter contained in or inferable from its proposal is eventually incorporated into the SRS or any part thereof, unless such idea or concept is the subject of a patent which (a) predates the issuance of this RFP and (b) is conspicuously disclosed in the proposal. 1.3 CONSTRUCTION OF THIS RFP Reference to or specification of the product or services of a particular manufacturer, vendor or provider shall be construed as establishing a standard of performance or quality and not as an indication that such manufacturer, vendor or provider should be used as a source nor does it conclusively establish that such product or services is suitable for inclusion in the Work for all purposes. Vendors must be aware that a particular product or service might be mentioned or inferable with respect to certain aspects of the Project and nevertheless be unsuited for inclusion in the Work by reason of other features not immediately relevant to the point being illustrated or exemplified. This RFP is an invitation to negotiate. It is not an offer. No Vendor acquires any legal rights or expectancies in connection with the subject matter of this RFP unless and until a formal contract is negotiated, executed and delivered. 1.3.1 CONTENT OF PROPOSAL 1.3.1.1 Abstract. The proposal must be prefixed by an abstract which serves as an executive summary of its content. 1.3.1.2 Technical Component The technical component of your proposal should be concisely presented and structured in the following order to include, but not necessarily be limited to, the following information: (a) Qualification Statement A brief description of your firm and an outline of recent experience on projects of a similar nature, including experience in the country where the Work will be performed and/or installed in the English language concerned. You should also provide information that will facilitate our evaluation of your firm/institution's substantive reliability and financial and managerial capacity to provide the services. You must also state whether your firm is publicly or privately held. If publicly held, you must state the exchange(s) on which your firm's equity interests are traded and identify the most recently filed comprehensive report on your firm s business filed in connection with the securities laws governing your firm as a publicly-held company. If privately held, you must identify each person, firm or corporation which beneficially owns five per cent (5%) or more of your equity or voting rights, as well as any person, firm or corporation owning options or convertible securities which, if exercised or converted, would result in their ownership of five per cent (5%) or more of your firms equity and/or voting rights. The submission of a proposal shall constitute your certification of the truth of each matter of fact contained in the qualification statement, as well as a certification that the qualification statement does not omit any statement of fact needed to make the qualification statement as a whole other than misleading. The contract awarded to the selected Vendor(s) may provide that falsity in such deemed certification is a breach of the entire agreement. (b) Understanding of the Requirements for Services, including Assumptions Include any assumptions as well as comments on the data and support services as indicated in the TOR, or as you may otherwise believe to be necessary. (c) Proposed Approach, Methodology, Timing and Outputs Any comments or suggestions on the TOR, as well as your detailed description of the manner in which your firm/institution would respond to the TOR. You should include the number of person-months in each specialization that you consider necessary to carry out all required work. Your detailed description of the manner in which your firm/institution would respond to the TOR should also be supplied. Provide a detailed schedule of milestones, deliverables, and what major factors you will depend on in meeting each milestone. Include a schedule of what work each team member will be doing in each month of the contract, and how these assignments can be changed to avoid slippage of deliverables. Include any comments or suggestions on the TOR. Describe any parts of the RFP that your contract DOES NOT propose to satisfy. State your reasons for declining to satisfy that section. If CORE accepts your reasons (e.g. the RFP requirement is too burdensome, would make it impossible to meet the schedule, would make the proposal uneconomical), your proposal may still be acceptable despite its incompleteness. (d) Proposed Team Structure The composition of the team which you would propose to provide and the work tasks (including supervisory) which would be assigned to each. An organigram illustrating the reporting lines, together with a description of such organization of the team structure, should support your proposal. (e) Proposed Project Team Members The list of persons who will be involved in the analysis and design should indicate: 1. Area of expertise 2. Experience with similar projects 3. Physical location of person 4. Languages spoken 5. Detailed CVs of Consultants and other key personnel should be attached to the response. The same categories of information should be supplied for personnel proposed for involvement in the operation of the CORE database. The identification of personnel will not be a firm requirement. In light of the uncertainties surrounding this process, it is recognized that Vendors cannot be expected to commit key personnel to this project. The proposal should nevertheless explain the Vendor's depth and experience, and make clear how the Vendor would staff this project in sufficient detail to prepare the final contract. Likewise there is no intention to preclude a Vendor from responding to changing employment conditions. However, it is intended to make clear that a Vendor who secures the contract award on the strength of particularly qualified personnel and then attempts to fulfill the contract with other personnel whose credentials are unequal to those of personnel originally proposed may be found to have acted in bad faith. (f) Scope of Proposals: Creation and Operation Proposals must specify whether they cover the creation of the SRS, its operation, or both. Proposals of all types will be entertained. The Proposal should clearly identify the portions of the Project which are addressed. Submitters' proposals should, among other things, address the following problems which CORE desires to solve: CORE wants an early demonstration that the system can be successfully operated by a separate contractor (or an in-house operation), other than the original software author. This is to prevent becoming "locked-in" to the original vendor. The work required to build the SRS, and later possibly integrate the COM domain into it, mean that CORE probably can't afford to take the time to make such a transition before approximately late 1998. Some suggested ways for proposals to deal with these problems include: Propose to both build the SRS and operate it for an initial period. Teams from two companies, that have a history of working together on successful projects with tight deadlines, could make a joint proposal. No proposals will be accepted which propose operation of the system for longer than eighteen months. A contract for operation of the system will be re-competed by late 1998, and the transition to the next operator will occur in the first quarter of 1999. Any operation proposal in response to this RFP must propose plans for smooth handling of this transition. It is not required that any proposal cover all aspects of this RFP. However, any proposal which covers less than all of the Work and initial operation of the SRS must detail how the different stages of the Project will be differentiated from each other as well as how the transition will be handled. At the same time, if an offer which covers several identifiable parts of the Project is intended to be divisible, so that certain parts may be accepted while others are not, then the proposal must articulate the means by which it may be parsed and separately-accepted. If the several parts are not adequately identified, CORE may treat the proposal as indivisible. 1.3.1.3 Price Component Your separate price component must, to the extent it does not state a comprehensive fixed price, contain a comprehensive statement of the cost of the Work or an objectively verifiable basis for the computation of the cost of the Work, and shall have a cover letter wherein your firm/institution's authorized representative affirms the following: - the price - the period of its validity. It is anticipated that fixed-price quotations for the design and implementation of the SRS will enjoy an advantage over other bases of compensation. The operation of the SRS can be quoted at a fixed price, or based upon such factors as the number of registrars interfacing to the system, number of domain names registered through the system, number of objects stored in the database, volume of transactions processed by the system, or other means to be measured periodically during operation. Such variable quotes shall specify exactly how the numerical values used in computing the price shall be determined, and how disagreements over those values shall be timely resolved. In addition, if stated as a variable price, the price component must cover all the services to be provided and, in order to indicate the basis for its calculation, must itemize the following, or provide equivalent information to evaluate the basis of the price component: - An all-inclusive rate per person-day/hour; - Days/hours to be considered by each team member; - An all-inclusive amount for international travel and related expenses; - An all-inclusive amount for local travel; - Other costs, if any (indicating nature and breakdown); - Summary of total cost for the services proposed. Where the cost of the Work varies depending on whether the Vendor is awarded a single-source contract or the contract makes separate awards for the design, implementation, operation and maintenance of the SRS, state the variation explicitly, unless the entire proposal is predicated upon an expressly-specified combination of work. State where the work will occur. CORE will not have physical premises available within the time-frame necessary for successful operation, so operations proposals must propose a physical location to hold the necessary computers, sufficiently provided-for in terms of power, cooling, security, Internet access, and operational staff. Separately state the cost of providing first- and second-level technical support. "First Level Technical Support" refers to those activities to which the ordinary, trained user of the system turns when unable to obtain the result or operation which is desired. First Level Support should be available 24/7. "Second Level Technical Support" refers to activities, not necessarily available to users at all, to which First Level Technical Support personnel turn when they are unable to resolve the problem. The Second Level Support Team typically includes engineering personnel and others whose familiarity with the Work and the Project enable them to recognize program errors when they present. The proposed schedule of payments, all of which must be expressed and will be effected in the currency of the proposal, must be given and related to the deliverables. It is permitted but not required that the payment schedule relate to a schedule of values which accords to certain identified elements of the Work a proportion of the overall value thereof and set forth an objective means for ascertaining the percentage of completion achieved by each of the several component parts of the Work. You should also indicate any comments or reservations to the draft form contract. 1.3.2 CONFIDENTIALITY OF PROPOSALS. Until October 3, 1997, CORE will exercise reasonable care to prevent the disclosure of the contents of any proposal to a Vendor other than the proposer. CORE makes this undertaking for its own benefit and protection of CORE and not for the protection of the Vendors, who are in any event bound by and subject to the Exculpation Terms and Provisions of the RFP. After October 3, 1997, CORE is free to disclose the terms of each proposal to one or more Vendors with whom it or they are negotiating in good faith with respect to selection as a Vendor or, subsequent to the selection of a Vendor, with respect to the terms and conditions of the contract to be awarded. CORE will take reasonable steps not to disclose the identity of any Vendor during these processes but will not be liable if the identity of a Vendor --whether selected or not-- is disclosed or inferred from the information so disclosed. CORE will act in good faith in connection with its activities under this paragraph. "Good Faith" means honesty in fact and the observance of reasonable standards of commercial conduct. CORE will refrain from intentionally harming the interests of proposers who respond to this RFP except to the extent that conduct specifically permitted under this RFP may not be beneficial to a proposer. In particular, CORE will not facilitate "cherry-picking" of one proposer's good ideas by another during the process of selecting a successful Vendor. However, CORE cannot be restrained from applying the insights and know-how gained from the contract award process in negotiating the final contract and specifying the requirements for the Work. 1.3.3 EVALUATION OF PROPOSALS A two-stage procedure will be used for evaluating the proposals, with evaluation of the technical component being completed prior to any price component being examined and compared. The Price Component will be examined only for those firms whose Technical Component meets the requirements for the assignment. If your technical component is found acceptable, your price proposal will be opened and taken into account. Please note that CORE is not bound to select any of the firms submitting proposals. Furthermore, since a contract will be awarded, if at all, in respect of the proposal which is considered most responsive to the needs of the requirements, due consideration being given to CORE general principles, including economy and efficiency, CORE is not bound in any way to select the firm offering the lowest price. Yours sincerely, ---------------------------------------------------------------- 2. ANNEX I -- TERMS OF REFERENCE (TOR) TERMS OF REFERENCE To the Request for Proposals (RFP) for the Development and operation of the Shared Domain Name Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). 2.1 THE ROLE OF CORE UNDER THE GTLD-MOU CORE is a non-profit association currently being organized under the laws of the Swiss Confederation. CORE has as its objectives the establishment of a structure in which the Registrars can operate in accordance with the provisions of the gTLD-MoU and the best interests of the DNS and the Internet. The gTLD-MoU provides that CORE is one of the components of the self-regulatory framework established by the gTLD-MoU, and charges CORE with operational responsibility for a shared registry system for second level domains within the CORE GTLDs. The basic responsibilities of CORE, adumbrated in Article 7 of the GTLD-MoU, are principally operational. That is, CORE will establish the operational standards which must be met by the Registrars, and it will supply the essential infrastructure for the performance by the Registrars of their functions as such. CORE will be soliciting proposals from interested parties for furnishing of engineering services and other goods, labor and services pertaining to the creation and operation of the CORE Shared Registry System (SRS). Because of the requirement that it be running in production use by February 9, 1998, the procurement and design processes for the SRS must be speedily completed. The approved Registrars have concluded that the universe of potentially-interested suppliers of engineering services, and other goods, labor, and services necessary to the creation of the SRS (collectively, "Vendors") must be apprised immediately of the requirements for the SRS, as well as the terms and conditions on which the present body of registrars believe it probable that a contract may be awarded by CORE. Vendors must nevertheless be aware that none of the CORE RFP Team is or represents CORE and that each and every act performed by an the CORE RFP Team or any member of it may be disaffirmed by CORE upon its due formation and organization. 2.2 BACKGROUND INFORMATION 2.2.1 Domain Name Registries The Domain Name System is a set of Internet-based and Internet related activities which enable end-users of the Internet to communicate with machines connected to the Internet by means of a human-friendly mnemonic code (such as "www.netscape.com") instead of having to remember a computer-friendly Internet address (such as "207.200.73.73"). The sections of this RFP which follow, together with the related documents referred to in the Appendix, set forth the basic requirements of one aspect of the Domain Name System, namely, the Registry Function. Registration is the act of creating a new name (second-level domain name) for a customer and setting up the data structures which enable that name to function on the Internet. Under the gTLD-MoU, registration is done in a shared rather than exclusive manner. That is, many entities (each a "Registrar") will have access to the system for purposes of creating the database objects necessary to enable end users to connect to specified machines connected to the Internet using the domain name system. More detail concerning the functions and operations related to and comprising the registry function is contained in the following sections of this RFP. 2.2.2 Expected Initial Surge The GTLD initiative came about in response to a number of events, including the actual or perceived exhaustion of namespace, that is, the pre-emptive registration of all of the good names for the Internet. Partially as a result of the actual or perceived exhaustion of namespace, the market value of certain domain names has skyrocketed. At the startup of the gTLD Registry System, we expect that there will be a surge of new applicants, presenting a significantly higher load on the system than in its expected steady state. This is expected because a set of new names --for which there is pent-up demand -- will become available. Some of the demand will come from domain name speculators who will attempt to purchase names they view as popular in order to resell them later, even though the GTLD system contains a number of features intended to discourage such speculation. The GTLD-MoU.org website contains a few ideas as to how this demand can be smoothed. Other suggestions have been put forth in a variety of fora, including mailing lists and Usenet newsgroups. Vendors are encouraged to present their best ideas for how to provide CORE with the ability to handle this surge gracefully without excessively raising the cost of the SRS. 2.2.3 Role of Registrars Registrars form the interface between the SRS and the using public. Each Registrar provides its own computers to maintain accounts and process transactions against them. A Registrar accepts transactions, provides payment transactions, interacts with the customer, and submits requests to CORE for the activation of unique second level domain names. 2.2.4 Overall Requirements of the SRS Several important goals must be satisfied by the SRS. These include: - Performance: the SRS must support concurrent database updates from a potentially-significant number of registrars while periodically updating a small number of root servers with new zone files; the expected load is in excess of 5,000 new domains per day and a number of other updates and associated queries. - Security: the SRS must resist tampering, including the insertion of bogus objects, unauthorized modification or destruction of existing data, or adverse effects on operation. - Reliability: the SRS must provide authoritative answers to relevant DNS questions, including the identity of nameservers for zones and the ownership of domain names. - Availability: the SRS must be accessible worldwide on a 24/7 basis - Scalability: the SRS must be capable of responding to extraordinary increases in the volume of the DNS. - Economy: the SRS must be operable at a price which makes the gTLD system more affordable than the existing generic top level domain name registry. 2.2.5 Special Considerations of Mistrust The design of the SRS must take into account that different registrars will be in competition with each other. As such, it must recognize that there will be a lack of mutual trust among registrars. The design of the system, particularly with respect to fairness of access and auditable paper trails, must take account of the fundamental mistrust among registrars which will pervade the operation of the system. A extension of this condition is that registrar trust of the registry should be minimized -- the system should facilitate non-repudiatable record keeping on the part of registrar, for example. 2.2.6 Further Considerations Some further matters which designers will wish to consider include: (1) This RFP permits Fast-Track Design-Build-Furnish-Operate proposals. A Vendor need not cover all aspects of the Project in its proposal, but any proposal which does not cover all aspects must take into account the need to interface with Other Work forming part of the Project. The Design should also take into account the possibility that the need for Other Work will appear during the course of Designing, Building, Furnishing or Operating the Project. Finally, unless a proposal is made on All or Nothing Terms, it must indicate what steps would be taken to parse the services offered into portions which might be awarded and performed separately. (2) This RFP frequently presupposes certain solutions to the problems presented by the task of creating a Shared Registry System for Internet Domain Names. CORE nevertheless expects each Vendor to exercise its independent judgment to identify other problems and better solutions. Furthermore, the RFP is very ambitious in what it asks for. All proposals will be examined, whether or not they meet every specification in the RFP. (3) A possible architecture for the SRS and related systems may be found at http://www.aui.es/core/. This represents one possible set of solutions to one reasonable perception of the design considerations. It is not necessarily exhaustive and it is not necessarily the design which will be followed by the successful Vendors. These considerations are far from exhaustive. As should be clear from a review of this RFP, not only is the work required to be fast-tracked but the preparation of this RFP has been fast-tracked as well. The designer is expected to anticipate, recognize, and articulate the goals and objectives of its design. ---------------------------------------------------------------- 2.3 BUSINESS FUNCTIONS The system can be seen from a number of points of view; each implies a different set of basic functions. 2.3.1 END USERS The term "end user" will be used throughout this document to refer to the customers of a registrar: the individuals or organizations who "own" domain names. The end user is interested in the following general functions: - checking to see whether a gTLD is already in use - registering SLDs under gTLDs managed by CORE - effecting modification of the records for an existing domain owned by the end user - making and replying to challenges from trademark holders and others claiming superior rights to a domain name - above all, making the end user's domain visible in the global DNS system 2.3.2 REGISTRARS Registrars have a somewhat different set of basic requirements: The system must be capable of rapidly and efficiently processing user applications, checking them for validity in various regards, and charging the user where the application goes through. These functions should be amenable to batch processing. The system should also provide the registrar for tools for monitoring activity levels and reporting these and error conditions. It should also provide an interface allowing single transactions, including at least - registering new users, hosts, and domains - modifying these [Note that renewal is a special case of modification.] - deleting these - transferring domains between registrars - renewing domains and possibly viewing users, hosts, and domains; reserving domains; and, under unusual circumstances, reviewing status of pending transactions. The system should optionally also support querying of registrar credit levels with and the transfer of funds to CORE. 2.3.3 CORE 2.3.3.1 Customer Service The system must provide an interface allowing CORE to suspend and transfer domains as a consequence of decisions taken by Administrative Challenge Panels, the WIPO Mediation/Arbitration Process, and compulsory process of courts of competent jurisdiction. The Vendor may (but need not) assume that such transactions will be countersigned by WIPO using a key dedicated to these functions. 2.3.3.2 Finance The system must provide management reports in such form as to enable CORE to set registrar fees based on a cost recovery analysis. It must include comprehensive accounting and billing functions allowing registrars to be accurately billed for services rendered; these must include detailed logging at the transaction level sufficient to allow full rollback and recovery in the case of errors. It must be possible to dump these logs in human readable form or as otherwise required for auditing purposes. It must also be possible to reverse out charges for individual transactions in the case of successful challenges. These reports must make it possible for CORE to operate at a deficit which is assessed to the Registrars under a variety of bases chosen by CORE from time to time. 2.3.3.3 System Administration The system must be capable of automatically generating DNS zone files from information in the CORE database and posting these to the primary gTLD name server. It must similarly generate automatic updates to a primary WhoIs server. These functions must be subject to manual overrides and all should generate comprehensive DNS and WhoIs management reports on demand; these must include performance statistics. 2.3.3.4 Order Entry The system must interoperate with registrar client software, receiving and validating transactions, accepting or rejecting each. The system should support batch downloads of part or all of the CORE database to allow search by trademark search shops. 2.3.3.5 WIPO and ACPs The system must provide an interface allowing it to accept a challenge for forwarding to WIPO for arbitration. It must allow the WIPO system to collect enough information from the database to carry out this function and develop a decision. It must be possible for WIPO to communicate its decision to all affected parties and automatically update the CORE database without human intervention at CORE. 2.3.3.6 Trademark Search The system must provide some form of access allowing the database to be searched on individual domain names, including names on hold; the information returned must include contact information. The system does not need to provide any sort of search logic relating to trademark/tradename search, but the information contained in the database must be effectively and economically accessible. ---------------------------------------------------------------- 2.4 TECHNICAL REQUIREMENTS 2.4.1 COMPONENTS Components Expected are the following deliverables, listed here and described in greater detail below: A Registration Subsystem Component (RSC), further composed of: - An application-level Registrar-Registry Protocol (RRP) - A Transport protocol (E-mail required) - RRP Server (Server) The vendor should also supply reference implementations of - A RRP Client API (API) - A RRP Client (Client) The RSC has many similarities with a standard Order Entry system, and in fact could be considered as a somewhat specialized example of such. A Registry Database (RDB), which contains data about the following objects: - Domains (SLDs within one of the established gTLD domains) - Hosts (Hosts that serve as nameservers for the SLDs) - Contacts (Individuals and organizations responsible for domains) - Keys (Public half of digital signature key pairs) - Registrars (Functional information about each registrar) A vendor should assume that the information to be collected for each of the above classes of objects will change over time, but in the initial implementation will be based on the information specified in the CORE-MoU. All such information, except only authentication information, shall be placed in the public domain and readily accessible. This will include the provision of a facility whereby any interested party can download the entire database economically and efficiently. FTP would meet this criterion. The current situation with respect to the .com, .net, and .org domains, wherein the registrar is not simplifying the task of downloading the relevant databases, will not be permitted with respect to the CORE TLDs. In addition we have: A Logging Subsystem -- many of the subsystems are required to keep logs. These must be stored indefinitely, and also must be available for inspection by any registrar, or other authorized entity. A Backup/archive Subsystem -- provides long term archival storage of logs and data. An Administrative Control Subsystem -- provides various levels of privileged access, for dealing with exceptional circumstances (Results of ACP deliberations, creation/deletion of registrars, etc) A Key Management Subsystem -- public display of public signature keys, secure access to private signature keys -- may use already existing keyservers or certificate authorities (CAs). A Registry Business Function Subsystem -- keeps track of money from registrars used to purchase "Registry Credit Units" (RCUs), and potentially other business information of the registry A Security Subsystem -- establishes an abstract Security Perimeter around certain components of the registry through firewalls or other technologies A Public DNS Subsystem A Public WhoIs Subsystem A Test Suite 2.4.2 INTERFACES RRP Client API RDB --> DNS RDB --> WhoIs RDB --> Backup RDB <--> RRP Server RDB <--> Key Management RDB <--> Business Functions RDB <--> Administrative Control RRP Server --> Logs Business Functions --> Logs Client <--> Key Management Administrative Control <--> Key Management Logs --> Backup 2.4.3 REGISTRY SUBSYSTEM 2.4.3.1 The Protocol Designing the RRP is one of the major jobs specified in this RFP. A well documented, well thought out design is crucial. Documentation similar to an IETF RFC would be a plus. Such documentation need not be included in the proposal, but its preparation as part of the Work is definitely desirable. The RRP consists of requests for a particular operation to be performed that goes from registrar to registry, and replies concerning those request that go from registry to registrar. Each request shall be identified by a globally unique request identifier (RID); each reply shall contain the RID for the request that the reply refers to. Each RRP request shall be signed by the registrar originating the request, with the registrars current signing key. Each RRP reply shall be signed by the RRP server with the Registry's current signature key. The RRP Server will authenticate every RRP request by verifying the registrar signature. The RRP must be designed to support an end user signature for any RRP operation. At a minimum, the first delivery must support end user generated templates signed with PGP 5.0; a means of supporting templates signed with earlier versions of PGP is highly desirable. The RRP must support DSS signatures for registrar and registry signatures. In addition, Vendors may choose to support additional authentication schemes such as those envisioned by the InterNIC Guardian plan: (http://rs.internic.net/nic-support/nicnews/may97/guardian.html). Such schemes involve an ACK/NACK protocol, and registration of contact information and domain names takes place with several operations (each of which is individually atomic). RRP operations can be expressed in templates, or in specially formatted RRP requests. RRP requests, that is, are a particular encoding of an RRP operation. This encoding includes the above mentioned RID and a signature, perhaps protocol-processing friendly op codes, result codes, an indication of the registrars remaining RCU balance, and other machinery. RRP requests and replies shall be 7-bit clean and suitable for transport over E-mail. Binary fields shall be encoded in a standard way. RRP shall be specified as one or more MIME types, and formatting of requests and replies shall use standard MIME mechanisms. Note that for the registry to check an end user signature the end user signed template must be transported unmodified. A lower level communication failure should result in exponential backoff and retries. Most operations should be idempotent. 2.4.3.2 Logging Every RRP request and reply will be logged in total (including signatures) to the Logging Subsystem. 2.4.3.3 RRP Operations The basic RRP operations are CREATE, MODIFY, and DELETE for the following RDB objects: domain, host, contact. However, other operations, for example SHOW or RESERVE, may be necessary or desirable. Furthermore, some semantic decisions may have impact on the protocol design -- for example, a possible implementation of MODIFY semantics would be to require that the request contain a hash of the EXISTING entry (or a hash of the portions being modified) so that the data base can verify that the requestor has an accurate picture of the current state. All these operations should be designed from the point of view of the registrar, not the underlaying database operations, and they should be atomic from the point of view of the registrar -- for example, a CREATE DOMAIN request might also involve creating host and contact objects in the RDB -- this should be done transparently, and the registrar should see this as one atomic operation. However, replies to such composite operations should contain information about each of the subsidiary operations -- in this example, a reference to each contact and host object created. Because there are many policy issues surrounding these various operations, some of which have not been resolved, the RRP Server should support a facility for "policy hooks" for each operation. For example, the circumstances under which a registrar may DELETE a paid up domain are currently unknown. However, the design of the system must allow for the possibility that registrars will be completely disqualified from deleting a paid-up domain unless the transaction has been initiated by the user. 2.4.3.4 Accounting Every request shall have a configurable cost associated with it. This cost is expressed in "Registry Credit Units" (RCUs). Each registrar shall have a current balance of RCUs, maintained in the RDB (perhaps cached in the RRP Server); every authenticated request from that registrar shall decrement that registrar's current balance by the cost of that operation; when the current balance reaches zero a facility must exist to reject all requests with a "0 RCU balance" reply. [Note, however, that some functions may have cost of 0 RCUs; these should be allowed to proceed.] The RCU balance for a registrar is set via the Administrative Control subsystem, after the RCUs are purchased through the Business Functions System. Obviously, an automated system for this would be desirable; however, such an automated system would have to be designed very carefully from a security standpoint, since it would cross the security perimeter. 2.4.3.5 Overall Performance Regardless of RRP operation type, the Registration subsystem must handle a sustained 3600 RRP operations per hour (one per second). That is, it must handle this rate even if all the transactions are worst-case time-burners involving multiple RDB operations and several public key signing or verification operations. This measurement must be made from outside the security perimeter. 2.4.3.6 RRP Server handling of requests The fundamental job of the RRP Server is to receive RRP requests, validate, authenticate, and authorize them, perform the requested operation, and send a reply back. "Validate" means check the syntax and semantic content of request. "Authenticate" means verify the registrar signature, and an end user signature if one is present. "Authorize" means to verify that the authenticated requestor has permission to perform the action. It is the authorization system that will check policy hooks. The registrar signature is checked first. If it fails the request should be rejected immediately. Authorization is checked second, and if it fails the request is also rejected. [Note that the Security Subsystem may eliminate all network traffic not coming from known registrars, as a rudimentary "pre-authentication"step.] From this point processing depends on the specific request, and policy decisions may impact the actual processing done. A very important design goal for the Server is that it can be replicated easily. This goal embodies both scalability and redundancy: Scalable in the sense that if the Server runs on a particular machine, and the machine is overloaded with requests, it should be easy to add a machine with a cloned server, and have it accept some of the load; and redundant in the sense that if one machine running the server should fail, other Server machines are able to take up the slack. Thus, a requirement of this RFP is that there be two instantiations of the Server, and that they run side-by-side for several days of testing. (This may not necessarily be the permanent configuration.) Other techniques for capacity upgrades may also be considered, including possible hardware upgrades (increasing the number of processors on a multi-processor machine, upgrading to faster processors, adding memory or faster disks, and so on). 2.4.3.7 Server Fairness The design of the RRP Server must address the issue of "fairness"of access by registrars. This is a complex issue, and there are divergent views as to its solution. Fundamentally, the registry is a "first come first served" system, and, as long as the system can handle requests as fast as they arrive, nothing more needs to be done. If requests arrive faster than they can be accepted, there is nothing that CAN be done, except to reject the request blindly, hopefully in a manner that causes a retry later. However, if requests can be accepted at a higher rate than they can be completed (that is, the system buffers pending requests),then "fairness" algorithms can be applied to the buffered requests. Similarly, the ORDER in which requests are accepted can affect fairness. In order for a fairness algorithm to be meaningful, the requests to which it is applied must have all arrived at exactly the same time (or in a defined, very small time interval), otherwise first come first serve must take precedence. A feature of an RRP Server, therefore, could be that it is able to buffer a significant number of pending requests. When the buffer is full, requests should be rejected in such a manner as to push the request back to the originator for a retry later. (E-mail does this, and ad hoc protocols can be designed to do it easily.) If the buffer has a group of essentially simultaneous pending requests (whose arrival time priority cannot be resolved), then the server should order those requests in a manner that provides"non-starvation" and "equal-access". That is, if there are N registrars with effectively simultaneous requests in the buffer, one request from each registrar will be processed for every total N requests processed. More generally, respondents to the RFP are required to fully describe whatever mechanisms they propose for providing equal access and non-starvation to all registrars. 2.4.3.8 The Reference RRP Client API Respondents are required to define and supply a reference implementation of an RRP Client API. It's primary purpose is to supply an example from which registrars or other interested parties may build a sophisticated registrar client. Several potential registrars have expressed an intent to build their own client, and indeed a preference for minimizing cost of the proposal by minimizing the effort expended on the Reference RRP Client. There are several general functions that any RRP client will need to perform. These include the following: - checking templates for valid syntax- generating globally unique RIDs- converting templates into signed requests- logging requests and replies- sending a request via some transport protocol- checking the transport protocol for arrival of a reply The Reference Client API should be provided with at least a portable POSIX implementation. An implementation for Microsoft Windows would be a desirable addition. 2.4.3.9 The RRP Reference Client Respondents are also required to define and supply a reference implementation of an RRP Client, using the above API. Such a client will be necessary for checking the functionality of the system as a whole. It is expected, however, that registrars and perhaps enterprising others will develop more sophisticated clients. In addition to presenting a user interface to the functions of the API, a Client could provide functions like DNS or WhoIs queries of current information (useful for modifications), matching of requests with replies (they might overlap), and so on. The reference client must work on POSIX; a Microsoft windows implementation would be desirable as well. The Client may also interface to, or be part of, the Key Management Subsystem. 2.4.2 REGISTRY DATABASE (RDB) The registry database contains all the important permanent data of the registry, for example: - A set of domain objects. These are of course the whole reason for the existence of the registry. A very important point is that each TLD should be treated as an independent set of domain objects -- i.e., a set of independent databases. Like the RRP Server, it must be possible to partition the database onto physically distinct machines. This change must be doable in a reasonably short time -- A vendor who can supply independent databases for each TLD will gain added credibility. - A set of host objects. - A set of contact objects. Must have a field for a signature public key list. - A set of registrar objects that contain data about the current set of registrars, including a list of all signature public keys ever used by that registrar. The exact fields required are not here defined. However, vendors should base their work on the data the InterNIC uses; the template specified in the CORE MoU; and the work on RIDE (http://www.isi.edu/~davidk/ride/index.html). Note that other information may be kept in the database for efficiency or archival purposes. Note that to a first order, contacts == people, and registrars == organizations. This may be a useful alternate abstraction in designing the database. Note that the performance characteristics of this database will need to be considerably greater than 1 transaction per second -- it can potentially be accessed several times for a single RRP operation. It is assumed that the DB server actually runs as a physically distinct machine that does nothing else but database operations. This assumption is based on security concerns -- an isolated machine, providing a single function, is intrinsically easier to secure than a machine providing multiple functions. Since the DB is extremely valuable, its security is a very important consideration. A vendor may propose an alternate architecture; in such a case the security issues must be addressed in detail. A strong request from an approved registrar is for the database to be physically distributed across legal jurisdictions. The DB server could even be redundant machines. In any case it needs to be extremely reliable and stable hardware. It should have a capacity to support 50 million objects. Indefinite archiving of detailed logs at this level may not be necessary, If the logging of RRP operations is sufficient to reconstruct any missing data. Procedures and software to reconstruct missing data would be desirable, in such a case. Database, database administrator, and system administrator access to the database machine should be tightly controlled, of course. The database server must be contained entirely within the Security perimeter, with no direct connection to the Internet. This server can only be directly accessed by the RRP Server and the Administrative Control System (ACS). The RRP Server updates and queries domain, contact, and host objects, and the ACS updates and queries registrar objects. However, reports formatted as DNS zone updates and WhoIs data updates need to be run on at least a daily basis, to be distributed to the DNS system and WhoIs systems, respectively. Running of these reports must not impact the query and update performance of the server. Other reports -- registrar information and so on -- will also run periodically. The performance of the DB server must be such that running of any reports will still leave a comfortable margin in query and update performance. Backups that maintain an archive of the entire object store of the DB server must be performed on a regular and frequent basis --these backups must have minimal impact on DB performance and availability, as well. It is required that the database be completely rebuildable from the backups and logs. 2.4.3 ADMINISTRATIVE CONTROL SUBSYSTEM (ACS) The ACS has 4 primary purposes:- updating registrar data, including RCU balance and public signing keys- implementing administrative actions, such as domain suspension due to a WIPO ACP determination, or transferring domains from one registrar to another in the case of disputes- adding and deleting registrars- manual repair of bad data These functions are very powerful, and must be strongly authenticated and completely and permanently logged. Presumably most of these actions will require special procedures and authorization mechanisms. The ACS is not connected directly to the Internet, resides inside the Security Perimeter, and speaks only to the DB system. [It might be able to send mail notification out through the Security Perimeter.] Physically, the ACS could reside on the same machine the DB runs on, or it could be a separate, standalone machine, connected to the DB machine via a private local network. 2.4.4 KEY MANAGEMENT SUBSYSTEM (KMS) Digital signatures are a vital component of the whole system. Therefore it is important to understand the intended use and meaning of signatures in this context, especially the limitations to the assurances provided by keys. Keys do *not* directly identify persons or organizations -- they only identify the entity that originally established the key. Furthermore, reliability of key authentication depends on how securely the private keys are managed. Given the wide variety of organizations that will be registrars, some key compromises are inevitable, and the KMS must be designed to deal with this. The KMS must provide for generation of new signature key pairs, secure storage of the private key for both registrars and registry, and public dissemination of the public key. Both the registry and the registrars must use this facility to periodically update keys. Easy generation and deployment of keys, therefore, is a firm requirement. Vendor must also address the issue of man-in-the-middle attacks possible because of intercepted public keys. An indefinite history of all signing keys must be kept immediately accessible, so that old signatures can be verified. Vendor must address the issue of maintaining the integrity of this critical database. Vendor must also address the issue of validity periods, guaranteeing that a revoked key cannot be re-used. Note that a public keyserver may provide many of the functions specified here. If a public or commercial facility is used the vendor must describe how. 2.4.5 REGISTRY BUSINESS FUNCTION SUBSYSTEM (RBFS) Like any business entity, a Registry will need to keep business records. However, the RBFS is not intended to keep track of payroll expenses and the like. Instead, its primary purpose is to keep records of the purchase of RCUs by registrars. This will involve yet another database, a database of funds received and RCUs purchased. In general, the more automated the RBFS, the better. In the limit it would only receive notice of online wire transfers of money from authenticated sources, verify the transfer, credit the appropriate account, and update the RDB with an incremented RCU balance, all without human intervention. This may not be possible in a time frame and at a cost CORE is willing to pay. In an international arena, wire transfers may be the medium of choice, but the system/procedures should deal with checks. The interface between the RBFS and the RDB is not defined. For security reasons they should not be physically connected; for convenience and unattended operation they should be connected. In the first model, hand-carried diskette or manual typing at the ACS would be necessary. In the second model the update could be automated. A middle ground would be a very loose, application-level connection, e.g. a serial terminal link, rather than an operating-system level facility like TCP/IP. The vendor must address the security issues involved. 2.4.6 SECURITY SUBSYSTEM The RRP Server, ACS, and RDB must be shielded from external threats coming over the Net. Technologies such as firewalls and screening routers must be used to guarantee that only the allowed protocols make it to the Server. These technologies define the"Security perimeter" around the Server, ACS, and RDB. Only defined protocols should pass the perimeter; tools such as ISS or Satan should be used to verify that no other ports are open. Furthermore, all the machines involved must be configured with security in mind. The latest patches from the hardware vendor must be applied; all unnecessary services on these machines must be turned off, only a restricted set of user accounts will be installed, and only for the purpose of system administration activities --these machines should not be used for any general computing purpose. A description of how the Security subsystem shall be kept up-to-date with the latest security-related patches shall be provided. 2.4.7 LOGGING SUBSYSTEM The logs will be archived indefinitely in a secure manner. The data in these logs will be available in a timely manner (no more than 24 hour delay) to any registrar, either through bulk transfer, or (preferably) through a database access (this would be a separate database from the RDB). This access to the log data maybe served from outside the security perimeter; but the original of the logs must be maintained in a manner equivalent to the RDB itself. Logs must be backed up and permanently archived. 2.4.8 BACKUPS/ARCHIVE It is a fundamental requirement of several subsystems that they support frequent and reliable backups. A further requirement for some systems is that backups be permanently archived. While it is possible that a vendor could propose a solution with each subsystem handling these issues independently, instead of developing a particular subsystem to handle them all, the vendor must then clearly document how the backups from the individual subsystems meet operational requirements. 2.4.9 PUBLIC DNS SUBSYSTEM Vendor must provide primary DNS name service for all the TLDs managed by CORE. The primary name server shall meet or exceed all the requirements of RFC2010. This primary server shall receive zone updates/transfers directly from the registration subsystem. Vendor must provide a means for zone updates to be generated by the RDB and installed In the master. It should be possible to make zone updates/transfers at least daily. In addition to the primary gTLD name server, at least 3, and preferably substantially more, secondary gTLD name servers must be deployed. Two options have been proposed for this: 1) Vendor will provide secondary servers; and 2) CORE will provide secondary servers through its members. A hybrid possibility is that vendor will subcontract back to CORE members with appropriate capabilities. Vendor will work with CORE to fulfill the requirement for DNS secondaries. Vendor may also propose that a number of secondary gTLD servers be hosted by some of the organizations currently hosting secondary root name servers on a volunteer basis, or by similarly qualified organizations. Reliability, robustness, and performance of these servers should be appropriate for a fundamental infrastructure component for the entire Internet. Each should serve an aggregate query rate of at least 3000/sec. These machines will be directly on the Internet; they must be administered in a very secure manner. Only the bare minimum of necessary services should run on these machines. This RFP is for development, and it is not necessary that the vendor commit to long term operation of the gTLD servers. However, vendors proposing to operate the service should be prepared to do so for 15 months. 2.4.10 FURTHER DNS CONSIDERATIONS DNS access to the system must be indirect, DNS queries must not be made directly to the RDB. The expected process is that some kind of report generator will be run to write a set of standard DNS master zone files from the RDB, and that those master zone files will then be propagated to the DNS nameservers, perhaps after some further processing. If possible, COREDB and the DNS zone file generation mechanism should be able to support all of the standard (IETF standards track) DNS types in the IN class. At a minimum, it must support the SOA, NS, and A types for current operation, and must be upgradable to support the AAAA, KEY, SIG, and NXT types for future operation. The NXT and SIG types will probably be added during a post-processing phase rather than being stored directly in the RDB. Support for DNSSEC and IPv6 AAAA RRs will probably become necessary in the near future if not immediately. Both of these specifications are still recent enough that CORE's deployment must not be delayed to wait for them, but once they are stable they are likely to become required services, so any current plans must consider them. All generation and processing of the SERIAL field of any SOA RR must obey the rules described in RFC-1982 (or its successors on the IETF standards track). So-called "dotted serial numbers" and other dangerous non-standard mechanisms must not be used. Every new version of any DNS zone file must have a new and unique SOA SERIAL number. Due to the expected large size of the DNS master zone files, it will probably be prohibitively slow to propagate entire zone files across the net on a regular basis, so the DNS infrastructure will require some way of propagating just the changes between two versions of a zone file, both from the RDB to the DNS servers and possibly between the DNS servers themselves. The appropriate technique for this may depend on details of the RDB security architecture. For communication between DNS servers, DNS Incremental Zone Transfer (IXFR) as specified in RFC-1995 (or its successors on the IETF standards track) may be appropriate. Alternatively, a solution based on the Unix "diff", "patch", "md5", and "scp" programs might be appropriate. Any solution of this type will require keeping several previous versions of the master DNS zone files available in order to compute the necessary change histories. All of the mechanisms for generating, transferring, and installing new DNS master files must take extreme care not to install truncated, corrupted, or otherwise damaged zone files. Automatic fallback to stale data is acceptable, installation of partial or corrupt data is not. Suggested techniques include (but are not limited to) atomic installation of new files or directories, and careful use of MD5 checksums or other verification techniques of this type. Wherever possible, any DNS name servers operated by CORE should use unmodified copies of the latest official version of the name server software (presumably ISC BIND). If modifications to the code are necessary, the vendor must make all reasonable attempts to propagate these code changes back to the code maintainers for inclusion in future releases. Operation should be consistent with good practice specified in the "Common DNS Errors" series of Informational RFCs (currently RFC-1912, RFC-1537, and RFC-1536 -- see current RFC index for full list). 2.4.11 PUBLIC WHOIS SUBSYSTEM Vendor must provide, either directly, or through a subcontract, or through arrangement with CORE, in a manner similar to that described above for DNS service, the capability to support full WhoIs service, using multiple redundant dispersed servers, well connected to the net. Besides the servers, vendor must provide a means for updates to be generated by the RDB and installed in the WhoIs service. This should happen at least daily. This RFP is for development, and it is not necessary that the vendor commit to a long term operation of WhoIs. However, vendors proposing to operate the service should be prepared to do so for 15 months. 2.4.12 TEST SUITE/QUALITY ASSURANCE Vendor must provide a Quality Assurance plan outlining the subsystem and integration testing to be performed. The plan should reflect an understanding of how the subsystem components are to be tested independently of one another and how the integration testing provides confidence that the entire system is robust. Vendor also must supply documentation providing a complete architectural overview of the system and it's major interfaces and components. The documentation is not intended to serve as a detailed description and definition of the system. Rather its purpose is to act as a communication tool amongst the various parties involved in the project, and to provide some context for the QA plan. Succinct descriptions and use of a widely-understood modeling notation may best suit this purpose. With the QA plan the Vendor must provide a test suite that exercises every protocol operation; as a performance test the system must support a sustained rate of domain creation at a rate greater than 3600/hour; this test must run for a full hour before acceptance. Also, the vendor must produce a number of test data sets, each of which contains multiple instances of every class of input error and each of which contains multiple classes of conflicts. For our purposes an error occurs when the input data does not parse correctly or where the data in input fields contains inadmissible values. Similarly a conflict occurs where a database transaction cannot be completed because, for example, there is already a record in the database with a given unique key. Associated with each test data set there should be a snapshot of an initial state and a snapshot of the database after the test data is fed into the system in sequence. The system can then be tested by setting it to an initial state, feeding in a fully serialized test data set, and checking to see that the expected end state results. The system can also be tested in real time by feeding in multiple test data sets in parallel. In this case all input errors must be detected but the end state of the database will not necessarily be predictable. The QA plan, overview documentation, test data sets, start states, and end states will be part of the deliverables of the contract. ---------------------------------------------------------------- 2.5 IMPLEMENTATION REQUIREMENTS 2.5.1 OPEN STANDARDS If feasible given our requirements for reliability and implementation schedule, the system software should use open standards. Specifically - if possible it should use a freely available, public domain operating system and preferably one that is portable over a number of hardware platforms - similarly it should use if possible use a public domain database package - similarly it should be developed using public domain software tools Any use of a proprietary operating system, database package, or software tools should be explicitly justified by showing that such use will significantly lower costs or improve reliability or is necessary to complete the project within the time allowed. 2.5.2 NON-EXCLUSIVE LICENSE Any software developed under this contract must be free of any encumbrance and freely redistributable by CORE under a Berkeley-style software license without further payments to the contractor either by CORE or by any CORE licensee. 2.5.3 PRIOR IMPLEMENTATIONS OF SIMILAR SOFTWARE The software may be modeled on or derived from an already existing implementation of a shared repository. If this is the case, vendor should identify the model, and address the issue of any intellectual property claims that may be involved. Proposal of software based on a working model is encouraged, but this does not mean that this approach will automatically be favored over a clean sheet of paper design. 2.6 FUNCTIONAL SPECIFICATIONS 2.6.1 GENERAL The system should be built against a set of detailed functional specifications which will be one of the deliverables under the contract. Implementation should follow approval of the specification, but the specification may be modular and the implementation of one module may begin before the detailed specification of all other modules is complete, so long as the interface specification is complete. 2.6.2 MODULARITY The system must be implemented in a modular fashion so that system components can be upgraded or replaced without necessitating changes elsewhere in the system. That is, the system must be built as a number of major components with all interactions between the components passing through a limited set of well-defined interfaces. 2.6.3 PRIMARY VS SECONDARY FUNCTIONALITY If it is possible to do so without significantly slowing system development, the system software should be specified at two or more levels, where the level 0 system provides the minimum necessary functionality and higher levels provide additional desirable functionality. Should such a division of functionality be possible, the system shall then be implemented in such as way as to have a fully functional level 0 system running as quickly as possible. 2.6.4 DEBUGGING AND TECHNICAL SUPPORT The system must incorporate a reasonable level of debugging support. The contractor is invited to propose what level of debugging is necessary and what types of debugging tools should constitute part of the deliverables of the contract. Proposals for creation of the SRS shall include technical support through the first eighteen months of operation, provided to CORE, the central database operation, and to all registrars (users of the SRS). Proposals for operation of the SRS shall include operational support provided to CORE and to all registrars through the term of the contract. Such support includes answering telephone questions about the general status of the system, resolving specific technical issues when the SRS appears to be malfunctioning, responding to inquiries from CORE about operational problems or proposed alterations, tracking down operational problems reported by outsiders. Operations staff will also handle internal operational problems such as equipment failures, upgrades for higher capacity as required, cleanup from failures to follow procedures, and installation of new registrars. 2.6.5 PRIMARY AND SECONDARY NAME SERVERS The contractor should clearly state how the proposed system is to be interfaced to the primary gTLD name server, how many secondary gTLD name servers there will be, and where these will be located geographically and in terms of network connectivity. The primary name server should have a RAID or similarly reliable disk storage system and dual hot-swappable power supplies. This server should be duplicated, and it should be possible to swap the servers, while in production use, without losing any messages. Console access shall be the only way into the systems. Alternatively the vendor may approve a demonstrably superior implementation. 2.7 OPERATIONS REQUIREMENTS 2.7.1 PHYSICAL LOCATION 2.7.1.1 Place The location at which the vendor proposes to host the operation of CORE should be described in detail, indicating its physical attributes that affect reliable computer operation. 2.7.1.2 Security conditions Specify what measures are proposed for physical security of the SRS systems, including emergency and disaster preparedness. 2.7.1.3 Access Method by which contractor will control access to systems. People who will be allowed to enter the actual computer room or have access to communication lines. Protection that will be set against unauthorized access. 2.7.1.4 Physical wires routed diversely If possible, the physical connections to the different ISPs should not be carried in the same wire or conduit, to prevent "backhoe fade" from disabling the redundant connectivity. 2.7.1.5 Power Specify provisions for carrying on service during interruptions in electrical power, air conditioning, or other services supplied to the physical environment. 2.7.1.6 More than one ISP. The contractor should have Internet connections with at least two different ISPs. If possible, these ISPs will be connected to two different telecommunication companies, for a total of four different paths to the Internet backbone. 2.7.2 DISASTER RECOVERY PLANS The vendor must include in his response an outline of what his disaster recovery plan will be. The final plan will be part of the overall project and should be included in the bid (must be included in deliverables). The plan must include: 2.7.2.1 Validity and Integrity of Backups Contractor must assure that in no case, because of voluntary or involuntary mishandling of processes, may a back-up be wrong, incomplete or just not done. 2.7.2.2 Physical Security of Backups Back-ups will have to be placed in secure sites. An option would be to have two copies, one in a fire-proof closet in the physical location and another one outside. 2.7.2.3 Redundancy The vendor should also consider the possibility of a completely redundant facility to be used in the case of total failure of systems due to a major disaster. Vendors could, for example, propose using his facilities as a back-up location in case CORE decides to move operations to its own site. 2.7.3 Service and availability Primary name servers must in any case be on line 24x7. The vendor must propose and justify the operations schedule for other systems components The vendor must propose a working schedule for administrative staff, a physical location, and other facilities. Where operations staff are on standby and actual physical interventions are to be done by 'remote hands', the times during which this is to apply should be clearly identified, and the means for communicating with such staff (beeper, cellular phone, etc) described, together with the means planned for coping with inability to reach staff on standby. Vendor must establish response time limits in case of hardware and software failures. Reliable operation at start-up will be critical; vendor should provide very rapid response during the first 15 days of operation. 2.8 DELIVERABLES In responding to this RFP, the following areas are essential and must be addressed in the submission. Additional items as considered necessary should also be answered. 1) "Costings" - Pricing estimate. Details must be provided as the total costs for development, test and delivery of an operating system. Information concerning the payment arrangements may be provided as deemed necessary. In addition the details for maintenance costs and procedures should also be included. 2) The system has two major components, first the Order Entry system for domain names and secondly the accounting system. a) Functional registry order entry system. Extensive details are required as to the functional specification for the order entry system. The components and associated interfaces must be provided. b) Functional CORE accounting system. An important aspect of this system is the accounting requirements for the system as a whole and those financial aspects for each registrar. The response needs to address both these aspects when responding to the financial area of the system. 3) Project plan. A detailed plan with dates and milestones must be provided. This plan should highlight when different components / services {areas of functionality} will be available and tested. 4) Operations procedures documents. For the external operation of the core system, extensive documentation needs to be provided as to the development, running and day to day operation of the system. This should included essential details as to how to backup and recover the system should be a crash. 5) Testing plan/strategy. In order for CORE to have a degree of faith in the system, details should be provided as to testing of the correctness and reliability of the proposed implementation. This must include the QA plan, overview, test data sets, and start/end data sets described in the TEST SUITE/QUALITY ASSURANCE section. 6) Registrar reference client implementation. CORE is composed of a number of registrars. Each registrar submits different types of transactions to the core system. As part of the RFP, the successful bid must provide a reference client implementation that provides basic functionality for the different type of requests. 7) System design documentation. The core implementation is composed of a number of components. The necessary documentation is required that provides details as to the integration of the components and provides details of dynamics of their interaction. 8) Operational infrastructure. For each submission, details need to be provided for the following components needed to implement and maintain an operational system. a) Hardware - details of hardware platform on which the system is implemented, e.g. disk, ram, speed. b) Software - details of software components necessary for the system, e.g., database engine, accounting package, and operating system c) Licenses - what third party licenses need to be maintained in order to maintain the implemented system. d) Wetware - What staffing, policies and procedures are needed tp operate the SRS. 2.9 PROJECT SCHEDULE The major considerations in determining the implementation timetable are (a) the expiration of NSI's contract on 1 April 1998 and (b) the 6-month wind-down period provided for in the NSI/NSF contract. New York Meeting 4 Sep 1997 Draft RFP available 11 Sep Public Comment period end 17 Sep Final RFP issued 26 Sep Response period ends 3 Oct Selection Announcement 10 Oct Development begins 20 Oct (start spending money) Component testing 17 Nov System testing begins 15 Dec (final engineering) Testing with registrars 12 Jan 1998 (acceptance, beta testing) Controlled operation begins 26 Feb (start w/clean database) Full production operation begins, without com/net/org 9 Mar (stable, public) Begin developing transition to add com/net/org 1 Apr Begin testing of com/net/org transition 1 Jul Begin testing com/net/org databases fully integrated 1 Oct 1998 ---------------------------------------------------------------- 2.10 APPENDIX Terminology Certification Authority gTLD Policy Oversight Committee (POC) Council of Registrars (CORE) Registrant (end user) Registrar Registry (TLD) Repository (TLD DB) WhoIs database Zone file 2.11 RELATED DOCUMENTS 2.11.1 Mailing Lists The following mailing lists have been established for the receipt of information pertaining to this RFP: rfp-team internal discussions about the RFP rfp-submit (one-way channel to RFP Team) incoming email about the RFP) rfp-vendors outgoing to vendors (gets copies of rfp-submit, and announcements from rfp-announce) rfp-announce outgoing to any interested parties To subscribe to these lists, send a message to: -request@mou.org with the single word "subscribe" as the body of the message. The archives of the rfp-submit and rfp-announce lists will be kept at a URL to be announced and posted periodically on the RFP Website and through RFP-Announce. The RFP Team maintains a website at http://www.core.gtld-mou.org/rfp. 2.11.2 Relevant RFCs This list does not purport to be accurate or exhaustive. Vendors may care to establish their qualifications by commenting on, expanding, criticizing the contents of this list. 1034 Domain Names - Concepts and Facilities 1035 Domain Names - Implementation and Specification 1101 DNS Encoding of Network Names and Other Types 1155 Structure and Identification of Management Information for TCP/IP-based Internets 1183 New DNS RR Definitions 1536 Common DNS Implementation Errors and Suggested Fixes 1537 Common DNS Data File Configuration Errors 1637 DNS NSAP RRs 1876 A Method for Expressing Location Information in the DNS 1912 Common DNS Operational and Configuration Errors 1982 Serial Number Arithmetic 1995 Incremental Zone Transfers in DNS 1996 A Mechanism for Prompt Notification of Zone Changes 2010 Operational Criteria for Root Name Servers 2015 MIME Security with Pretty Good Privacy (PGP) 2045-2049 The Mime RFCs 2065 DNS Security Extensions 2136 Dynamic Updates in the DNS 2137 Secure DNS Dynamic Update 2181 Clarifications to the DNS Specification 2.11.3 Relevant GTLD-MOU Documents and URLs at Which they are available gTLD-MoU http://www.gtld-mou.org/gTLD-MoU.html CORE MoU http://www.gtld-mou.org/docs/core-mou.html CORE Articles of Association http://www.gtld-mou.org/docs/core-ass.htm ACP Substantive Guidelines http://www.gtld-mou.org/docs/racps.htm <> ------------------------------------------------------------ 3. ANNEX II -- LETTER OF INTENT ANNEX II TO THE REQUEST FOR PROPOSALS Date: ______________ 1997 ACKNOWLEDGEMENT SUBJECT: FORMAL REQUEST FOR PROPOSAL Dear Sir/Madam, We, the undersigned, acknowledge receipt of your Request for Proposal, and hereby confirm that we: ( ) intend ( ) do not intend to submit a proposal to the CORE RFP Team by deadline 5 p.m. New York City Time on October 3, 1997). Yours sincerely, Signature Name and Title: Name and Address of Bidder: E-Mail Address: Telephone Number: Fax Number: RETURN IMMEDIATELY VIA FAX TO: CORE RFP Team c/o Kevin J. Connolly, Esq. 39th Floor 600 Third Avenue New York, NY 10016 USA (212) 986-8711 or by e-mail (preferred) to rfp-submit@gtld-mou.org, setting the subject of the message to "RFP Ack[nowledgement]". ---------------------------------------------------------------- 4. ANNEX III -- SUBMISSION FORM ANNEX III TO THE REQUEST FOR PROPOSALS for the Development and operation of the Shared Domain Name Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). PROPOSAL SUBMISSION FORM TO: CORE RFP Team c/o Kevin J. Connolly 39th Floor 600 Third Avenue New York, New York 10016 USA Gentlemen, Having examined the Solicitation documents, the receipt of which is hereby duly acknowledged, we the undersigned, offer to supply the required services for the sum as may be ascertained in accordance with the Price Component attached hereto and made part of this proposal. We undertake, if our proposal is accepted, to commence and complete delivery of all items in the contract within the time frame stipulated. We understand that you are not bound to accept any proposal you may receive and that a biding contract would result only after final negotiations are concluded on the basis of the Technical and Price Components proposed. Dated this day of , 1997 Signature (in the Capacity of) Duly authorized to sign proposal for and on behalf of: ---------------------------------------------------------------- 5. ANNEX IV -- CONTRACT FORM ANNEX IV TO THE REQUEST FOR PROPOSALS for the Development and operation of the Shared Domain Name Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). CONTRACT FORM GENERAL CONDITIONS FOR CORE PROCUREMENT CONTRACTS CONTRACT BETWEEN The CORE Association AND [INSERT NAME OF THE COMPANY] THIS CONTRACT is made this [INSERT DATE] by and between the CORE Association, an association organized and existing under and by virtue of Articles 60-79 of the Swiss Civil Code, having its statutory seat at Geneva, Switzerland, (hereinafter referred to as CORE ), and [INSERT NAME OF THE COMPANY], a corporation incorporated under the laws of [INSERT NAME OF THE COUNTRY] and having its principal office in [INSERT COMPLETE ADDRESS] (hereinafter referred to as the Vendor ). CORE and the Vendor are collectively hereinafter referred to as the Parties. WITNESSETH In consideration of the mutual covenants and subject to the terms and conditions hereinafter set forth, CORE wishes to engage the Vendor for the Development and/or operation of the Shared Domain Name Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). The Parties agree as follows: 1. Contract Documents 1.1 This document (hereinafter referred to as the "Basic Contract"), including all of its Annexes and the following named documents, incorporated herein by reference, constitute the entire Contract between the Parties (hereinafter referred to as the Contract ): 1. CORE's Request for Proposal dated [INSERT DATE]; 2. The Vendor's Proposal dated [INSERT DATE]. 1.2 The Annexes to this Basic Contract are the following: 1. Annex I: Statement of Work; 2. Annex II: CORE General Conditions for Professional Services; 3. Annex III: Payment Schedule. 1.3 In the event of any conflict or inconsistencies between or among any of the documents comprising this Contract, where possible,the documents shall be construed to require the greater amount or quality of work, the sooner completion of the Work, the lesser price of the Work and the later payment thereof. If that rule cannot sensibly be applied, then the following order of priority shall apply: 1. First, this Basic Contract and Annex II; 2. Second, the remaining Annexes to this Basic Contract; 3. Third, CORE's RFP; 4. Fourth, the Vendor's Proposal. 2 Obligations of the Vendor 2.1 The Vendor shall perform and complete the Services described in Annex I with due diligence and efficiency and in accordance with the Contract. 2.2 The Vendor services shall be provided by any or all of the following personnel: Name Specialization Nationality Period of service /.../ 2.3 Any changes in the above personnel shall require prior written approval of CORE. 2.4 The Vendor shall also provide all technical and administrative support needed in order to ensure the timely and satisfactory performance of the Services. 2.5 The Vendor shall submit to CORE the deliverables specified hereunder or in the RFP according to the following schedule and/or the schedules required to be delivered under the terms hereof. [LIST DELIVERABLES] [INDICATE DELIVERY DATES] e.g.Progress/Design report ................... Final deliverables and report 2.6 All deliverables shall be provided in the English language, and shall describe in detail the services rendered under this Contract during the period of time covered in such deliverable. All deliverables shall be transmitted by the Vendor by mail or courier to the CORE address specified in? below. 2.7 The Vendor represents and warrants the accuracy of any information or data provided to CORE for the purpose of entering into this Contract, including, without limitations, all representations made in the Proposal, as well as the quality of the deliverables and reports foreseen under this Contract in accordance with the highest industry and professional standards. 3 Price and Payment 3.1 In full consideration for the complete and satisfactory performance of the Services under this Contract, CORE shall pay the Vendor a {{fixed contract price of [INSERT CURRENCY & AMOUNT IN FIGURES AND WORDS].}} {{contract price to be computed as stated in the Price Attachment.}} 3.2 The price of this Contract is not subject to any adjustment or revision because of price or currency fluctuations or the actual costs incurred by the Vendor in the performance of this Contract. {{If fixed-cost contract: However, the price of this Contract shall be adjusted to reflect changes in the cost of performance occasioned by changes in the Work specified by CORE after the execution thereof.}} 3.3 Payments effected by CORE to the Vendor shall be deemed neither to relieve the Vendor of its obligations under this Contract nor as acceptance by CORE of the Vendor's performance of the Services. 3.4 CORE shall effect payments to the Vendor after acceptance of the invoices submitted by the Vendor to the CORE address specified in 9.1 below. The payment schedule shall foresee a maximum of 3 (three) installments. Each installment shall be related to the submission of a certain number of deliverables to be clearly indicated (the deliverables on article 2 are not necessarily in chronological order). The last installment, however, will be of 30% of the total price. All the payments will be effected within 30 days after receipt of the invoice and subject to the satisfactory acceptance of the deliverables. Payment of the last installment, will be subject to the overall satisfactory contract performance. 4. Special conditions 4.1 No special conditions shall apply. 5. Submission of invoices 5.1 An original invoice shall be submitted by mail by the Vendor foreach payment under this Contract to the following address: <<>> 5.2 Invoices submitted by fax shall not be accepted by CORE. 6 Time and manner of payment 6.1 Invoices shall be paid within thirty (30) days of the date of their receipt and acceptance by CORE. 6.2 All payments shall be made by CORE to the following Bank account of the Vendor: [NAME OF THE BANK][ACCOUNT NUMBER][ADDRESS OF THE BANK] 7. Entry into force. Time limits 7.1 This Contract shall enter into force upon its signature by both Parties. The Vendor shall commence the performance of the Services not later than [INSERT DATE] and shall complete the Services within [INSERTNUMBER OF DAYS OR MONTHS] of such commencement. 7.2 All time limits contained in this Contract shall be deemed to be of the essence in respect of the performance of the Services. 8. Modifications 8.1 Any modification to this Contract shall require an amendment in writing duly signed by both Parties. 9. Notifications 9.1 For the purpose of notifications under this Contract, the addresses of CORE and the Vendor are as follows: For CORE: Ref.[INSERT CONTRACT REFERENCE & NUMBER as applicable....] Telex: Fax: Cable: For the Vendor: [Insert Name, Address and Telex, Fax and Cable Numbers] IN WITNESS THEREOF, the Parties have signed this Agreement. [Insert name of the company] CORE By: By: ________________ Name: Name: _____________ Title: Title: Assistant Director General Date: Date:________________ ANNEX I To Contract for the Development and operation of the Shared DomainName Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). STATEMENT OF WORK [To be prepared based on the selected proposal] ANNEX II To Contract the Development and operation of the Shared Domain Name Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU). GENERAL CONDITIONS FOR CORE CONTRACTS Table of Contents Articles General Conditions 1 Independent Contractor, Assignment and Removal of Personnel 2 Vendor's General Responsibilities 3 Insurance 4 Subcontracting 5 Confidential Nature of Documents 6 Copyright, Patents and Other Proprietary Rights 7 Exclusivity of Services 8 Amendments 9 Payment 10 Delays 11 Termination by CORE 12 Termination by the Vendor 13 Bankruptcy 14 Arbitration 15 Form of Notice, Request, Statement or Approval GENERAL CONDITIONS FOR CORE PROCUREMENT CONTRACTS Article 1 Independent Contractor, Assignment and Removal of Personnel (1) Nothing contained in this Contract shall be construed as establishing or creating between CORE and the Vendor the relationship of principal and agent or employer and employee; it being understood that the Vendor is an independent contractor in relation to CORE. No person engaged by the Vendor in connection with the performance of any obligation under this Contract shall be regarded as an agent or employee of CORE, and the Vendor shall be solely responsible for all claims by such persons arising out of or in connection with their engagement by the Vendor. (2) Other than persons specifically named in this Contract, no person shall be assigned by the Vendor to work or perform services in connection with this Contract until after the Vendor has notified CORE of the identity of such proposed persons, has provided CORE with their curricula vitae, and CORE has notified the Vendor that CORE approves of such assignments. (3) Upon reasonable notice by CORE in writing stating its reasons, the Vendor shall promptly withdraw any person assigned to work or perform services in connection with this Contract and shall as soon as practically possible assign new persons in accordance with the provisions of paragraph (2) of this Article. CORE shall not unreasonably refuse or delay approval of any such replacement. Such withdrawal or replacement shall not be a cause for suspension of the Contract. Any costs or expenses resulting from any withdrawal or replacement of persons pursuant to this Article shall be borne by the Vendor. Article 2 Vendor's General Responsibilities (1) The Vendor warrants that it shall perform its obligations under this Contract with due diligence and efficiency and in conformity with generally accepted, sound professional, administrative and financial standards. (2) The Vendor shall act at all times so as to protect, and not be in conflict with, the interests of CORE, and shall take all reasonable steps to keep all costs and expenses at a reasonable level. (3) The Vendor shall be responsible for the work or services performed by its agents, employees, subcontractors and independent contractors in connection with this Contract. (4) The Vendor shall respect and abide by all applicable laws, regulations and ordinances of the country in which the obligations under this Contract are to be performed, and shall take all reasonable measures to ensure that its agents, employees, subcontractors and independent contractors do so. Vendor shall not discriminate in the employment of personnel assigned to the Work covered by this contract, nor in the selection of contractors, subcontractors and consultants, on the basis of sex, creed, or national origin. (5) The Vendor shall not commence work before the commencement date specified in the contract or, in the absence thereof, before having received CORE's written request to that effect. (6) The Vendor shall cooperate with CORE in the coordination of all work to be carried out, and shall supply all information in the manner stipulated. (7) The Vendor will complete the work in the time specified, without halting or unduly interfering with the work of or other parties working for, or on behalf of, CORE by reason of the Vendor's fault. (8) A Vendor who fails to observe the specified time limits for reasons which are not outside his control shall be held responsible for any and all resulting damages. (9) The Vendor shall draw up all plans, drawings and other documents necessary for carrying out the contract awarded to him. (10) On completion of the work and in accordance with the deadlines specified in the Contract (see paragraph 2.5), the Vendor shall supply CORE with complete documentation and detailed plans of the work carried out, along with operating or maintenance manuals, where appropriate. (11) Except as may otherwise be specified in this Contract, the English language shall be used by the Vendor in all written communications to CORE with respect to the performance of the obligations under this Contract and with respect to all documents procured or prepared by the Vendor pertaining to such obligations. (12) Coordination of Engineering Functions. Vendor(s) shall coordinate with each other and with any Project Manager designated by CORE so that the Work is presented to CORE as a cohesive whole. Design work shall be accomplished in a top-down or other professional manner so that CORE or its Project Manager shall have the ability to approve general aspects of the design before Work proceeds on more particular details. The design of the Work shall be so coordinated with the preparation of deliverables so that the documentation at all times provides a reasonable specification for the quality of the Work. The intention of this requirement is to assure that when the Work is completed, the conformance of the operation of the system to the documentation is a comprehensive and reasonable standard for determining the acceptability of the Work. (13) Warranty. Vendor(s) shall warrant that the Work is free from defects and executed in a workmanlike manner. Without limiting the generality of the foregoing, Vendor(s) shall warrant that program errors shall be corrected in accordance with a reasonable schedule, to be specified in the proposal, which relates the severity of the error to the time within which Vendor commits to cause program errors to be corrected. Article 3 Insurance and liability (1) The Vendor shall take out and maintain: (A) liability insurance with respect to its agents and employees performing work or services in connection with this Contract to a limit not less than one million United States dollars (US$1,000,000.00) per occurrence, including Errors and Omissions Coverage and Coverage for Completed Operations. (B) comprehensive general liability insurance in an amount not less than one million United States dollars (US$1,000,000.00) per occurrence; for all claims for death, bodily injury or damage to property, including, but not limited to, products liability, arising from acts performed or omissions committed by the Vendor, its agents,employees, subcontractors and independent contractors in connection with this Contract; and (C) such other insurance as may be agreed upon between CORE and the Vendor. All such insurance shall be written on the occurrence basis and shall name CORE as an additional insured. (2) CORE accepts no responsibility for providing life, health, accident, travel or any other insurance coverage which may be necessary or desirable in respect of any persons performing services in connection with this Contract. Article 4 Subcontracting The Vendor shall engage no subcontractor to perform any work or services in connection with this Contract unless the Vendor has notified CORE of the identity of the proposed subcontractor and CORE has notified the Vendor of its approval of the engagement of that subcontractor. CORE shall, in its sole discretion, be entitled to reject any proposed assignment or subcontract, without having to give any justification in that regard. The approval by CORE of the engagement of a subcontractor shall not relieve the Vendor of any of its obligations under this Contract or from its responsibility for the work or services performed by the subcontractor. Article 5 Confidential Nature of Documents (1) All drawings, photographs, plans, manuscripts, records, reports, recommendations, estimates, documents and all other data (referred to hereinafter in this Article as documents ) compiled by or received by the Vendor or its agents, employees, subcontractors or independent contractors in connection with this Contract shall be the property of CORE, shall be treated as confidential and shall be delivered only to duly authorized CORE officials on completion of the work or services under this Contract or on termination of the Contract, or as may otherwise be required by CORE. (2) In no event shall the contents of such documents or any information known or made known to the Vendor by reason of its association with CORE be made known by the Vendor or its agents, employees, subcontractors or independent contractors to any unauthorized person without the written approval of CORE. (3) Subject to the provisions of this Article, the Vendor may retain a copy of documents produced by the Vendor. (4) The Vendor shall take all reasonable measures to ensure that its agents, employees, subcontractors and independent contractors comply with the provisions of this Article. (5) The obligations in this Article shall not lapse upon termination of this Contract. Article 6 Copyright Patents and Other Proprietary Rights, Intellectual Property Rights. (1) All intellectual property and other proprietary rights, including but not limited to patents, copyrights and trademarks, in all countries, with regard to drawings, photographs, plans, manuscripts, records, reports, recommendations, estimates, documents and other materials (referred to hereinafter in this Article as materials ) except preexisting materials, publicly or privately owned, collected or prepared in consequence of or in the course of the performance of this Contract, shall become the sole property of CORE, which shall have the sole right to publish the same in whole or in part and to adapt and use them as may seem desirable, and to authorize all translations and extensive quotations therefrom. If the Vendor incorporates in its materials any previously published or unpublished materials, it shall obtain permission for the publication, use and adaptation in any language free of cost to CORE from the persons in whom any existing copyrights therein maybe vested and provide CORE with evidence of such permission. (2) The Vendor agrees that it will forthwith disclose and assign to CORE all discoveries, processes or inventions made or conceived in whole or in part by it alone or in conjunction with others relating to or arising out of this Contract, and the said discoveries, processes orinventions shall become and remain the property of CORE. (3) At the request of CORE and at its expense, the Vendor shall take all necessary steps, execute all necessary documents and generally assist CORE in securing such proprietary rights and transferring them to CORE in compliance with the requirements of the applicable law. (4) The obligations in this Article shall not lapse upon termination of the Contract. (5) All source code created by a Vendor shall be furnished to CORE openly in both hard copy and electronic formats. CORE shall be the owner of all Source Code created by Vendor in the performance of the Work, and must be provided with a fully-paid perpetual license for all works of others and other intellectual property rights held by others which are necessary or appropriate to the operation, maintenance, support and enhancement of the Work. Source Code includes application scripts and other command files created to automate and expedite the performance of function and operation of the SRS. The source code shall be accompanied by lucid and comprehensive documentation in the English language conforming to reasonable standards of professionalism in the computer industry. The documentation must be such as to make it reasonably possible to support and maintain the software without resort to Vendor for assistance. (6) Vendor shall warrant that the Work does not infringe the intellectual property rights of any other person, firm or corporation. Article 7 Exclusivity of Services The Vendor agrees that it will provide its services for the development of the on-line domain name dispute-resolution facility exclusively for CORE and will not without the prior written consent of CORE render such services for any other domain name registry institution, public or private, for a period of two years or without the express prior consent of CORE. Article 8 Amendments No modification of or change in this Contract, waiver of any of its provisions or additional contractual provisions shall be valid or enforceable unless previously approved in writing by the parties to this Contract or their duly authorized representatives in the form of an amendment to this Contract duly signed by the parties hereto. Article 9 Payment Payment shall be made only after the work has been completed and accepted by CORE within 30 days following the date of submission of the provisional or final invoice, provided such invoice has been accepted by CORE. Article 10 Delays (1) If there should be any delay in the performance of this Contract or any part thereof, the Vendor shall notify CORE in writing giving the cause, such notification to reach CORE no later than ten (10) days after the date on which the delay is known by the Vendor. (2) The Vendor shall be liable for any excess costs or damage caused to CORE by a failure or delay on the part of the Vendor in the performance of his obligations under the Contract except where such failure or delay is due to: causes which are attributable to CORE; any cause beyond the control of and without any fault or negligence on the part of the Vendor, including but not limited to acts of God, acts of governments, fires, floods, epidemics, quarantine restrictions, strikes, lockouts and freight embargoes. Article 11 Termination by CORE (1) Notwithstanding the provisions of Article 9, CORE may terminate this Contract for any reason upon not less than fourteen (14) days (in the case of Contracts initially for a period of sixty (60) days or more) or seven (7) days (in the case of Contracts initially for a period of less than sixty (60) days) notice to the Vendor. The provisions of the Contract applicable to the winding up of the Contract, the liquidation of claims and the settlement of disputes shall remain in force for such additional period as may be necessary. (2) Upon termination of this Contract: CORE shall complete all payments which may be due up to the effective date of termination; The Vendor shall deliver all work in process and in any event shall take all reasonable measures to avoid any loss or deterioration ofgoods or equipment or any other damage; CORE shall pay to the Vendor any sum which is determined by CORE as equitable for any work in process; The Vendor shall take immediate steps to terminate the work and services in a prompt and orderly manner and, to that end, shall provide such information as may reasonably be requested by CORE concerning the preservation and protection of the work or services performed by the Vendor and the results thereof and all property of CORE, and to minimize losses and further expenditure; the Vendor shall also take reasonable measures to provide for such prevention and protection and for minimization of losses and expenditure; Unless the termination has been occasioned by any fault or negligence on the part of the Vendor, its agents, employees, subcontractors or independent contractors, or by any failure of the Vendor to perform an obligation under this Contract, the Vendor shall also be entitled, against appropriate vouchers, to be reimbursed for such reasonable costs and expenses as shall have been duly and properly incurred in accordance with this Contract prior to the date of such notice of termination; The Vendor shall produce such reports covering the work and services performed up to the time of termination as may reasonably berequested by CORE. The reports shall conform to any reasonable requirements of CORE as to nature, structure and contents. Article 12 Termination by the Vendor The Vendor may terminate this Contract for cause upon not less than fourteen (14) days written notice to CORE. Notice of termination may not be given until the expiration of at least 14 days from the giving of notice by Vendor of the cause for termination, and its intention to terminate, without CORE having cured the condition giving rise to Vendor's right to terminate. In the case of a condition (other than non-payment of a sum certain in money) which cannot reasonably be cured within such 14 day period, CORE's time to cure the condition shall be extended so long as (x) CORE begins in good faith to effect a cure within such 14 day period; (y) within such 14 day period, CORE gives notice of its intent to effect such cure; and (z) CORE prosecuutes the cure with due diligence. Notices under this Article shal be givenn in the manner prescribed in Article 16. In the event of termination pursuant to this clause, no costs relating to termination shall be reimbursable by CORE. The provisions of paragraph 2 of Article 11 shall apply. Article 13 Bankruptcy Should the Vendor be declared bankrupt or become insolvent, or should control of the Vendor change by virtue of insolvency, CORE may, without prejudice to any other right or remedy, terminate this Contract immediately by giving the Consultant notice of such termination. Article 14 Arbitration Any dispute, controversy or claim arising out of or relating to this Contract, or the breach, termination or invalidity thereof, shall, unless settled amicably by direct negotiation, be settled by arbitration in accordance with the UNCITRAL Arbitration Rules as at present in force. The appointing authority shall be the Secretary general of the Permanent Court of Arbitration. The number of arbitrators shall be one. The place of arbitration shall be Geneva, Switzerland. The language to be used in the arbitral proceedings shall be English. The dispute shall be decided in accordance with the law of Switzerland. Article 15 Form of Notice, Request, Statement or Approval Any notice, request, statement or approval provided for in these General Conditions shall be effective if it is given in writing by letter, telex or facsimile. ANNEX III To Contract for the Development and operation of the Shared DomainName Registration System (SRS) of the Council of Registrars (CORE) Established under the Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System (gTLD-MoU) . PAYMENT SCHEDULE [To be prepared based on the selected proposal] ---------------------------------------------------------------------