IANA Naming Function Contract between ICANN and PTI

Why the Board is addressing the issue now?

Completion of the Naming Function Contract is specified as one of the requirements from the package of proposals that the Board approved on 10 March 2016 to transition NTIA's stewardship of the IANA functions to the global multistakeholder community. Since 15 July 2016, ICANN has worked with the CWG-Stewardship and its outside counsel to finalize the Naming Function Contract. After incorporating initial feedback from the CWG-Stewardship, the Agreement was published for a 30-day public comment period on 10 August 2016. The 30-day comment period ended on 9 September 2016 and the Board is being asked today to consider the proposed Agreement for approval.

What is the proposal being considered?

The proposed Naming Function Contract designates PTI as the operator of the IANA Naming Function and authorizes PTI to perform the IANA naming function. The Agreement includes Service Level Expectations for the performance of the IANA naming function, which were agreed upon between ICANN and the CWG-Stewardship. The Agreement will become effective upon the successful completion of the IANA stewardship transition.

Which stakeholders or others were consulted?

ICANN conducted a public comment period on the proposed Naming Function Contract from 10 August 2016 through 9 September 2016. ICANN also worked closely with the CWG-Stewardship and its external counsel to address any concerns. After the public comment period, the comments were summarized and analyzed.

What concerns or issues were raised by the community?

There were two major concerns raised during the CWG-Stewardship review process.

The first concern was raised by some in the ccTLD community and related to applicable policies for the root zone management of ccTLDs. After consultation with the ccTLD community and members of the GAC that participated in CWG-Stewardship discussions, the Agreement was updated to reflect that the applicable policies include: (1) Those defined by the ccNSO; and (2) RFC 1591 ("Domain Name System Structure and Delegation") as interpreted by the Framework of Interpretation of Current Policies and Guidelines Pertaining to the Delegation and Redelegation of Country-Code Top Level Domain Names, dated October 2014. In addition to these policies, PTI shall consult the 2005 Governmental Advisory Committee Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains when appropriate.

The second concern, also raised by some in the ccTLD community, was that ccTLDs that do not have contracts with ICANN "do not want to appoint ICANN in charge of their entries in the root zone" and this should be reflected in the Agreement. ICANN pointed out that in the Proposal, the CWG-Stewardship in fact expects that ICANN's and the Root Zone Maintainer's roles in root zone management do not change post-transition. Paragraph 1158 of the CWG-Stewardship proposal says:

Currently, updating the Root Zone requires the active participation of three parties: the IFO, the Root Zone Maintainer and the NTIA. The IFO receives change requests from various sources, validates them, and sends them to the Root Zone Maintainer who, once they are authorized by the NTIA, updates the Root Zone File, DNSSEC signs it and distributes it to the Root operators.

Post transition there will only be the IFO and the Root Zone Maintainer. The CWG-Stewardship is not recommending any change in the functions performed by these two roles at this time. The CWG-Stewardship is recommending that should there be proposals to make changes in the roles associated with Root Zone modification, that such proposals should be subject to wide community consultation.
What significant materials did the Board review?

As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:

The proposed Naming Function Contract [PDF, 283 KB].
Public comments
Summary and analysis of public comments [PDF, 497 KB]
ICG's IANA Stewardship Transition Proposal [PDF, 2.32 MB]
What factors has the Board found to be significant?

The Board considered the extent to which the public comment was incorporated into the proposed Naming Function Contract. Especially significant is the CWG-Stewardship's involvement, and reliance on external counsel, in the review and identification of additional changes to the Naming Function Contract. ICANN's agreement to take on the modifications generated through the CWG-Stewardship helps assure continued consistency with the IANA Stewardship Transition Proposal. The Board also considered the terms of the Agreement to ensure that the IANA naming function will continue to be operated in a secure, stable, and reliable manner that will meet the needs of the customers.

Are there positive or negative community impacts?

The proposed Naming Function Contract sets out the requirements and obligations for PTI to perform the IANA Naming Function in a secure and stable and reliable manner. The Agreement also includes Service Level Expectations for the performance of the IANA Naming Function. The Board's approval of the proposed Agreement will fulfill one of the key requirements of the community-developed proposal to transition the IANA stewardship, which the Board approved on 10 March 2016, and ensure that the IANA Naming Function will continue to be operated in a secure, stable and reliable manner that meets the needs of the customers.

Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

There is no significant fiscal impact expected if the Board approves the proposed Naming Function Contract. ICANN will provide the necessary services to PTI for it to meet the obligations under this proposed Agreement. These services and associated costs are specified in a separate Services Agreement between ICANN and PTI.

Are there any security, stability or resiliency issues relating to the DNS?

The Board's approval of the proposed Naming Function Contract would ensure continued operation of the IANA naming function in a secure, stable, and reliable manner post transition.