 |
|
|
|
Response to Request for Quotation Number 40SBNT067020 As its response to Request for Quotation Number 40SBNT067020, the Internet Corporation for Assigned Names and Numbers (ICANN) submits the following proposals, representations, and certifications:
I. Business Proposal As its Business Proposal in response to Request for Quotation Number 40SBNT067020, the Internet Corporation for Assigned Names and Numbers (ICANN) proposes:
A. Proposal for Consideration for Work Performed Under the Contract.
ICANN makes the following proposal for consideration for work it will perform under the contract:
1. No Cost to the Government. ICANN proposes to perform under the contract at no monetary cost to the Government. In no event shall a price adjustment result in reducing the price below zero.
2. Consideration for Agreement. As consideration for the contract, ICANN proposes the following two elements:
a. Possibility of User Fees. The IANA function involves providing technical coordination services (e.g., assigning port numbers and other protocol parameters) to all Internet users, including U.S. Government agencies as well as other public-sector entities and private-sector entities. The IANA function is currently performed without fees to users. In some cases, however, the documents establishing emerging standards contemplate that the IANA may in the future charge application fees to defray its costs of operation. For example, RFC 2450 (December 1998), which describes proposed rules for Top-Level Aggregation Identifiers (TLA IDs) and Next-Level Aggregation Identifiers in assignments of the just-introduced IPv6 addresses, states that registries will require organizations assigned Sub-TLA and TLA IDs to make "[p]ayment [of] a registration fee to the Internet Assigned Numbers Authority (IANA)" (RFC 2450, page 8).
ICANN proposes initially to continue the longstanding IANA practice of not charging applicants for the assignment services and other coordination services contemplated by the contract. Indeed, ICANN has no present plans to charge for these services at any time. However, as discussions in the Internet community evolve in the future, including through the Internet Standards Development Organizations (SDOs) that develop the standards under which the IANA makes assignments, it is possible that a consensus may emerge that the IANA should charge for particular assignments to defray its cost of operation. Such a proposal to charge fees would require approval through ICANN's consensus-based policymaking framework. In no event would fees be charged to the Government for services. To accommodate the possibility of future fees, ICANN proposes that the following provision be included in the contract:
"3. COMPENSATION
"Contractor shall perform under this purchase order without any cost to the United States Government.
"At the effective date of this purchase order, the Contractor shall not impose or collect any fees for performing the IANA functions under this purchase order. After the effective date of this purchase order, ICANN may establish and collect fees from third parties (i.e. other than the United States Government) for the functions performed under this purchase order, provided the fee levels are approved by the Contracting Officer before going into effect, which approval shall not be withheld unreasonably provided the fee levels are fair and equitable and provided the aggregate fees charged during the term of this purchase order do not exceed the cost of providing the functions."
b. Governmental Approval of USC-ISI's Transfer of Intellectual Property to ICANN. ICANN proposes to perform the IANA function using personnel, facilities, and intellectual property it has contracted to obtain from the prior contractor, the University of Southern California's Information Sciences Institute (USC-ISI). In the transition agreement it has entered with USC-ISI, ICANN obtained a license to certain intellectual property rights used by USC-ISI in performing the IANA function under the prior contract. Section 2.6 of the transition agreement gave ICANN an option, upon consent of the United States Government, to acquire the intellectual property rights held by USC-ISI:
"2.6 Optional Acquisition of Licensed IP Rights. ICANN shall have the option to acquire USC's entire right, title and interest in and to the Licensed IP Rights upon (a) receiving written approval of such acquisition in form and in substance acceptable to USC from the United States government and (b) licensing back to USC all such Licensed IP Rights on the basis of a fully paid up, nonexclusive license in perpetuity to use such Licensed IP Rights on the same terms under which those Licensed IP Rights are licensed to ICANN hereunder; provided that USC may use such Licensed IP Rights for any purpose whatsoever and shall not be obligated under the terms of Section 2.5(a) hereof."
In negotiating this provision, ICANN and USC-ISI concluded that this optional acquisition was appropriate because, although transfer of title to the intellectual property is not necessary to secure ICANN's right to use the intellectual property to perform the IANA function, it is more appropriate that ICANN, as the new contractor, take responsibility for any effort or costs associated with maintenance or enforcement of the intellectual property.
ICANN proposes that the Government approve USC-ISI's agreement to transfer to ICANN the intellectual property rights. To implement this, a Section 4(b) should be included in the purchase order stating:
"As contemplated by Section 2.6 of the Transition Agreement, the United States Government hereby approves the acquisition by ICANN of USC's entire right, title and interest in and to the Licensed IP Rights as defined in the Transition Agreement."
Because the Government is not giving up any rights it holds in the intellectual property, but is merely consenting to transfer of title in the intellectual property from one party (the former contractor) to another (the new contractor), this term involves no cost to the Government. Since the practical value of the intellectual property being transferred is only in performance of the IANA function, and ICANN already has a license to use the intellectual property for that purpose, the transfer is of negligible value to ICANN.
3. Estimated Value of Contract. ICANN estimates that the value of this contract to it is substantially under $10,000.
B. Other Elements of Business Proposal.
ICANN also proposes these miscellaneous additional terms for the contract:
1. Governmental Approval of Transition from USC-ISI to ICANN. Under their transition agreement, USC-ISI and ICANN agreed that the transition of responsibilities would not take effect until approval by the Government. Specifically, Sections 5.4 and 5.5 of the transition agreement provide:
"5.4 Governmental Approval. ‘Governmental Approval' shall mean the receipt by either party of written approval of the transfer of functions and responsibilities contemplated in Section 1 of this Agreement, in form and substance satisfactory to both parties hereto, from the United States government.
"5.5 Effective Date. Irrespective of the date the approval or ratification [by ICANN's Board of Directors] required by Section 5.3 above occurs, USC and ICANN acknowledge that the effective date and time of each of this Agreement and the Service Mark and Copyright Assignment ("Effective Date") shall be the later of (i) January 1, 1999 at 12:01 a.m. and (ii) the date upon which Governmental Approval is received."
As a term of the contract, ICANN proposes that the Government give its approval, as contemplated by Section 5.4 of the transition agreement.
2. Place of Performance. ICANN identifies Marina del Rey, California, as the place at which it proposes to perform the services under the contract.
3. Preservation of Third-Party Confidential Information. In the course of performing the IANA function, it is necessary to review proprietary information of third parties concerning applications for which they seek assignment of protocol parameters. In its ordinary functioning, the IANA enters non-disclosure agreements with these third parties to preserve the proprietary nature of this information. ICANN proposes the contract provide that any Governmental rights in such information shall be subject to any such non-disclosure agreements entered in behalf of the IANA.
C. Period of Effectiveness of Quotation.
This quotation is valid for sixty days.
II. Technical Proposal As its Technical Proposal in response to Request for Quotation Number 40SBNT067020, the Internet Corporation for Assigned Names and Numbers (ICANN) proposes:
A. Description of ICANN and its Experience and Capabilities.
1. Role of ICANN in Internet Coordination. ICANN is a California non-profit public-benefit corporation formed by Internet stakeholders in response to the U.S. Government's announcement, in its Statement of Policy on Management of Internet Names and Addresses, 63 Fed. Reg. 31741 (June 10, 1998) (usually known as the "White Paper") of its intention to privatize Internet-coordination activities historically performed by the U.S. Government and its contractors, including the IANA function that is the subject of this Request for Quotation. In the White Paper, the U.S. Government stated its intention to transfer responsibility for technical coordination of the Internet to a private-sector, consensus-based, not-for-profit, to-be-formed organization referred to in the White Paper as "NewCo."
ICANN is composed of three supporting organizations and several committees. These supporting organizations have as members the key organizations involved in Internet technical coordination throughout the world, and as a result ICANN maintains close relations with those organizations. ICANN's supporting organizations–known as the Address Supporting Organization (ASO), the Domain Name Supporting Organization (DNSO), and Protocol Supporting Organization (PSO)–are responsible for developing recommendations in their respective areas of expertise:
- The ASO has three members: the three Regional Internet Registries (APNIC, ARIN, and RIPE NCC) that have been delegated responsibility by the IANA for routine allocation and assignment within their respective regions. These three organizations select members of the ASO's Address Council, which is responsible for developing consensus-based recommended policies concerning the operation, assignment and management of Internet (IP) addresses.
- The DNSO consists of a Names Council selected by seven constituencies representing entities involved in using and operating the domain-name system. The DNSO is responsible for developing consensus-based recommendations on policy issues relating to the domain name system.
- The PSO has four members that are the principal standards-development organizations involved in developing Internet protocols: the Internet Engineering Task Force (IETF), the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), and the International Telecommunication Union's Telecommunication Standardization Sector (ITU-T). These organizations select a Protocol Council, which is responsible for developing consensus-based policy recommendations relating to the assignment of parameters for Internet protocols.
ICANN's supporting organizations provide a mechanism for close cooperation with, and input by, the broad range of entities concerned with the maintenance and improvement of the Internet's technical coordination. These supporting organizations make ICANN uniquely suited to perform the IANA function.
In addition to the three ICANN supporting organizations, one of ICANN's committees is also particularly pertinent to the IANA function: the Root Server System Advisory Committee. This committee includes the individuals responsible for operating all thirteen DNS root nameservers and is responsible for advising the ICANN Board about the operation of the root name servers of the domain name system.
2. Related Activities of ICANN Pursuant to Other Agreements with the U.S. Government. The United States Department of Commerce (DOC) recognized ICANN as NewCo in a Memorandum of Understanding (MOU) entered by DOC and ICANN on November 25, 1998. Under that agreement, ICANN and DOC agreed to jointly design, develop, and test the mechanisms, methods, and procedures that should be in place and the steps necessary to transition management responsibility for DNS functions now performed by, or on behalf of, the U.S. Government to a private-sector not-for-profit entity. The MOU contemplates that, once testing is successfully completed, management of the DNS will be transitioned to the mechanisms, methods, and procedures designed and developed under the MOU.
To prepare for the transfer of responsibilities, in December 1998 ICANN entered into a "USC/ICANN Transition Agreement" and related agreements with the University of Southern California's Information Sciences Institute (USC-ISI). Under those agreements, ICANN has secured the services of the IANA project team at USC-ISI, which was the prior U.S. Government contractor for the IANA function. Those agreements also give ICANN access to the technical facilities and intellectual property USC-ISI was using to operate the IANA.
DOC and ICANN have also entered into a Cooperative Research and Development Agreement (CRADA) to fulfill the White Paper mandate and carry out one of the objectives in the MOU with ICANN -- to improve the security of, and to formalize procedures for managing, the root-server system. To this end, ICANN and DOC are collaborating on the development of written technical procedures for operation of the primary root server and for making the root server system more robust and secure. This initiative represents an important first step in the creation of more formal relationships for administration of the DNS root nameserver system.
3. Personnel. Although ICANN is a relatively new organization, ICANN's personnel have extensive experience in providing technical coordination of the Internet and, specifically, in performing the IANA function. For the performance of this contract, ICANN proposes the following project team, made up of personnel employed by ICANN or on loanout from USC-ISI to ICANN:
a. Michael M. Roberts, President and CEO of ICANN
Michael M. Roberts is a policy consultant in the field of Internet technology, services and product development, with a specialization in research and education. Shortly before joining ICANN in 1998, he retired as Vice President at EDUCOM, a consortium of 600 universities and colleges with interests in information technology, where he was responsible for networking and telecommunications programs, including the development of public policy positions in information technology on behalf of EDUCOM members. He was for a number of years staff director of the EDUCOM Networking and Telecommunications Task Force, a group of sixty universities and corporations with common networking interests.
He was an organizer and the first director of Internet2, a project of more than one hundred American universities to plan, integrate and deploy an advanced broadband network and applications for research and education. He was also one of the founders and the first Executive Director of the Internet Society, whose purpose is to promote the use of the Internet and guide its further development as a foremost means of national and international communication.
Prior to joining EDUCOM, he was at Stanford University where he was Deputy Director of Information Technology Services, with executive responsibilities in Stanford's computing, communications, and information systems programs. During 1983-86, he directed the university's telecommunications modernization project, which installed a large digital voice switch and extensive fiber optic network facilities.
Mr. Roberts is a liberal arts graduate of Stanford and holds an MBA from the Stanford Graduate School of Business.
As ICANN's President and CEO, Mr. Roberts will be responsible for ensuring that adequate resources are devoted to the work to be performed under this contract.
b. Louis Touton, Vice-President, Secretary, and General Counsel of ICANN
Louis Touton became Vice-President, Secretary, and General Counsel of ICANN on 1 November 1999. Prior to that time, he was with the law firm of Jones, Day, Reavis & Pogue for eighteen years, first as an associate (1981-1988) and then as a partner (1989-1999) in its Los Angeles and Dallas offices. His practice at Jones Day focused on technology-related commercial litigation, prominently including patent litigation in the semiconductor and communication industries. He is a member of the bars of Arizona, California, Texas, and Washington; is admitted to practice before nine U.S. federal courts; and is registered to handle patent matters before the U.S. Patent and Trademark Office.
During the last 20 months, Mr. Touton has handled legal aspects of several matters concerning the IANA, including review and conciliation of disputes involving delegation of country-code top-level domains. He also has participated in the formulation of the contractual structure under which the .com, .net, and .org generic top-level domains are operated.
Mr. Touton holds SB degrees from the Massachusetts Institute of Technology's departments of Mechanical Engineering (1977) and Electrical Engineering & Computer Science (1977). He received his JD degree from Columbia Law School (1980), where he served as an editor of the Columbia Law Review and co-editor of the thirteenth edition of A Uniform System of Citation (1981). In 1980-1981, he served as law clerk to the Honorable Jerome Farris, United States Court of Appeals for the Ninth Circuit.
Mr. Touton will be responsible for day-to-day supervision of the work performed under this contract, for compliance with reporting requirements, and for interface with governmental personnel concerning the contract.
c. Joyce K. Reynolds, Manager of Publications of ICANN (under loanout arrangement from USC-ISI).
Ms. Reynolds holds bachelor's and master's degrees from the University of Southern California. Since 1979, she has been with the University of Southern California's Information Sciences Institute (USC-ISI) where she is Internet Services Manager in the Computer Division. She is ICANN's Manager of Publications.
Ms. Reynolds has contributed to the development of the DARPA Experimental Multimedia Mail System, the Post Office Protocol, the Telnet Protocol, and the Telnet Option Specifications. She helped update the File Transfer Protocol (FTP).
Her current interests include co-project leader, Request for Comments (RFC) Editor. The RFC Editor provides technical and administrative management of the editorial and on-line publication of the Internet documents called RFCs. She is the RFC Editor liaison to the Internet Architecture Board (IAB).
She is the Internet Assigned Numbers Authority (IANA) liaison to the Internet Engineering Steering Group (IESG). She coordinates and assists with the IANA's day-to-day functions. She also assists in the maintenance of the central registry of assigned protocol parameters for the Internet.
Ms. Reynolds developed, organized, and directed the User Services Area of the Internet Engineering Task Force (IETF) from 1988 - 1998. She established a new informational series of notes for the Internet community: FYI (For Your Information) RFCs. FYI RFCs are documents useful to network users. Their purpose is to make available general and useful information with broad applicability.
For the last twelve years, she has been an international keynote speaker and panelist of over 70 different conferences in Europe, Asia-Pacific, Scandinavia, and the Middle East. She has authored or co-authored over 70 RFCs and additional international publications.
Ms. Reynolds is a past Member of the IESG. She is a recipient of the Internet Society (ISOC) service recognition plaque for outstanding contributions in the User Services Area of the IETF.
She is a Pioneer Member of ISOC, a past member of the Editorial Advisory Board of ISOC, and past Associate Editor of the Internet Society News. She is a member of American Society of Professional and Executive Women, and is affiliated with Phi Alpha Theta (Honors Society). She is currently listed in Who's Who in the American Society of Professional and Executive Women and USC's Who's Who in the College of Letters, Arts, and Sciences Alumni Directory.
d. Suzanne Woolf, Manager, Technical Operations (under loanout arrangement from USC-ISI).
Suzanne Woolf has a B.S. in Information Systems from Carnegie-Mellon University. She joined USC-ISI in 1989, first in the Computer Center as a member of the technical support staff. Primary responsibilities there included system administration, user support, documentation, and troubleshooting system and network problems. This period included USC-ISI's transition from a computing environment built on large mainframes and expensive, slow networking to distributed workstations and cheap, high speed networking.
Suzanne joined the USC-ISI Networks Division, headed by Jon Postel, in 1994. From then until her loanout to ICANN at the beginning of 1999, she divided her time in the Division among several projects, including technical support for the DNS and Whois services for the .us Domain and network engineering on the Los Nettos project, which provides dedicated internet access for a consortium of major research and educational institutions in southern California and a variety of smaller non-profits, schools, and area startups. She has participated in the IETF, NANOG (North American Network Operators' Group), and ARIN as the Los Nettos Consortium representative. Recent projects include participating in the deployment of CalREN2, a large-scale high speed network for research and education, funded by a consortium of universities and planned as California's participation Internet2.
In 1997, Dr. Postel asked her to provide support and planning for the anticipated transition of the IANA from USC and US government management to a private non-profit entity. This effort included day-to-day system management tasks, planning for the technical aspects of the transition as it proceeds, and providing an operational perspective to discussion of some of the issues facing IANA during this process.
e. Michelle M. Schipper, Administrative Assistant for the IANA Function
Ms. Schipper has just joined ICANN as Administrative Assistant for the IANA Function. She holds a B.S. degree in Business Administration from San Diego State University (1999) with an emphasis in marketing.
4. Facilities. ICANN currently operates from facilities subleased from, and in the same building as, USC-ISI. ICANN plans in the near future to enter into a lease for expanded office facilities in a nearby building. Thus, both presently and in the future ICANN will benefit from proximity to the technical resources of USC-ISI, including its many employees with institutional memory of many years of the IANA's operations.
ICANN operates primarily with its own information processing system although, by contractual arrangement with USC-ISI, it also has access to that organization's computer center. Under its transition agreement with USC-ISI, ICANN has obtained a sublicense to the intellectual property used by USC-ISI in performing the IANA function, with an option to acquire that intellectual property on the U.S. Government's consent.
5. Financial Capabilities. As a non-profit organization, ICANN operates on a cost-recovery basis. During its startup phase, ICANN has operated primarily on funds received from charitable donations ($801,000 through 30 September 1999) and unsecured borrowing ($1,025,000 through 30 September 1999). In the long term, as contemplated by the White Paper, its source of funding will be payments by domain-name registries and registrars and IP address registries. In the fall of 1999, ICANN convened a Task Force on Funding consisting of representatives of those entities. This task force recommended a set of principles by which these funding sources would provide ICANN with $ 4,275,000 in funding during the fiscal year ending 30 June 2000. ICANN is currently in the process of negotiating agreements under which the various entities will provide this funding; contractual commitments for an estimated $2,500,000 have already been finalized, of which over half has already been received. While there are some uncertainties in full realization of the contributions called for in the task force's report, ICANN believes that its current contractually committed funding sources are more than sufficient to permit it to perform the IANA function during the term of the contract.
ICANN proposes to perform the services under the contract by building on the techniques for technical coordination of the Internet pioneered by Dr. Jon Postel. His (and that of those working under his supervision) consistently evenhanded treatment of requests for assignments, rigorous application of technical knowledge, meticulous attention to detail, familiarity with the full historical background of the Internet's development, and efforts to consult broadly in the Internet technical community promoted a tradition of wise and fair handling of the IANA function that achieved a great measure of stability for the Internet. ICANN believes that these same values form an essential foundation for the successful continuation of the IANA function.
To realize these values going forward, ICANN has assembled a team of Dr. Postel's key co-workers, has arranged to acquire the intellectual property and other tools he used in performing the function, and has followed his example in establishing relationships with the key other Internet-coordination entities. In particular, ICANN believes its relationships with the IETF, W3C, ETSI, ITU-T, APNIC, ARIN, RIPE NCC, and IAB, as well as its continuing relationship with USC-ISI, gives it knowledge resources that are very important to continued successful performance of the IANA function.
ICANN proposes to improve on the past, already successful, performance of the IANA function, by employing the consultative and consensus-development management procedures that it has been developing jointly with the Department of Commerce under the November 25, 1998, Memorandum of Understanding. Thus, ICANN proposes to formalize the consensus-building efforts of Dr. Postel by using the supporting organization structure that has been designed (and continues to evolve) under the MOU.
C. Organization, Staffing, and Management.Performance under the contract will be under the overall supervision of Mr. Roberts, who will be specifically responsible for ensuring that adequate resources are devoted to the work. Mr. Touton will be responsible for day-to-day supervision of the work performed under this contract, for compliance with reporting requirements, for interface with governmental personnel concerning the contract, and for formulating any legal positions needed in the work. He will also take responsibility for a variety of administrative functions associated with root management. Ms. Reynolds will be responsible for coordination with the IETF, IAB, and RFC Editor, will attend to publication tasks, and will also provide advice based on her longstanding background in how the IANA function has been performed in the past. Ms. Woolf will perform necessary technical analyses and advice and will maintain liaison with the root-server operators (in addition to continuing her role in operating the "L" root nameserver.). Ms. Schipper will be responsible for the day-to-day assignment of parameters.
The roles and projected time commitments of each of these personnel is as follows:
Person Role % of FTE Michael M. Roberts Overall supervision 5 Louis Touton Day-to-day supervision; gov't liaison; legal 20 Joyce K. Reynolds IETF/IAB liaison; historical input; publication 30 Suzanne Woolf Technical advice; root server liaison 20 Michelle M. Schipper Assignment duties 100 D. Work Plan for Specific Tasks.
1. Coordination of the Assignment of Technical Protocol Parameters.
One core function of the IANA has traditionally been, and continues to be, the assignment of technical parameter values (for example, operation codes, port numbers, object identifiers, protocol numbers, enterprise numbers) to various entities or applications that must be uniquely identified for stable operation of the Internet. The ICANN team has a combined total of nearly 25 years in performing this function, and is proud of the tradition of prudent and fair protocol assignments that has developed.
One key feature of ICANN's proposed approach to performing this aspect of the IANA function is keeping close and constructive working ties with the Internet Standards Development Organizations (SDOs) that formulate the standards under which protocol parameters are assigned. To date, most Internet standards have been developed by the Internet Engineering Task Force (IETF) and, to a lesser extent, the World Wide Web Consortium (W3C). In part, ICANN's ability to maintain close contacts with the appropriate standards development organizations is facilitated by the membership of such organizations on ICANN's Protocol Supporting Organization (PSO). In addition to the IETF and W3C, the members of the PSO are the European Telecommunications Standards Institute (ETSI) and the International Telecommunications Union, Telecommunications Standards Sector (ITU-T).
Under ICANN's proposed approach, the IANA will remain the entity responsible for assigning protocol parameters for Internet standards. By providing a single point of contact for assignment of protocol parameters, this should simplify the task of software and systems developers seeking to bring innovative products into operation on the Internet. In addition, having a single assignment entity, to the extent that can be achieved, will diminish the chances of conflicting assignments and standards, further promoting the stability of the protocol system.
Nearly all the standards for which the IANA currently makes assignments have been established by the IETF. One important aspect of the IANA's current approach is to be involved in an advisory role in the IETF's formulation and publication of standards (including thorough "last call" review of standards documents), so that the assignment criteria are appropriately specified by the standard and so that the assignment process can be conducted in a way that makes the standard most effective in achieving its goals. Another important aspect of the IANA's current approach is the use of expert advisers from the IETF to provide the IANA guidance when assignment questions not addressed by the expressed language of the standard arise. ICANN proposes to continue using both of these approaches with IETF standards and to apply these approaches to new standards that are developed by the other three SDOs.
In addition to assigning parameter values, the IANA also performs the important task of making those parameter values publicly available. This is currently done primarily through the well-known iana.org web site by giving web- and ftp-based access to the relevant parameter tables. ICANN currently holds the registration for the iana.com, iana.net, and iana.org domain names and operates the server at the IANA site. ICANN proposes to continue the basic framework of the current assignment-publication structure, enhancing it as standards from other SDOs are brought into the system.
2. Administrative Functions Associated with Root Management.
A second important aspect of the IANA function involves administrative functions associated with management of the authoritative domain-name system (DNS) root. Under the leadership of Dr. Postel, the IANA team undertook the project of delegating 243 of the country-code top-level domains (ccTLDs) listed (except for grandfathered cases) on ISO 3166-1 (three more ccTLDs are still undelegated). These 243 ccTLDs, in conjunction with the seven generic top-level domains (gTLDs), and the special, legacy second-level domain, in-addr.arpa, make up the root zone of the DNS that is disseminated to thirteen root nameservers deployed throughout the world.
Continuing maintenance of this root zone involves a variety of administrative functions that are key to maintaining the stable operation of the DNS. These tasks involve, first, maintenance of accurate records not only of the root-zone file information (i.e. correspondence of TLDs to host computers providing authoritative nameservice for those domains) but also of detailed contact information so that persons seeking second-level domains know who to contact and so that problems with a particular TLD can be quickly resolved. Routine requests for technical changes are made by the delegated operators of ccTLDs and the IANA/ICANN team has developed various means of verifying the authenticity of these requests based on its familiarity with the various operators. The IANA/ICANN team is experienced in working closely with Network Solutions, which currently generates the authoritative root-zone file and operates the root-zone Whois service, and with the U.S. Department of Commerce, which approves various changes to the root-zone file. ICANN proposes to continue processing routine requests for technical changes in the root-zone file and root-zone contact information in the same manner as is currently done, subject to changes in procedures agreed with the U.S. Department of Commerce Government consistent with ICANN's MOU with that agency.
A second aspect of the administrative tasks associated with root management is receiving requests for redelegation of existing TLDs and, where new TLDs are created, for initial delegation. After receiving the request, the IANA investigates the circumstances of the request, evaluates its conformity with the relevant guidelines as contained in ICANN Corporate Policy (ICP-1), reports the results to the U.S. Department of Commerce, and if appropriate recommends a course of action on the request. Often a key stability-enhancing technique is the mediation of delegation disputes, which the ICANN staff has performed frequently, resulting in nearly all disputes being resolved by a consensual solution.
At this stage in the U.S. Government's transition to private-sector-led technical management of the Internet, the U.S. Department of Commerce acts on delegation and redelegation requests by giving approval as appropriate to changes in root-zone files and associated information. Nothing in the current contract contemplates any change in the IANA's role with respect to authorizing modifications, additions, or deletions to the root-zone file or associated information that constitute delegation or redelegation of top-level domains; those issues are to be dealt with under the MOU between ICANN and the U.S. Department of Commerce and past and future amendments to that MOU.
Actions by the U.S. Department of Commerce on delegation and redelegation requests are made after reviewing reports submitted by the IANA, which makes the reliability of the reports especially vital. The ICANN team is uniquely situated to perform the investigation and reporting function based on its unequalled familiarity with ccTLD delegees worldwide, familiarity of precedents in prior delegation and redelegation situations, and longstanding reputation for handling requests impartially and in a manner that promotes the benefits of the Internet worldwide.
A third aspect of the administrative tasks associated with root management is coordination with the operators of the thirteen root nameservers deployed throughout the world. ICANN is closely involved with the operation of the root nameservers, and this relationship will permit it to facilitate a stable transition from the current system of volunteer (but nonetheless highly professional) operation to a more accountable and formally documented system. ICANN itself operates one of the root nameservers ("L"), one of ICANN's nineteen directors (Jun Murai) is involved in the operation of another ("M"), and ICANN works closely with USC-ISI's staff, which operates another ("B"). In addition, ICANN's Root Server System Advisory Committee has as its members the operators of all thirteen root nameservers. ICANN proposes to work collaboratively through the Committee to develop a set of contracts between ICANN and each operator that will permit stable evolution and enhancement of the procedures under which the root nameserver system is operated.
3. Allocation of IP Address Blocks.
The remaining principal aspect of the IANA function involves overall supervision of the assignment of Internet Protocol (IP) address space, both under the traditional IPv4 protocol and the recently introduced IPv6 protocol.
Since the early 1990s, assignment of IP addresses has been performed by an "Internet Registry System" recommended by the Internet Architecture Board to the Federal Networking Council in RFC 1174 (V. Cerf, Dec. 1990). This RFC sets forth the official "IAB Recommended Policy on Distributing Internet Identifier Assignment." As stated in section 1.2 of that RFC:
"Throughout its entire history, the Internet system has employed a central Internet Assigned Numbers Authority (IANA) for the allocation and assignment of various numeric identifiers needed for the operation of the Internet. . . . The IANA has the discretionary authority to delegate portions of this responsibility and, with respect to numeric network and autonomous system identifiers, has lodged this responsibility with an Internet Registry (IR). This function [was then] performed by SRI International at its Network Information Center (DDN-NIC).
"With the rapid escalation of the number of networks in the Internet and its concurrent internationalization, it is timely to consider further delegation of assignment and registration authority on an international basis. . . ."
Section 1.3 of RFC 1174 then recommended the delegation of the IR function under the IANA to Regional Internet Registries (RIRs).
Six years later, this Internet Registry System was described as follows in BCP 12-RFC 2050 (K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg & J. Postel, November 1996):
"In order to achieve the above goals the Internet Registry (IR) hierarchy was established.
"The Internet Registry hierarchy consists of the following levels of hierarchy as seen from the top down: IANA, Regional IRs, Local IRs.
"IANA
"The Internet Assigned Numbers Authority has authority over all number spaces used in the Internet. This includes Internet Address Space. IANA allocates parts of the Internet address space to regional IRs according to its established needs.
"Regional IRs
"Regional IRs operate in large geopolitical regions such as continents. Currently there are three regional IRs established; InterNIC [later ARIN] serving North America, RIPE NCC serving Europe, and AP-NIC serving the Asian Pacific region. Since this does not cover all areas, regional IRs also serve areas around its core service areas. It is expected that the number of regional IRs will remain relatively small. Service areas will be of continental dimensions.
"Regional IRs are established under the authority of the IANA. This requires consensus within the Internet community of the region. A consensus of Internet Service Providers in that region may be necessary to fulfill that role.
"The specific duties of the regional IRs include coordination and representation of all local IRs in its respective regions.
"Local IRs
"Local IRs are established under the authority of the regional IR and IANA. These local registries have the same role and responsibility as the regional registries within its designated geographical areas. These areas are usually of national dimensions."
(For background on the evolution of Internet address policy, see obsoleted RFCs 1366 and 1466.)
In addition to this strategy of delegating routine assignments of IP addresses through Regional Internet Registries (RIRs), the IANA accommodates various other needs for IP addresses through direct assignments. As noted in the statement of work in the Request for Quotation, at present these other needs include multicast addressing, cable blocks, addresses for private networks as described in RFC 1918, and globally specified applications. While these examples of direct allocation apply to the traditional IPv4 address space, the policies applicable to the IPv6 address space similarly envision routine allocations through RIRs and exceptional assignments directly by the IANA:
"The IANA will assign small blocks (e.g., few hundred) of TLA ID's to registries. The registries will assign the TLA ID's to organizations meeting the requirements for TLA ID assignment. When the registries have assigned all of their TLA ID's they can request that the IANA give them another block. The blocks do not have to be contiguous. The IANA may also assign TLA ID's to organizations directly. This includes the temporary TLA assignment for testing and experimental usage for activities such as the 6bone or new approaches like exchanges." (RFC 2450, section 5.0)
At the outset of the term of the contract, ICANN proposes in both the IPv4 and IPv6 spaces to follow the current policies as to which particular uses of IP addresses are accommodated by allocation through the RIRs and which are handled by direct assignments. This dual-track assignment system works well in practice because it provides significant input by local ISPs and users into policies concerning assignment for existing types of uses while providing a global (i.e. Internet-wide) mechanism for making assignments of IP address blocks for needs that are important to the overall growth and vitality of the Internet. In large part, the global mechanism has been used for purposes that are experimental in character, which would have difficulty in justifying assignments within the RIR context in view of the RIRs' orientation towards serving the needs of existing users, but which are vital to the promotion of innovation on the Internet worldwide. In the past, significant new special uses of the IP address space have been unable to obtain assignments at individual RIRs, but have received assignments directly from the IANA in their infancy, and have ultimately proven their technical efficacy and grown in popularity. According to present practices, this use of direct assignment by the IANA is intended to be exceptional in scope, directed to particular IP address-space uses that serve needs of the overall Internet, and which could not acceptably be thwarted by the regional allocation policies of the RIRs.
As uses of IP addresses on the Internet are introduced and evolve, there is a need to periodically evaluate the application of the two-track assignment system to particular uses. As one example, IPv4 addresses for cable modems have been assigned directly by the IANA since 1996. At the time this direct-allocation practice for cable modems began, RIR policies did not sufficiently accommodate this then-innovative use. Since that time, the cable industry's use of cable modems has matured significantly and RIR policies have evolved to accommodate these needs. Thus, it may be appropriate to migrate cable-modem assignments to the RIRs; ICANN expects this issue will be taken up shortly by ICANN's ASO. When new uses of IP addresses arise, ICANN proposes to evaluate their proper treatment under the dual-track assignment system on a case-by-case basis. To the extent that the new uses can be appropriately handled under the institutional framework of the RIRs, the presumption should be that allocations through the RIRs will be used to make the assignments. In the exceptional case of an innovative or other globally specified use that does not qualify for necessary IP address assignment through the RIRs, but which is sufficiently important to the overall Internet's operation or evolution that it cannot acceptably be thwarted by RIR procedures, direct assignment by the IANA may be employed. ICANN proposes to make these distinctions based on policies formulated through the ICANN process with the opportunity for input from all affected parts of the Internet community, including from the RIRs through the ASO and from SDOs through the PSO.
4. Refinements During Course of Contract.
In various aspects of its operation (concerning principally address and domain-name-system matters), the IANA is responsible for implementation of policies developed through the ICANN process. As previously noted, ICANN and the United States Department of Commerce are parties to a Memorandum of Understanding under which they are engaged in a joint project to design, develop, and test the mechanisms, methods, and procedures that should be in place and the steps necessary to transition management responsibility for DNS functions now performed by, or on behalf of, the U.S. Government to a private-sector not-for-profit entity. As part of this joint effort, ICANN has recognized supporting organizations devoted to particular subject areas, including the ASO for address policy and the DNSO for domain-name-system policy.
ICANN contemplates that, during the period of this contract, policies may be adopted through the ICANN process as developed under the Memorandum of Understanding that affect the manner in which the IANA function is performed. ICANN proposes that, to the extent such policies are adopted, the corresponding IANA practices may be revised upon Government approval.
5. Other Services, Including Performance Reporting.ICANN proposes to prepare and submit reports on its performance under the contract every three months during the term of the contract and at its conclusion. The three-month progress reports will set forth quantitative measures of the IANA's performance as well as narrative descriptions of major events during the period covered by the report. The final report will describe the techniques, methods, software, and tools used in the performance of the IANA function.
III. Representations and Certifications (a) Definitions. As used in this provision:
"Emerging small business" means a small business concern whose size is no greater than 50 percent of the numerical size standard for the standard industrial classification code designated.
"Small business concern" means a concern, including its affiliates, that is independently owned and operated, not dominant in the field of operation in which it is bidding on Government contracts, and qualified as a small business under the criteria in 13 CFR Part 121 and size standards in this solicitation.
"Small disadvantaged business concern" means a small business concern that-
(1) Is at least 51 percent unconditionally owned by one or more individuals who are both socially and economically disadvantaged, or a publicly owned business, having at least 51 percent of its stock unconditionally owned by one or more socially and economically disadvantaged individuals, and
(2) Has its management and daily business controlled by one or more such individuals. This term also means a small business concern that is at least 51 percent unconditionally owned by an economically disadvantaged Indian tribe or Native Hawaiian organization, or a publicly owned business having at least 51 percent of its stock unconditionally owned by one or more of these entities, which has its management and daily business controlled by members of an economically disadvantaged Indian tribe or Native Hawaiian organization and which meets the requirements of 13 CFR Part 124.
"Women-owned small business concern" means a small business concern-
(1) Which is at least 51 percent owned by one or more women or, in the case of any publicly owned business, at least 51 percent of the stock of which is owned by one or more women; and
Whose management and daily business operations are controlled by one or more women.
"Women-owned business concern" means a concern which is at least 51 percent owned by one or more women; or in the case of any publicly owned business, at least 51 percent of the stock of which is owned by one or more women; and whose management and daily business operations are controlled by one or more
women.
(b) Taxpayer identification number (TIN) (26 U.S.C. 6050M).(1) Taxpayer Identification Number (TIN).
x TIN: 95-4712218 .
____ TIN has been applied for.
____ TIN is not required because:
____ Offeror is a nonresident alien, foreign corporation, or foreign partnership that does not have income effectively connected with the conduct of a trade or business in the U.S. and does not have an office or place of business or a fiscal paying agent in the U.S.;
____ Offeror is an agency or instrumentality of a foreign government;
____ Offeror is an agency or instrumentality of a Federal, state, or local government;
____ Other. State basis.______________________
(2) Corporate Status.
____ Corporation providing medical and health care services, or engaged in the billing and collecting of payments for such services;
x Other corporate entity;
____ Not a corporate entity:
____ Sole proprietorship
____ Partnership
____ Hospital or extended care facility described in 26 CFR 501(c)(3) that is exempt from taxation under 26 CFR 501(a).
(3) Common Parent.
x Offeror is not owned or controlled by a common parent:
____ Name and TIN of common parent:
Name_______________________________
TIN________________________________
(c) Offerors must complete the following representations when the resulting contract is to be performed inside the United States, its territories or possessions, Puerto Rico, the Trust Territory of the Pacific Islands, or the District of Columbia. Check all that apply.
(1) Small business concern. The offeror represents as part of its offer that it ____ is, x is not a small business concern.
(2) Small disadvantaged business concern. The offeror represents and certifies that it ____ is, x is not a small disadvantaged business concern.
(3) Women-owned small business concern. The offeror represents that it ____ is, x is not a women-owned small business concern.
Note: Complete paragraphs (c)(4) and (c)(5) only if this solicitation is expected to exceed the simplified acquisition threshold.
(4) Women-owned business concern. The offeror represents that it ____ is, ____ is not, a women-owned business concern.
(5) Tie bid priority for labor surplus area concerns. If this is an invitation for bid, small business offerors may identify the labor surplus areas in which costs to be incurred on account of manufacturing or production (by offeror or first-tier subcontractors) amount to more than 50 percent of the contract price:
_____________________________________________
(6) Small Business Size for the Small Business Competitiveness Demonstration Program and for the Targeted Industry Categories under the Small Business Competitiveness Demonstration Program. [Complete only if the offeror has certified itself to be a small business concern under the size standards for this solicitation.]
(i) (Complete only for solicitations indicated in an addendum as being set-aside for emerging small businesses in one of the four designated industry groups (DIGs).) The offeror represents as part of its offer that it ____ is, ____ is not an emerging small business.
(ii) (Complete only for solicitations indicated in an addendum as being for one of the targeted industry categories (TICs) or four designated industry groups (DIGs).) Offeror represents and certifies as follows:
(A) Offeror's number of employees for the past 12 months (check the Employees column if size standard stated in the solicitation is expressed in terms of number of employees); or
(B) Offeror's average annual gross revenue for the last 3 fiscal years (check the Average Annual Gross Number of Revenues column if size standard stated in the solicitation is expressed in terms of annual receipts).
(Check one of the following):
Number of Employees Average Annual Gross Revenues___ 50 or fewer ___ $1 million or less
___ 51 – 100 ___ $1,000,001 - $2 million
___ 101 – 250 ___ $2,000,001 - $3.5 million
___ 251 – 500 ___ $3,500,001 - $5 million
___ 501 – 750 ___ $5,000,001 - $10 million
___ 751 - 1,000 ___ $10,000,001 - $17 million
___ Over 1,000 ___ Over $17 million
(d) Certifications and representations required to implement provisions of Executive Order 11246--
(1) Certification of non-segregated facilities. (Applies only if the contract amount is expected to exceed $10,000)--
By submission of this offer, the offeror certifies that it does not and will not maintain or provide for its employees, any facilities that are segregated on the basis of race, color, religion, or national origin because of habit, local custom, or otherwise and that it does not and will not permit its employees to perform their services at any location where segregated facilities are maintained. The offeror agrees that a breach of this certification is a violation of the Equal Opportunity clause in the contract.
(2) Previous Contracts and Compliance. The offeror represents that--
(i) It ____ has, x has not, participated in a previous contract or subcontract subject either to the Equal Opportunity clause of this solicitation, the clause originally contained in Section 310 of Executive Order 10925, or the clause contained in Section 201 of Executive Order 11114; and
(ii) It (N/A) has, ____ has not, filed all required compliance reports.
(3) Affirmative Action Compliance. The offeror represents that--
(i) It ____ has developed and has on file, ____ has not developed and does not have on file, at each establishment, affirmative action programs required by rules and regulations of the Secretary of Labor (41 CFR Subparts 60-1 and 60-2), or
(ii) It x has not previously had contracts subject to the written affirmative action programs requirement of the rules and regulations of the Secretary of Labor.
(e) Certification Regarding Debarment, Suspension or Ineligibility for Award (Executive Order 12549). The offeror certifies, to the best of its knowledge and belief, that--
(1) The offeror and/or any of its principals ____ are, x are not presently debarred, suspended, proposed for debarment, or declared ineligible for the award of contracts by any Federal agency, and
(2) ____ Have, x have not, within a three-year period preceding this offer, been convicted of or had a civil judgment rendered against them for: commission of fraud or a criminal offense in connection with obtaining, attempting to obtain, or performing a Federal, state or local government contract or subcontract; violation of Federal or state antitrust statutes relating to the submission of offers; or commission of embezzlement, theft, forgery, bribery, falsification or destruction of records, making false statements, tax evasion, or receiving stolen property; and ____ are, x are not presently indicted for, or otherwise criminally or civilly charged by a Government entity with, commission of any of these offenses.
(End of provision)