[IANAOversight] Fwd: [Ianaplan] A Summary of the 2012 NTIA - ICANN Contract

[Seun Ojedeji]

This may be useful for those following

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.
---------- Forwarded message ----------
From: "Bernard Aboba" <bernard.aboba at gmail.com>
Date: 9 Sep 2014 18:54
Subject: [Ianaplan] A Summary of the 2012 NTIA - ICANN Contract
To: "ianaplan at ietf.org" <ianaplan at ietf.org>
Cc:

Since a number of the comments on the list have referred to the 2012 NTIA -
ICANN contract, I thought it might be helpful to provide a summary of the
contract and its amendments.  So as to provide some context for readers of
the contract and MOU,  their contents are compared.

DISCLAIMER

I am not licensed to practice law anywhere, nor have I had any legal
training.  There this summary shouldn't be construed as a legal analysis or
advice. In particular, there is no assessment of whether either the
NTIA-ICANN contract or the MOU is legally enforceable, or whether the MOU
would in practice enable the IETF to transition to an alternate protocol
parameter vendor.

Rather than attempting to provide answers, questions which might be
answered by counsel are prefaced by my initials [BA].

Executive Summary

The 2012 NTIA-ICANN contract represents a legal framework, which while
representing an agreement between two parties (NTIA & ICANN), is also
designed to facilitate the relationship between ICANN and the "interested
and affected parties", which include the IETF and IAB.

In addition to defining the IANA functions and listing the "interested and
affected parties", the contract establishes requirements for the IANA
functions operator (such as Reporting and Security Requirements) and sets
basic parameters such as the contract timeline, compensation framework, IPR
and copyrights, and requirements upon selection of another operator.

In addition, by requiring that ICANN remain dociled in the US, the contract
establishes the jurisdiction in which the contract could be

enforced. Note that many of these details are not covered in the IETF-ICANN
MOU (RFC 2860), including aspects relating to compensation,
IPR/copyright/trademarks, and obligations on contract termination.

The contract provides little in the way of operational details, which are
to be provided by the operator to NTIA in a series of deliverables, in
coordination with the "interested and affected parties", who in practice
develop that documentation in cooperation with their communities. Since the
documentation is to be provided

later, the contract itself only has a few direct references to RFCs, such
as RFC 1918 (private addresses, referenced in C.2.9.3), and RFC 3172
(.arpa, referenced in Section C.2.9.1).

Contract Overview

-----------------

IANA functions

The NTIA-ICANN contract defines the IANA functions as follows:

(Section C.2.9)

(1) the coordination of the assignment of technical Internet protocol
parametjers;

(2) the administration of certain responsibilities associated with the
Internet DNS root zone management;

(3) the allocation of Internet numbering resources; and

(4) other services related to the management of the ARPA and INT top-level
domains (TLDs).

[MOU] In contrast, the MOU focuses on the IANA protocol parameters, and
notes that assignment of domain names and IP address blocks are out of
scope. It does not mention .ARPA (that was covered in RFC 3172, published
in September 2001).

(Section 4.3) Two particular assigned spaces present policy issues in
addition to the technical consideations specified by the IETF: the
assignment of domain names and the assignment of IP address blocks. These
policy issues are outside the scope of this MOU.

Timeline

(Page 2) The contract is for a BASE YEAR from October 1, 2012 - September
30, 2015 with provisions for two options, OPTION YEAR 1 (October 1, 2015 -
September 30, 2017) and OPTION YEAR 2 (through October 1, 2017).

Transition to a Successor Contractor

The contract requires the contractor to provide a plan for the transition
of each of the IANA functions to a successor contractor. The plan was to
have been submitted by ICANN to NTIA in April 2014.

[BA] Is a copy of the transition plan available?

(Section C.7.3)

"In the event the Government selects a successor contractor, the Contractor
shall have a plan in place for transitioning each of the IANA functions to
ensure an orderly transition while maintaining continuity and security of
operations. The plan shall be submitted to the COR

eighteen (18) months after date of contract award, reviewed annually, and
updated as appropriate."

[MOU] The MOU notes that either party may terminate the arrangement on 6
months notice:

"2. This MOU will remain in effect until either modified or cancelled by
mutual consent of the Internet Engineering Task Force and the Internet
Corporation for Assigned Names and Numbers, or cancelled by either party
with at least six (6) months notice."

[BA] The MOU does not require a succession plan, nor does it cover
ownership of IPR and copyrights that would presumbably affect a transition,
were it to occur. Is there an issue here?

Interested and Affected Parties

The contract names the "interested and affected Parties" that ICANN "must
have or develop a constructive working relationship with"; the list
includes the IETF and IAB.

(Section C.1.3)

"The Contractor, in the performance of its duties, must have or develop a
close constructive working relationship with all interested and affected
parties to ensure quality and satisfactory performance of the IANA
functions. The interested and affected parties include, but are not limited
to, the multi-stakeholder, private sector led, bottom-up policy development
model for the domain name system (DNS) that the Internet Corporation for
Assigned Names and Numbers (ICANN) represents; the Internet Engineering
Task Force (IETF) and the Internet

Architecture Board (IAB); Regional Internet Registries (RIRs); top-level
domain (TLD) operators/managers (e.g., country codes and generic);
governments; and the Internet user community."

[MOU] The MOU enables ICANN to provide similar services to other
organizations only with respect to protocols not within the IETF's scope.

(Section 1)

"It is recognized that ICANN may, through the IANA, provide similar
services to other organisations with respect

to protocols not within IETF's scope (i.e. registries not created by IETF
or IRTF action); nothing in this MOU

limits ICANN's ability to do so."

Separation of Policy Development and Operational Roles

The contract requires the strict separation of policy development and
operational roles. There has been some lack of clarity in the precise
meaning of this. For example, in RFP Amendment 001 the USG interpretted
ICANN staff authorship of RFCs as "policy development". ]

(Section C.2.5)

"The Contractor shall ensure that designated IANA functions staff members
will not initiate, advance, or advocate any policy development related to
the IANA functions. The Contractor's staff may respond

to requests for information requested by interested and affected parties as
enumerated in Section C.1.3 to inform ongoing policy discussions and may
request guidance or clarification as necessary for the performance of the
IANA functions."

(Section C.8.2)

"This contract does not authorize the Contractor to make material changes
in the policies and procedures developed by the relevant entities
associated with the performance of the IANA functions. The Contractor shall
not change or implement the established methods associated with the
performance of the IANA functions without prior approval of the CO."

(Amendment 001):
http://www.ntia.doc.gov/files/ntia/publications/sf30_amendment_0001.pdf

Question 1: "If IANA staff members are asked to participate in the
development of a standard or to co-author a document (such as a Request for
Comment), is that considered advancing policy?

USG: Yes.

[MOU] The MOU appears to define the seperation requirement in a more
practical way:

(Section 4.1)

"The IANA will assign and register Internet protocol parameters only as
directed by the criteria and procedures specified in RFCs"

Fees

While it is commonly stated that the NTIA-ICANN contract is a "zero dollar"
contract, that provision only applies to charges to the United States
Government. While there is no prohibition against fees to third parties
(e.g. the IETF), collaboration with the "interested and affected parties"
is required for fees imposed beyond the first year. While the MOU does
include prohibitions on fees for access registration fees and requires IAB
permission for registration fees, it does not cover fees to be charged to
the IETF.

(Section B.2)

"The Contractor may not charge the United States Government to perform the
requirements of this Contract. The Contractor may establish and collect
fees from third parties provided the fee levels are approved

by the Contracting Officer and are fair and reasonable. If fees are
charged, the Contractor shall base any proposed fee structure on the cost
of providing the specific service for which the fee is charged and

the resources necessary to monitor the fee driven requirements."

(Section C.2.3)

"The Contractor may propose an interim fee for the first year of the
contract, which will expire one year after the contract award. The
documentation must be based upon the anticipated cost for providing the

specific service for which the fee is charged, including start up costs, if
any, equipment, personnel, software, etc. If the Contractor intends to
establish and collect fees from third parties beyond the first year of the
contract, the Contractor must collaborate with the interested and affected
parties as enumerated in Section C.1.3 to develop a proposed fee structure
based on a methodology that tracks the actual costs incurred for each
discrete IANA function enumerated and described in C.2.9. "

[MOU] Charges for accessing information about current assignments are
prohibited (Section 4.4); charges for assignments are permitted only by
consent of the IAB (Section 4.5). Note that neither the MOU nor the annual
SLAs discuss fees to be charged to the IETF (e.g. there are

no statements prohibiting fees), nor is a process for negotiation of fees
described.

[BA] Is there a requirement for collaboration on fee structure that is not
covered by the current MOU? If so, can this be incorporated into the annual
amendments?

IPR and copyrights

The Contract includes a number of clauses addressing IPR and other rights.

H.2 Patent Rights - Ownership by the Contractor

This is a long section which relates to ICANN patents relating to

the IANA functions.

[BA] Do such patents actually exist?

H.4 Rights in Data - Special Works

"(1) The Government shall haveâ€"

(i) Unlimited rights in all data delivered under this contract, and in all
data first produced in the performance of this contract, except as provided
in paragraph

(c) of this clause for copyright.

(ii) The right to limit assertion of copyright in data first produced in
the performance of this contract, and to obtain assignment of copyright in
that data, in accordance with paragraph (c)(1) of this clause.

(iii) The right to limit the release and use of certain data in accordance
with paragraph (d) of this clause."

H.5 Rights in Data - Existing Works

"Contractor grants to the Government, and others acting on its behalf, a
paid-up nonexclusive, irrevocable, worldwide license to reproduce, prepare
derivative works, and perform publicly and display publicly, by or on
behalf of the Government, for all the material and subject

matter called for in this contract, or for which this clause is
specifically made applicable."

In RFP Amendment 001, ICANN inquired about ownership of IPR and copyrights
accruing under the contract, and the USG indicated that the government
could take ownership of the deliverables.

8. "Under this contract, the contractor provides the deliverables at no
cost to the U.S. Government. Is it therefore correct that the Contractor
also retains ownership of the deliverables? If not, please clarify how the
U.S. Government may take ownership of the deliverables produced under this
zero dollar contract?"

USG: "A zero dollar contract does not mean that there is no consideration
provided by the Government. The Government may take ownership of
deliverables in exchange for the consideration of the

provider under this contract."

A similar response is provided with respect to Question 11.

[BA] Has the USG taken ownership of the deliverables under the contract or
does it plan to do so? If not, would the contractor retain ownership?

Deliverables

The deliverables outlined in Section F.4 of the contract, and updated in
Amendment Modification 002, provide the operational framework for the IANA
functions, and are based on documentation supplied by the "interested and
affected parties". While the contract itself only mentions two RFCs, the
documentation supplied by the communities relies more heavily on IETF RFCs.
With respect to the IANA protocol parameters and .ARPA, the relevant
deliverables include the following:

a. User documentation (C.2.6): In the case of the IANA protocol parameters,
the "user documentation" consists of a list of relevant RFCs selected by
the IETF/IAB, including RFCs 5226, 6220, etc. For .ARPA, RFC 3172 is the
relevant reference.

b. Policies and procedures (C.2.7): In the case of the IANA protocol
parameters, the "policies and procedures" consist of references to RFCs
selected by the IETF/IAB, as well as the IANA web pages themselves (which
reference the allocation policies and documents for each registry).

c. Performance Standards (C.2.8): In the case of the IANA protocol
parameters, the MOU and annual SLAs constitute the performance standards.

d. Performance Standards Reports (C.4.4): These reports, provided to the
IPROC, are based on the annual SLAs.

e. Customer Service Survey (C.4.5).

f. Successor transition plan (C.7.3).

 References

[1] NTIA RFP:
http://www.ntia.doc.gov/files/ntia/publications/sa1301-12-rp-0043-_final_04.16.2012.pdf

[2] Amendment 001 to the RFP (May 17, 2012):
http://www.ntia.doc.gov/files/ntia/publications/amendment_0001_sa1301-12-rp-0043-05.17.12_-final.pdf

[3] NTIA-ICANN contract (July 2, 2012):
http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf

[4] Contract Amendment Modification 0001 (October 1, 2012):
http://www.ntia.doc.gov/files/ntia/publications/sa1301-12-cn-0035_mod_0001_-_deliverable_schedule.pdf

[5] Contract Amendment Modification 0002 (April 30, 2013):
http://www.ntia.doc.gov/files/ntia/publications/sa1301-12-cn-0035001.pdf

[6] ICANN proposal:
http://www.ntia.doc.gov/other-publication/2012/icann-proposal

Other relevant links

IANA functions purchase order:

http://www.ntia.doc.gov/page/iana-functions-purchase-order

MOU, SLA and other relevant IETF documents:

http://www.ietf.org/iana/iproc.html

_______________________________________________
Ianaplan mailing list
Ianaplan at ietf.org
https://www.ietf.org/mailman/listinfo/ianaplan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/ianaoversight/attachments/20140909/a825ed8e/attachment-0001.htm