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.
||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)
C. Section C Statement of Work
|CAR Clause Number
||Statement of Work/Specifications
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
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
C.22.214.171.124 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.126.96.36.199 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
C.188.8.131.52 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.184.108.40.206 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
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 220.127.116.11, 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
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
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
||Inspection and Acceptance
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
F.1 PERIOD OF PERFORMANCE
|CAR Clause Number
||Period of Performance
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
F.3 DISTRIBUTION OF DELIVERABLES
The Contractor shall submit copies of all deliverables specified below
COTR 1 Copy
Contracting Officer 1 Copy
|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
|Report - Allocation of Additional IP Address Blocks
||Quarterly 15 calendar days following the end of each business
|Performance Progress Reports
||Every six months (the first report is due six months after award
of this order)
||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
G. SECTION G - Contract Administration
G.1 CONTRACTING OFFICER'S AUTHORITY
|CAR Clause Number
||Contracting Officer's Authority
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,
G.2 CONTRACTING OFFICER'S TECHNICAL REPRESENTATIVE
||CAR Clause Number
||Contracting Officer's Technical Representative
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:
||Address: National Telecommunications and Information Administration
1401 Constitution Avenue, NW
Washington, D.C. 20230
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
(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
||Organizational Conflict of Interest
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
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
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
(i) 52.222-3, Convict Labor (Aug 1996) (E.O. 11755).
(ii) 52.222-21, Prohibition of Segregated Facilities (FEb 1999)
(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
(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
(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
(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
(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
(End of clause)
I.2 CLAUSES INCORPORATED BY REFERENCE
||Clauses Incorporated by Reference
||Authorization and Consent
||Notice and Assistance Regarding Patent and Copyright Infringement
||Patent Rights Retention by the Contractor (Short Form)
||Rights in Data General
||Rights in Data General Alternate I
||Rights in Data General Alternate II
||Rights in Data General Alternate III
||Rights in Data General Alternate V
||Additional Data Requirements
J. Section J Attachments
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:
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
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
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
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
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:
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
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
|C.18.104.22.168 Coordinate the assignment of technical protocol parameters.
||1c. Coordinates . . . Protocol port and parameter
|C.22.214.171.124 Perform administrative functions associated with root
||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.126.96.36.199 Allocate Internet Numbering Resources.
||1b. Coordinates . . . Internet protocol ("IP") addresses
and autonomous system ("AS") numbers.
|C.188.8.131.52 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
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
- 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
- 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
- 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
|| % of FTE
|Michelle S. Cotton
||Supervisor of IANA Operations: Supervision of IANA functions;
||Senior Technical Officer: Technical advice on root management
and root-nameserver coordination; liaison to root-nameserver operators
and Regional Internet Registries
||Administrative Assistant: Support of ccTLD liaison function
||ccTLD Liaison (Acting): Liaison to ccTLD managers
||Senior Advisor: Assistance in assessment of ccTLD relations
||IANA Administrative Assistant: Assistance with protocol-parameter
||Director of ccNSO Support & International Relations: Liaison
to ccTLD managers and governments; development of ccTLD relations;
analysis of ccTLD redelegation matters
||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
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
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
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
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
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
"In order to achieve the above goals the Internet Registry (IR) hierarchy
"The Internet Registry hierarchy consists of the following levels
of hierarchy as seen from the top down: IANA, Regional IRs, Local
"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 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 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
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
"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."
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
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 firstname.lastname@example.org.
©2003 The Internet
Corporation for Assigned Names and Numbers.All