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

[Mamadou LO]

Hi Seun and ALL!!
Thanks Bernard for this useful document. 
I think that summarizing document can help have a quick read for better understanding as we have lots of tasks, readings, comments to deal with!!

Mamadou
Date: Tue, 9 Sep 2014 19:15:01 +0100
From: seun.ojedeji at gmail.com
To: ianaoversight at afrinic.net
Subject: [IANAOversight] Fwd: [Ianaplan] A Summary of the 2012 NTIA - ICANN	Contract

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




_______________________________________________
ianaoversight mailing list
ianaoversight at afrinic.net
https://lists.afrinic.net/mailman/listinfo.cgi/ianaoversight 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/ianaoversight/attachments/20140910/8e4fc668/attachment-0001.htm