ICANN | IANA Contract Between the U.S. Government and ICANN | 17 March 2003
  ICANN Logo

Contract Between ICANN and the United States Government for Performance of the IANA Function

(17 March 2003)



B. Section B - Supplies or Services and Prices/Costs

B.1 CONTRACT VALUE

The requirements identified in the statement of work are performed by the contractor at no cost to the Government.

B.2 SCHEDULE

Line Item Description Price
0001 Base Period (April 1, 2003 – September 30 , 2003) $0.00
0002 Option Period 1 (October 1, 2003 – September 30, 2004) $0.00
0003 Option Period 2 (October 1, 2004 – September 30, 2005) $0.00
0004 Option Period 3 (October 1, 2005 – March 31, 2006) $0.00

C. Section C Statement of Work

CAR Clause Number Title Date
1352.211-70 Statement of Work/Specifications March 2000

C.1 BACKGROUND

C.1.1 The U.S. Department of Commerce (DoC), National Telecommunications and Information Administration (NTIA) has initiated this agreement to maintain the continuity and stability of services related to certain interdependent Internet technical management functions, known collectively as the Internet Assigned Numbers Authority (IANA).

C.1.2 Initially, these interdependent technical functions were performed on behalf of the U.S. Government under a contract between the Defense Advanced Research Projects Agency (DARPA) and the University of Southern California (USC), as part of a research project known as the Terranode Network Technology (TNT). As the TNT project neared completion and the DARPA/USC contract neared expiration in 1999, the U.S. Government recognized the need for the continued performance of the IANA functions as vital to the stability and correct functioning of the Internet. On December 24, 1998, USC entered into a transition agreement with the Internet Corporation for Assigned Names and Numbers (ICANN) under which ICANN secured directly from USC, all necessary resources, including key personnel, intellectual property, and computer facility access critical to the continued performance of the IANA functions. Having assumed these key resources (as well as other responsibilities associated with privatization of the Internet domain name system), ICANN was uniquely positioned to undertake performance of these functions. On February 8, 2000 and then on March 21, 2001, the DoC entered into an agreement with ICANN to perform the IANA functions. In connection with its work under these agreements, ICANN has developed and maintained close, constructive working relationships with a variety of interested parties, including Internet standards development organizations and technical bodies.

C.1.3 The Government acknowledges that data submitted by applicants in connection with the IANA function is confidential information. To the extent permitted by law, the Government shall accord any data submitted by applicants in connection with the IANA functions with the same degree of care as it uses to protect its own confidential information, but not less than reasonable care, to prevent the unauthorized use, disclosure or publication of confidential information. In providing data that is subject to such a confidentiality obligation to the United States Government, the Contractor shall advise the United States Government of that obligation.

C.2 CONTRACTOR REQUIREMENTS

C.2.1 The Contractor shall furnish the necessary personnel, material, equipment, services, and facilities (except as otherwise specified), to perform the following requirements without any cost to the United States Government. On or after the effective date of this purchase order, the Contractor 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 requirements of this purchase order. The Government will review the contractor's accounting data at anytime fees are charged to verify that the above conditions are being met.

C.2.1.1 DoC NTIA has a requirement for a Contractor to maintain the operation of the Internet by performing the IANA functions. In performance of this purchase order, the Contractor shall furnish the necessary personnel, material, equipment, services, and facilities (except as otherwise specified), to perform the following IANA requirements.

C.2.1.1.1 Coordinate the assignment of technical protocol parameters – This function involves the review and assignment of unique values to various parameters (e.g., operation codes, port numbers, object identifiers, protocol numbers) used in various Internet protocols. This function also includes the dissemination of the listings of assigned parameters through various means (including on-line publication) and the review of technical documents for consistency with assigned values.

C.2.1.1.2 Perform administrative functions associated with root management – This function addresses facilitation and coordination of the root zone of the domain name system, with 24 hour-a-day/7 days-a-week coverage. It includes receiving requests for and making routine updates of the country code top level domain (ccTLD) contact (including technical and administrative contacts) and nameserver information. It also includes receiving delegation and redelegation requests, investigating the circumstances pertinent to those requests, and making its recommendations and reporting actions undertaken in connection with processing such requests. This function, however, does not include authorizing modifications, additions, or deletions to the root zone file or associated information that constitute delegation or redelegation of top level domains. (This purchase order does not alter root system responsibilities as set forth in Amendment 11 of the Cooperative Agreement NCR-9218742 between the DoC and VeriSign, Inc.)

C.2.1.1.3 Allocate Internet Numbering Resources – This function involves overall responsibility for allocated and unallocated IPv4 and IPv6 address space and Autonomous System Number space. It includes the responsibility for delegation of IP address blocks to regional registries for routine allocation, typically through downstream providers, to Internet end-users within the regions served by those registries. This function also includes reservation and direct allocation of space for special purposes, such as multicast addressing, addresses for private networks as described in RFC 1918, and globally specified applications.

C.2.1.1.4 Other services – The Contractor shall perform other IANA functions and implement modifications in performance of the IANA functions as needed upon mutual agreement of the parties. These functions may include the performance of periodic functions or supplemental functions identified by the Contractor as part of the six (6) month performance progress report.

C.3 REPORTING REQUIREMENTS

C.3.1 The Contractor shall, in collaboration with the DoC, work to specify (a) metrics for processing times for requests under section 2.1.1.2, and (b) elements to be included in reporting on delegation and re-delegation requests. The Contractor shall submit to the COTR no later than August 1, 2003 an initial specification of such metrics and elements. Should this initial specification suggest substantive changes in established policies associated with the IANA functions, such changes must comply with section C.4.2.

C.3.2 Requests for Modification to the Root Zone File – The Contractor shall prepare and submit to the COTR a report that contains statistical and narrative information concerning requests for modification to the root zone file and associated information, including primary and secondary name-servers changes; administrative and/or technical contact changes; registration website url changes; and street address, email address, telephone or facsimile transmission changes. Such report shall include the date of the request; the date of completion of processing the request; its disposition; and its status, if it has been pending longer than 30 days. Such report shall be submitted to the COTR no later than 15 calendar days following the end of each business quarter.

C.3.3 Allocation of IP address blocks – The Contractor shall prepare and submit to the COTR a report that contains statistical and narrative information concerning requests to the Contractor for the allocation of additional IP address blocks. Such report shall include the date of the request; the date of completion of processing the request; its disposition; and its status, if it has been pending longer than 30 days. Such report shall be submitted to the COTR no later than 15 calendar days following the end of each business quarter.

C.3.4 Performance Progress Report – The Contractor shall prepare and submit to the COTR a performance progress report every six (6) months after purchase order award that contains statistical and narrative information on the performance of the IANA functions during the previous six (6) month period. The report shall include a summary of the major work performed for each of the functions during the previous six (6) month period, including technical status, major events, problems encountered, and any projected significant changes related to the performance of the functions.

C.3.5 Final Report – The Contractor shall prepare and submit a final report on the performance of the IANA functions that documents standard operating procedures, including a description of the techniques, methods, software, and tools employed in the performance of the IANA functions. This report shall be submitted to the COTR no later than thirty days after expiration of the purchase order.

C.4 PERFORMANCE EXCLUSIONS

C.4.1 This purchase order, in itself, does not authorize modifications, additions, or deletions to the root zone file or associated information that constitute delegation or re-delegation of top level domains. (This purchase order does not alter root system responsibilities as set forth in Amendment 11 of the Cooperative Agreement NCR-9218742 between the DoC and VeriSign, Inc.)

C.4.2 This purchase order, in itself, does not authorize the Contractor to make material changes in established methods associated with the performance of the IANA functions. Procedures for policy development will remain the subject of the Joint Project Agreement (JPA) entitled "Memorandum of Understanding between the U.S. Department of Commerce and the Internet Corporation for Assigned Names and Numbers," dated November 25, 1998, as amended. Policy development procedures developed pursuant to the JPA may result in the adoption of new or changed policies concerning Internet technical management functions. To the extent such policies require alterations in the manner in which the IANA functions are performed, those alterations may be implemented upon mutual agreement of the parties.

C.4.3 Contractor's obligation to perform the IANA functions shall not be conditioned on the existence of any agreement between the Contractor and any third party.

D. Section D - Packaging and Marking

All deliverables required by this order shall be submitted in accordance with Section F.

E. Section E - Inspection and Acceptance

INSPECTION AND ACCEPTANCE

CAR Clause Number Title Date
1352.246-70 Inspection and Acceptance March 2000

Final inspection and acceptance of all work performed, reports, and other deliverables will be performed by the Technical Representative identified in Section G at the place of delivery.

F. Section F—Deliveries and Performance

F.1 PERIOD OF PERFORMANCE

CAR Clause Number Title Date
1352.215-70 Period of Performance March 2000

The period of performance for this requirement is as follows:

Base Period (April 1, 2003 – September 30 , 2003)
Option Period 1 (October 1, 2003 – September 30, 2004)
Option Period 2 (October 1, 2004 – September 30, 2005)
Option Period 3 (October 1, 2005 – March 31, 2006)

F.2 PLACE OF PERFORMANCE

All work shall be performed by the Contractor at the Contractor's facility.

F.3 DISTRIBUTION OF DELIVERABLES

The Contractor shall submit copies of all deliverables specified below as follows:

COTR 1 Copy
Contracting Officer 1 Copy

F.4 DELIVERABLES

Deliverable Due Date
Initial Specification of Metrics and Elements August 1, 2003
Report - Root Zone File Modifications Report Quarterly – 15 calendar days following the end of each business quarter
Report - Allocation of Additional IP Address Blocks Quarterly – 15 calendar days following the end of each business quarter
Performance Progress Reports Every six months (the first report is due six months after award of this order)
Final Report 30 days after expiration of the base period and 30 days after the expiration of each option period

F.5 GOVERNMENT RIGHTS TO DELIVERABLES

All deliverables provided under this task order become the property of the U.S. Government.

F.6 GOVERNMENT REVIEW OF DELIVERABLES

The Government shall review deliverables and determine acceptability. Any deficiencies shall be corrected by the Contractor and resubmitted to the Government within seven (7) workdays after notification.

F.7 REQUIRED DELIVERABLES

The Contractor shall transmit all deliverables so that the deliverables are received by the parties listed above on or before the indicated due dates.

G. SECTION G - Contract Administration Data

G.1 CONTRACTING OFFICER'S AUTHORITY

CAR Clause Number Title Date
1352.201-70 Contracting Officer's Authority March 2000

The Contracting Officer is the only person authorized to make or approve any changes in any of the requirements of this contract and not withstanding any provisions contained elsewhere in this contract, the said authority remains solely in the Contracting Officer. In the event the Contractor makes any changes at the direction of any person other than the Contracting Officer, the change will be considered to have been made without authority and no adjustment will be made in the contract terms and conditions, including price.

G.2 CONTRACTING OFFICER'S TECHNICAL REPRESENTATIVE (COTR)

a. CAR Clause Number Title Date
  1352.201-71 Contracting Officer's Technical Representative March 2000

i. Ms. Cathy Handley is hereby designated as the Contracting Officer's Technical Representative (COTR). The COTR may be changed at any time by the Government without prior notice to the Contractor by a unilateral modification to the contract. The COTR is located at:

COTR Address: National Telecommunications and Information Administration
1401 Constitution Avenue, NW
Room 4701
Washington, D.C. 20230
Phone: (202) 482-1866
E-mail: CHANDLEY@ntia.doc.gov

ii. The responsibilities and limitations of the COTR are as follows:

(1) The COTR is responsible for the technical aspects of the project and serves as technical liaison with the Contractor. The COTR is also responsible for the final inspection and acceptance of all reports and such other responsibilities as may be specified in the contract.

(2) The COTR is not authorized to make any commitments or other wise obligate the Government or authorize any changes, which affect the contract price, terms, or conditions. Any contractor requests for changes shall be referred to the Contracting Officer. No such changes shall be made without the expressed prior authorization of the Contracting Officer.

b. The COTR is responsible for: receiving all deliverables; inspecting and accepting supplies or services provided hereunder in accordance with the terms and conditions of this contract; providing direction to the contractor, which clarifies the contract effort, fills in details or otherwise serves to accomplish the contractual Scope of Work; evaluating performance; and certifying all invoices/vouchers for acceptance of the supplies or services furnished for payment prior to forwarding to the Contracting Officer.

H. SECTION H - Special Contract Requirements

H.1 ORGANIZATIONAL CONFLICT OF INTEREST

CAR Clause Number Title Date
1352.209-71 Organizational Conflict of Interest March 2000

a. The Contractor warrants that, to the best of the Contractor's knowledge and belief, there are no relevant facts or circumstances which would give rise to an organizational conflict of interest, as defined in FAR Subpart 9.5, or that the Contractor has disclosed all such relevant information.

b. The Contractor agrees that if an actual or potential organizational conflict of interest is discovered after award, the Contractor will make a full disclosure in writing to the Contracting Officer. This disclosure shall include a description of actions which the Contractor has taken or proposes to take, after consultation with the Contracting Officer, to avoid, mitigate, or neutralize the actual or potential conflict.

c. Remedies - The Contracting Officer may terminate this contract for convenience, in whole or in part, if it deems such termination necessary to avoid an organizational conflict of interest. If the Contractor was aware of a potential organizational conflict of interest prior to award or discovered an actual or potential conflict after award and did not disclose or misrepresented relevant information to the Contracting Officer, the Government may terminate the contract for default, debar the Contractor for Government contracting, or pursue such other remedies as may be permitted by law or this contract.

d. The Contractor further agrees to insert provisions which shall conform substantially to the language of this clause, including the paragraph (d), in any subcontract or consultant agreement hereunder.

I. Section I – Contract Clauses

I.1 CLAUSES INCORPORATED IN FULL TEXT

52.213-4 Terms and Conditions-Simplified Acquisitions (Other Than Commercial Items).

Terms and Conditions-Simplified Acquisitions (Other Than Commercial Items) (Sept 2002)

(a) The Contractor shall comply with the following Federal Acquisition Regulation (FAR) clauses that are incorporated by reference:

(1) The clauses listed below implement provisions of law or Executive order:

(i) 52.222-3, Convict Labor (Aug 1996) (E.O. 11755).

(ii) 52.222-21, Prohibition of Segregated Facilities (FEb 1999) (E.O. 11246).

(iii) 52.222-26, Equal Opportunity (Apr 2002) (E.O. 11246).

(iv) 52.225-13, Restrictions on Certain Foreign Purchases (JUly 2000) (E.O.'s 12722, 12724, 13059, 13067, 13121, and 13129).

(v) 52.233-3, Protest After Award (Aug 1996) (31 U.S.C. 3553).

(2) Listed below are additional clauses that apply:

(i) 52.232-1, Payments (Apr 1984).

(ii) 52.232-8, Discounts for Prompt Payment (Feb 2002).

(iii) 52.232-11, Extras (Apr 1984).

(iv) 52.232-25, Prompt Payment (Feb 2002).

(v) 52.233-1, Disputes (July 2002).

(vi) 52.244-6, Subcontracts for Commercial Items (Dec 2001).

(vii) 52.253-1, Computer Generated Forms (Jan 1991).

(b) The Contractor shall comply with the following FAR clauses, incorporated by reference, unless the circumstances do not apply:

(1) The clauses listed below implement provisions of law or Executive order:

(i) 52.222-19, Child Labor-Cooperation with Authorities and Remedies (Sept 2002) (E.O. 13126). (Applies to contracts for supplies exceeding the micro-purchase threshold.)

(ii) 52.222-20, Walsh-Healey Public Contracts Act (DEc 1996) (41 U.S.C. 35-45) (Applies to supply contracts over $10,000 in the United States, Puerto Rico, or the U.S. Virgin Islands).

(iii) 52.222-35, Equal Opportunity for Special Disabled Veterans, Veterans of the Vietnam Era, and Other Eligible Veterans (Dec 2001) (38 U.S.C. 4212) (Applies to contracts of $25,000 or more).

(iv) 52.222-36, Affirmative Action for Workers with Disabilities (JUne 1998) (29 U.S.C. 793). (Applies to contracts over $10,000, unless the work is to be performed outside the United States by employees recruited outside the United States.) (For purposes of this clause, United States includes the 50 States, the District of Columbia, Puerto Rico, the Northern Mariana Islands, American Samoa, Guam, the U.S. Virgin Islands, and Wake Island.)

(v) 52.222-37, Employment Reports on Special Disabled Veterans, Veterans of the Vietnam Era, and Other Eligible Veterans (Dec 2001) (38 U.S.C. 4212) (Applies to contracts of $25,000 or more).

(vi) 52.222-41, Service Contract Act of 1965, As Amended (MAy 1989) (41 U.S.C. 351, et seq.) (Applies to service contracts over $2,500 that are subject to the Service Contract Act and will be performed in the United States, District of Columbia, Puerto Rico, the Northern Mariana Islands, American Samoa, Guam, the U.S. Virgin Islands, Johnston Island, Wake Island, or the outer continental shelf lands).

(vii) 52.223-5, Pollution Prevention and Right-to-Know Information (Apr 1998) (E.O. 12856) (Applies to services performed on Federal facilities).

(viii) 52.225-1, Buy American Act-Supplies (May 2002) (41 U.S.C. 10a - 10d) (Applies to contracts for supplies, and to contracts for services involving the furnishing of supplies, for use within the United States if the value of the supply contract or supply portion of a service contract exceeds the micro-purchase threshold and the acquisition-

(A) Is set aside for small business concerns; or

(B) Cannot be set aside for small business concerns (see 19.502-2), and does not exceed $25,000).

(ix) 52.232-33, Payment by Electronic Funds Transfer-Central Contractor Registration (MAy 1999). (Applies when the payment will be made by electronic funds transfer (EFT) and the payment office uses the Central Contractor Registration (CCR) database as its source of EFT information.)

(x) 52.232-34, Payment by Electronic Funds Transfer-Other than Central Contractor Registration (MAy 1999). (Applies when the payment will be made by EFT and the payment office does not use the CCR database as its source of EFT information.)

(xi) 52.247-64, Preference for Privately Owned U.S.-Flag Commercial Vessels (June 2000) (46 U.S.C. 1241). (Applies to supplies transported by ocean vessels.)

(2) Listed below are additional clauses that may apply:

(i) 52.209-6, Protecting the Government's Interest When Subcontracting with Contractors Debarred, Suspended, or Proposed for Debarment (July 1995) (Applies to contracts over $25,000).

(ii) 52.211-17, Delivery of Excess Quantities (Sept 1989) (Applies to fixed-price supplies).

(iii) 52.247-29, F.o.b. Origin (June 1988) (Applies to supplies if delivery is f.o.b. origin).

(iv) 52.247-34, F.o.b. Destination (Nov 1991) (Applies to supplies if delivery is f.o.b. destination).

(c) FAR 52.252-2, Clauses Incorporated by Reference (Feb 1998). This contract incorporates one or more clauses by reference, with the same force and effect as if they were given in full text. Upon request, the Contracting Officer will make their full text available. Also, the full text of a clause may be accessed electronically at this/these address(es):

www.arnet.gov

(d) Inspection/Acceptance. The Contractor shall tender for acceptance only those items that conform to the requirements of this contract. The Government reserves the right to inspect or test any supplies or services that have been tendered for acceptance. The Government may require repair or replacement of nonconforming supplies or re-performance of nonconforming services at no increase in contract price. The Government must exercise its post-acceptance rights-

(1) Within a reasonable period of time after the defect was discovered or should have been discovered; and

(2) Before any substantial change occurs in the condition of the item, unless the change is due to the defect in the item.

(e) Excusable delays. The Contractor shall be liable for default unless nonperformance is caused by an occurrence beyond the reasonable control of the Contractor and without its fault or negligence, such as acts of God or the public enemy, acts of the Government in either its sovereign or contractual capacity, fires, floods, epidemics, quarantine restrictions, strikes, unusually severe weather, and delays of common carriers. The Contractor shall notify the Contracting Officer in writing as soon as it is reasonably possible after the commencement of any excusable delay, setting forth the full particulars in connection therewith, shall remedy such occurrence with all reasonable dispatch, and shall promptly give written notice to the Contracting Officer of the cessation of such occurrence.

(f) Termination for the Government's convenience. The Government reserves the right to terminate this contract, or any part hereof, for its sole convenience. In the event of such termination, the Contractor shall immediately stop all work hereunder and shall immediately cause any and all of its suppliers and subcontractors to cease work. Subject to the terms of this contract, the Contractor shall be paid a percentage of the contract price reflecting the percentage of the work performed prior to the notice of termination, plus reasonable charges that the Contractor can demonstrate to the satisfaction of the Government, using its standard record keeping system, have resulted from the termination. The Contractor shall not be required to comply with the cost accounting standards or contract cost principles for this purpose. This paragraph does not give the Government any right to audit the Contractor's records. The Contractor shall not be paid for any work performed or costs incurred that reasonably could have been avoided.

(g) Termination for cause. The Government may terminate this contract, or any part hereof, for cause in the event of any default by the Contractor, or if the Contractor fails to comply with any contract terms and conditions, or fails to provide the Government, upon request, with adequate assurances of future performance. In the event of termination for cause, the Government shall not be liable to the Contractor for any amount for supplies or services not accepted, and the Contractor shall be liable to the Government for any and all rights and remedies provided by law. If it is determined that the Government improperly terminated this contract for default, such termination shall be deemed a termination for convenience.

(h) Warranty. The Contractor warrants and implies that the items delivered hereunder are merchantable and fit for use for the particular purpose described in this contract.

(End of clause)

52.217-8 Option to Extend Services.

As prescribed in 17.208(f), insert a clause substantially the same as the following:

Option to Extend Services (Nov 1999)

The Government may require continued performance of any services within the limits and at the rates specified in the contract. These rates may be adjusted only as a result of revisions to prevailing labor rates provided by the Secretary of Labor. The option provision may be exercised more than once, but the total extension of performance hereunder shall not exceed 6 months. The Contracting Officer may exercise the option by written notice to the Contractor within 30 days.

(End of clause)

52.217-9 Option to Extend the Term of the Contract.

Option to Extend the Term of the Contract (Mar 2000)

(a) The Government may extend the term of this contract by written notice to the Contractor within 30 days prior to the expiration of the current performance period; provided that the Government gives the Contractor a preliminary written notice of its intent to extend at least 60 days before the contract expires. The preliminary notice does not commit the Government to an extension.

(b) If the Government exercises this option, the extended contract shall be considered to include this option clause.

(c) The total duration of this contract, including the exercise of any options under this clause, shall not exceed 3 years and 6 months.

(End of clause)

I.2 CLAUSES INCORPORATED BY REFERENCE

52.252-2 Clauses Incorporated by Reference Feb 1998
52.227-1 Authorization and Consent Jul 1995
52.227-2 Notice and Assistance Regarding Patent and Copyright Infringement Aug 1996
52.227-11 Patent Rights – Retention by the Contractor (Short Form) Jun 1997
52.227-14 Rights in Data – General Jun 1987
52.227-14 Rights in Data – General – Alternate I Jun 1987
52.227-14 Rights in Data – General – Alternate II Jun 1987
52.227-14 Rights in Data – General – Alternate III Jun 1987
52.227-14 Rights in Data – General – Alternate V Jun 1987
52.227-16 Additional Data Requirements Jun 1987

J. Section J – Attachments

None


Response to Request for Quotation Number DG1335-03-RQ-0030

In response to Request for Quotation (RFQ) Number DG1335-03-RQ-0030, the Internet Corporation for Assigned Names and Numbers (ICANN) submits the following proposal:

A. Summary.

In November 1998, the United States Government began the transition of the responsibility for performing various technical Internet-coordination functions – which the United States Government and its contractors previously performed – to private-sector management. The transition is proceeding under a Memorandum of Understanding (MoU) between the United States Department of Commerce and ICANN, under which the parties are jointly designing, developing, and testing mechanisms that should be in place and the steps necessary to transition these responsibilities to a private-sector not-for-profit entity. Once testing is successfully completed, it is contemplated that management of the DNS will be transitioned to the mechanisms, methods, and procedures designed and developed under the MoU.

The RFQ covers the continued operation during the transition process of the Internet Assigned Numbers Authority (the IANA), one important part of the functions involved in the transition to private-sector management. In particular, the IANA functions involve implementation aspects of the Internet-coordination policies that are established according to the private-sector mechanisms that are being developed under the MoU. The purpose of the RFQ is to ensure the seamless performance of these key coordination functions as the transition proceeds.

ICANN is uniquely well-suited to perform the IANA functions during the transition. To ensure continued stable operation of the Internet, it is important that the IANA functions be performed in a manner that blends smoothly from the former (US-Government) regime to the emerging (private-sector) regime. Because ICANN serves as the forum for designing, developing, and testing the mechanisms for the performance of these Internet-coordination functions – both the development of the relevant policies and the execution of those policies – it is uniquely positioned to ensure the provision of the IANA functions is smoothly adapted to the transition.

From a technical perspective as well, ICANN is ideally suited to ensure the continued smooth operation of the IANA functions. By a transition agreement entered in late 1998, ICANN secured from the University of Southern California (which had performed the IANA functions for over twenty years) the resources, methods, and intellectual property necessary to perform this interdependent set of vital functions. In the four years since then, the requirements for the IANA functions have expanded and evolved with the Internet, and ICANN has continually refined and improved the methods employed to operate the IANA functions to ensure that it continues to provide the platform for stable Internet operation through useful, efficient, and convenient coordination services.

One very important way in which the Internet has evolved over the last several years is the constantly increasing diversity of stakeholders that have important interests in the coordination process. The Internet is no longer an academic and research network focused in a single country; it is now a ubiquitous global communications medium for commerce, research, education, and cultural and other expressive activities. This evolution has resulted in governments, commercial interests, and others joining the technical community as essential stakeholders to be served by the IANA functions. As a result, there has been a steadily increasing diversity of interests and needs to be accommodated in performing the IANA's coordination role.

ICANN's institutional design is uniquely suited to address the evolving requirements of the IANA functions. ICANN has established relationships with the entities responsible for the Internet's technical operations (gTLD registry operators, sponsors, and registrars; ccTLD managers; Regional Internet (IP Address) Registries; the IETF and other Internet standards-development organizations; root-nameserver operators; and Internet service providers) as well as governments, commercial interests, non-commercial organizations, and others that have come to depend on the Internet. ICANN's alliances with these entities allow it to call on their cooperative assistance in addressing increasingly complex coordination issues (such as the challenges presented by conflicting views over ccTLD delegations), thereby leveraging ICANN's resources to address the continually evolving coordination tasks the IANA must perform.

The broad-based support within the Internet community also gives ICANN a sound financial basis for performing the IANA functions in the long term. ICANN has secured long-term commitments of funding from registries and registrars adequate to support its Internet-coordination activities, including the performance of the IANA functions. As ICANN and the Internet evolve together, an increasing number of registries and registrars have joined in these commitments. These commitments have allowed ICANN to provide the IANA functions without charging any fees for services in the past, and the long-term funding base is expected to allow ICANN to continue to provide the IANA functions without charging fees for services throughout the term of contract contemplated by the RFQ.

B. Description of ICANN, its Experience, and its Capabilities.

1. Role of ICANN in Internet Coordination. ICANN was formed in 1998 by Internet stakeholders in response to the US Government's announcement, in its Statement of Policy on Management of Internet Names and Addresses, 63 Fed. Reg. 31741 (10 June 1998) (usually known as the "White Paper") of its intention to privatize Internet-coordination activities historically performed by the US Government and its contractors, including the IANA functions that are the subject of the RFQ. ICANN is a California non-profit public-benefit corporation that works to develop and implement Internet-coordination policies though consensus-based processes.

In 2002, ICANN underwent an intensive community-based effort to evaluate its structures and processes and refine them to best meet the Internet community's evolving needs and expectations. As a result of this effort, ICANN developed the following clarified mission statement that was broadly endorsed by the Internet stakeholders that participate in ICANN:

MISSION

The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems. In particular, ICANN:

1. Coordinates the allocation and assignment of the three sets of unique identifiers for the Internet, which are

a. Domain names (forming a system referred to as "DNS");

b. Internet protocol ("IP") addresses and autonomous system ("AS") numbers; and

c. Protocol port and parameter numbers.

2. Coordinates the operation and evolution of the DNS root name server system.

3. Coordinates policy development reasonably and appropriately related to these technical functions.

The IANA functions that are the subject of the RFQ encompass the execution of parts 1 and 2 of this mission statement:

RFQ Statement of Work ICANN Mission
C.2.1.1.1 Coordinate the assignment of technical protocol parameters. 1c. Coordinates . . . Protocol port and parameter numbers.
C.2.1.1.2 Perform administrative functions associated with root management. 1a. Coordinates . . . Domain names (forming a system referred to as "DNS").2. Coordinates the operation and evolution of the DNS root name server system.
C.2.1.1.3 Allocate Internet Numbering Resources. 1b. Coordinates . . . Internet protocol ("IP") addresses and autonomous system ("AS") numbers.
C.2.1.1.4 Other services [upon mutual agreement of the parties]. The mission of [ICANN] is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems.

Thus, ICANN's mission is targeted to perform Internet-coordination activities, including those encompassed in the RFQ's statement of work.

In addition to developing a sharpened statement of ICANN's mission, the 2002 evaluation and reform process focused on enhancing ICANN's structures and processes for stakeholder participation and input. Under these enhancements, ICANN is to be composed of three community-based supporting organizations and several advisory committees. These supporting organizations – known as the Address Supporting Organization (ASO), the Country-Code Names Supporting Organization (ccNSO), and the Generic Names Supporting Organization (GNSO) – are responsible for developing recommendations in their respective areas of expertise:

  • The ASO has four members: the four Regional Internet Registries (APNIC, ARIN, LACNIC, and RIPE NCC) that have been delegated responsibility by the IANA for routine allocation and assignment within their respective regions. These four 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 Numbering Resources (IP addresses and autonomous system numbers).
  • The GNSO consists of a Council selected by six constituencies representing entities involved in using and operating the domain-name system. The GNSO is responsible for developing consensus-based recommendations on policy issues relating to the generic top-level domains.
  • The ccNSO, which is still in the formation process, will be responsible for policy-related activities relevant to country-code top-level domains, specifically (1) developing policy recommendations to the ICANN Board; and (2) nurturing consensus across the ccNSO's constituencies, including the name-related activities of ccTLDs. The structure and processes of the ccNSO are currently the subject of extensive consultation and development throughout the ccTLD managers and other affected stakeholders, led by a ccNSO Assistance Group, which has published for comment ten reports and related documents.

ICANN's supporting organizations provide mechanisms for close cooperation with, and input by, the broad range of entities concerned with the maintenance and improvement of the Internet's technical coordination. The input and assistance these supporting organizations provide not only effective community-based mechanisms for development of coordination policies, but also a collaborative environment that assists in the execution of those policies (i.e. the performance of the IANA functions).

ICANN also includes several active advisory committees, which contribute significantly to ICANN's ability to effectively perform the IANA functions in a manner that is responsive to the Internet's evolving needs. These committees are:

  • Governmental Advisory Committee. The GAC is open to participation by all national governments and certain multinational organizations (including the European Union, the World Intellectual Property Organization, the Organization for Economic Cooperation and Development, and the International Telecommunications Union). Governments of over forty countries with significant use of the Internet participate regularly in the GAC, and the GAC has had interactions with 179 national governments and public authorities.

    ICANN has benefited greatly from its association with governments through the GAC, and those benefits are particularly relevant to ICANN's unique ability to perform the IANA functions. For example, one of the GAC's major accomplishments has been its issuance, in February 2000, of Principles for the Delegation and Administration of ccTLDs. These principles, which state best practices for ccTLD managers, ICANN, and governments in connection with ccTLD delegation and administration, have given important guidance to those parties. On many occasions, members of the Governmental Advisory Committee have served as important resources in assisting ICANN in making contact with governments concerning ccTLD matters, as well as in counseling governments and ccTLD managers on ccTLD-related practices that will promote stable and secure Internet coordination.
  • Root-Server System Advisory Committee. This committee consists of the operators of the thirteen root nameservers as well as other personnel involved in Internet-infrastructure management. The RSSAC has a liaison from the Internet Architecture Board. The RSSAC considers and provides advice on the operational requirements of root nameservers, including security and performance matters concerning the root-nameserver system. The RSSAC's advice is particularly useful to ICANN in providing guidance regarding how particular root-zone-management practices affect performance of the root-nameserver system. For example, the RSSAC is currently engaged in formulating advice concerning inclusion of IPv6 glue in the root zone.
  • Security and Stability Advisory Committee. This committee consists of technical experts drawn from gTLD and ccTLD registries, gTLD registrars, RIRs, and the IETF community. It is responsible for advising on matters relating to the security and integrity of the Internet's naming and address allocation systems. Its projects also contribute to ICANN's ability to soundly perform the IANA functions. For example, it is currently conducting a review, with participation of ccTLD managers and IANA personnel, of the IANA's procedures for review of nameserver change requests.
  • At-Large Advisory Committee. This committee is responsible for providing advice on the activities of ICANN, insofar as they relate to the interests of individual Internet users. It is an important vehicle for the informed participation by users in ICANN.

ICANN also benefits from the support of a Technical Liaison Group (TLG), which consists of 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 have agreed to be available to provide technical advice on specific matters pertinent to ICANN's activities.

ICANN also recently introduced more structured procedures for taking advantage of existing expertise that resides in the public or private sector but outside of ICANN. These procedures are not yet tested, but it is expected that they will expand ICANN's access to specialized expertise, which is likely also to assist in performance of the IANA functions.

2. Facilities. ICANN operates from facilities subleased from, and in the same building as, USC-ISI. Thus, ICANN benefits 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 agreements with USC-ISI, ICANN has acquired the intellectual property used by USC-ISI in performing the IANA functions.

ICANN's proximity to USC-ISI is particularly beneficial because of USC-ISI's performance of the RFC Editor function. The protocol-parameter aspects of the IANA functions require close cooperation with the RFC Editor. ICANN's proximity to USC-ISI's operations promotes close relationships with the USC-ISI personnel that perform the RFC Editor function, thereby improving the coordination between the IANA and RFC Editor.

3. Financial Capabilities. As a non-profit organization, ICANN operates on a cost-recovery basis. Over the last four years, the Internet community has developed a framework for financial support of ICANN from diverse sources including gTLD registry operators and registrars; ccTLD managers; and IP address registries. Each year, a consultative budget process occurs in which the representatives funding sources, with opportunity for input from organizational and individual Internet users and the public generally, assess priorities for ICANN's operations and necessary funding levels.

For its 2002-2003 fiscal year, ICANN expects to receive over $6,500,000 in revenue, of which over $4,500,000 is generated from long-term contractual support commitments by gTLD and ccTLD registries and registrars. These funding levels are fully adequate to support the continued performance of the IANA functions without cost to the US Government and without establishment of service fees for the coordination activities involved in the IANA functions.

C. General Approach to Work.

ICANN proposes to perform the services under the contract by continuing to build on the techniques for technical coordination of the Internet pioneered by Dr. Jon Postel, as adapted to meet the Internet's evolving needs since ICANN assumed responsibility for the IANA functions in 1999-2000. Dr. Postel's 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 functions that achieved a great measure of stability for the Internet. Although continuous improvement of methods is required to meet the Internet's evolving and expanding coordination needs, ICANN believes that the values pioneered by Dr. Postel form an essential foundation for the successful continuation of the IANA functions.

To realize these values going forward, ICANN has built upon the expertise it received from Dr. Postel's key co-workers and the intellectual property and other tools he used in performing the IANA functions, 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, LACNIC, RIPE NCC, as well as its continuing relationship with USC-ISI, give it knowledge resources that are very important to continued successful performance of the IANA functions.

Historically, an essential requirement for the successful performance of the IANA functions has been constant consultation with the Internet's stakeholders. In Dr. Postel's era, this consultation was performed mostly in informal ways, but the expanding size and diversity of the Internet has required the addition of more formal consultation structures. The supporting organizations, advisory committees, and other consultative structures established by ICANN pursuant to the MoU provide avenues for consultation that are used extensively in guiding appropriate performance of the IANA functions.

D. Organization, Staffing, and Management.

Currently, the following ICANN staff is devoted to performing the IANA functions:

Person Role % of FTE
Michelle S. Cotton Supervisor of IANA Operations: Supervision of IANA functions; IETF liaison 100
John Crain Senior Technical Officer: Technical advice on root management and root-nameserver coordination; liaison to root-nameserver operators and Regional Internet Registries 30
Lauren Graham Administrative Assistant: Support of ccTLD liaison function 20
Anne-Rachel Inne ccTLD Liaison (Acting): Liaison to ccTLD managers 25
Andrew McLaughlin Senior Advisor: Assistance in assessment of ccTLD relations 5
Jennifer Rodriguez IANA Administrative Assistant: Assistance with protocol-parameter registry maintenance 60
Theresa Swinehart Director of ccNSO Support & International Relations: Liaison to ccTLD managers and governments; development of ccTLD relations; analysis of ccTLD redelegation matters 75
Louis Touton Vice President and General Counsel; Director of Technical Functions and IANA (Acting): Overall supervision of IANA operations and performance of contract; US Government liaison; legal; liaison with gTLD managers 25

The above does not include the efforts of ICANN personnel involved in management (including personnel and accounting functions), general technical functions support, and other general overhead.

ICANN is currently in the process of expanding its staff to meet the goals of the evaluation and reform process that it underwent in 2002. That process will result in an addition of approximately 2 full-time-equivalent employees to the resources shown above that are devoted to the IANA functions.

E. Work Plan for Specific Tasks.

1. Coordination of the Assignment of Technical Protocol Parameters.

One core part of the IANA functions has traditionally been, and continues to be, the assignment of technical parameter values (for example, operation codes, port numbers, object identifiers, protocol numbers, and enterprise numbers) to various entities or applications that must be uniquely identified for stable operation of the Internet. The ICANN team has extensive experience in performing this function.

One essential feature of ICANN's approach to performing this aspect of the IANA functions is keeping close and constructive working ties with the Internet standards-development organizations 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 reflected in their agreement to serve on ICANN's Technical Liaison Group. 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).

Nearly all the standards for which the IANA currently makes protocol-parameter assignments have been established by the IETF. Assignments under these standards should be made in a manner that is suitable to the IETF. To achieve that goal ICANN and IETF entered a Memorandum of Understanding Concerning the Technical Work of the IANA on 10 March 2000. Under that MoU, IANA assignments of protocol parameters (i.e. assignments not relating to domain names and Numbering Resources) for the IETF-created standards are made as directed by the criteria and procedures specified in Requests for Comments (RFCs), including Proposed, Draft and full Internet Standards and Best Current Practice documents, and any other RFC that calls for IANA assignments. In several cases, the relevant RFCs give unclear or incomplete guidance; ICANN and IETF have been engaged in a joint project over the past three years to develop and document clarified or additional criteria for these situations. In the meantime, protocol-parameter assignments continue to be assigned by the IANA following past and current practice for such assignments, unless otherwise directed by the Internet Engineering Steering Group (IESG).

One important aspect of ICANN's approach to performing the IANA functions is to be closely involved with the IETF's formulation and publication of standards (including thorough Alast 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 ICANN's 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.

A major effort that ICANN has pursued in the protocol-parameter area (in consultation with the IETF) involves clarifying and simplifying the assignment process for those seeking assignments. This has involved improved dissemination of information concerning requirements for assignments (in many cases this requires that the requirements be clarified in consultation with the IETF) and introduction of on-line forms and other tools to guide applicants through the process. Although additional improvements in this respect are ongoing, the process for many types of assignments has already been made significantly more convenient.

In addition to assigning parameter values, the IANA functions also include 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 holds the registration for the iana.com, iana.net, and iana.org domain names and operates the server at the IANA website. In addition, ICANN has been investigating (in consultation with the IETF community) additional means of disseminating lists of assigned parameter values, including mechanisms that facilitate periodic automated updates.

2. Administrative Functions Associated with Root Management.

A second important aspect of the IANA functions involves administrative functions associated with management of the authoritative domain-name system (DNS) root. Under the leadership of Dr. Postel, the IANA coordinated the deployment of the DNS (including the root nameserver system) in the mid-1980s. As part of this effort, the IANA undertook the project of delegating approximately 240 country-code top-level domains (ccTLDs) as well as the initial set of seven generic top-level domains (gTLDs). Beginning in 2001, the IANA implemented the introduction of seven new gTLDs approved through the ICANN process. The resulting fourteen gTLDs, 243 ccTLDs, and the special infrastructure TLD (.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 can require attention at any time, so that ICANN provides 24-hour/7-day "on call" coverage for these tasks.

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 needing information about TLDs know who to contact so that problems with a particular TLD can be quickly resolved. The contact information includes information about the technical and administrative contacts (organization, postal and e-mail address, and telephone and fax number) as well as about the sponsoring organization for the TLD.

In nearly every case, responsibility for the daily operation of TLDs is delegated to third-party delegees (in the case of gTLDs, these are registry operators and sponsors; in the case of ccTLDs they are ccTLD managers). Most changes to the root-zone information and to the related contact information about a TLD are initiated by requests from these delegees, although in some cases the need for changes is noticed by the IANA (or called to its attention by others), prompting the IANA to suggest to the delegee the need to submit a request for change. The IANA/ICANN team has developed various procedures for handling different categories of change requests according to the applicable technical and other requirements, so that changes are made in a properly authenticated and timely manner, while ensuring the continued security and stability of the root zone and DNS generally, as well as adherence to other applicable policies.

ICANN currently maintains and disseminates the authoritative contact information concerning TLDs, but VeriSign Registry currently serves in the role as root-zone editor. Changes to the root zone currently require approval of the Department of Commerce, as do some categories of changes to the contact information (i.e. those changes constituting redelegations, see below). The IANA/ICANN team has a demonstrated record of successfully coordinating these processes with VeriSign Registry and with the Department of Commerce. 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 any changes in procedures agreed with the Department of Commerce.

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, ICANN investigates the circumstances of the request, evaluates its conformity with the applicable policies, reports the actions undertaken in connection with processing the requests to the Department of Commerce, and makes recommendations for action on the request according to applicable policies. The policies are summarized in the May 1999 "Internet Domain Name System Structure and Delegation (ccTLD Administration and Delegation)" (ICP-1), and additional guidance is provided by the February 2000 GAC Principles as well as by the over 20 formal "IANA Reports" that have been published on TLD delegation and redelegation matters.

Particularly in the case of ccTLD redelegation matters, disputes often arise as to the suitability of various alternative delegees. A key stability-enhancing technique recognized in the policies is the mediation of delegation disputes. Although mediating resolutions of disputes, as well as thoroughly investigating the circumstances of particular delegation and redelegation requests, involves mostly work from ICANN's offices, meetings with the affected parties are often essential to achieving a suitable resolution. ICANN personnel frequently travel to Internet-related events around the world (including periodic ICANN meetings), and they frequently take advantage of the opportunities these meetings offer for bringing together parties concerned with ccTLD disputes. In addition, on a few occasions ICANN personnel have traveled to affected countries to investigate and help resolve the circumstances of particular redelegation matters. As noted above, ICANN also has available the assistance of participants in its processes (particularly governments participating in the GAC) that are often very helpful in promoting constructive dialog among contending parties. Through these techniques, ICANN has been successful in achieving consensual resolution of ccTLD disputes in a very high proportion of disputed cases.

At the present stage in the US Government's transition to private-sector-led technical management of the Internet, the 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. See item C.4.2 of the RFQ.

Actions by the Department of Commerce on delegation and redelegation requests are made after reviewing reports submitted by the IANA, which makes reliable reports that provide reasoned recommendations 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 with precedents in prior delegation and redelegation situations, and reputation for making recommendations 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 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 Numbering Resources.

The remaining principal aspect of the IANA functions involves overall supervision of the assignment of Numbering Resources, including IPv4 and IPv6 addresses and autonomous system numbers.

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 RFQ, at present these other needs include multicast addressing, addresses for private networks as described in RFC 1918, and globally specified applications. In September 2002, the IANA authored RFC 3330, which documents the "Special-Use IPv4 Addresses." 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)

Similar special assignments are (rarely) made of autonomous system numbers. In general (excluding multicast addresses), ICANN consults with the Regional Internet Registries to make new assignments of special Numbering Resources in a manner that meets IETF-defined needs. According to present practices, direct assignment by the IANA is intended to be exceptional in scope and in coordination with the RIRs, directed to particular IP address-space uses that serve needs of the overall Internet, and which could not acceptably be hindered 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 assignment system to particular uses. To the extent that new uses can be appropriately handled under the institutional framework of the RIRs, the presumption is 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 cannot be accommodated through the RIRs' assignment processes, ICANN intends to work with the RIRs to develop a suitable allocation mechanism to meet the need, based on policies formulated through the Address Supporting Organization.

4. Other Services

The RFQ also includes within the scope of services: "perform other IANA functions and implement modifications in performance of the IANA functions as needed upon mutual agreement of the parties." These functions include the administration of the .arpa top-level domain as reflected in the 28 April 2000 letter from Karen Rose (then Department of Commerce Purchase Order Technical Representative) to Louis Touton (ICANN Vice-President, Secretary, and General Counsel). ICANN will continue performing these administration services and will consult with the Department of Commerce on other additional IANA functions that arise during the course of performance. It should be noted that the six-month performance progress reports offer one means of commencing discussion of whether other functions should be performed.

5. Performance Reporting.

ICANN notes the reporting requirements of item C.3 of the RFQ and will comply with those requirements. With regard to the initial specification of metrics and elements required by item C.3.1, ICANN will develop an effective specification in consultation with affected ICANN stakeholders, including TLD managers and the Governmental Advisory Committee.

6. 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 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 US Government to a private-sector not-for-profit entity.

ICANN contemplates that, during the period of this contract, policies may be adopted through the ICANN process that affect the manner in which the IANA functions are performed. These situations will be addressed under item C.4.2 of the RFQ.

F. No Cost to Government; No Fees for Services

ICANN proposes to perform under the contract at no cost to the Government. In addition, as noted above a growing number of Internet stakeholders have contractually committed to provide ICANN the funding necessary to allow ICANN to achieve its mission, including performance of the IANA functions. Accordingly, fees to third parties for the assignment and related coordination services included in the RFQ will not be necessary.


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 02-Feb-2012
©2003  The Internet Corporation for Assigned Names and Numbers.All rights reserved.