SEE BILLING INSTRUCTIONS ON REVERSE 18. SHIPPING POINT 19. GROSS SHIPPING WEIGHT 20. INVOICE NO. 17(h) TOTAL (Cont. pages) 21. MAIL INVOICE TO: a. NAME DOC/NOAA/OFA/External Customers b. STREET ADDRESS (or P.O. Box) US 17(I) GRAND TOTAL CAMS Support Center 209 Perry Parkway, Suite 5 c. CITY d. STATE e. ZIP CODE 0.00 GAITHERSBURG MD 20877-2171 22. UNITED STATES OF AMERICA BY (Signature) /s/ Carole A. Silverman 23. NAME (Typed) Carol A.Silverman 301-258-4506 (TITLE CONTRACTING/ORDERING OFFICER) AUTHORIZED FOR LOCAL REPRODUCTION OPTIONAL FORM 347 (REV. 6/95) Previous edition not usable Prescribed by GSA/FAR 48 CFR 53.213(e)
If desired, this order (or a copy thereof) may be used by
the Contractor as the Contractor’s invoice, instead of a separate invoice,
provided the following statement, (signed and dated) is (or attached to) the
order: “Payment is requested in the amount of $_____________. No other
invoice will be submitted.” However,
if the Contractor wishes to submit an invoice, the following information must
be provided: contract number (if any), order number, item number(s),
description of supplies or services, sizes, quantities, unit prices, and
extended totals. Prepaid shipping costs will be indicated as a separate item
on the invoice. Where shipping costs exceed $10 (except for parcel post), the
billing must be supported by a bill of lading or receipt. When several orders
are invoiced to an ordering activity during the same billing period,
consolidated periodic billings are encouraged. |
|||||||||||||||||||||
RECEIVING
REPORT |
|||||||||||||||||||||
Quantity in the
“Quantity Accepted” column on the face of this order has been: |
|
|
inspected, |
|
accepted, |
|
|
received, |
|||||||||||||
by me and conforms to contract. Items listed below have been rejected for the reasons indicated. |
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
SHIPMENT
NUMBER |
PARTIAL |
|
DATE RECEIVED |
SIGNATURE OF
AUTHORIZED U.S. GOV’T REP. |
DATE |
||||||||||||||||
FINAL |
|
|
|
|
|||||||||||||||||
TOTAL CONTAINERS |
GROSS WEIGHT |
RECEIVED AT |
TITLE |
||||||||||||||||||
|
|
|
|
||||||||||||||||||
REPORT OF
REJECTIONS |
|||||||||||||||||||||
ITEM NO. |
SUPPLIES OR SERVICES |
UNIT |
QUANTITY REJECTED |
REASON FOR REJECTION |
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
|
|||||||||||||||||
|
|
|
|
OPTIONAL
FORM 347 (REV. 6/95) BACK |
|||||||||||||||||
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 (
0002 Option Period 1 (
0003 Option Period 2 (
0004 Option Period 3 (
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
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
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
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 (
Option
Period 1 (
Option
Period 2 (
Option
Period 3 (
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
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 March 2000
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:
COTR Address: National Telecommunications and Information Administration
Room 4701
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
(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
(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
(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 Aug
1996
Copyright
Infringement
52.227-11 Patent Rights – Retention by the
Contractor Jun
1997
(Short
Form)
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 (
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 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 organizationsBknown as the Address Supporting Organization (ASO), the Country-Code Names Supporting Organization (ccNSO), and the Generic Names Supporting Organization (GNSO)Bare 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 (AL@), one of ICANN=s directors (Jun Murai) is involved in the operation of another (AM@), and ICANN works closely with USC-ISI=s staff, which operates another (AB@). 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 AInternet 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 AIAB Recommended Policy on Distributing Internet Identifier Assignment.@ As stated in section 1.2 of that RFC:
AThroughout 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).
AWith 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):
AIn order to achieve the above goals the Internet Registry (IR) hierarchy was established.
AThe Internet Registry hierarchy consists of the following levels of hierarchy as seen from the top down: IANA, Regional IRs, Local IRs.
AIANA
AThe 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.
ARegional IRs
ARegional 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.
ARegional 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.
AThe specific duties of the regional IRs include coordination and representation of all local IRs in its respective regions.
ALocal IRs
ALocal 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:
AThe 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.