Response to the IANA Stewardship Transition Coordination Group Request for Proposals on the IANA Stewardship Transition from the Cross Community Working Group on Naming Related Functions (CWG-Stewardship)

Abstract .................................................................................................................................................................................................

Proposal type .......................................................................................................................................................................................

I. The Community’s Use of the IANA ...............................................................................................................................

I.A The service or activity ..................................................................................................................................................................

I.B The customer of the service or activity ......................................................................................................................................

I.C Registries involved in providing the service or activity ............................................................................................................

I.D Overlap or interdependencies between your IANA requirements and the functions required by other customer communities              

II. Existing Pre-Transition Arrangements ..........................................................................................................................

II.A Policy Sources .............................................................................................................................................................................

II.B Oversight and Accountability ...................................................................................................................................................

III. Proposed Post-Transition Oversight and Accountability .....................................................................................

III.A The elements of this proposal ..................................................................................................................................................

III.A.i. Post-Transition IANA (PTI)

III.A.ii. PTI Board

III.A.i. IANA Statement of Work (carryover of provisions noting updates)

III.A.ii. IANA Function Review [DT N]

III.A.iii. Customer Standing Committee (CSC) - Overseeing performance of IANA functions as  they relate to naming services  [DT C]

III.A.iv. Service Level Expectations (DT A)

III.A.v. Escalation Mechanisms [DT M]

III.A.vi. Framework for Transition to Successor IANA Operator (Continuity of    Operations) [DT L]

III.A.vii. Proposed changes to root zone environment and relationship with Root Zone  Maintainer

III.A.viii. ccTLD Delegation Appeals [DT B]

III.A.ix. IANA Budget [DT O]

III.A.x. Regulatory and Legal Obligations

III.B Implications for the interface between the IANA functions and existing policy arrangements ......................................

IV. Transition Implications – under development .........................................................................................................

IV.A Operational requirements to achieve continuity of service and possible new service  integration throughout the transition              

IV.B Description of any legal framework requirements in the absence of the NTIA contract .................................................

IV.C Workability of any new technical or operational methods ....................................................................................................

IV.D Length the proposals in Section III are expected to take to complete, and any intermediate  milestones that may occur before they are completed              

V. NTIA Requirements - under development .................................................................................................................

V.A Support and enhance the multistakeholder model ..................................................................................................................

V.B Maintain the security, stability, and resiliency of the Internet DNS;

V.C Meet the needs and expectation of the global customers and partners of the IANA services;

V.D Maintain the openness of the Internet.

V.E The proposal must not replace the NTIA role with a government-led or an inter- governmental organization solution.

VI. Community Process (DRAFT and under development) .....................................................................................

Annex A – The Community’s Use of the IANA – Additional Information ..........................................................

Annex C - Principles and Criteria that Should Underpin Decisions on the Transition of NTIA Stewardship for names functions              

Annex D – IANA Periodic Reviews - Statement of Work Duration and Review Periodicity [DT N] .....

Annex E – Framework for Transition to Successor IANA Operator [DT L] ........................................................

Annex F - ccTLD Appeals Mechanism Background and Supporting Findings [DT B] ...................................

Annex G – IANA Operations Cost Analysis .......................................................................................................................

Annex H – IANA Budget [DT O] ...........................................................................................................................................

Annex I - Charter of the Customer Standing Committee (CSC) [DT C] ...............................................................

Annex J – IANA Customer Service Complaint Resolution Process [DT M] .......................................................

Annex K - IANA Problem Resolution Process [DT M] ..................................................................................................

Annex L - Root Zone Emergency Process [DT M] ............................................................................................................

Annex M - Proposed changes to root zone environment and relationship with Root Zone Maintainer .....

Annex N – IANA Contract Provisions to be carried over post-transition ...............................................................

[MK1]

Appendix A - Baseline Requirements for DNSSEC in the Authoritative Root Zone

 


 


Response to the IANA Stewardship Transition Coordination Group Request for Proposals on the IANA Stewardship Transition from the Cross Community Working Group on Naming Related Functions (CWG-Stewardship)

Abstract

This document is a response from the Internet Names Community to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals made on September 8, 2014.

 

Please note that an appendix is included at the end of this document.

 

Proposal type

Identify which category of the IANA functions this submission proposes to address:

 

[ X ] Names [] Numbers [  ] Protocol Parameters

 

I.          The Community’s Use of the IANA

This section should list the specific, distinct IANA services or activities your community relies on. For each IANA service or activity on which your community relies, please provide the following:

 

II.A A description of the service or activity.

II.B A description of the customer of the service or activity.

II.C What registries are involved in providing the service or activity.

II.D             A description of any overlaps or interdependencies between your IANA requirements and the functions required by other customer communities

 

I.A    The service or activity

The IANA activities, as described in the current IANA contract, relevant to the Internet Naming Community are:

  1. Root Zone Change Request Management – not including delegation and redelegation (NTIA IANA Functions Contract: C.2.9.2.a)

  1. Root Zone “WHOIS” Change Request and Database Management (NTIA IANA Functions Contract: C.2.9.2.b)
  2. Delegation and Redelegation of a Country Code Top Level-Domain (ccTLD) (NTIA IANA Functions Contract: C.2.9.2.c)
  3. Delegation and Redelegation of a Generic Top Level Domain (gTLD) (NTIA IANA Functions Contract: C.2.9.2.d)
  4. Redelegation and Operation of the .INT TLD (NTIA IANA Functions Contract: C.2.9.4)
  5. Root Domain Name System Security Extensions (DNSSEC) Key Management (NTIA IANA Functions Contract: C.2.9.2.f)
  6. Root Zone Automation (NTIA IANA Functions Contract: C.2.9.2.e)
  7. Customer Service Complaint Resolution Process (CSCRP) (NTIA IANA Functions Contract: C.2.9.2.g)

 

Services provided by ICANN’s IANA department that are not part of the contractually defined IANA functions, but which are relevant to the Internet Naming Community are:

  1. Management of the Repository of IDN Practices (IANA service or activity beyond the scope of the IANA functions contract)
  2. Retirement of the Delegation of TLDs (IANA service or activity beyond the scope of the IANA functions contract)

 

For further details concerning each of these IANA activities, please see Annex A.

 

I.B     The customer of the service or activity

The primary customers of these IANA activities are TLD registry managers, .INT registrants, DNS [MK2] validating resolver operators. For further details on the customer(s) for each activity, please see Annex A.

 

I.C    Registries involved in providing the service or activity

TLD registries (including ccTLD and gTLD) are involved in providing the service [MK3] . For further details on which TLD registry (ccTLD or gTLD) is involved in each activity, please see Annex A.

 

I.D   Overlap or interdependencies between your IANA requirements and the functions required by other customer communities

The IETF, through its responsibilities for developing the underlying DNS protocol and its extensions, may designate parts of the domain name space for particular protocol-related purposes that may overlap with usages assigned through ICANN policies. It may also designate portions of the namespace as invalid, illegal or reserved based on evolution of the underlying DNS protocol and its extensions. It may also expand the scope of namespace to be managed through such changes. Additional overlap and/or interdependencies have been identified for each activity in Annex A. 


II.       Existing Pre-Transition Arrangements

This section should describe how existing IANA-related arrangements work, prior to the transition.

 

II.A Policy Sources

This section should identify the specific source(s) of policy which must be followed by the IANA functions operator in its conduct of the services or activities described above. If there are distinct sources of policy or policy development for different IANA activities, then please describe these separately. For each source of policy or policy development, please provide the following:

 

   Which IANA service or activity (identified in Section I) is affected.

   A description of how policy is developed and established and who is involved in policy development and establishment.

   A description of how disputes about policy are resolved.

   References to documentation of policy development and dispute resolution processes.

 

II.A-2.i.               Affected IANA Service (ccTLDs [1] )

All functions which apply to ccTLDs and can modify the Root Zone database or its WHOIS database are affected.

 

II.A-2.ii.             How policy is developed and established by whom (ccTLDs)

RFC1591 was written in 1994 as a "Request For Comments" (RFC) by the then-head of the IANA Functions Operations, Jon Postel. It is a short document intended to outline how the Domain Name System was structured at that time and what rules were in place to decide on its expansion. The longest part of it outlines selection criteria for the manager of a new TLD and what was expected of such a manager.

 

This document was not meant to be a policy document but parts of it came to be regarded as such over time. Although like all RFCs, this is a static document (RFCs are updated by the issuance of a new RFC) there have been two significant attempts to revise it so it can be more easily applied to the current context:

 

            Internet Coordination Policy 1 (ICP-1)

 

This document from the "Internet Coordination Policy" group of ICANN was one of three such documents created by ICANN staff shortly after its creation. It attempted to update operational details over how the DNS was structured and should be run.

 

The ICP-1 document was a source of significant friction between ICANN and the ccTLD community and the ccNSO formally rejected the ICP-1 document (final report of the ccNSO’s Delegation and Redelegation Working Group or DRDWG) arguing that it modified policy but did not meet the requirements for doing so at the time of its introduction in 1999.

 

            Framework Of Interpretation Working Group (FOIWG) Recommendations

 

A follow on to the ccNSO’s DRDWG, the FOIWG was joint effort between the ccNSO and the Governmental Advisory Committee (GAC) that also involved representatives from a number of ICANN communities to interpret RFC1591 in light of the Internet of today. In its final report it made a number of recommendations which clarify the application of RFC1591 within the current context.

 

The ccNSO formally endorsed the FOIWG’s Final Report in February 2015 and transmitted it to the ICANN Board. It is currently pending review and adoption by the ICANN Board of Directors.

 

            Government Advisory Committee (GAC) Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains 2005

This document, also known as the 2005 GAC Principles, which the GAC regards as formal “Advice” to the ICANN Board and as such is subject to the Bylaws provisions regarding such Advice at the time of submission [2] .This Advice was developed privately by the GAC and the first version of these principles was published in 2000 and later revised to produce the 2005 version.

Section 1.2 of this document highlights one of the key principles for governments with respect to the management of the ccTLDs associated with their country or territory code:

 

1.2. The main principle is the principle of subsidiarity. ccTLD policy should be set locally, unless it can be shown that the issue has global impact and needs to be resolved in an international framework. Most of the ccTLD policy issues are local in nature and should therefore be addressed by the local Internet Community, according to national law.

 

Also section 7.1 of this document can be directly relevant to delegation and redelegation of a ccTLD:

 

7.1. Principle

Delegation and redelegation is a national issue and should be resolved nationally and in accordance with national laws, taking into account the views of all local stakeholders and the rights of the existing ccTLD Registry. Once a final formal decision has been reached, ICANN should act promptly to initiate the process of delegation or redelegation in line with authoritative instructions showing the basis for the decision.

 

            Local laws applicable to ccTLDs, or IDN ccTLDs, associated with a specific country or territory are developed by the governments of those countries or territories.

 

II.A-2.iii.           How disputes about policy are resolved (ccTLDs)

Section 3.4 of RFC1591 provided for a dispute resolution mechanism however the body listed in the document does not currently exist. Most ccTLDs do not have any contracts which specify a dispute resolution mechanism with ICANN.

 

For those ccTLDs that do not have a contract with ICANN which specifies dispute resolution mechanisms, the ICANN-provided escalation paths available to them are the ICANN Ombudsman or the ICANN Bylaws relating to the Independent Review of ICANN Board Actions (which would only apply to the relevant Board action i.e. delegations and redelegations in this case). Given these mechanisms are non-binding on the Board or ICANN they are perceived by many ccTLDs as being of limited value.

 

There are additional sources of accountability for the limited number of ccTLDs that have formal Sponsorship Agreements or Frameworks of Accountability with ICANN. These types of agreements have dispute resolution clauses to settle disagreements between the parties which are relevant to all actions and activities by the Operator for ccTLDs. These typically use the International Chamber of Commerce (ICC).

 

It is also important to note that local laws applicable to ccTLDs, or IDN ccTLDs, associated with a specific country or territory are developed by the governments of those countries or territories and that disputes with respect to such laws can be handled in courts of competent jurisdiction.

 

II.A-2.iv.            References to documentation of policy development and dispute resolution processes (ccTLDs)

 

II.A-3.i.               Affected IANA Service (gTLDs)

Delegation and redelegation of gTLDs.

 

II.A-3.ii.             How policy is developed and established by whom (gTLDs)

This is a complex and well-described process that would dwarf this document and as such will not be included.

Details can be found at: https://www.icann.org/resources/pages/governance/bylaws-en#AnnexA

 

II.A-3.iii.           How disputes about policy are resolved (gTLDs)

This is a complex and well-described process that would dwarf this document and as such will not be included.

Details can be found at: http://newgtlds.icann.org/EN/APPLICANTS/AGB

 

II.A-3.iv.            References to documentation of policy development and dispute resolution processes (gTLDs)

            GNSO PDP: https://www.icann.org/resources/pages/governance/bylaws-en#AnnexA

            New gTLD Applicant Guidebook: http://newgtlds.icann.org/EN/APPLICANTS/AGB


 

II.B Oversight and Accountability

This section should describe all the ways in which oversight is conducted over IANA’s provision of the services and activities listed in Section I and all the ways in which IANA is currently held accountable for the provision of those services. For each oversight or accountability mechanism, please provide as many of the following as are applicable:

 

   Which IANA service or activity (identified in Section I) is affected.

   If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way.

   A description of the entity or entities that provide oversight or perform accountability functions, including how individuals are selected or removed from participation in those entities.

   A description of the mechanism (e.g., contract, reporting scheme, auditing scheme, etc.). This should include a description of the consequences of the IANA functions operator not meeting the standards established by the mechanism, the extent to which the output of the mechanism is transparent and the terms under which the mechanism may change.

   Jurisdiction(s) in which the mechanism applies and the legal basis on which the mechanism rests.

 

II.B-1.i.                Which IANA service or activity is affected (NTIA IANA Functions Contract)

For the purposes of this section, oversight and accountability of the IANA Functions Operator refers to independent oversight and accountability. Specifically, oversight and accountability are defined as:

 

 

All IANA functions described section I of this document are affected. Annex B provides an overview of oversight mechanisms that are found in the NTIA IANA Functions Contract.

 

II.B-1.ii.              If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way (NTIA IANA Functions Contract)

These oversight and accountability mechanisms in the IANA Functions contract do not affect the policies listed in section II.A.

 

II.B-1.iii.            The entity or entities that provide oversight or perform accountability functions (NTIA IANA Functions Contract)

The NTIA is currently responsible for providing this oversight. There is no description regarding how the individuals who perform these functions are selected, removed or replaced.

 

II.B-1.iv.            A description of the mechanism (NTIA IANA Functions Contract)

The only official accountability mechanism included in the IANA Functions contract is the ability to cancel or not renew. Although there is only one accountability mechanism in the contract one would expect that there are a number of escalation steps between the parties for dealing with any issues.

 

II.B-1.v.              Jurisdiction and legal basis of the mechanism NTIA IANA Functions Contract)

The Jurisdiction of the mechanism is the United States of America.

 

II.B-2.i.                Which IANA service or activity is affected (NTIA acting as Root Zone Management Process Administrator)

The oversight function can be presumed as the NTIA reviewing all requests and documentation provided by the IANA Contractor for changes to the root zone or its WHOIS database to validate that IANA has met its obligations in recommending a change. If the NTIA does not believe IANA has met its obligations it can refuse to authorize the request. It a ffects all IANA functions which modify the root zone file and database or its WHOIS database.

 

II.B-2.ii.              If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way (NTIA acting as Root Zone Management Process               Administrator)

This does not affect the policies listed in section II.A

 

II.B-2.iii.            The entity or entities that provide oversight or perform accountability functions (NTIA acting as Root Zone Management Process Administrator)

The NTIA is currently responsible for providing this oversight. There is no description regarding how the individuals who perform these functions are selected, removed or replaced.

 

II.B-2.iv.            A description of the mechanism (NTIA acting as Root Zone Management Process Administrator)

The accountability can be resumed as the NTIA not approving a change request for the root zone or its WHOIS database.

 

II.B-2.v.              Jurisdiction and legal basis of the mechanism ((NTIA acting as Root Zone Management Process Administrator)

The Jurisdiction of the mechanism is the United States of America.

 

II.B-3.i.                Which IANA service or activity is affected (Binding arbitration included in TLD contracts)

Most gTLD registries as well as a few ccTLD registries have contracts (for ccTLDs also called Sponsorship Agreements or Frameworks of Accountability) with ICANN. All of these contracts provide for binding arbitration of disputes (The standard gTLD contract language begins with: “ Disputes arising under or in connection with this Agreement that are not resolved pursuant to Section 5.1, including requests for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce .”) All IANA functions which modify the Root Zone file or database are affected

 

II.B-3.ii.              If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way (Binding arbitration included in TLD contracts)

This does not affect the policies listed in section II.A

 

II.B-3.iii.            The entity or entities that provide oversight or perform accountability functions (Binding arbitration included in TLD contracts)

For most gTLDs the language is: Disputes arising under or in connection with this Agreement that are not resolved pursuant to Section 5.1, including requests for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce. Any arbitration will be in front of a single arbitrator, unless (i) ICANN is seeking punitive or exemplary damages, or operational sanctions, (ii) the parties agree in writing to a greater number of arbitrators, or (iii) the dispute arises under Section 7.6 or 7.7.  In the case of clauses (i), (ii) or (iii) in the preceding sentence, the arbitration will be in front of three arbitrators with each party selecting one arbitrator and the two selected arbitrators selecting the third arbitrator.

 

For ccTLDs the language relating to this is usually a version of the following: Each party shall nominate one arbitrator, and the two arbitrators so nominated shall, within 30 days of the confirmation of their appointment, nominate the third arbitrator, who will act as Chairman of the Arbitral Tribunal.

 

II.B-3.iv.            A description of the mechanism (Binding arbitration included in TLD contracts)

The results of the arbitration are binding on both parties.

 

II.B-3.v.              Jurisdiction and legal basis of the mechanism (Binding arbitration included in TLD contracts)

For gTLDs the arbitration will be conducted in the English language and will occur in Los Angeles County, California, USA.

 

For ccTLDs that have dispute resolution clauses with ICANN, the place of arbitration needs to be agreed to by both parties.   Typically there is language inserted that identified the law that will be relevant in evaluating each parties’ actions, such as the law of the country within which the ccTLD is operated for ccTLDs, and the laws of California for ICANN’s actions.

 

II.B-4.i.                Which IANA service or activity is affected (Applicability of local law for the administration by the IANA Functions Operator of ccTLDs associated with a specific               country or territory (ccTLDs)

The IANA Functions Contract clearly establishes the importance of the GAC Principles 2005 in the delegation and redelegation of ccTLDs.

 

As such section 1.7 of the GAC Principles 2005 clearly sets the stage for such oversight by governments:

 

1.7. It is recalled that the WSIS Plan of action of December 2003 invites “Governments to manage or supervise, as appropriate, their respective country code top-level domain name”. Any such involvement should be based on appropriate national laws and policies. It is recommended that governments should work with their local Internet community in deciding on how to work with the ccTLD Registry.

 

Within the context provided by section 1.2 of the same document:

 

1.2. The main principle is the principle of subsidiarity. ccTLD policy should be set locally, unless it can be shown that the issue has global impact and needs to be resolved in an international framework. Most of the ccTLD policy issues are local in nature and should therefore be addressed by the local Internet Community, according to national law.

 

Given the IANA Functions Operator currently seeks government approval for all ccTLD delegations and redelegations governments usually limit the use of their power in these matters to redelegations where the local government is requesting a change of ccTLD manager which is not supported by the current manager.

 

ccTLD delegations and redelegations are affected.

 

II.B-4.ii.              If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way (Applicability of local law for the                                           administration by the IANA Functions Operator of ccTLDs associated with a specific               country or territory (ccTLDs)

This does not affect the policies listed in section II.A

 

II.B-4.iii.            The entity or entities that provide oversight or perform accountability functions (Applicability of local law for the administration by the IANA Functions Operator of               ccTLDs associated with a specific country or territory (ccTLDs)

Local law should prevail unless the decision has global impacts.

 

II.B-4.iv.            A description of the mechanism (Applicability of local law for the administration by the IANA Functions Operator of ccTLDs associated with a specific country or territory               (ccTLDs)

Variable depending on the specific government.

 

II.B-4.v.              Jurisdiction and legal basis of the mechanism Applicability of local law for the administration by the IANA Functions Operator of ccTLDs associated with a specific               country or territory (ccTLDs)

Jurisdiction is that of the country or territory concerned.

 


III.    Proposed Post-Transition Oversight and Accountability

This section should describe what changes your community is proposing to the arrangements listed in Section II.B in light of the transition. If your community is proposing to replace one or more existing arrangements with new arrangements, that replacement should be explained and all of the elements listed in Section II.B should be described for the new arrangements. Your community should provide its rationale and justification for the new arrangements. If your community's proposal carries any implications for existing policy arrangements described in Section II.A, those implications should be described here. If your community is not proposing changes to arrangements listed in Section II.B, the rationale and justification for that choice should be provided here.

 

III.A           The elements of this proposal

The sections below describe how the transition will affect each of the naming functions identified and what changes, if any, the CWG-Stewardship recommends addressing these effects. In summary, the CWG-Stewardship recommends that:

 

In developing this response the CWG-Stewardship has been mindful of the “Principles and Criteria that Should Underpin Decisions on the Transition of NTIA Stewardship for Naming Related Functions” as developed and agreed by the CWG-Stewardship as included in Annex C.

 

Note, this section provides the high-level recommendations which should be read in conjunction with the relevant annexes which provide additional details.

 

PROPOSED POST-TRANSITION STRUCTURE

 

III.A.i.                  Post-Transition IANA (PTI)

[To be completed following receipt of legal memo]

 

III.A.ii.                PTI Board

[To be completed following receipt of legal memo]

 

III.A.i.                  IANA Statement of Work (carryover of provisions noting updates)

The CWG expects that a number of existing provisions of the IANA Functions Contract are carried over to the new IANA Statement of Work, taking into account updates that will need to be made as a result of the changing relationship post-transition as well as other recommendations outlined in this section. An overview of provisions expected to be carried over and changes to be made to those provisions can be found in Annex M. 

 

III.A.ii.                IANA Function Review [ DT N [MK4] ]

The CWG-Stewardship recommends that the Statement of Work (SOW) review be done as part of an IANA Function Review. The IANA Function Review would not only take into account performance against the SOW, but would be responsible for taking multiple input sources into account including community comments, CSC evaluations, reports submitted by IANA, and recommendations for technical or process improvements. The outcomes of reports submitted to the CSC, reviews and comments received on these reports during the relevant time period will be included as input to the IANA Function Review.

 

The first IANA Function Review is recommended to take place no more than 2 years after the transition is completed. After that the IANA Function Reviews should occur no less often than [MK5] every 5 years. The IANA Function Review is expected to be assured in a “Fundamental Bylaw” [3] as part of the work of the CCWG- Accountability [MK6] and would operate in a manner analogous to an Affirmation of Commitments (AOC) review. The members of the IANA Function Review Team would be selected by the Supporting Organizations and Advisory Committees and would include several liaisons from other operational communities. While the IANA Function Review Team is intended to be a smaller group, it will be open to participants in much the same way as the CWG-Stewardship.

 

While the IANA Function Review will normally be scheduled based on a regular 5 year rotation with other ICANN reviews, it may also be initiated by a the Customer Standing Committee (CSC).

 

For further details, please see Annex D.

 

PROPOSED OVERSIGHT & ACCOUNTABILITY REPLACEMENT

 

III.A.iii.               Customer Standing Committee (CSC) - Overseeing performance of IANA functions as they relate to naming services               [DT C]

The CWG recommends the creation of a Customer Standing Committee (CSC) to monitor the performance of IANA with the following mission:

 

The Customer Standing Committee (CSC) has been established to perform the operational responsibilities previously performed by the U.S. Department of Commerce National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date].

 

The mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are top level domain registry operators, but also include root server operators and other non-root zone functions.

 

The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.

 

The CSC is not mandated to initiate a change in the IANA Functions Operator, but could initiate an IANA Function Review..

 

The complete charter of the Customer Standing Committee can be found in Annex J.

 

III.A.iv.               Service Level Expectations (DT A)

[To be completed following finalisation of DT A’s work]

 

III.A.v.                 Escalation Mechanisms [DT M]

The CWG recommends requiring the continuation, with minor modifications, of a progressive set of escalation steps that can be performed for emergency situations as well as customer service complaints and a new Problem Management Process, as applicable, for individual TLD registry operators, or others with relevant IANA functions operational issues. Three processes [4] are recommended:

  1. Customer Service Complaint Resolution Process

This process is for anyone who has a complaint about IANA services. The CWG has modified the current process used by ICANN by adding some steps at the end.

  1. Problem Resolution Process

This is a new process created by the CWG for persistent performance issues or systemic problems associated with the provision of IANA services.

  1. Root Zone Emergency Process

This process is for TLD managers in cases where expedited handling is required and is the same as the process currently used by ICANN, but reflects the post-transition environment.

[MK7]

The details of these processes, including proposed modifications to the existing processes to reflect the transition, can be found in Annexes K (Customer Service Complaint Resolution Process) L (Problem Management Escalation Process) and M (Root Zone Emergency Process).

 

III.A.vi.               Framework for Transition to Successor IANA Operator (Continuity of               Operations) [DT L]

The CWG recommends the continuation, with modifications, of a transition framework for the IANA functions should it be necessary for the IANA functions to be transitioned from the incumbent IANA Functions operator to a successor IANA Functions operator. This framework is based upon the current NTIA-ICANN contract clause C.7.3 “ Plan for Transition to Successor Contractor”. The transition framework should be part of the operations and management of the IANA functions going forward and be considered part of the operator’s business contingency and continuity of operations planning. [5] This is a framework only and it is expected – as per the following recommendations – that a full plan will be developed post-IANA stewardship transition. The principles and recommendations for the future evolution of the Framework for Transition to Successor IANA Operator include:

 

  1. The integrity, stability and availability of the IANA functions must be the core concern during any transition of the IANA functions;
  2. The transition framework must [MK8] be further developed into a detailed, fully functional, transition plan within 18 months from the completion of the IANA Stewardship Transition;
  3. The budget for IANA operations should be augmented with specific funding for the detailed transition plan development referred to in 2;
  4. The process established for the potential transitioning of the IANA functions to an operator other than the incumbent should specifically recognize that the detailed transition plan referred to in 2 must be in place before the commencement of the transitioning process;
  5. Both the incumbent and the successor IANA functions operators will be required to fully engage in the transition plan and to provide appropriate transition staff and expertise to facilitate a stable transition of the IANA functions.
  6. Once developed, the full Transition to Successor IANA Operator Plan should be reviewed every year to ensure that it remains up to date and every five years to ensure that it remains fit for purpose. [MK9]

For further information, please see Annex E.

 

 

PROPOSED CHANGES TO ROOT ZONE ENVIRONMENT AND RELATIONSHIP WITH ROOT ZONE MAINTAINER

 

III.A.vii.             Proposed changes to root zone environment and relationship with Root Zone Maintainer

 

In relation to the Root Zone Management Process Administrator role that is currently performed by NTIA, the CWG recommends that this role is discontinued post-transition. As a result of this discontinuation the CWG recommends:

 

  1. Changes to the Root Zone Content and the associated Whois database.

Post-transition no authorization for TLD change requests is needed. As such there is a need to:

  1. Ensure that the transaction software and associated processes and procedures used by IANA and the Root Zone Maintainer (currently Verisign) to request and process changes no longer require NTIA approval.

 

  1. Ensure that post transition, the Root Zone Maintainer can and will make changes to the Root Zone as requested by IANA.
    1. The NTIA has said that there will be a parallel but separate transition process (yet to be defined) to disengage the NTIA from the Root Zone Maintainer. If that transition is not completed prior to the IANA transition, the Cooperative Agreement will likely have to be amended by the NTIA to allow Verisign, acting as the Root Zone Maintainer, to implement changes to the root zone requested by the IANA Functions Operator without requiring approval from the NTIA.
    2. If the Root Zone Maintainer transition is completed prior to, or in conjunction with, the IANA transition, the new arrangements must provide a clear and effective mechanism to ensure that post transition IANA can have its change requests for the Root Zone implemented in a timely manner by the Root Zone Maintainer (possibly an agreement between the Root Zone Maintainer and IANA).

 

  1. Determine if additional checks/balances/verifications are required post transition (transferred from DT-D)

The CWG recommends that a formal study is required to be carried out post transition to investigate whether there is a need for, and if so, how to increase the robustness of the operational arrangements for making changes to the Root Zone content to reduce or eliminate single points of failure. This study should include a risk analysis and cost/benefit analysis factoring in the history and possibility of such problems.

 


  1. Changes to the Root Zone Management Architecture and Operation.

Per the IANA Functions Contract, NTIA approval was required for the implementation of all changes to the Root Zone environment such as DNSSEC and many classes of changes to IANA processes (including what may be published). As such:

  1. The CWG recommends that the CWG proposal provide for a replacement of this approval function for major architectural and operational changes. The entity responsible for such approvals will establish a process which allows for consultation with the bodies involved in such changes as well as with those with wide experience in the specific technology or process to ensure the prudent but effective changes are made. The replacement approval function should coordinate with the NTIA at the time of transition to transfer relevant information about any ongoing major architectural and operational changes so that any such ongoing activities are not negatively impacted by the transition.
  2. The CWG recommends that for changes internal to IANA and for those related to reports and communications, no external approval shall be needed. Such decision should be made, where appropriate, in consultation with the community, or the approval function referenced in sub-section a.
  3. The CWG recommends that post transition IANA budgets must support IANA’s capability to investigate, develop and deploy the type of Root Zone enhancements required to keep the Root Zone and its management evolving.

 

  1. Principle regarding transparency of actions by IANA

The CWG recommends that, to the extent allowed by external agreements and as necessitated by security issues and the need to respect business confidentiality, IANA should operate in a transparent manner.

  1. Principle regarding a single entity.

 

Currently updating the Root Zone requires the active participation of three parties, the IANA Function Operator, the Root Zone Maintainer and the NTIA. Post transition there will only be the first two. DT-F recommends that the remaining two functions should not be awarded to a single entity. Note that the implications of this might vary depending on the outcomes of the robustness study. [The design team does not fully agree on this recommendation. Although no one suggests any merger at this time, some do not believe that there are sufficient hard reasons to make it a “principle”. Comments are welcome on this issue.]

For further details, please see Annex M.

 

OTHER

 

III.A.viii.           ccTLD Delegation Appeals [DT B]

The CWG recommends not including any appeal mechanism that would apply to ccTLD delegations and redelegations in the IANA stewardship transition proposal. For further               information, please see Annex G.

 

III.A.ix.               IANA Budget [DT O]

The CWG recommends that:

  1. The IANA Function’s comprehensive costs should be transparent for any future state of the IANA Function.
  2. Future Fiscal Year (FY) ICANN Operating Plans & Budgets, and if possible even the FY16 ICANN Operating Plan & Budget, include at a minimum itemization of all IANA operations costs in the FY ICANN Operating Plan & Budget to the project level and below as needed.

Further details on the expected detail, based on the information provided in relation to the FY15 budget, can be found in Annex H. Furthermore, the CWG has identified a number of items for future work that can be found in Annex I.

 

Regulatory and Legal Obligations The process for handling the requests for waivers or licenses relating to its legal obligations in its place of business (such as, from the U.S. Department of the Treasury’s Office of Foreign Assets control) is an obligation that is universally applicable no matter which community is at issue within the specific request, and no matter who is serving as the IANA Functions Operator.   ICANN already has a process in place for seeking any necessary waivers or licenses, and will continue to work with contacts at relevant authorities to identify ways to streamline those requests. For licenses or waivers that related to the IANA Function, ICANN commits that any licenses or waivers it seeks would also be sought for the Root Zone Maintainer as well, so that a single request for any applicable entity is required .

 

 

III.B            Implications for the interface between the IANA functions and existing policy arrangements

[ To be completed ]

 

 


IV.    Transition Implications – under development

This section should describe what your community views as the implications of the changes it proposed in Section III. These implications may include some or all of the following, or other implications specific to your community:

   Description of operational requirements to achieve continuity of service and possible new service integration throughout the transition.

   Risks to operational continuity and how they will be addressed.

   Description of any legal framework requirements in the absence of the NTIA contract.

   Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements.

   Description of how long the proposals in Section III are expected to take to complete, and any intermediate milestones that may occur before they are completed.

 

IV.A           Operational requirements to achieve continuity of service and possible new service integration throughout the transition

This section should describe what your community views as the implications of the changes it proposed in Section III.

   Description of operational requirements to achieve continuity of service and possible new service integration throughout the transition.

   Risks to operational continuity and how they will be addressed.

 

Operational Requirements for Service Continuity and Integration Throughout Transition:

Risks to Operation Continuity and Mitigation:

 

IV.B            Description of any legal framework requirements in the absence of the NTIA contract

This section should describe what your community views as the implications of the changes it proposed in Section III.

Legal Framework Requirements:

IV.C           Workability of any new technical or operational methods

This section should describe what your community views as the implications of the changes it proposed in Section III.

Testing and Evaluation of New Technical or Operational Methods Proposed:

 

IV.D           Length the proposals in Section III are expected to take to complete, and any intermediate milestones that may occur before they are completed

This section should describe what your community views as the implications of the changes it proposed in Section III.

Proposal Implementation Length and Intermediate Milestones:

 

V.    NTIA Requirements - under development

 

Additionally, NTIA has established that the transition proposal must meet the following five requirements:

 

    Support and enhance the multistakeholder model;

 

    Maintain the security, stability, and resiliency of the Internet DNS;

 

    Meet the needs and expectation of the global customers and partners of the IANA services;

 

    Maintain the openness of the Internet.

 

    The proposal must not replace the NTIA role with a government-led or an inter-governmental organization solution.

 

This section should explain how your community’s proposal meets these requirements and how it responds to the global interest in the IANA functions.

 

This proposal addresses each of the NTIA’s requirements as follows:

 

V.A Support and enhance the multistakeholder model

[To be completed]

 

V.B Maintain the security, stability, and resiliency of the Internet DNS;

[To be completed]

 

V.C             Meet the needs and expectation of the global customers and partners of the IANA services;

[To be completed]

 

V.D             Maintain the openness of the Internet.

[To be completed]

 

V.E The proposal must not replace the NTIA role with a government-led or an inter- governmental organization solution.

[To be completed]

 

VI.    Community Process (DRAFT and under development)

This section should describe the process your community used for developing this proposal, including:

    The steps that were taken to develop the proposal and to determine consensus.

    Links to announcements, agendas, mailing lists, consultations and meeting proceedings.

    An assessment of the level of consensus behind your community’s proposal, including a description of areas of contention or disagreement.

 

VI.A     The steps that were taken to develop the proposal and to determine consensus.

VI.A.1   Establishing the CWG

          CWG charter: https://community.icann.org/display/gnsocwgdtstwrdshp/Charter

 

VI.A.2   Members and Participants

          https://community.icann.org/pages/viewpage.action?pageId=49351381

 

VI.A.3   Working methods of the CWG

         TBC

 

VI.A.4   Determining Consensus

         TBC

 

VI.B      Links to announcements, agendas, mailing lists, consultations and meeting proceedings

VI.B.1   Meetings

          Full CWG (meeting dates, AGENDAS, participants and meeting notes) - https://community.icann.org/display/gnsocwgdtstwrdshp/Meetings

VI.B.2   Public Consultations

          1 December public consultation on first CWG draft transition proposal: https://www.icann.org/public-comments/cwg-naming-transition-2014-12-01-en

          February 2015 - Discussion document for ICANN52 meeting: https://community.icann.org/pages/viewpage.action?pageId=52889457

VI.B.3   Webinars and other public presentations

          `(URL TBC)

VI.B.4 Mailing list archives: https://community.icann.org/display/gnsocwgdtstwrdshp/Mailing+List+Archives

VI.B.5 Correspondence (URL TBC)

VI.B.6 Outreach : https://community.icann.org/display/gnsocwgdtstwrdshp/Outreach+Tracking+CWG-Stewardship

 

VI.C     An assessment of the level of consensus behind your community’s proposal, including a description of areas of contention or disagreement.

 


Annex A – The Community’s Use of the IANA – Additional Information

 

a)        Root Zone Change Request Management (NTIA IANA Functions Contract: C.2.9.2.a)

  • Description of the function: Receive and process root zone change requests for TLDs. These change requests include addition of new or updates to existing TLD name servers (NS) and delegation signer (DS) resource record (RR) information along with associated 'glue' (A and AAAA RRs). A change request may also include new TLD entries to the root zone.
  • Customers of the function: TLD registries
  • What registries are involved in providing the function: Root Zone database.
  • Overlaps or interdependencies: Policy for entries in the root zone are determined both by the ICANN policy setting mechanisms (e.g. for ccTLDs and gTLDs), and by the IETF standardisation process (e.g. for specially reserved names).

 

b)        Root Zone “WHOIS” Change Request and Database Management (NTIA IANA Functions Contract: C.2.9.2.b)

  • Description of the function: IANA maintains, updates, and make publicly accessible a Root Zone “WHOIS” database with current and verified contact information for all TLD registry operators. The Root Zone “WHOIS” database, at a minimum, shall consist of the TLD name; the IP address of the TLD’s nameservers; the corresponding names of such nameservers; the creation date of the TLD; the name, postal address, email address, and telephone and fax numbers of the TLD registry operator; the name, postal address, email address, and telephone and fax numbers of the technical contact for the TLD registry operator; and the name, postal address, email address, and telephone and fax numbers of the administrative contact for the TLD registry operator; reports; date the “WHOIS” record was last updated; and any other information relevant to the TLD requested by the TLD registry operator. IANA shall receive and process root zone “WHOIS” change requests for TLDs.
  • Customers of the function: TLD registries.
  • What registries are involved in providing the function: Root Zone WHOIS database.
  • Overlaps or interdependencies: None

 

c)        Delegation and Redelegation of a Country Code Top Level-Domain (ccTLD) (NTIA IANA Functions Contract: C.2.9.2.c)

  • Description of the function: Assigning or re-assigning a manager (sponsoring organization) for a ccTLD registry (including IDN ccTLDs). IANA applies existing policy frameworks in processing requests related to the delegation and redelegation of a ccTLD, such as RFC 1591 Domain Name System Structure and Delegation, the Governmental Advisory Committee (GAC) Principles And Guidelines For The Delegation And Administration Of Country Code Top Level Domains, and any further clarification of these policies by interested and affected parties. If a policy framework does not exist to cover a specific instance, ICANN will consult with the interested and affected parties, relevant public authorities and governments on any recommendation that is not within or consistent with an existing policy framework. In making its recommendations, ICANN shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves.
  • Customers of the function: ccTLD registries.
  • What registries are involved in providing the function: Root Zone, Root Zone WHOIS database.
  • Overlaps or interdependencies: Policy for entries in the root zone are determined both by the ICANN policy setting mechanisms (e.g. for ccTLDs and gTLDs), and by the IETF standardisation process (e.g. for specially reserved names)

 

d)       Delegation and Redelegation of a Generic Top Level Domain (gTLD) (NTIA IANA Functions Contract: C.2.9.2.d)

  • Description of the function: Assigning or re-assigning a Sponsoring Organization for a gTLD registry. ICANN verifies that all requests related to the delegation and redelegation of gTLDs are consistent with the procedures developed by ICANN. In making a delegation or redelegation recommendation ICANN must provide documentation in the form of a Delegation and Redelegation Report verifying that ICANN followed its own policy framework including specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest.
  • Customers of the function: gTLD registries
  • What registries are involved in providing the function: Root Zone, Root Zone WHOIS database.
  • Overlaps or interdependencies: Policy for entries in the root zone are determined both by the ICANN policy setting mechanisms (e.g. for ccTLDs and gTLDs), and by the IETF standardisation process (e.g. for specially reserved names)

 

e)        Redelegation and Operation of the .INT TLD (NTIA IANA Functions Contract: C.2.9.4)

  • Description of the function: Operate the .INT TLD within the current registration policies for the TLD (act as the registry operator). Upon designation of a successor registry by the Government, if any, IANA shall cooperate with NTIA to facilitate the smooth transition of operation of the INT TLD. Such cooperation shall, at a minimum, include timely transfer to the successor registry of the then-current top-level domain registration data.
  • Customers of the function: .INT Registry database.
  • What registries are involved in providing the function: Root Zone database, Root Zone WHOIS, .INT Zone database, .INT WHOIS database.
  • Overlaps or interdependencies: Historically policy has partially been determined by IETF, however per RFC 3172, .INT is no longer used for such purposes. IETF maintains a registry of special-use domain names in per RFC 6761 that may conflict with .INT eligibility policy.

 

f)         Root Domain Name System Security Extensions (DNSSEC) Key Management (NTIA IANA Functions Contract: C.2.9.2.f)

  • Description of the function: The IANA Functions Operator is responsible for generating the KSK (key signing key) and publishing its public portion. The KSK used to digitally sign the root zone ZSK (zone signing key) that is used by the Root Zone Maintainer to DNSSEC-sign the root zone.
  • Customers of the function: Root Zone Maintainer, DNS validating resolver operators.
  • What registries are involved in providing the function: The Root Zone Trust Anchor.
  • Overlaps or interdependencies: -

 

g)        Root Zone Automation (NTIA IANA Functions Contract: C.2.9.2.e)

  • Description of the function: A fully automated system that includes a secure (encrypted) system for customer communications; an automated provisioning protocol allowing customers to manage their interactions with the root zone management system; an online database of change requests and subsequent actions whereby each customer can see a record of their historic requests and maintain visibility into the progress of their current requests; a test system, which customers can use to test the technical requirements for a change request; and an internal interface for secure communications between the IANA Functions Operator; the Administrator, and the Root Zone Maintainer..
  • Customers of the function: TLD registries.
  • What registries are involved in providing the function: Root Zone database, Root Zone WHOIS.
  • Overlaps or interdependencies: -

 

h)       Customer Service Complaint Resolution Process (CSCRP) (NTIA IANA Functions Contract: C.2.9.2.g)

  • Description of the function: A process for IANA function customers to submit complaints for timely resolution that follows industry best practice and includes a reasonable timeframe for resolution.
  • Customers of the function: TLD registries.
  • What registries are involved in providing the function: n/a
  • Overlaps or interdependencies: All IANA functions that are customer facing for the names registries.

 

i)         Management of the Repository of IDN Practices (IANA service or activity beyond the scope of the IANA functions contract)

  • Description of the function: The IANA Repository of TLD IDN Practices, also known as the “IDN Language Table Registry”, was created to support the development of the IDN technology as described in the “Guidelines for the Implementation of Internationalized Domain Names (IDNs)”. In addition to making the IDN Tables publicly available on TLD registry websites, the TLD registries may register IDN Tables with the IANA Functions Operator, which in turn will display them online for public access.
  • Customers of the function: TLD registries.
  • What registries are involved in providing the function: IDN Language Table Registry
  • Overlaps or interdependencies: IDNs are based on standards developed and maintained by the IETF.

 

j)         Retirement of the Delegation of TLDs (IANA service or activity beyond the scope of the IANA functions contract)

  • Description of the function: Retire TLDs from active use.
  • Customers of the function: TLD registries
  • What registries are involved in providing the function: Root Zone database, Root Zone WHOIS database.
  • Overlaps or interdependencies:


Annex B – Oversight Mechanisms in the NTIA IANA Functions Contract

 

The following is a list of oversight mechanisms found in the NTIA IANA Functions Contract:

 

Ongoing Obligations

 

 


Annex C - Principles and Criteria that Should Underpin Decisions on the Transition of NTIA Stewardship for names functions

 

Final

These principles and criteria are meant to be the basis on which the decisions on the transition of NTIA stewardship are formed.  This means that the proposals can be tested against the principles and criteria before they are sent to the ICG.   

  1. Security, stability and resiliency : changes must not undermine the operation of the IANA function and should assure accountability and objectivity in the stewardship of the service.
  2. Transition should be subject to adequate stress testing.
  3. Any new IANA governance mechanisms should not be excessively burdensome and should be fit for purpose.
  4. Support the open Internet: the transition proposal should contribute to the open and interoperable Internet.
  5. Accountability and transparency : the service should be accountable and transparent. 
    1. Transparency :  transparency is a prerequisite of accountability. While there might be confidentiality concerns or concerns over operational continuity during the process of delegation or redelegation of a TLD, the final decision and the rationale for that decision should be made public or at least be subject to an independent scrutiny as part of an ex-post assessment of service performance;
      Unless prevented or precluded by confidentiality, any and all audit reports and other review materials should be published for inspection by the larger community;
    2. Independence of accountability : accountability processes should be independent of the IANA Functions Operator [6] and should assure the accountability of the Operator to the inclusive global multistakeholder community;
    3. Independence of policy from IANA : the policy processes should be independent of the IANA Functions Operator.  The Operator’s role is to implement changes in accordance with policy agreed through the relevant bottom up policy process;
    4. Protection against Capture [7] : safeguards need to be in place to prevent capture of the service or of any IANA oversight or stewardship function;
    5. Performance standards: the IANA Functions Operator needs to meet agreed service levels and its decisions should be in line with agreed policy. Processes need to be in place to monitor performance and mechanisms should be in place to remedy failures. A fall-back provision also needs to be in place in case of service failure; and
    6. Appeals and redress :  any appeals process should be independent, robust, affordable, timely, provide binding redress open to affected parties and be open to public scrutiny. Appeals should be limited to challenging the implementation of policy or process followed, not the policy itself.
  6. Service levels : the performance of the IANA Functions must be carried out in a reliable, timely and efficient manner.  It is a vital service and any proposal should ensure continuity of service over the transition and beyond, meeting a recognized and agreed quality of service and in line with service-level commitments;
    1. Service level commitments should be adaptable to developing needs of the customers of the IANA Function and subject to continued improvement; and
    2. Service quality should be independently audited ( ex-post review) against agreed commitments.
  7. Policy based : decisions and actions of the IANA Functions Operator should be made objectively based on policy agreed to through the recognised bottom-up multi-stakeholder processes. As such, decisions and actions of the IANA Functions Operator should:
    1. Be predictable: decisions are clearly rooted in agreed and applicable policy as set by the relevant policy body;
    2. For ccTLDs - Respect national laws and processes, as well as any applicable consensus ICANN policies and IETF technical standards.  Post transition of the IANA function, IANA will continue to provide service to existing registries in conformance with prevailing technical norms, conforming with policy decisions of registries and the security and stability of the root zone itself.
  1. Be non-discriminatory;
  2. Be auditable ( ex-post review); and
  3. Be appealable by significantly interested parties.
    1. Diversity of the Customers of the IANA functions:
      1. The IANA Functions operator needs to take account the variety of forms of relationship with TLD operators. The proposal will need to reflect the diversity of arrangements in accountability to the direct users of the IANA Functions ;
      2. For ccTLDs: the IANA Functions Operator should provide a service without requiring a contract and should respect the diversity of agreements and arrangements in place for ccTLDs. In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.
      3. For gTLDs: the IANA function should continue to provide service notwithstanding any on-going or anticipated contractual disputes between ICANN and the gTLD operator. No additional requirements for prompt delivery of IANA services should be imposed unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.
    2. Separability: any proposal must ensure the ability:
      1. To separate the IANA Functions from the current operator (i.e. ICANN) if warranted and in line with agreed processes;
      2. To convene a process for selecting a new Operator; and
      3. To consider separability in any future transfer of the IANA Functions.
    3. Multistakeholderism : any proposal must foster multi-stakeholder participation in the future oversight of the IANA functions.

Annex D – IANA Periodic Reviews - Statement of Work Duration and Review Periodicity [DT N]

 

What period (duration) should be covered by the first SOW post-transition?

It is critical that any proposal provide opportunities to improve the performance of the IANA Naming Functions as well as to review the proposed oversight structure against the needs of its customers and the ICANN community. This is especially important in the initial period following the transition of the NTIA’s stewardship over the IANA Functions, in order to account for lessons learned as a result of the transition, to review the effectiveness of new structures created pursuant to the IANA Stewardship Transition, and to address any implications for IANA’s performance. As a result, the CWG recommends that the initial IANA SOW for the naming functions be reviewed no more than two years from the date of the IANA Stewardship Transition. This review would be led by a multi-stakeholder body drawn from the ICANN community.

 

Following the initial review period of two years from the date of the IANA Stewardship Transition, a longer period in between reviews would be advisable to avoid the constant trash of reviews, while still accounting for emerging or evolving needs of IANA Customers and the ICANN community. We recommend that subsequent reviews be initiated on a calendar basis [8] with a recommended standard period of no later than once every five years.

 

While the Periodic Review will normally be scheduled based on a regular 5 year rotation with other ICANN reviews. A Special Periodic Review may be also be initiated by community action:

  • Recommendation of the CSC and 1 SO
  • Recommendation of a combination of 3 AC/SO, including at least one SO and one AC in agreement.

 

Reviews would be focused on identifying necessary changes or amendments to the existing statement of work. The outcomes of a Periodic Review are not limited but not either prescribed and could include a variety of recommendations. [MK12]

 

What should be the process for reviewing or amending SOWs (including approval by the community and acceptance by ICANN)?

 

The review could identify recommended amendments to the IANA Statement of Work to address any performance deficiencies, or to the Charter of the Customer Standing Committee to address any issues or deficiencies. The process of developing and approving amendments would take place through a defined process that included, at minimum, the following steps, in advance of an amendment to either document being proposed:

         Consultation with the IANA Functions Operator;

         Consultation with the Customer Standing Committee;

         Public input session for ccTLD and gTLD operators; and

         Public comment period.

 

Drafted amendments would be subject to at least the following processes before they came into effect:

         Public comment period;

         Ratification by the ccNSO and the GNSO; and

         approval by the ICANN Board.

 

The timeline for implementing any amendments to the IANA SOW would be agreed to between the Periodic Review Team and the IANA Functions Operator.

 

Scope of Periodic Reviews

What is the scope of periodic reviews?

At minimum, the Periodic Review of IANA Performance and the IANA statement of work would consider the following:

         The performance of the IANA Functions Operator against the requirements set forth in the IANA Statement of Work;

         Any necessary additions to the IANA statement of work to account for the needs of consumers of the IANA naming functions or the ICANN community at large;

         Openness/transparency procedures for the IANA Functions Operator and any oversight structures, including reporting requirements and budget transparency;

         The effectiveness of new structures created to carry out IANA oversight in monitoring performance and handling issues with the IANA Functions Operator;

         The relative performance of the IANA Functions pre- and post-transition according to established service levels; and

         Discussion of process or other improvements suggested by the CSC or community.

 

At minimum, the following inputs would be considered as a part of the review:

         The current IANA Statement of Work;

         Regular reports provided by the IANA Functions Operator during the defined review period including:

         Monthly performance reports;

         Delegation/redelegation reports;

         Annual IANA Audits;

         Security Process Reports;

         RZM Data Audits;

         Response to IANA Customer Satisfaction Surveys; [9] and

         Conflict of Interest Enforcement and Compliance Report.

         Inputs by the Customer Standing Committee including:

         Issues flagged in reviewing above reports;

         Public transcripts and meeting minutes;

         Inputs related to the effectiveness of any remediation efforts with the IANA Functions Operator; and.

         Annual evaluation of IANA Functions Operator performance.

         Community inputs through Public Consultation Procedures defined by the Periodic Review Team, potentially including:

         Public Comment Periods;

         Input at in-person sessions during ICANN meetings;

         Responses to public surveys related to IANA Performance; and

         Public inputs during meetings of the Periodic Review Team.

 

What are the goals of periodic reviews?

In reviewing the above data points the goal of the Periodic Review Team would be:

         To evaluate the performance of the IANA Functions Operator and any related oversight bodies vis-a-vis the needs of its direct customers and the expectations of the broader ICANN Community;

         To evaluate the performance of any IANA Oversight bodies with respect to the responsibilities set forth in their Charters;

         To consider and assess any changes effected since the last periodic review and their implications for the Performance of the IANA Naming Functions; and 

         To identify areas for improvement in the performance of the IANA Functions and associated oversight mechanisms.

 

Any recommendations would be expected to identify improvements in these areas that were supported by data and associated analysis about existing deficiencies and how they could be addressed.

 

Composition of Review Teams

Who are the relevant stakeholders? 

All stakeholder groups represented at ICANN would be relevant for the reviews done by Periodic Review Team [10] .  Additionally the Number and Protocol operational communities would each be offered the opportunity to name a liaison to the review group.  The periodic review team would be composed as follows:

 

Group

PRT Members

ccNSO

1

ccTLDs (non-ccNSO)

1

Registry Stakeholder Group (RySG)

2

Registrar Stakeholder Group (RsSG)

1

Commercial Stakeholder Group (CSG)

1

Non-Commercial Stakeholder Group (NCSG)

1

Government Advisory Committee (GAC)

1

Security and Stability Advisory Committee (SSAC)

1

Root Server Operators Advisory Committee (RSSAC)

1

At-Large Advisory Committee (ALAC

1

IETF Liaison

1

RIRs Liaison

1

CSC Liaison 

1

 

Additionally an IANA staff member would be appointed as a point of contact for the PRT.

 

What body should coordinate reviews?

A periodic review team should be convened once every five years (or two years from the date of transition for the initial review) for the purpose of leading a review of the IANA Statement of Work and the additional performance parameters defined above. The Periodic Review Team would not be a standing body and would be reconstituted for every Periodic Performance Review.

 

Individuals interested in participating in the Periodic Review Team would submit an Expression of interest that included a response to the following questions:

 

  • Why they are interested in becoming involved in the Periodic Review Team;
  • What particular skills they would bring to the Periodic Review Team;
  • Their knowledge of the IANA function ;
  • Their understanding of the purpose of the Periodic Review Team; and
  • That they understand the time necessary required to participate in the review process and can commit to the role.

 

Individuals that had submitted expressions would be appointed by their respective Supporting Organization or Advisory Committee in accordance with internally defined processes.

 

What is the scope of its responsibility for leading the review?

The review team defined above will have the primary responsibility for carrying out the IANA Performance Review, including:

         Review and evaluation of of the review inputs defined above;

         Initiation of public comment periods and other processes for wider community input;

         Considering inputs received during public comment periods and other procedures for community input; and

         Development of recommendations on changes to the IANA Statement of Work, to IANA performance.

 

The IANA Periodic Performance Reviews will be a high-intensity project and all members selected are expected to participate actively in the work of the Periodic Review Team.

 

The IANA Functions Operator will provide Secretariat support for the Periodic Performance Reviews.

 

What sort of process structure is warranted (what is the timeline? what are the working methods?) ?

We recommend that reviews that needed to be done by the Periodic Review Team, would be organized along the same  ICANN Cross Community Working Group guidelines that have developed over the past years and which have been used successfully in the process of developing the Stewardship Transition recommendations.  As with the CWG IANA Stewardship, this review group would be co-chaired by someone designated by the GNSO and someone designated by the ccNSO.  The groups would work on a consensus basis.  In the event that consensus could not be reached, the Periodic Review Team  could decide by a supermajority vote of the group members.

 

We expect that this process should take six months from the appointment of members to the Periodic Review Team to the publication of a Final Report, including conducting two 40-day public comment periods.

 

How is the wider community involved in such a review?

As with with other Cross Community working groups, we recommend that all listservs and meeting would be open to interested participants and transparent, with recordings and transcripts made available to the public. At several stages in the process, community comment will be requested:

         Near the beginning of the process asking the community to consider issues relevant to the review

         Midway through the process when a draft report for the review was prepared

         Once the final report was prepared.

 

What should trigger reviews?

Similar to the Affirmation of Commitment Reviews the Periodic Performance Reviews will be triggered on a calendar basis, with the first call for expressions of interest being scheduled to kick off one year from the date of the IANA Stewardship Transition to allow sufficient time to convene the Periodic Review Team and complete the Periodic Performance Review within two years of the date of the IANA Stewardship Transition. Subsequent reviews will be scheduled to commence at five year intervals from the date of the initial Periodic Review.

 

We recommend that the requirement to conduct and facilitate these reviews be put forward in the ICANN Bylaws and potentially included in the set of “fundamental bylaws” under consideration by the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability). Alternatively, if the “legal separation model” developed by Sidley Austin is adopted the review requirements and associated “trigger dates” could be set forth in the contract between ICANN and its wholly-owned subsidiary “Post-Transition IANA.”

 

Dependencies

         The requirement to conduct Periodic Performance Reviews may require changes to the ICANN bylaws, including the potential introduction of fundamental bylaws. These changes should be considered and approved by the (CCWG-Accountability).

         The work of the Periodic Review Team will require cooperation by the Customer Standing Committee, this proposal should be considered by Design Team C.

         The work of the Periodic Review Team makes reference to considering an Annual Report on IANA Performance, which would presumably would be carried out by the CSC. This responsibility should be considered by representatives of DT C to ensure that this report will be produced by the identified group.

         As currently defined the Periodic Review Team is not a standing body, but would be convened every five years for the purpose of carrying out the Periodic Review of the IANA Naming Functions. A question was raised about whether this would be an appropriate body to deal with emergency performance/escalation-related issues and could be convened on that basis as well. DT-M and the overall CWG should consider whether the Periodic Review Team would be the appropriate body to address these issues.

 

Table of Reviews

 

Review Type

Frequency

Responsible

Periodic full IANA Program review including:

Statement Of Work (SOW)

Initially after two years, then moving to every 5 years

CSC

Periodic Review Team

 

Review monthly performance report

Monthly

CSC

Site visit

On-demand

IRT

Review CSC report on IANA performance SOW report

Annual

AC/SO/ICANN

Comment period

ICANN Board

Review performance metrics

Quarterly

CSC

Review customer survey report

Yearly

CSC

Review security audit process report

Annual

CSC

Review RZM audit report

Quarterly

CSC

RZOs

Review annual audit report

Annually

CSC with community input, ie. open ICANN comments

 

Review COI Enforcement Compliance audit report

Annually

Community review (AC/SO/Board) with comments to IANA

 

 

 

 

 


Annex E – Framework for Transition to Successor IANA Operator [DT L]

 

Framework Principles

  1. The integrity, stability and availability of the IANA functions must be the core concern during any transition of the IANA functions.
  2. Both the incumbent and any possible future IANA functions operator will be required to fully engage in the transition plan
  3. All involved parties will be required to provide appropriate transition staff and expertise to facilitate a stable transition of the IANA operations.

 

Framework recommendations:

  1. The transition framework outlined in this document should be further developed into a detailed, fully functional, transition plan within 18 months of the date of implementation of the overall IANA stewardship transition;
  2. The budget for IANA operations should be augmented with specific funding for the detailed transition plan development referred to in 1;
  3. The process established for the potential transitioning of the IANA functions to an operator other than the incumbent (the escalation process) should specifically recognize that the detailed transition plan referred to in 1 must be in place before the commencement of the transitioning process.

 

Dependencies:

Some elements of this framework may have to be adapted further depending on the CWG names model selected and the final transition proposal from the ICG to NTIA.

 

There may be additional dependencies related to the work of other CWG Design Teams, including:

 

DT-F NTIA, IANA and RZM

DT-M Escalation

DT-N Periodic Review

DT-O Budget

 

Additionally, part of the final proposal development work will need to identify those elements/clauses of the CWG’s proposal that are relevant to the transition framework (using the NTIA-ICANN contract clauses table in C.7.3 for guidance).

 

Note on terminology:

While the current plan is based on a contractual relationship between the NTIA and ICANN we have elected to refer to the “operator” of the IANA functions rather than “contractor” for the purposes of this document.  So ICANN as the current operator is referred to as the Incumbent IANA Operator (IIO) and the successor operator is referred to as the Successor IANA Operator (SIO).

 

(Revised) plan:

Framework for Transition to Successor IANA Operator                                                   

This framework plan outlines key actions that would allow the incumbent IANA operator (IIO) to ensure an orderly transition of the IANA functions to a successor IANA operator (SIO) while maintaining continuity and security of operations.

 

Document Structure

This document identifies those functions, systems, processes and documents that might need to be transitioned, including actions that would be required.

 

Additional documents of importance to a transition include (on CWG DT-L wiki):

         Current KSK Operator Function Termination Plan

         Current CCOP (DIDP refused)

         Current ICANN Plan for Transition to Successor Contractor

 

Transition Actions:

  1. IANA website: The Incumbent IANA Operator would transfer the content of the IANA website including the administrative passwords for managing the website; and provide copies of, or links to, the publicly available text for all processes, performance standards, request templates and other pages used to support operations or provide context to reporting.  [Placeholder text: Depending on the transition model selected, all IPR related to the IANA website and published documents will need to be assigned or licensed to the successor contractor]
  2. IANA Functions registry data The Incumbent IANA Operator would provide a copy of all registry data for Protocol Parameter and Internet Number Resources registries, including a copy of the .ARPA zone file [11] . The Incumbent IANA Operator would also provide the public registration data for the root DNS zone, along with management information, such as special instructions from governments and non-public contact information associated with TLDs. The Incumbent IANA Operator would provide a copy of the .INT zone file, along with the contact information for the registrants.
  3. Root Zone Automation system: The Incumbent IANA Operator would transfer the existing  Root Zone Management software suite and relevant APIs, along with the source code, and documentation including any/all existing descriptions of functional requirements, explanations of source code and manuals for using the suite. The Incumbent IANA Operator would also transfer all essential machinery required for continued operation of the suite.
  4. Request history data: The Incumbent IANA Operator would provide a copy of the databases it has used to store requests data, including ticketing systems and workflow management systems used for protocol parameter registries and the maintenance of the Root DNS Zone. The Incumbent IANA Operator would also provide copies of any published reports and paper records it holds supporting these request histories.
  5. Documentation and Knowledge: The Incumbent IANA Operator would provide a copy of all documentation that captures formalized processes, institutional knowledge and experience related to the operation of the IANA function.  The IIO is also encouraged to provide documentation related to Monthly Performance Progress reports, Customer Satisfaction Surveys, External Auditor reports, Conflicts of Interest processes established by the IIO, and the IIO’s Contingency and Continuity of Operations Plan.
  6. Secure notification system data The Incumbent IANA Operator would provide details of the notification categories, the subscribers to those categories and a history of notifications.
  7. Root KSK transition In 2010, ICANN developed a Root Zone KSK Operator Function Termination Plan that sets out the steps ICANN would take if required to transition its duties and responsibilities as the Root Zone Key Signing Key (KSK) operator to another entity. This plan was provided to NTIA in 2010 [12] . That plan requires that a full KSK rollover be done so the successor starts fresh. [13]
  8. Transition Assistance : The Incumbent IANA Operator would assist the successor operator during the transition period until the time the requisite service levels, security and stability are achieved. Such assistance would include training the employees of the successor operator and developing training material.
  9. Security for data retention : The Incumbent IANA Operator would continue to provide security for any data retained by it after transferring such data to the successor contractor.

 

Conclusion

This document describes what the incumbent IANA operator would need to transition to allow a successor operator to perform the IANA Functions.

 

Outstanding questions:

Who will own the IANA website will depend on the final model selected by the CWG. Will the ownership of website be transferred to the successor contractor or will only the authority of managing the website be transferred to the successor contractor? Suggest that ICANN or the IETF Trust retain ownership of the domain name and only the administrative authority to manage the website be transferred.


Annex F - ccTLD Appeals Mechanism Background and Supporting Findings [DT B]

 

While the CWG’s December 1, 2014 draft proposal contained an appeal mechanism that would apply to ccTLD delegation and redelegations, some question arose as to the level of support within the ccTLD community on aspects of this proposal (see Appendix A).   Design Team B was formed to assess whether there might be sufficient consensus within the ccTLD community on such an appeal mechanism.  DT-B decided to undertake a survey of the ccTLD community to assess this (see the survey attached as Appendix A).  After informing the ccTLD community about the upcoming survey, it was sent to the ‘ccTLD World List’, the most comprehensive list of the managers of the 248 ccTLDs on March 23, 2015 with responses accepted to April 3, 2015.  Overall, responses on behalf of just 28 managers were received (see Appendix B).  Such a low level of response was judged to be an insufficient a basis to provide a mandate for the inclusion of an appeal mechanism in the CWG’s proposal.  While acknowledging the limitations of drawing any conclusions from a survey with such a low response rate, it is nevertheless worthwhile pointing out that these limited responses tended to reinforce the overall recommendation.  While 93% of respondents (Q.1) believe there is a need for an appeal mechanism, only 58% (Q.2) believe that it should be developed and introduced now as part of the IANA oversight transition and 73% (Q.3) agreed that it should be developed and introduced after the IANA transition has taken place.  Questions designed to probe the level of consensus on the parameters of such an appeal mechanism (see Q.5 – Q.9) elicited no consensus suggesting that it would take considerable time for the ccTLD community to come to a consensus view on the details of an appeal mechanism.  Some 71% of respondents (Q.3) indicated that they would not wish to see the design of such a mechanism delay the finalization of the IANA stewardship transition.

 

Survey of ccTLD Managers on Need for Appeal Mechanism for ccTLD Delegations and Redelegations

On December 1, 2014, the Cross Community Working Group on IANA transition issued a draft proposal which contained a proposal for an ‘independent appeal panel”:

“Independent Appeals Panel (IAP) - The CWG recommends that all IANA actions which affect the Root Zone or Root Zone WHOIS database be subject to an independent and binding appeals panel. The Appeals Mechanism should also cover any policy implementation actions that affect the execution of changes to the Root Zone File or Root Zone WHOIS and how relevant policies are applied. This need not be a permanent body, but rather could be handled the same way as commercial disputes are often resolved, through the use of a binding arbitration process using an independent arbitration organization (e.g., ICDR, ICC, AAA) or a standing list of qualified people under rules promulgated by such an organization.”

There exists in the ccTLD community an apparent lack of consensus on the question of the introduction of an ‘appeals mechanism’ in respect of ccTLD delegations and redelegations.  At  ICANN 51  in Los Angeles  an overwhelming majority of ccTLD representatives at the October 15, 2014 ccNSO meeting indicated there wish for an ‘appeal mechanism’ as part of the IANA transition, though what was meant by ‘an appeal mechanism’ was not defined.  In a survey of all ccTLD managers undertaken in November 2014, 94% of respondents agreed that ‘if the IANA operator does not perform well or abuses its position, the affected ccTLD should have the opportunity to (have access to) an independent and binding appeal process’.  The expression of need resulted in the appeal mechanism proposal that the CWG released on December 1 2014. The proposal  indicates that such a mechanism could be used in disputes over the consistency of ccTLD delegation or redelegation decisions.

A survey was undertaken in January of this year of CWG members and participants (this includes representation from many communities, not just ccTLD managers) on many aspects of the CWG’s December 1 proposal.  It found that 97% of respondents agreed that “ ccTLD registry operators should have standing to appeal delegation and re-delegation decisions to which they are a party that they believe are contrary to applicable laws and/or applicable approved ccTLD policy ”.  However when questions were posed about potential specific parameters of such an appeal mechanism support for it was reduced.  For example, only 54% of respondents agreed that “ ccTLD registry operators should have standing to appeal delegation and redelegation decisions to which they are a party that they believe are contrary to applicable laws and/or applicable approved ccTLD policy, even if the operator is not a party involved in the delegation or redelegation. In addition, only 60% of respondents agreed that “ Governments should have standing to appeal any ccTLD delegation or redelegation decisions that they believe are contrary to applicable laws ”.

This information suggests that while there may be support for an appeal mechanism in general, consensus may be difficult to achieve on some of the important aspects of such a mechanism, including:

  • Who would ‘have standing’ to appeal a decisions,
  • What aspects of decisions might be subject to an appeal,
  • Whether the scope should be limited to determining whether the process followed was complete and fair,
  • whether the dispute resolution panel would have the authority to substitute its own view on a delegation, for example, direct that the incumbent manager be retained rather than a proposed new manager, or
  • Be limited to requiring that the delegation process be repeated.  

As a consequence, this survey is intended to determine whether they might be sufficient consensus within the ccTLD community as a whole to seek a binding appeal mechanism and if so, whether this should be sought as part of the IANA stewardship transition process. 

 

QUESTIONS

Overall Need for an Appeal Mechanism

  1. D o you as a ccTLD manager believe that there is a need for an appeal mechanism on ccTLD (re)delegation decisions?
  2. If you answered ‘yes’ should such a mechanism be
    1. Developed now and introduced as part of  the IANA oversight transition , or
    2. Developed later, likely by the ccNSO, and introduced after the IANA transition has taken place.
  3. If the design of this appeal mechanism were preventing the finalization of the IANA stewardship transition, would you agree to defer finalizing it so that the IANA process could be completed (this would likely entail the ccNSO proceeding with a separate process).

 

Form of Appeal Mechanism and Composition of Panel

  1. The CWG indicated it believes that an appeal need not be a permanent body, but rather could be handled the same way as commercial disputes are often resolved, through the use of a binding arbitration process, an independent arbitration organization, such as the ICC, ICDR or AAA, or a standing list of qualified panelists under established rules promulgated by such an organization.  The CWG recommended that a three person panel be used, with each party to a dispute choosing one of the three panelists, with these two panelists choosing the third panelist. Do you agree with this overall approach to establishing an appeal mechanism?
    1. Do you have another idea – please indicate.
  2. Where there is a panel of individuals, should they be chosen:
    1. From a list of recognized international experts regardless of country, or
    2. from individuals the country that the ccTLD represents.
    3. In another manner (please specify)

Eligibility to Appeal a (re)delegation decision.

  1. Who do you believe should be permitted to appeal a ccTLD (re)delegation decision?

 

a. The governmental or territorial authority referred to in a. above?

b. The incumbent ccTLD manager?

c. Other individuals, organizations, companies, associations, educational institutions, or others that have a direct, material, substantial, legitimate and demonstrable interest in the operation?

  1. Should any of the parties referenced above  be excluded from the appeals process? If yes, please indicate.

 

Scope and Authority of the Appellant Organization

  1. Should there be any limit on the scope of the appeal?
    1. Should the scope be limited to questions about whether procedures have been followed properly?
    2. Should a panel have the authority to order that an existing delegation process be done again?
    3. Should it have the authority to suspend a pending delegation?
    4. Should it have authority to order to revoke and existing delegation?
    5. Should it have the authority to order that another party be delegated the ccTLD ?

 

Survey Results

Question

Data

Percentage

 

Yes

No

Total

Yes

No

1.    Do you as a ccTLD manager believe that there is a need for an appeal mechanism on ccTLD (re)delegation decisions?

26

2

28

93

7

2.   If you answered ‘yes’ should such a mechanism be -

 

 

 

 

 

a.

Developed now and introduced as part of the IANA oversight transition

14

10

24

58

42

b.

Developed later and introduced after the IANA transition has taken place.

11

4

15

73

27

3.   If the design of this appeal mechanism were preventing the finalization of the IANA stewardship transition, would you agree to defer finalizing it so that the IANA process could be completed (this would likely entail the ccNSO proceeding with a separate process).

20

8

28

71

29

4.   The CWG indicated it believes that an appeal mechanism need not include a permanent body. It suggested that disputes could be handled the same way as many commercial disputes, through the use of a binding arbitration process, using an independent arbitration organization, such as the ICC, ICDR or AAA, or a standing list of qualified panelists under established rules promulgated by such an organization.

The CWG recommended using this approach and that it use a three person panel, with each party to a dispute choosing one of the three panelists, with these two panelists choosing the third panelist. Do you agree with this overall approach to establishing an appeal mechanism?

13

8

21

62

38

 

Do you have another idea – please indicate.

 

The approach should not be designed now.

However  I do not see any rason to decide on how it will be set now

An "as and when" appeal panel is good because it allows panelist rotation which is an important safeguard against (permanent) panelist that may be lobbied or influenced by parties to a delegation dispute. One can have more confidence in a decision taken by a jointly agreed panel which is only convened for a specific dispute. The only potential challenging area is the choice of a 3rd panelist by the 2 appointed panelists. It may be more plausible to leave the appointment of the 3rd panelist to an arbitration organisation instead of the individual panelists themselves.

I think ALL panelist should be chosen independently from each other, from an approved list of panelists, similar to a jury selection process.

Let the ccs develop their own mechanism

I do not think a central appeals mechanism is workable for ccTLD del/redel appeals but would think that every ccTLD designs its own appeals mechanisms together with its own local internet community (including the relevant government(s).

The ccTLD community should be empowered enough to seek redress at an international independent court  in case of unfair treatment by IANA functions Operator. Since national laws are respected in ccTLD policies processes and development, disputes involving Governments with the IANA Functions Operator requires a mechanism that would be acceptable to such sovereign nations. I will suggest Court of Arbitration for IANA functions at the International Court of Apeal at the Hague, similar to Court of Arbitration for Sports put in place by FIFA.

The issues are either much more complicated (for example, contested re-delegations) than could be sensibly dealt with by an independent appeals group, or are much simpler in that they just look to see whether due process has been followed and documented.  In the first case, I would oppose the creation of such a group.  In the second, it would work, but would not necessarily need a complex solution as is proposed.  2.  There will be issues for ccTLDs of an organisation in another jurisdiction having a say over the national ccTLD.  This is not an acceptable position.

ce qui importe, c'est surtout la base sur laquelle ce panel doit se prononcer. Concernant les CCTLD, le cadre légal et réglementaire national doit être la base de la décision prise sur un recours, en même temps que le respect des procédures techniques de délégation - redélégation

5.   Where the appeal mechanism uses a panel of individuals, should they be chosen:

 

 

 

 

 

a.

From a list of recognized international experts regardless of country

11

13

24

46

54

b.

From individuals the country that the ccTLD represents.

11

10

21

52

48

c.

In another manner (please specify)

(no responses)

6.   Who do you believe should be permitted to launch an appeal a ccTLD (re)delegation decision?

 

 

 

 

 

a.

The governmental or territorial authority associated with the ccTLD?

23

3

26

88

12

b.

The incumbent ccTLD manager?

24

0

24

100

0

c.

Other individuals, organizations, companies, associations, educational institutions, or others that have a direct, material, substantial, legitimate and demonstrable interest in the operation?

5

16

21

24

76

7.  Should any of the parties referenced above be excluded from the appeals process? If yes, please indicate.

 

The FOI recommends only that the incumbent manager should have the right to appeal a non consented revocation decision.

As already mentioned, my understanding  was that the goal of the survey was to learn if the appeal mechanism is needed in general; than decide if it is mandatory at this stage of project to enable its completion within planned time frame. So my preliminary answer to all the questions here was YES, however as already pointed out the detail design of the mechanism may be agreed and completed later on.

"Other individuals, organisations...." should be excluded because their interest will be very hard to define & quantify. For example, if the ccTLD in dispute accredits foreign registrars, then foreign registrars have interest in the ccTLD operation even though they may not be from the concerned ccTLD country. Rather, let us keep the appeal process to the concerned government & to the incumbent ccTLD manager.

No, but there should be clear guidelines on what issues can trigger a valid appeal to prevent appeals tying up the process of running a ccTLD and wasting time and money.

Let the ccs develop their own process...who can appeal and the scope will depend on the development of that

anyone with a relevant interest (to be determined locally per ccTLD)

There might be good reason for the third category, but it would be in limited cases where the role of these organisations was already defined.

dans une décision de délégation -redélégation, on peut s'attendre à ce que l'autorité territoriale soit celle qui effectue la demande, et que le conflit se situe entre elle et le gestionnaire du CCTLD. Les autres parties, qui doivent être consultées (consensus de la communauté internet locale) ne devraient pas pouvoir interjeter appel d'une décision, sauf à rendre le processus extrêmement instable.

8.  Should there be any limit on the scope of the appeal?

19

7

26

73

27

9.  Should the scope be limited to questions about whether procedures have been followed properly

18

8

26

69

31

a.

Should a panel have the authority to order that an existing delegation process be done again?

17

8

25

69

31

b.

Should it have the authority to suspend a pending delegation?

14

6

20

70

30

c.

Should it have authority to order to revoke and existing delegation?

4

21

25

16

84

d.

Should it have the authority to order that another party be delegated the ccTLD?

2

22

24

8

92

 


Annex G – IANA Operations Cost Analysis

Preamble:

The cost estimate below corresponds to a "fully absorbed" IANA Operations cost for ICANN . It therefore reflects the benefit of leveraging economies of scale from ICANN's infrastructure and expertise of other functions. The fully absorbed IANA Operations cost within another entity would be different, as would be a "standalone" cost estimate as the cost of a fully operational and mature IT infrastructure would be higher, economies of scale would not exist, and additional costs of operating a separate organization would be created (relative for example to governance, communication, reporting,...).

The below analysis includes a placeholder estimate for the annual depreciation of assets, but does not include any capital costs, or representation of the value of the capital assets that are currently supporting the IANA functions as operated by ICANN.

 

US Dollars in millions

Using the FY15 Budget basis

Description

[A]

Direct Costs (IANA department)

$2.4

These costs cover direct and dedicated personnel (12 employees) and associated costs assigned to delivering the

IANA functions: registration and maintenance of protocol parameter registries; allocation of Internet numbers and the maintenance of the Internet number registries; validation and processing of root zone change requests as well as maintenance of the root zone registry; management of the .int and .arpa domains; and holder of the root zone key signing key for the security of the DNS root zone.

[B]

Direct Costs (Shared resources)

$1.9

Within ICANN, other departments than the IANA department perform or participate to processes directly related to the

delivery of the IANA functions.

The costs of the activities carried out by other departments to perform the IANA Operations were evaluated by each department's budget owners by identifying the direct external costs (professional services, infrastructure,...), and estimating the time spent by personnel from the department on the identified activities valued at the annual cost of each employee (base+benefits).

See in Appendix the full description of the activities that are carried out by those departments, which are summarized below:

-   Request processing - IT

-   Root Key Signing - IT, Registry technical Services, SSR, GSE

-   IANA Website - IT, Legal, Web-admin

-   Protection of data and systems - IT, Security, Legal

-   Continuity and Contingency of service - IT

-   Conflict of Interest assertions - IT, Legal

-   Monthly reporting of performance - IT, Legal, Gov. Engagement

-   Administrative support (shared with Compliance)

-   Annual updates to Agreements - Legal

The Direct costs of shared resources also include a placeholder estimate for the depreciation costs of capital assets of 0.5m.

[C]

Support functions allocation

$2.0

Support functions which organize the ability for operational activities to be carried out.

The total costs of these functions [D], after excluding the shared from those functions included in [B], were divided by the total costs of operational functions [E], to determine a percentage of support functions ([D]+[E]= total costs of ICANN Operations).

This percentage was then applied to the total costs of IANA (both IANA department direct costs and shared resources direct costs as defined above), to determine a cost of support function allocated to IANA. This cost [C] is additive to [A] and [B].

List of functions included:

-   Executive

-   Communications

-   Operations (HR, Finance, Procurement, ERM, PMO/BI, HR development, Operations Executive, Administrative / Real Estate)

-   IT (cyber-security, admin, infrastructure, PMO, Staff facing solutions)

-   Governance support (Legal, Board support, Nomcom)

Total Functional costs of IANA Operations

 

$6.3

 

 

[B] Direct costs (shared resources), associated with operations of the IANA functions Function and dependencies on other ICANN departments:

1)   Request processing

a. RT trouble ticketing system supported and provided by IT

b. RZMS software development, support and maintenance by IT

c. Email system provided and supported by IT

d. On-­‐line connectivity provided and supported by IT

e. OFAC checks supported by Legal

f. Board resolutions reviewed by Legal/sometimes drafted by Legal. Delegation/Redelegation Reports reviewed by Legal on as as-­‐needed basis

g. All hardware and infrastructure provided and supported by IT

h. Support from GSE to gather information for ccTLD requests

2)   Root Key Signing

a. Roles in ceremonies by IT, Registry Technical Services, SSR, Strategy, GSE, and program department

b. Suite of Security documents reviewed and adopted by SSR and IT departments

c. Facility rent and connectivity to the Key Management Facility (KMF) provided by IT

d. DNSSEC SysTrust Audit requires work samples from IT, Legal, and SSR

e. Third Party Contract/RFP prepared by Procurement and reviewed by Legal

3)  IANA Website

a.    Hardware provided, administered, and supported by IT

b.     Contract compliance requirements reviewed by Legal

c.   Web-­‐admin support to post reports and documents on ICANN website

4)  Security to protect data and systems

a.    Security plan reviewed and accepted by IT and SSR

b.    Reviewed by Legal prior to submission to NTIA

5)  Continuity and Contingency of service

a.    Dependent on IT and Finance

b.     Plan reviewed by IT, SSR, HR, Legal, and Finance prior adoption

6)   Conflict of Interest compliance

a.     Annual report prepared by HR and Legal

7)   Monthly reporting of performance

a.     Posted on hardware maintained and administered by IT

b.    Contract compliance requirements reviewed by Legal

8)   Customer Service Survey

a.     RFP prepared by Procurement

b.     Final report from 3rd party reviewed by Legal prior to posting

9)   Administrative support

a.     Share Administrative Assistant with Contractual Compliance 50% dedicated to supporting IANA department

10)  Annual updates to Agreements

a.    Legal review of annual Supplemental Agreement to the IETF MOU

 

 


Annex H – IANA Budget [DT O]

 

The costs of providing the IANA services by ICANN under its agreement with the NTIA are currently not sufficiently separated from other ICANN expenses in the ICANN operating plans and budgets to determine reasonable estimates of projected costs after the IANA stewardship is transferred away from NTIA. The need for clearer itemization and identification of IANA operations costs is consistent with current expectations of the interested and affected parties of the IANA functions, and the broader community as expressed in ATRT1 and ATRT2, to separate policy development and IANA operations. As a result, the CWG has provided recommendations with regard to the information and level of detail it expects to receive from ICANN in relation to the IANA budget in the future (see section III.A.i.d and Annex H).

 

In addition, the CWG recommends three areas of future work that can be addressed once the CWG-Stewardship proposal is finalized for SO/AC approval and again after the ICG has approved a proposal for IANA Stewardship Transition:

 

  1. Identification of any existing IANA naming services related cost elements that may not be needed after the IANA Stewardship Transition, if any;
  2. Projection of any new cost elements that may be incurred as a result of the IANA Stewardship Transition and in order to provide the ongoing services after the transition.
  3. A review of the projected IANA Stewardship Transition costs in the FY16 budget to ensure that there are adequate funds to address significant cost increases if needed to implement the transition plan without unduly impacting other areas of the budget.

 


Annex I - Charter of the Customer Standing Committee (CSC) [DT C] [MK13]

 

Mission

The Customer Standing Committee (CSC) has been established to perform the operational responsibilities previously performed by the US Department of Commerce National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date].

 

The Mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are top level domain registry operators, but also include root server operators and other non-root zone functions.

 

The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.

 

The CSC is not mandated to initiate a change in the IANA Functions Operator [MK14] .

 

Scope of Responsibilities

The CSC is authorised to monitor the performance of the IANA function against agreed service level targets on a regular basis.

 

The CSC will analyse reports provided by IANA on a monthly basis and publish their findings.

 

The CSC is authorised to undertake remedial action to address poor performance in accordance with the Remedial Action Procedures.

 

In the event performance issues are not remedied to the satisfaction of the CSC, despite good-faith attempts to do so, the CSC is authorised to escalate through the ccNSO and GNSO using agreed consultation and escalation processes [MK15] .

 

The CSC may receive complaints from individual registry operators regarding the performance of the IANA naming function; however, the CSC will not become involved in a dispute between the registry operator and IANA. [MK16]

 

The CSC will, on an annual basis or as needs demand, conduct a consultation with the IANA Functions Operator, the primary customers of the naming services, and the ICANN community about the performance of IANA. This consultation is expected to include any changes to the IANA services that are underway or are anticipated in the future.

 

In the event a change in IANA services is anticipated, the CSC is authorised to establish an ad hoc committee of technical and other experts to oversee the changes, in accordance with a defined process.

 

The CSC, in consultation with registry operators, is authorised to discuss with the IANA Functions Operator ways to enhance the provision of IANA’s operational services to meet changing technological environments; as a means to address performance issues; or other unforeseen circumstances. In the event it is agreed that a material change in IANA functions services or operations would be beneficial, the CSC reserves the right to call for a community consultation and independent validation, to be convened by IANA, on the proposed change. Any recommended change must be approved by the ccNSO and RySG.

 

The IANA Functions Operator would be responsible for implementing any recommended changes and must ensure that sufficient testing is undertaken to ensure smooth transition and no disruption to service levels.

 

Membership Composition

The CSC should be kept small and comprise representatives with direct experience and knowledge of IANA naming functions. At a minimum the CSC will comprise:

2 x gTLD registry operators

2 x ccTLD registry operators

1 Liaison from IANA

Liaisons can also be appointed from the following organisations; however, providing a Liaison is not mandatory for any group:

1 additional TLD representative (this could be a ccTLD or gTLD or other TLD operator such as the IAB for .arpa)

1 Liaison each from other ICANN Supporting Organizations and Advisory Committees:

o GNSO (non-registry)

o RSSAC

o SSAC

o GAC

o ALAC

The Chair of the CSC will be elected on an annual basis by the CSC. Ideally the Chair will be a direct customer of the IANA naming function, but cannot be the IANA Liaison.

The CSC and the IANA Functions Operator will nominate primary and secondary points of contact to facilitate formal lines of communication.

 

Selection Process

Members and Liaisons to the CSC will be appointed by their respective communities in accordance with internal processes. However, all candidates will be required to submit an Expression of Interest describing the following:

why they are interested in becoming involved in the CSC;

what particular skills they would bring to the CSC;

their knowledge of the IANA function ;

their understanding of the purpose of the CSC; and

that they understand the time necessary required to participate in the CSC and can commit to the role.

Interested candidates should also include a resume or curriculum vitae or biography in support of their Expression of Interest.

 

While the ccTLD and gTLD members and liaisons will be appointed by the ccNSO and RySG respectively, registry operators that are not participants in these groups will be eligible to participate in the CSC as members or liaisons.

 

The full membership of the CSC must be approved by the ccNSO and the GNSO. While it will not be the role of the ccNSO and GNSO to question of validity of any recommended appointments to the CSC they will take into account the overall composition of the proposed CSC in terms of geographic diversity and skill sets.

 

Terms

CSC appointments will be for a two-year period with the option to renew for up to two additional two- year period. The intention is to stagger appointments to provide for continuity.

 

To facilitate this, at least half of the inaugural CSC appointees will be appointed for an initial term of three years.  Subsequent terms will be for two years.

 

CSC appointees must attend a minimum of 9 meetings in a one-year period, and must not be absent for more than two consecutive meetings. Failure to meet this requirement may result in the Chair of the CSC requesting a replacement from the respective organisation.

 

Recall of members

Any CSC appointee can be recalled at the discretion of their appointing community.

 

In the event that a ccTLD or gTLD registry representative is recalled, a replacement must be provided in order to participate in the next meeting of the CSC.

 

The CSC may also request the recall of a member of the CSC in the event they have not met the minimum attendance requirements. The appointing community will be responsible for finding a suitable replacement.

 

Meetings

The CSC shall meet at least once every month via teleconference at a time and date agreed by members of the CSC.

 

The CSC will provide regular updates, no less than 3 per year, to the direct customers of the IANA naming function. These updates may be provided to the RySG and the ccNSO during ICANN meetings.

 

The CSC will also consider requests from other groups to provide updates regarding IANA’s performance.

 

Record of Proceedings

Minutes of all CSC teleconferences will be made public within five business days of the meeting.

 

Any remedial action will also be reported by the CSC.

 

Information sessions conducted during ICANN meetings will be open and posting of transcripts and presentations will be done in accordance with ICANN’s meeting requirements.

 

Secretariat

The IANA Functions Operator will provide Secretariat support for the CSC. The IANA Functions Operator will also be expected to provide and facilitate remote participation in all meetings of the CSC.

 

Review

The Charter will initially be reviewed by a committee of representatives from the ccNSO and the RySG on year after the first meeting of the CSC.  The review is to include the opportunity for input from other ICANN stakeholders. Any recommended changes are to be ratified by the ccNSO and the GNSO.

 

Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO.

The effectiveness of the CSC will initially be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO.

 

The CSC or the IANA Functions Operator can request a review or change to service level targets. Any proposed changes to service level targets as a result of the review must be agreed by the ccNSO and GNSO .

 


Annex J – IANA Customer Service Complaint Resolution Process [DT M]

 

(Modified Procedure)

Refer to the existing ICANN IANA process at http://www.iana.org/help/escalation-procedure .

If anyone experiences an issue with the IANA Function Operator’s delivery of the IANA services, then it should be reported to the IANA Functions Operator as follows. This process should be used in cases where response has been too slow, where a possible mistake has been made or when there appears to have been inequitable service delivery.

 

Phase 1 – Initial remedial Process for IANA Naming Functions

Send an e-mail to escalation@iana.org and provide the ticket numbers of the requests where the problem arose.  If the problem is not resolved, IANA staff will escalate the problem to the following team members in this order as applicable:

  1. IANA Function Liaison for Root Zone Management
  2. IANA Functions Program Manager
  3. Ombudsman (voluntary step)

Efforts are made to resolve complaints as soon as possible but the structured process above allows escalation of complaints to the IANA management team. If, at any point, you are not satisfied with the resolution process you can use the Ombudsman or similar process instead.

 

Who can use the process?

This process is open to anyone [14] . The functions include:

  • Protocol Parameters management, including the management of the .ARPA TLD
  • Root Zone Management
  • Root DNS Key Signing Key Management
  • Internet Number Resources Allocation
  • Management of the .INT TLD

 

What information must be provided?

In addition to providing the ticket numbers for the requests where the problem arose, any other information that may be needed to understand and resolve the complaint should be provided.

 

What is the expected time line?

Receipt of the complaint will be acknowledged within one business day and a substantive response will be sent within two business days. Efforts will be made to resolve complaints as soon as possible.

 

Is there another resolution process?

The Ombudsman or similar service can help resolve problems using Alternative Dispute Resolution techniques. (In the case of the current IANA Functions Operator, the Ombudsman web pages have more details.)

 

Escalation Contact Information for the current IANA Functions Operator (ICANN)

Role

Name

Email Address

IANA

IANA Staff

iana@iana.org

IANA Function Liaison for Technical Protocol Parameters Assignment

Michelle Cotton

michelle.cotton@icann.org

IANA Function Liaison for Root Zone Management

Kim Davies

kim.davies@icann.org

IANA Function Liaison for Internet Number Resource Allocation

Naela Sarras

Naela.sarras@icann.org

IANA Functions Program Manager

Elise Gerich

elise.gerich@icann.org

Ombudsman

Chris LaHatte

ombudsman@icann.org

 

In case the issue is escalated to members of the IANA team and/or to the Ombudsman or equivalent, the Customer Standing Committee (CSC) is notified for information purposes only.

 

Phase 2

Should the issue not be resolved after phase 1, the following escalation mechanisms will be made available to direct customers [15] :

  1. If issue is not addressed, the complainant (direct customer) may request mediation [16]
  2. CSC is notified of the issue by complainant and/or IFO. CSC reviews to determine whether the issue is part of a persistent performance issue and/or is an indication of a possible systems problem. If so, the CSC may seek remediation through the Problem Resolution Process.
  3. The complainant (direct customer) may initiate an Independent Review Process, if the issue is not addressed.


Annex K - IANA Problem Resolution Process [DT M]

 

(New procedure)

 

Problem Management (including responding to persistent performance issues or systemic problems)

 

The Customer Standing Committee is authorized to monitor the performance of the IANA function against agreed service level targets on a regular basis. In the event that persistent  performance issues are identified by the CSC, the CSC will seek resolution in accordance with a Remedial Action Plan which includes:.

 

  1. CSC reports persistent performance issues to the IANA Functions Operator and requests remedial action in a predetermined number of days.
  2. CSC confirms completion of remedial action.
  3. If CSC determines that the remedial action has been exhausted and has not led to necessary improvements, the CSC is authorized to escalate to the ccNSO and/or the GNSO, which might then decide to take further action using agreed consultation and escalation processes [17] .

 

Systemic problems

The IANA Review Function will include provision to consider whether there are any systemic issues which are impacting IANA services, which might then decide to take further action using agreed consultation and escalation processes [18]

 


Annex L - Root Zone Emergency Process [DT M]

 

As well as general staff availability during standard business hours, the IANA Functions Operator will continue to provide TLD managers with a 24×7 emergency contact number that allows TLD managers to quickly reach IANA Functions Operator to declare an emergency and seek to expedite a Root Zone change request. IANA Functions Operator will execute such changes in accordance with the obligations of the standard root zone management workflow as expeditiously as possible. This prioritization will include performing emergency reviews of the request as the first priority, out of ordinary business hours if necessary, and informing its contacts at the Root Zone Maintainer [19] of any pending changes that will require priority authorization and implementation.

 

Please note that both figures below are consistent with existing processes but terminology has been updated to ensure consistency and general applicability.

Figure 1.2-41. 24x7 Emergency Process

 

Figure 1.2-42. 24x7 Emergency Process Step-by-Step Description

1 TLD CONTACTS CALL CENTER

Description

All TLD managers are provided with an emergency contact telephone number that will reach a 24x7 call center.

2

D OES CALLER DECLARE AN EMERGENCY ?

Description

The caller is asked if the issue is an emergency that requires an urgent root zone change, and can not wait until regular business hours.

3

C ALL IANA Functions Operator DURING BUSINESS HOURS

Description

In the event the caller decides it is not an emergency, their contact details are logged and they are advised to speak to IANA Function staff during regular business hours.

4

F OLLOW INSTRUCTIONS AND ASK QUESTIONS

Description

Call center staff follow a set of instructions to solicit relevant information relating to the nature of the emergency, and the contact details of the TLD manager.

5

S END EMAIL TO ROOT - MGMT @ IANA . ORG

Description

The particulars of the emergency call are sent by the call center staff to the ticketing system. This opens a ticket and starts an audit log of the specific request.

6 C ALL CENTER REACHES THE IANA Functions Operator E MERGENCY                             R ESPONSE T EAM

 

Description

The call center has the emergency roster of IANA Functions staff, as well as escalation points for IANA Functions Operator senior management. The call center will call through the roster until they contact a person to hand the issue to. The IANA Function staff member that receives the issue will be the primary person responsible for resolution of the issue.

7

H AS SOMEONE FROM THE R OOT Z ONE M ANAGEMENT (RZM) T EAM BEEN INFORMED ?

Description

The primary person responsible checks if the Root Zone Management team within the IANA Functions staff is aware of the issue.

8

P ASS INFO ON TO RZM T EAM

Description

If necessary, information relating to the emergency request is communicated to the Root Zone Management team.

9

RZM T EAM CONTACTS TLD MANAGER

 

Description

The IANA Functions staff performing the root zone management functions contact the TLD manager using the contact details provided to the call center. The nature of the issue is discussed in more detail, and a plan is devised to resolve the issue.

10

RZM T EAM CONFIRMS EMERGENCY

Description

Following dialog with the TLD manager, the RZM team confirms the particulars of the issue and the need to perform an emergency root zone change to resolve the issue.

11

I NFORM TLD ABOUT APPROPRIATE OPTIONS

 

Description

In the event the TLD manager and RZM team deem that an emergency root zone change can not resolve the issue, IANA Functions Operator will inform the TLD manager about what other options they have to resolve the issue.

12

V ALIDATE REQUESTED CHANGES

 

Description

IANA Functions Operator validates the request in accordance with the standard procedures described in the Root Zone Change process, including performing technical checks and performing contact confirmations. IANA Functions Operator takes steps to conduct these as quickly as possible.

13

G IVE HEADS UP TO Root Zone Maintainer

 

Description

IANA Functions Operator takes all available steps to inform personnel at the Root Zone Maintainer that there is an active emergency change request being conducted, and encourages the Root Zone Maintainer to process the request as quickly as possible.

14

A CT ACCORDING TO R OOT Z ONE CHANGE REQUEST PROCESS EXPEDITIOUSLY

 

Description

IANA Functions Operator executes the root zone change request as quickly as possible according to all standard policies and procedures. IANA Functions Operator prioritizes the rapid implementation of the request above other requests at normal priority.

 


Annex M - Proposed changes to root zone environment and relationship with Root Zone Maintainer

 

  1. Recommendations related to the elimination of NTIA Authorization of changes to the Root Zone content and the associated Whois database.

 

Currently, changes to the DNS Root Zone File, as well as changes to the DNS Root Zone WHOIS Database, are transmitted to the NTIA for authorization. Such changes cannot be enacted without explicit positive authorization from the NTIA. Post-transition, as per DT-D, no authorization for TLD change requests will be needed.

  1. Changes will be required to the IANA Functions Operator and Root Zone Maintainer software to remove this requirement. In the very short term, if making the software changes cannot be completed before the transition and/or to avoid multiple coincident changes, the existing software could be used and IANA staff could authorize the changes (effectively masquerading as the NTIA).

 

  1. Currently there is a Cooperative Agreement between the NTIA and the Root Zone Maintainer. The NTIA has said that there will be a parallel but separate transition to disengage the NTIA from the Root Zone Maintainer. The exact form of the latter transition is not currently known, nor what, if anything, will replace the current Cooperative Agreement and the parties involved in providing the services currently covered under the Cooperative Agreement. However, there may be a requirement to have a formal agreement between the IANA Functions Operator and The Root Zone Maintainer. In the event that the Cooperative Agreement stays in place post-IANA transition (on a temporary or permanent basis), it is likely that some changes will be required in the Agreement to remove the requirement for NTIA authorization for Root Zone changes.
  2. Determine if additional checks/balances/verifications are required post transition to further improve robustness and reduce or eliminate any possible single points of failure. DT-F recommends that the CWG proposal ensure that this issue be considered post-transition. Any new procedures/processes should be designed to minimize:
    1. The potential for accidental or malicious changes or omissions by the IANA Functions Operator or Root Zone Maintainer.
    2. The potential for out-of-policy changes by the IANA Functions Operator. The term “policy” is used in its most general sense, representing formal Policy adopted by ICANN as well as established standards, practices and processes.
    3. The potential for accidental or malicious errors in the communications path from the IANA Functions Operator to the Root Zone Maintainer.
    4. The potential for accidental outages or malicious actions related to the telecommunications infrastructure serving the IANA Function Operator and The Root Zone Maintainer. Such outages or actions could be related to the infrastructure shared with ICANN.

Any such decisions should be based on a cost/benefit and risk analysis factoring in the history and possibility of such problems.

  1. The NTIA has traditionally been involved in discussions related to and/or overseeing substantive Root Zone changes, (such as the implementation of DNSSEC and the deployment of IPv6), or Root Zone Management process changes (such as decisions to make specific reports public and Root Zone Management automation requirements). The NTIA has contributed and opened avenues to resources (such as those from NIST – the National Institute of Standards and Technologies, a part of the U.S. Department of Commerce in efforts surrounding DNSSEC). Moreover as the Root Zone Administrator, they have been the entity to ultimately approve the changes going forward.

 

a)        Access to relevant expertise and resources will surely be possible in the absence of the NTIA acting as the Root Zone Administrator. Similarly, it is clear that the DNS-related technical and operational communities have both the technology skills and appropriate incentives to make prudent and cautious changes. Nevertheless, DT-F recommends that for major architectural or operational changes an approval function must be retained and assigned to some entity. It is not possible to be more specific as to where this approval function should reside until the overall CWG recommendations are more fully developed. Changes in process at the time of transition should be carefully tracked to ensure that they are not negatively impacted by the transition.

b)        DT-F further recommends that for changes internal to IANA and for those related to reports and communications, no external approval shall be needed. Such decision should be made, where appropriate, in consultation with the community, or the approval function referenced above.

c)        The DT notes that IANA budgets must not only address operational costs, but must include a component to allow for the investigation, development and deployment of further Root Zone enhancements and  the necessary consultations between IANA and the technical and operational communities). Such development costs may be significant.

Principles

 

  1. Transparency

 

To the extent allowed by external agreements and as necessitated by security issues, IANA should operate in a transparent manner.

  1. Change Requests: Currently, all change requests submitted to the IANA Function Operator are treated as confidential (to the extent possible) until they are actually deployed by Root Server Operators. In addition to an overall preference for transparency, if the content of changes (or proposed changes) could be made public earlier, there are a number of possible ways of addressing some of the robustness issues. Note that there are two separate aspects to this:
  1. Changes requested by a registry. These could be made public either at the time of the request, or at the time that a request has passed all IANA Functions Operator verifications and validation. This would also apply to delegations or redelegations once a formal decision has been made.
  2. Notice that a Delegation and Redelegation is in process. This was suggested in the 2012 Technical Proposal from IANA to the NTIA, but has not as yet been approved.

 

  1. Reporting: Reports on IANA operations should not be withheld unless there are explicit and defendable needs for confidentiality.
  1. Multiple-Party Organization

 

Currently updating the Root Zone requires the active participation of three parties, the IANA Function Operator, the Root Zone Maintainer and the NTIA. Post transition there will only be the first two. DT-F recommends that the remaining two functions should not be awarded to a single organizational entity. Note that the implications of this might vary depending on the outcomes of the robustness study. [The design team does not fully agree on this recommendation. Although no one suggests any merger at this time, some do not believe that there are sufficient hard reasons to make it a “principle”. Comments are welcome on this issue.]

  1. Future changes to the Root Zone Management process must be made with due consideration to the IANA ability to process change requests expeditiously.


Annex N – IANA Contract Provisions to be carried over post-transition

 

III.A.1.4.1.1. – Working relationship with all affected parties

Background / Current State

Currently section C.1.3 of the NTIA IANA Functions Contract requires the Contractor to develop constructive working relationships with all affected parties: ICANN stakeholders, IETF, IAF, RIRs and TLDs.

Issues Identified & Rationale for Changes, if any

As such, the CWG recommends that this language is updated as follows:

Current Language – section C.1.3 of the IANA Functions Contract

Proposed Language

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.

The Contractor IANA , 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. The interested and affected parties also include the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB) and the Regional Internet Registries (RIRs) in matters that are directly relevant to them.

 

III.A.1.4.1.2. – Root Zone File Change Request Management

Background / Current State

Currently section C.2.9.2.a of the NTIA IANA Functions Contract describes the Root Zone File Change Request Management requirements referring to the ‘Contractor’.

Issues Identified & Rationale for Changes, if any

As a result, the CWG recommends that this section is updated and should read as follows in the statement of work post-transition

Current Language – section C.2.9.2.a of the IANA Functions Contract

Proposed Language

The Contractor shall receive and process root zone file change requests for TLDs. These change requests include addition of new or updates to existing TLD name servers (NS) and delegation signer (DS) resource record (RR) information along with associated 'glue' (A and AAAA RRs). A change request may also include new TLD entries to the root zone file. The Contractor shall process root zone file changes as expeditiously as possible.

The Contractor IANA shall receive and process root zone file change requests for TLDs. These change requests include addition of new or updates to existing TLD name servers (NS) and delegation signer (DS) resource record (RR) information along with associated 'glue' (A and AAAA RRs). A change request may also include new TLD entries to the root zone file. The Contractor IANA shall process root zone file changes as expeditiously as possible.

 

Note: If the CWG decides that IANA requires authorization to implement these changes to the Root Zone it will be dealt with as a requirement in section III.A.2 (Oversight and Accountability - NTIA acting as Root Zone Management Process Administrator) of the CWG Transition proposal (Design Teams D and F)].

 

III.A.1.4.1.3. – Root Zone WHOIS Change Request and Database Management

Background / Current State

Currently section C.2.9.2.b of the NTIA IANA Functions Contract describes the Root Zone “WHOIS” Change Request and Database Management requirements

Issues Identified & Rationale for Changes, if any

As a result, the CWG recommends that this section is updated and should read as follows in the statement of work post-transition

Current Language – section C.2.9.2.b of the IANA Functions Contract

Proposed Language

The Contractor shall maintain, update, and make publicly accessible a Root Zone “WHOIS” database with current and verified contact information for all TLD registry operators. The Root Zone “WHOIS” database, at a minimum, shall consist of the TLD name; the IP address of the primary nameserver and secondary nameserver for the TLD; the corresponding names of such nameservers; the creation date of the TLD; the name, postal address, email address, and telephone and fax numbers of the TLD registry operator; the name, postal address, email address, and telephone and fax numbers of the technical contact for the TLD registry operator; and the name, postal address, email address, and telephone and fax numbers of the administrative contact for the TLD registry operator; reports; and date record last updated; and any other information relevant to the TLD requested by the TLD registry operator. The Contractor shall receive and process root zone “WHOIS” change requests for TLDs.

The Contractor IANA shall maintain, update, and make publicly accessible a Root Zone “WHOIS” database with current and verified contact information for all TLD registry operators. The Root Zone “WHOIS” database, at a minimum, shall consist of the TLD name; the IP address of the primary nameserver and secondary nameserver for the TLD; the corresponding names of such nameservers; the creation date of the TLD; the name, postal address, email address, and telephone and fax numbers of the TLD registry operator; the name, postal address, email address, and telephone and fax numbers of the technical contact for the TLD registry operator; and the name, postal address, email address, and telephone and fax numbers of the administrative contact for the TLD registry operator; reports; and date record last updated; and any other information relevant to the TLD requested by the TLD registry operator. The Contractor IANA shall receive and process root zone “WHOIS” change requests for TLDs.

 

[Note: If IANA requires authorization to implement changes to the Root Zone WHOIS it will be dealt with as a requirement in section III.A.2 (Oversight and Accountability - NTIA acting as Root Zone Management Process Administrator) of the CWG Transition proposal (Design Teams D and F).

 

III.A.1.4.1.4. – Delegation and Redelegation of a Country Code Top Level Domain

Background / Current State

Currently section C.2.9.2.c of the NTIA IANA Functions Contract describes Delegation and Redelegation of a Country Code Top Level Domain (ccTLD) requirements.

Issues Identified & Rationale for Changes, if any

To deal with these issues, the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language – section C.2.9.2.c of the IANA Functions Contract

Proposed Language

The Contractor shall apply existing policy frameworks in processing requests related to the delegation and redelegation of a ccTLD, such as RFC 1591 Domain Name System Structure and Delegation, the Governmental Advisory Committee (GAC) Principles And Guidelines For The Delegation And Administration Of Country Code Top Level Domains, and any further clarification of these policies by interested and affected parties as enumerated in Section C.1.3. If a policy framework does not exist to cover a specific instance, the Contractor will consult with the interested and affected parties, as enumerated in Section C.1.3; relevant public authorities; and governments on any recommendation that is not within or consistent with an existing policy framework. In making its recommendations, the Contractor shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves. The Contractor shall submit its recommendations to the COR via a Delegation and Redelegation Report.

The Contractor IANA shall apply existing policy frameworks in processing requests related to the delegation and redelegation of a ccTLD, such as RFC 1591 Domain Name System Structure and Delegation, the Governmental Advisory Committee (GAC) Principles And Guidelines For The Delegation And Administration Of Country Code Top Level Domains, and any further clarification of these policies by interested and affected parties as enumerated in Section C.1.3 . III.A.1.4.1.4 of the CWG Transition Proposal. If a policy framework does not exist to cover a specific instance, the Contractor IANA will consult with the interested and affected parties, as enumerated in Section III.A.1.4.1.4 of the CWG Transition Proposal ; relevant public authorities; and governments on any recommendation that is not within or consistent with an existing policy framework. In making its recommendations, the Contractor IANA shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves. The Contractor IANA shall submit publish its recommendations to the COR via on its website in a Delegation and Redelegation Report.

 

[Note: If IANA requires authorization to implement delegations or redelegations it will be dealt with as a requirement in section III.A.2 (Oversight and Accountability - NTIA acting as Root Zone Management Process Administrator) of the CWG Transition proposal (Design Teams D and F).]

 

III.A.1.4.1.5. – Delegation And Redelegation of a Generic Top Level Domain (gTLD)

Background / Current State

Currently section C.2.9.2.d of the NTIA IANA Functions Contract describes Delegation And Redelegation of a Generic Top Level Domain (gTLD) requirements.

Issues Identified & Rationale for Changes, if any

To deal with these issues, the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language – section C.2.9.2.d of the IANA Functions Contract

Proposed Language

The Contractor shall verify that all requests related to the delegation and redelegation of gTLDs are consistent with the procedures developed by ICANN. In making a delegation or redelegation recommendation, the Contractor must provide documentation verifying that ICANN followed its own policy framework including specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest. The Contractor shall submit its recommendations to the COR via a Delegation and Redelegation Report.

The Contractor IANA shall verify that all requests related to the delegation and redelegation of gTLDs are consistent with the procedures developed by ICANN. In making a delegation or redelegation recommendation, the Contractor IANA must provide documentation verifying that ICANN followed its own policy framework including specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest. The Contractor IANA shall publish submit its recommendations in to the COR via a Delegation and Redelegation Report.

 

[Note: If IANA requires authorization to implement delegations or redelegations it will be dealt with as a requirement in section III.A.2 (Oversight and Accountability - NTIA acting as Root Zone Management Process Administrator) of the CWG Transition proposal (Design Teams D and F)].

III.A.1.4.1.6. – Root Zone Automation

Background / Current State

Currently section C.2.9.2.e of the NTIA IANA Functions Contract describes Root Zone Automation requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language – section C.2.9.2.e of the IANA Functions Contract

Proposed Language

The Contractor shall work with NTIA and the Root Zone Maintainer, and collaborate with all interested and affected parties as enumerated in Section C.1.3, to deploy a fully automated root zone management system within nine (9) months after date of contract award. The fully automated system must, at a minimum, include a secure (encrypted) system for customer communications; an automated provisioning protocol allowing customers to manage their interactions with the root zone management system; an online database of change requests and subsequent actions whereby each customer can see a record of their historic requests and maintain visibility into the progress of their current requests; and a test system, which customers can use to meet the technical requirements for a change request ; an internal interface for secure communications between the IANA Functions Operator; the Administrator, and the Root Zone Maintainer.

The Contractor shall work with NTIA and the Root Zone Maintainer, and collaborate with all interested and affected parties as enumerated in Section C.1.3, to deploy IANA will continue to operate a fully automated root zone management system within nine (9) months after date of contract award. ( The fully automated system must, at a minimum, include a secure (encrypted) system for customer communications; an automated provisioning protocol allowing customers to manage their interactions with the root zone management system; an online database of change requests and subsequent actions whereby each customer can see a record of their historic requests and maintain visibility into the progress of their current requests; and a test system, which customers can use to meet the technical requirements for a change request ; an internal interface for secure communications between the IANA Functions Operator ;[ the Administrator], and the Root Zone Maintainer ) .

 

Note If IANA requires authorization to implement delegations or redelegations it will be dealt with as a requirement in section III.A.2 (Oversight and Accountability - NTIA acting as Root Zone Management Process Administrator) of the CWG Transition proposal (Design Teams D and F). If authorization is required the optional [; the Administrator,] would be added back into the text.]

 

III.A.1.4.1.7. – Root Domain Name System Security Extensions (DNSSEC) Key Management

Background / Current State

Currently section C.2.9.2.f of the NTIA IANA Functions Contract describes the Root Domain Name System Security Extensions (DNSSEC) Key Management requirements

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language – section C.2.9.2.f of the IANA Functions Contract

Proposed Language

The Contractor shall be responsible for the management of the root zone Key Signing Key (KSK), including generation, publication, and use for signing the Root Keyset. As delineated in the Requirements at Appendix 2 entitled Baseline Requirements for DNSSEC in the Authoritative Root Zone that is incorporated by reference herein as if fully set forth. The Contractor shall work collaboratively with NTIA and the Root Zone Maintainer, in the performance of this function.

 

The Contractor IANA shall be responsible for the management of the root zone Key Signing Key (KSK), including generation, publication, and use for signing the Root Keyset. As delineated in the Requirements at Appendix 2 Appendix 1 of the CWG Transition proposal entitled Baseline Requirements for DNSSEC in the Authoritative Root Zone that is incorporated by reference herein as if fully set forth. The Contractor IANA shall work collaboratively with NTIA and the Root Zone Maintainer, in the performance of this function.

 

[Note:  Appendix 2 of the NTIA IANA Function contract is quite complete and generic. It would have to be edited to remove references to the NTIA and reference to other sections of the NTIA IANA Functions contract].

[ Note : If IANA requires authorization to implement changes to the root key Signing Key (KSK) it will be dealt with as a requirement in section III.A.2 (Oversight and Accountability - NTIA acting as Root Zone Management Process Administrator) of the CWG Transition proposal (Design Teams D and F).]

 

III.A.1.4.1.8 – Retirement of ccTLDs

Background / Current State

Currently the NTIA IANA Functions Contract does not contain any requirements concerning the retirement of ccTLDs

Issues Identified & Rationale for Changes, if any

Current Language

Proposed Language

None

 

IANA should continue with its current processes and practices with respect to the retirement of ccTLDs until such a time a policy framework has been developed for the retirement of ccTLDs. If current processes and practices do not exist to cover a specific instance, IANA will consult with the interested and affected parties, as enumerated in Section III.A.1.4.1.4 of the CWG Transition Proposal ; relevant public authorities; and governments on any recommendation that is not within or consistent with current processes and practices. In making its recommendations, IANA shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves. IANA shall publish its recommendations on its website in a format similar to a Delegation and Redelegation Report. Once a policy for the retirement of ccTLDs is developed and adopted IANA will adapt its practices and procedures to comply with this new policy.

 

[ Note : The core of the text is a cut and paste, with minor edits, from the proposed text from Section III.A.1.4.1.4 which deals with the delegation and redelegation of ccTLDs.]

III.A.1.4.2.1 – Performance Standards Requirements

Background / Current State

Currently section C.2.8 of the NTIA IANA Functions Contract describes the Performance Standards requirements

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.2.8 of the IANA Functions Contract

Proposed Language

Performance Standards -- Within six (6) months of award, the Contractor shall develop performance standards, in collaboration with all interested and affected parties as enumerated in Section C.1.3, for each of the IANA functions as set forth at C.2.9 to C.2.9.4 and post via a website.

Performance Standards -- Within six (6) months of award, the Contractor IANA shall develop performance standards, in collaboration with all interested and affected parties as enumerated in Section C.1.3, for each of the IANA functions as set forth at C.2.9 to C.2.9.4 and post via a website its performance standards for the functions from section for III.A.1.4.1 of the CWG Transition proposal .

 

Note: This is indirectly linked to the DT A on SLEs.

III.A.1.4.2.2 – Performance Standards Requirements

Background / Current State

Currently section C.4.2 of the NTIA IANA Functions Contract describes the Monthly

Performance Progress Report Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.4.2 of the IANA Functions Contract

Proposed Language

Monthly Performance Progress Report -- The Contractor shall prepare and submit to the COR a performance progress report every month (no later than 15 calendar days following the end of each month) that contains statistical and narrative information on the performance of the IANA functions (i.e., assignment of technical protocol parameters; administrative functions associated with root zone management; and allocation of Internet numbering resources) during the previous calendar month. The report shall include a narrative summary of the work performed for each of the functions with appropriate details and particularity. The report shall also describe major events, problems encountered, and any projected significant changes, if any, related to the performance of requirements set forth in C.2.9 to C.2.9.4.

Monthly Performance Progress Report -- The Contractor IANA shall prepare and submit to the COR CSC a performance progress report every month (no later than 15 calendar days following the end of each month) that contains statistical and narrative information on the performance of the IANA functions (i.e., assignment of technical protocol parameters; administrative functions associated with root zone management; and allocation of Internet numbering resources) during the previous calendar month. The report shall include a narrative summary of the work performed for each of the functions with appropriate details and particularity. The report shall also describe major events, problems encountered, and any projected significant changes, if any, related to the performance of requirements set forth in C.2.9 to C.2.9.4. section for III.A.1.4.1 of the CWG Transition proposal

 

[ Note: Potential post-transition issue : The Monthly Performance Progress Report may contain sensitive information regarding issues with specific TLDs which the operators of those TLDs may wish to keep confidential. This was not an issue with NTIA as it was not a competitor to any registry but may be an issue with the CSC if registries are members. This will have to be addressed in the Transition proposal of the CWG. Possibly to be addressed by DT I, competition and conflict of interest or DT J, CSC/MRT confidential information and conflict of Interest,

III.A.1.4.2.3 – Root Zone Management Dashboard Requirements

Background / Current State

Currently section C.4.3 of the NTIA IANA Functions Contract describes the Root Zone

Management dashboard Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.4.3 of the IANA Functions Contract

Proposed Language

Root Zone Management Dashboard -- The Contractor shall work collaboratively with NTIA and the Root Zone Maintainer, and all interested and affected parties as enumerated in Section C.1.3, to develop and make publicly available via a website, a dashboard to track the process flow for root zone management within nine (9) months after date of contract award.

Root Zone Management Dashboard -- The Contractor IANA shall continue to work collaboratively with NTIA and the Root Zone Maintainer, and all interested and affected parties as enumerated in Section C.1.3, to develop and make publicly available via a website, a dashboard to track the process flow for root zone management within nine (9) months after date of contract award .

 

III.A.1.4.2.4 – Performance Standards Reports

Background / Current State

Currently section C.4.4 of the NTIA IANA Functions Contract describes the Performance Standards Reports Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.4.4 of the IANA Functions Contract

Proposed Language

Performance Standards Reports -- The Contractor shall develop and publish reports for each discrete IANA function consistent with Section C.2.8. The Performance Standards Metric Reports will be published via a website every month (no later than 15 calendar days following the end of each month) starting no later than six (6) months after date of contract award.

Performance Standards Reports -- The Contractor IANA shall develop and publish reports for each discrete IANA function consistent with Section C.2.8 . III.A.1.4.2.1 of the CWG transition proposal . The Performance Standards Metric Reports will be published via a website every month (no later than 15 calendar days following the end of each month) starting no later than six (6) months after date of contract award .

 

III.A.1.4.2.5 – Customer Service Survey

Background / Current State

Currently section C.4.5 of the NTIA IANA Functions Contract describes the Customer Service Survey Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.4.5 of the IANA Functions Contract

Proposed Language

Customer Service Survey (CSS) --The Contractor shall collaborate with NTIA to develop and conduct an annual customer service survey consistent with the performance standards for each of the discrete IANA functions. The survey shall include a feedback section for each discrete IANA function. No later than 30 days after conducting the survey, the Contractor shall submit the CSS Report to the COR.

Customer Service Survey (CSS) -- The Contractor IANA shall collaborate with NTIA the CSC to develop and conduct an annual customer service survey consistent with the performance standards for each of the discrete IANA functions associated with the Root Zone management . The survey shall include a feedback section for each discrete IANA function. No later than 30 days after conducting the survey, the Contractor IANA shall submit the CSS Report to the COR CSC .

 

III.A.1.4.2.6 – Audit Data

Background / Current State

Currently section C.5.1 of the NTIA IANA Functions Contract describes the Audit Data Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.5.1 of the IANA Functions Contract

Proposed Language

Audit Data -- The Contractor shall generate and retain security process audit record data for one year and provide an annual audit report to the CO and the COR. All root zone management operations shall be included in the audit, and records on change requests to the root zone file. The Contractor shall retain these records in accordance with the clause at 52.215-2. The Contractor shall provide specific audit record data to the CO and COR upon request.

 

Audit Data -- The Contractor IANA shall generate and retain security process audit record data for one year and provide an annual audit report to the CO and the COR CSC . All root zone management operations shall be included in the audit, and records on change requests to the root zone file. The Contractor IANA shall retain these records in accordance with best practices for maintaining such records. the clause at 52.215-2 . The Contractor IANA shall provide specific audit record data to the CO and COR CSC upon request.

 

[Note: To a certain extend dependent on outcome of discussion DT B CSC

Potential post-transition issue: These reports and records may contain sensitive information regarding issues with specific TLDs which the operators of those TLDs may wish to keep confidential from potential competitors. This was not an issue with NTIA as it was not a competitor to any registry but may be an issue with the CSC if registries are members. This will have to be addressed in the Transition proposal of the CWG. Possibly to be addressed by DT I, competition and conflict of interest or DT J, CSC/MRT confidential information and conflict of Interest.]

III.A.1.4.2.7 – Root Zone Management Audit Data

Background / Current State

Currently section C.5.2 of the NTIA IANA Functions Contract describes the Root Zone Management Audit Data Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.5.2 of the IANA Functions Contract

Proposed Language

Root Zone Management Audit Data -- The Contractor shall generate and publish via a website a monthly audit report based on information in the performance of Provision C.9.2 (a-g) Perform Administrative Functions Associated With Root Zone Management. The audit report shall identify each root zone file and root zone “WHOIS” database change request and the relevant policy under which the change was made as well as identify change rejections and the relevant policy under which the change request was rejected. The Report shall start no later than nine (9) months after date of contract award and thereafter is due to the COR no later than 15 calendar days following the end of each month.

 

Root Zone Management Audit Data -- The Contractor IANA shall generate and publish via a website a monthly audit report based on information in the performance of Provision C.9.2 (a-g) Perform Administrative Functions Associated With Root Zone Management. The audit report shall identify each root zone file and root zone “WHOIS” database change request and the relevant policy under which the change was made as well as identify change rejections and the relevant policy under which the change request was rejected. The Report shall start no later than nine (9) months after date of contract award and thereafter is due to the COR CSC no later than 15 calendar days following the end of each month.

 

[Note: To a certain extend dependent on outcome of discussion DT B CSC]

 

III.A.1.4.2.8 – External Auditor

Background / Current State

Currently section C.5.3 of the NTIA IANA Functions Contract describes the External Auditor Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.5.3 of the IANA Functions Contract

Proposed Language

External Auditor - - The Contractor shall have an external, independent, specialized compliance audit which shall be conducted annually and it shall be an audit of all the IANA functions security provisions against existing best practices and Section C.3 of this contract.

 

External Auditor - - The Contractor IANA shall have an external, independent, specialized compliance audit which shall be conducted annually and it shall be an audit of all the IANA functions security provisions against existing best practices and Section C.3 of this contract the security requirements from section III.A.1.4.3 of the CWG Transition proposal.

 

[Note: As this is relevant for all functions (address, protocols and names), consolidated approach required (task of ICG?)]

III.A.1.4.3.1 Transparency and Accountability

Background / Current State

Currently section C.2.6 of the NTIA IANA Functions Contract describes the Transparency and Accountability Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.2.6 of the IANA Functions Contract

Proposed Language

Transparency and Accountability -- Within six (6) months of award, the Contractor shall, in collaboration with all interested and affected parties as enumerated in Section C.1.3, develop user instructions including technical requirements for each corresponding IANA function and post via a website.

 

Transparency and Accountability -- Within six (6) months of award, the Contractor shall, in collaboration with all interested and affected parties as enumerated in Section C.1.3, develop IANA shall post via a website user instructions including technical requirements for each corresponding IANA function and post via a website listed in section III.A.1.4.1 of the CWG Transition Proposal.

 

III.A.1.4.3.2 Responsibility and Respect for Stakeholders

Background / Current State

Currently section C.2.7 of the NTIA IANA Functions Contract describes the Responsibility and Respect for Stakeholders Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.2.7 of the IANA Functions Contract

Proposed Language

Responsibility and Respect for Stakeholders – Within six (6) months of award, the Contractor shall, in collaboration with all interested and affected parties as enumerated in Section C.1.3, develop for each of the IANA functions a process for documenting the source of the policies and procedures and how it will apply the relevant policies and procedures for the corresponding IANA function and post via a website.

 

Responsibility and Respect for Stakeholders – Within six (6) months of award, the Contractor shall, in collaboration with all interested and affected parties as enumerated in Section C.1.3, develop IANA shall continue to provide for each of the IANA functions listed in section III.A.1.4.1 of the CWG Transition Proposal via a website a process for document ation ing of the source of the policies and procedures and how it will apply the relevant policies and procedures for the corresponding IANA function s and post via a website. (such documentation having been developed with all interested and affected parties as enumerated in section III.A.1.4.1.1).

 

III.A.1.4.3.3 Qualified Program Manager

Background / Current State

Currently section C.2.12.a of the NTIA IANA Functions Contract describes the requirement for contractor to provide a qualified program manager.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.2.12.a of the IANA Functions Contract

Proposed Language

Program Manager. The contractor shall provide trained, knowledgeable technical personnel according to the requirements of this contract. All contractor personnel who interface with the CO and COR must have excellent oral and written communication skills. "Excellent oral and written communication skills" is defined as the capability to converse fluently, communicate effectively, and write intelligibly in the English language. The IANA Functions Program Manager organizes, plans, directs, staffs, and coordinates the overall program effort; manages contract and subcontract activities as the authorized interface with the CO and COR and ensures compliance with Federal rules and regulations and responsible for the following:

 

Program Manager. The contractor IANA shall provide trained, knowledgeable technical personnel according to the requirements of this contract the CWG Transition Proposal . All contractor IANA personnel who interface with the CO and COR CSC must have excellent oral and written communication skills. "Excellent oral and written communication skills" is defined as the capability to converse fluently, communicate effectively, and write intelligibly in the English language. The IANA Functions Program Manager organizes, plans, directs, staffs, and coordinates the overall program effort; manages contract and subcontract activities as the authorized interface with the CO and COR CSC and ensures compliance with Federal rules and regulations and is responsible for the following:

 

 

[ Note: the proposed text assumes that the main interface for IANA will be the CSC].

 

III.A.1.4.3.4 Key Personnel

Background / Current State

Currently section C.12.b of the NTIA IANA Functions Contract describes the assignment of key personnel Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.12.b of the IANA Functions Contract

Proposed Language

The Contractor shall assign to this contract the following key personnel: IANA Functions Program Manager (C.2.9); IANA Function Liaison for Technical Protocol Parameters Assignment (C.2.9.1); IANA Function Liaison for Root Zone Management (C.2.9.2); IANA Function Liaison for Internet Number Resource Allocation (C.2.9.3).

The Contractor IANA shall assign to this contract the following key personnel to the tasks described in the CWG Transition Proposal : IANA Functions Program Manager (C.2.9) ; IANA Function Liaison for Technical Protocol Parameters Assignment (C.2.9.1); IANA Function Liaison for Root Zone Management (C.2.9.2); IANA Function Liaison for Internet Number Resource Allocation (C.2.9.3). Director of Security; Conflict of Interest Officer.

 

III.A.1.4.3.5 Secure Systems

Background / Current State

Currently section C.3.1 of the NTIA IANA Functions Contract describes the Secure System Requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.3.1 of the IANA Functions Contract

Proposed Language

Secure Systems -- The Contractor shall install and operate all computing and communications systems in accordance with best business and security practices. The Contractor shall implement a secure system for authenticated communications between it and its customers when carrying out all IANA function requirements. The Contractor shall document practices and configuration of all systems.

Secure Systems -- The Contractor IANA shall install and operate all computing and communications systems in accordance with best business and security practices. The Contractor IANA shall implement a secure system for authenticated communications between it and its customers when carrying out all IANA function requirements. The Contractor IANA shall document practices and configuration of all systems.

 

III.A.1.4.3.6 Secure Systems

Background / Current State

Currently section C.3.2 of the NTIA IANA Functions Contract describes the Secure System Notification requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.3.2 of the IANA Functions Contract

Proposed Language

Secure Systems Notification -- The Contractor shall implement and thereafter operate and maintain a secure notification system at a minimum, capable of notifying all relevant stakeholders of the discrete IANA functions, of such events as outages, planned maintenance, and new developments. In all cases, the Contractor shall notify the COR of any outages.

Secure Systems Notification -- The Contractor IANA shall implement and thereafter operate and maintain a secure notification system at a minimum, capable of notifying all relevant stakeholders of the discrete IANA functions, of such events as outages, planned maintenance, and new developments. In all cases, the Contractor IANA shall notify the COR CSC of any outages.

 

[Note: The proposed text assumes that the main interface with IANA will be the CSC].

III.A.1.4.3.7 Secure Data

Background / Current State

Currently section C.3.3 of the NTIA IANA Functions Contract describes the Secure Data requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.3.3 of the IANA Functions Contract

Proposed Language

Secure Data -- The Contractor shall ensure the authentication, integrity, and reliability of the data in performing each of the IANA functions.

Secure Data -- The Contractor IANA shall ensure the authentication, integrity, and reliability of the data in performing each of the IANA functions.

 

III.A.1.4.3.8 Security Plan

Background / Current State

Currently section C.3.4 of the NTIA IANA Functions Contract describes the Security Plan requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.3.4 of the IANA Functions Contract

Proposed Language

Security Plan - The Contractor shall develop and execute a Security Plan that meets the requirements of this contract and Section C.3. The Contractor shall document in the security plan the process used to ensure information systems including hardware, software, applications, and general support systems have effective security safeguards, which have been implemented, planned for, and documented. The Contractor shall deliver the plan to the COR after each annual update.

Security Plan - The Contractor IANA shall develop and execute a Security Plan that meets the requirements of this contract and Section C.3 CWG Transition Plan . The Contractor IANA shall document in the security plan the process used to ensure information systems including hardware, software, applications, and general support systems have effective security safeguards, which have been implemented, planned for, and documented. The Contractor IANA shall deliver the plan to the COR CSC after each annual update.

 

[Note: The proposed text assumes that the main interface with IANA will be the CSC].

III.A.1.4.3.9 Director of Security

Background / Current State

Currently section C.3.5 of the NTIA IANA Functions Contract describes the Director of Security requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.3.5 of the IANA Functions Contract

Proposed Language

Director of Security - The Contractor shall designate a Director of Security who shall be responsible for ensuring technical and physical security measures, such as personnel access controls. The Contractor shall notify and consult in advance the COR when there are personnel changes in this position. The Director of Security shall be one of the key personnel assigned to this contract.

Director of Security - The Contractor IANA shall designate a Director of Security who shall be responsible for ensuring technical and physical security measures, such as personnel access controls. The Contractor IANA shall notify and consult in advance the COR CSC when there are personnel changes in this position. The Director of Security shall be one of the key personnel assigned to this contract.

 

[Note: The proposed text assumes that the main interface with IANA will be the CSC].

 

III.A.1.4.3.10 Conflict of Interest

Background / Current State

Currently section C.6.1 of the NTIA IANA Functions Contract describes the conflict of interest requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.6.1 of the IANA Functions Contract

Proposed Language

Conflict of Interest Requirements - The Contractor shall take measures to avoid any activity or situation that could compromise, or give the appearance of compromising, the impartial and objective performance of the contract (e.g., a person has a conflict of interest if the person directly or indirectly appears to benefit from the performance of the contract). The Contractor shall maintain a written, enforced conflict of interest policy that defines what constitutes a potential or actual conflict of interest for the Contractor. At a minimum, this policy must address conflicts based on personal relationships or bias, financial conflicts of interest, possible direct or indirect financial gain from Contractor's policy decisions and employment and post-employment activities. The conflict of interest policy must include appropriate sanctions in case of non-compliance, including suspension, dismissal and other penalties.

Conflict of Interest Requirements - The Contractor IANA shall take measures to avoid any activity or situation that could compromise, or give the appearance of compromising, the impartial and objective performance of the contract its responsibilities (e.g., a person has a conflict of interest if the person directly or indirectly appears to benefit from the performance of the contract). The Contractor IANA shall maintain a written, enforced conflict of interest policy that defines what constitutes a potential or actual conflict of interest for the Contractor IANA . At a minimum, this policy must address conflicts based on personal relationships or bias, financial conflicts of interest, possible direct or indirect financial gain from Contractor IANA 's policy decisions and employment and post-employment activities. The conflict of interest policy must include appropriate sanctions in case of non-compliance, including suspension, dismissal and other penalties.

 

III.A.1.4.3.11 Conflict of Interest Officer

Background / Current State

Currently section C.6.2 of the NTIA IANA Functions Contract describes the conflict of interest officer requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.6.2 of the IANA Functions Contract

Proposed Language

Conflict of Interest Requirements - The Contractor shall designate a senior staff member to serve as a Conflict of Interest Officer who shall be responsible for ensuring the Contractor is in compliance with the Contractor’s internal and external conflict of interest rules and procedures. The Conflict of Interest Officer shall be one of the key personnel assigned to this contract.

Conflict of Interest Requirements - The Contractor IANA shall designate a senior staff member to serve as a Conflict of Interest Officer who shall be responsible for ensuring the Contractor IANA is in compliance with the Contractor’s IANA’s internal and external conflict of interest rules and procedures. The Conflict of Interest Officer shall be one of the key personnel assigned to this contract .

 

III.A.1.4.3.12 Additional Conflict of Interest Requirements

Background / Current State

Currently sub-sections of C.6.2 (C.6.2.1-5) of the NTIA IANA Functions Contract describe additional conflict of interest requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.6.2.1-5 of the IANA Functions Contract

Proposed Language

Conflict of Interest Requirements - The Contractor shall designate a senior staff member to serve as a Conflict of Interest Officer who shall be responsible for ensuring the Contractor is in compliance with the Contractor’s internal and external conflict of interest rules and procedures. The Conflict of Interest Officer shall be one of the key personnel assigned to this contract. (sub sections to C.6.2)

Conflict of Interest Requirements - The Contractor IANA shall designate a senior staff member to serve as a Conflict of Interest Officer who shall be responsible for ensuring the Contractor IANA is in compliance with the Contractor IANA’s internal and external conflict of interest rules and procedures. The Conflict of Interest Officer shall be one of the key personnel assigned to this contract. (sub sections to C.6.2 ). The Conflict of Interest Officer shall:

 

III.A.1.4.3.13 Redundancy

Background / Current State

Currently section C.7.1 of the NTIA IANA Functions Contract describes the redundancy requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.7.1 of the IANA Functions Contract

Proposed Language

Continuity of Operations (COP) – The Contractor shall, at a minimum, maintain multiple redundant sites in at least 2, ideally 3 sites, geographically dispersed within the United States as well as multiple resilient communication paths between interested and affected parties as enumerated in Section C.1.3 to ensure continuation of the IANA functions in the event of cyber or physical attacks, emergencies, or natural disasters.

Continuity of Operations (COP) – The Contractor IANA shall, at a minimum, maintain multiple redundant sites in at least 2, ideally 3 sites, geographically dispersed within the United States as well as multiple resilient communication paths between interested and affected parties as enumerated in Section C.1.3 III.A.1.4.1.1. of the CWG transition proposal to ensure continuation of the IANA functions in the event of cyber or physical attacks, emergencies, or natural disasters.

 

III.A.1.4.3.14 Contingency Plan

Background / Current State

Currently section C.7.2 of the NTIA IANA Functions Contract describes the contingency plan requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.7.2 of the IANA Functions Contract

Proposed Language

Contingency and Continuity of Operations Plan (The CCOP) – The Contractor shall collaborate with NTIA and the Root Zone Maintainer, and all interested and affected parties as enumerated in Section C.1.3, to develop and implement a CCOP for the IANA functions within nine (9) months after date of contract award. The Contractor in collaboration with NTIA and the Root Zone Maintainer shall update and test the plan annually. The CCOP shall include details on plans for continuation of each of the IANA functions in the event of cyber or physical attacks, emergencies, or natural disasters. The Contractor shall submit the CCOP to the COR after each annual update.

Contingency and Continuity of Operations Plan (The CCOP) – The Contractor IANA shall collaborate with NTIA and the Root Zone Maintainer, and all interested and affected parties as enumerated in Section C.1.3, to develop and implement a CCOP for the IANA functions within nine (9) months after date of contract award. The Contractor in collaboration with the CSC NTIA and the Root Zone Maintainer shall update and test the plan annually. The CCOP shall include details on plans for continuation of each of the IANA functions in the event of cyber or physical attacks, emergencies, or natural disasters. The Contractor IANA shall submit the CCOP to the COR CSC after each annual update.

 

[Note: The proposed text assumes that the main interface with IANA will be the CSC].

 

III.A.1.4.3.15 Transition to a Successor Contractor

Background / Current State

Currently section C.7.3 of the NTIA IANA Functions Contract describes the transition to a successor contractor requirements.

Issues Identified & Rationale for Changes, if any

As such the CWG recommends that this section is updated and should read as follows in the statement of work post-transition:

Current Language section C.7.3 of the IANA Functions Contract

Proposed Language

Transition to Successor Contractor – 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.

 

Transition to Successor Contractor – In the event the Government [CSC/MRT?] selects a successor contractor, the Contractor ICANN-IANA 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 and submitted to the [CSC?] .

 

[Note: Actual replacement for the Government in this text will depend on the results of Design Team L.]


Appendix A - Baseline Requirements for DNSSEC in the Authoritative Root Zone [MK17]

 

Note: this appendix is based on section C.2.9.2.f of the IANA Functions Contract. The proposed changes are highlighted in bold / strikethrough.

 

Baseline Requirements for DNSSEC in the Authoritative Root Zone

 

DNSSEC at the authoritative Root Zone requires cooperation and collaboration between the root zone management partners and the CSC. [20] The baseline requirements encompass the responsibilities and requirements for both the IANA Functions Operator and the Root Zone Maintainer as described and delineated below.

 

General Requirements

 

The Root Zone system needs an overall security lifecycle, such as that described in ISO 27001, and any security policy for DNSSEC implementation must be validated against existing standards for security controls.

 

The remainder of this section highlights security requirements that must be considered in developing any solution. ISO 27002:2005 (formerly ISO 17799:2005) and NIST SP 800-53 are recognized sources for specific controls. Note that reference to SP 800-53 is used as a convenient means of specifying a set of technical security requirements. [21] It is expected that the systems referenced in this document will meet all the SP 800-53 technical security controls required by a HIGH IMPACT system. [22]

 

Whenever possible, references to NIST publications are given as a source for further information. These Special Publications (SP) and FIPS documents are not intended as a future auditing checklist, but as non-binding guidelines and recommendations to establish a viable IT security policy. Comparable security standards can be substituted where available and appropriate. All of the NIST document references can be found on the NIST Computer Security Research Center webpage (http://www.csrc.nist.gov/).

 

          Security Authorization and Management Policy

 

            Each partner [23] in the Root Zone Signing process shall have a security policy in place; this security policy must be periodically reviewed and updated, as appropriate.

             

i)         Supplemental guidance on generating a Security Authorization Policy may be found in NIST SP 800-37.

 

            These policies shall have a contingency plan component to account for disaster recovery (both man-made and natural disasters). [24]

 

            Supplemental guidance on contingency planning may be found in SP 800-34.

 

            These policies shall address Incident Response detection, handling and reporting (see 4 below).

 

            Supplemental guidance on incident response handling may be found in NIST SP 800-61.

 

2)       IT Access Control

 

a)        There shall be an IT access control policy in place for each of the key management functions and it shall be enforced.

 

i)         This includes both access to hardware/software components and storage media as well as ability to perform process operations.

ii)       Supplemental guidance on access control policies may be found in NIST SP 800-12.

 

            Users without authentication shall not perform any action in key management.

 

            In the absence of a compelling operational requirement, remote access to any cryptographic component in the system (e.g. HSM) is not permitted. [25]

 

3)       Security Training

 

a)        All personnel participating in the Root Zone Signing process shall have adequate IT security training.

 

i)         Supplemental guidance on establishing a security awareness training program may be found in NIST SP 800-50.

 

4)       Audit and Accountability Procedures

 

a)        The organization associated with each role shall develop, disseminate, and periodically review/update: (1) a formal, documented, audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (2) formal, documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls.

i)         Supplemental guidance on auditing and accountability policies may be found in NIST SP 800-12.

ii)       Specific auditing events include the following:

  • Generation of keys
  • Generation of signatures
  • Exporting of public key material
  • Receipt and validation of public key material (i.e., from the ZSK holder or from TLDs)
  • System configuration changes
  • Maintenance and/or system updates
  • Incident response handling
  • Other events as appropriate

b)        Incident handling for physical and exceptional cyber attacks [26] shall include reporting to the Department’s National Telecommunications and Information Administration (NTIA) in a timeframe and format as mutually agreed by the Department, IANA Functions Operator, and Root Zone Maintainer.

c)        The auditing procedures shall include monthly reporting to NTIA. [27] 9

d)       The auditing system shall be capable of producing reports on an ad-hoc basis.

e)        A version of these reports must be made publically available.

 

5)       Physical Protection Requirements

 

a)        There shall be physical access controls in place to only allow access to hardware components and media to authorized personnel.

i)         Supplemental guidance on token based access may be found in NIST SP 800-73 and FIPS 201.

ii)       Supplemental guidance on token based access biometric controls may be found in NIST SP 800-76.

b)        Physical access shall be monitored, logged, and registered for all users and visitors.

c)        All hardware components used to store keying material or generate signatures shall have short-term backup emergency power connections in case of site power outage. ( See, SP 800-53r3)

d)       All organizations shall have appropriate protection measures in place to prevent physical damage to facilities as appropriate.

 

6)       All Components

 

a)        All commercial off the shelf hardware and software components must have an established maintenance and update procedure in place.

 

i)         Supplemental guidance on establishing an upgrading policy for an organization may be found in NIST SP 800-40.

 

b)        All hardware and software components provide a means to detect and protect against unauthorized modifications/updates/patching.

 

Role Specific Requirements

 

7)  Root Zone Key Signing Key (KSK) Holder [28]

 

The Root Zone KSK Holder (RZ KSK) is responsible for: (1) generating and protecting the private component of the RZ KSK(s); (2) securely exporting or importing any public key components, should this be required (3) authenticating and validating the public portion of the RZ Zone

 

Signing Key (RZ ZSK); and (4) signing the Root Zone’s DNSKEY record (ZSK/KSK).

 

a)        Cryptographic Requirements

 

i)         The RZ KSK key pair shall be an RSA key pair, with a modulus of at least 2048 bits.

ii)       RSA key generation shall meet the requirements specified in FIPS 186-3. [29] In particular, key pair generation shall meet the FIPS 186-3 requirements for exponent size and primality testing.

iii)      The RZ KSK private key(s) shall be generated and stored on a FIPS 140-2 validated hardware cryptographic module (HSM) [30] , validated at Level 4 overall. [31]

iv)      RZ KSK Digital Signatures shall be generated using SHA-256.

v)        All cryptographic functions involving the private component of the KSK shall be performed within the HSM; that is, the private component shall only be exported from the HSM with the appropriate controls (FIPS 140-2) for purposes of key backup.

 

b) Multi-Party Control

 

At least two persons shall be required to activate or access any cryptographic module that contains the complete RZ KSK private signing key.

 

i)         The RZ KSK private key(s) shall be backed up and stored under at least two-person control. Backup copies shall be stored on FIPS 140-2 compliant HSM, validated at Level 4 overall, or shall be generated using m of n threshold scheme and distributed to organizationally separate parties.

ii)       Backup copies stored on HSMs shall be maintained in different physical locations [32] , with physical and procedural controls commensurate to that of the operational system.

iii)      In the case of threshold secret sharing, key shares shall be physically secured by each of the parties.

iv)      In all cases, the names of the parties participating in multi-person control shall be maintained on a list that shall be made available for inspection during compliance audits.

 

c)        Root Zone KSK Rollover

 

i)         Scheduled rollover of the RZ KSK shall be performed. [33] 15 (See Contingency planning for unscheduled rollover.)

ii)       RZ KSK rollover procedures shall take into consideration the potential future need for algorithm rollover.

iii)      DNSSEC users shall be able to authenticate the source and integrity of the new RZ KSK using the previously trusted RZ KSK’s public key.

 

d)             Contingency Planning

 

i)         Procedures for recovering from primary physical facility failures (e.g., fire or flood that renders the primary site inoperable) shall be designed to reconstitute capabilities within 48 hours.

ii)       Procedures for emergency rollover of the RZ KSK shall be designed to achieve key rollover and publication within 48 hours. These procedures, which are understood to address DNSSEC key provision only, should accommodate the following scenarios:

(1)     The current RZ KSK has been compromised; and

(2)     The current RZ KSK is unavailable, but is not believed to be compromised.

 

e)        DNS Record Generation/Supporting RZ ZSK rollover

 

i)         The RZ KSK Holder shall authenticate the source and integrity of RZ ZSK public key material

(1)     Mechanisms must support proof of possession and verify the parameters (i.e., the RSA exponent)

ii)       The signature on the root zone’s DNSKEY record shall be generated using SHA-256.

 

f)         Audit Generation and Review Procedures

 

i)         Designated Audit personnel may not participate in the multi-person control for the RZ ZSK or RZ KSK.

ii)       Audit logs shall be backed up offsite at least monthly.

iii)      Audit logs (whether onsite or offsite) shall be protected from modification or deletion.

iv)      Audit logs shall be made available upon request for Department review.

 

8)       RZ KSK Public Key Distribution

 

a)        The RZ KSK public key(s) shall be distributed in a secure fashion to preclude substitution attacks.

b)        Each mechanism used to distribute the RZ KSK public key(s) shall either

i)         Establish proof of possession of the RZ KSK private key (for public key distribution); or

ii)       Establish proof of possession of the previous RZ KSK private key (for Root zone key rollover).

 

9)       RZ Zone Signing Key (RZ ZSK) Holder [34]

 

The Root Zone ZSK Holder (RZ ZSK) is responsible for (1) generating and protecting the private component of the RZ ZSK(s); (2) securely exporting or importing any public key components, should this be required and (3) generating and signing Zone File Data in accordance to the DNSSEC specifications.

 

a)        Cryptographic Requirements

 

i)         The RZ ZSK key pair shall be an RSA key pair, with a modulus of at least 1024 bits. [35]

ii)       RSA key generation shall meet the requirements specified in FIPS 186-3. [36] In particular, key pair generation shall meet the FIPS 186-3 requirements for exponent size and primality testing.

iii)      RZ ZSK Digital Signatures shall be generated using SHA-256.

iv)      The RZ ZSK private key(s) shall be generated and stored on a FIPS 140-2 compliant HSM. At a minimum, the HSM shall be validated at Level 4 overall.

v)        All cryptographic functions involving the private component of the RZ ZSK shall be performed within the HSM; that is, the private component shall not be exported from the HSM except for purposes of key backup.

 

b)        Multi-Party Control

 

i)         Activation of the RZ ZSK shall require at least two-person control. This requirement may be satisfied through a combination of physical and technical controls.

ii)       If the RZ ZSK private key(s) are backed up, they shall be backed up and stored under at least two-person control. Backup copies shall be stored on FIPS 140-2 validated HSM, validated at Level 4 overall. [37]

 

(1)     Backup copies shall be maintained both onsite and offsite [38] 20 , with physical and procedural controls commensurate to that of the operational system.

(2)     The names of the parties participating in multi-person control shall be maintained on a list and made available for inspection during compliance audits.

 

c)        Contingency Planning

 

i)         Procedures for recovery from failure of the operational HSM containing the RZ ZSK shall be designed to re-establish the capability to sign the zone within 2 hours.

ii)       Procedures for emergency rollover of the RZ ZSK shall be designed to achieve key rollover within a technically feasible timeframe as mutually agreed among the Department, Root Zone Maintainer, and the IANA functions operator. These procedures must accommodate the following scenarios:

(1)     The current RZ ZSK has been compromised; and

(2)     The current RZ ZSK is unavailable (e.g. destroyed), but is not believed to be compromised.

 

d)       Root Zone ZSK Rollover

 

i)         The RZ ZSK shall be rolled over every six months at a minimum. [39]

ii)       DNSSEC users shall be able to authenticate the source and integrity of the new RZ

ZSK using the previously trusted RZ ZSK’s public key.

iii)      RZ KSK holder shall be able to authenticate the source and integrity of the new RZ ZSK.

 

e)        Audit Generation and Review Procedures

 

i)         Designated Audit personnel may not participate in the control for the RZ ZSK or RZ KSK.

ii)       Audit logs shall be backed up offsite at least monthly.

iii)      Audit logs (whether onsite or offsite) shall be protected from unauthorized access, modification, or deletion.

iv)      Audit logs shall be made available upon request for CSC review.

 

Other Requirements

 

10)    Transition Planning

 

a)        The IANA Functions Operator and Root Zone Maintainer shall have plans in place for transitioning the responsibilities for each role while maintaining continuity and security of operations. In the event the IANA Functions Operator or Root Zone Maintainer are no longer capable of fulfilling their DNSSEC related roles and responsibilities (due to bankruptcy, permanent loss of facilities, etc.) or in the event the [TBD - Department ] selects a successor, that party shall ensure an orderly transition of their DNSSEC roles and responsibilities in cooperation with the Department. [40]

 

11)    Personnel Security Requirements

 

a)        Separation of Duties

 

i)         Personnel holding a role in the multi-party access to the RZ KSK may not hold a role in the multi-party access to the RZ ZSK, or vice versa.

ii)       Designated Audit personnel may not participate in the multi-person control for the RZ ZSK or KSK.

iii)      Audit Personnel shall be assigned to audit the RZ KSK Holder or the RZ ZSK Holder, but not both.

 

b)        Security Training

 

i)         All personnel with access to any cryptographic component used with the Root Zone Signing process shall have adequate training for all expected duties.

 

12)    Root Zone Maintainer Basic Requirements

 

a)        Ability to receive NTIA authorized TLD Resource Record Set (RRset) updates from NTIA and IANA Functions Operator

b)        Ability to integrate TLD RRset updates into the final zone file

c)        Ability to accept NTIA authorized signed RZ keyset(s) and integrate those RRsets into the final zone file

 

13)    IANA Functions Operator Interface Basic Functionality

 

a)        Ability to accept and process TLD DS records. New functionality includes:

i)         Accept TLD DS RRs

 

(1)     Retrieve TLD DNSKEY record from the TLD, and perform parameter checking for the TLD keys, including verify that the DS RR has been correctly generated using the specified hash algorithm.

 

ii)       Develop with, and communicate to, TLD operators procedures for:

 

(1)       Scheduled roll over for TLD key material

 

(2)     Supporting emergency key roll over for TLD key material.

(3)     Moving TLD from signed to unsigned in the root zone.

b)        Ability to submit TLD DS record updates to NTIA for authorization and inclusion into the root zone by the Root Zone Maintainer.

c)        Ability to submit RZ keyset to NTIA for authorization and subsequent inclusion into the root zone by the Root Zone Maintainer.

 

14)                Root Zone Management Requirements [41]

a)        Ability and process to store TLD delegations and DS RRs

b)        Ability and process to store multiple keys for a delegation with possibly different algorithms

c)        Ability and process to maintain a history of DS records used by each delegation

d)       Procedures for managing scheduled roll over for TLD key material

e)        Procedures for managing emergency key roll over for TLD key material. [42]

f)         Procedures for managing the movement of TLD from signed to unsigned. [43] 25

g)        Procedures for DNSSEC revocation at the root zone and returning the root zone to its pre-signed state.

 

 

 

 

 

 

 

 

 

 

 


[1] According to the Fast Track Methodology the rules for delegation and relegation for ccTLD apply to delegation and relegation of IDN ccTLD.

[3] [ include definition of fundamental bylaw ]

[4] Note, nothing in these processes prevents a TLD an operator to pursue other applicable legal recourses that may be available.

[5] We note that the ICANN Contingency and Continuity of Operations Plan (CCOP) was the subject of a DIDP that was refused.

[6] The term IANA functions operator means the unit that provides the service.

[7] A group can be considered captured when one or more members are able to effectively control outcomes despite a lack of agreement from other stakeholders whose agreement or non-objection would be required to achieve consensus. Conditions for consensus will need to be agreed appropriate for the group.

 

[9] It is expected that these reports be retained for the duration of the reporting period, and be made available to members of the Periodic Review Team (to the extent that they are not published publically).

[10] This team has not determined the manner in which the Community Function is instantiated in most cases.  The assumption is that the larger solutions in CWG & CCWG will determine the possible forms for the community function activities. In some cases the Community Function may be expressed by an on-demand cross community group, at other times it might be represented by a mechanism that gathers the views of the various SOAC.

[11] Needs to be checked whether or not a copy of the .ARPA zone file comes from the IANA operator or the RZ Maintainer

[13] Given that there has up to now never been such a KSK roll-over and given the desire to maintain stability of security of the root zone a somewhat lighter procedure can be followed (tbd). The important part is the transfer of administration of the HSMs, related infrastructure and the operation of the key ceremonies.  This is not unlike the process that will take place in April 2015 when the Hardware Security Modules (HSM) are going to be replaced - see: https://www.icann.org/news/announcement-3-2015-03-23-en

[14] Including individuals, ccTLD regional organizations, ICANN SO/ACs, etc.

[15] Non-direct customers, including TLD organizations, that are of the view that an issue has not been addressed through step 1 may escalate the issue to the ombudsman or via the applicable liaisons to the Customer Standing Committee to step 2.

[16] If this is approved by the CWG, it would require further implementation work that would need to be done after approval of this step in the process and before the transition occurs

[17] Which would include IRP and CCWG work stream 1 accountability mechanisms once these are completed.

[18] ibid

 

[20] The Root Zone management partners consist of the IANA Functions Operator (per the IANA functions contract), CSC, and Root Zone Maintainer (per the Cooperative Agreement with VeriSign). This document outlines requirements for both the IANA Functions Operator and Root Zone Maintainer in the operation and maintenance of DNSSEC at the authoritative root zone.

[21] Note in particular that the use of the requirements in SP 800-53 does not imply that these systems are subject to other Federal Information Security Management Act (FISMA) processes.

[22] For the purpose of identifying SP 800-53 security requirements, the Root Zone system can be considered a HIGH IMPACT system with regards to integrity and availability as defined in FIPS 199.

[23] For this document, the roles in the Root Zone Signing process are those associated with the Key Signing Key holder, the Zone Signing Key holder, Public Key Distributor, and others to be conducted by the IANA Functions Operator and the Root Zone Maintainer.

6 For the IANA Functions Operator, the contingency plan must be consistent with and/or included in the “Contingency and Continuity of Operations Plan” as articulated in Section III.A.1.4.3.14 of the CWG transition proposal.

7 Remote access is any access where a user or information system communicates through a non-organization controlled network (e.g., the Internet).

 

[26] Non-exceptional events are to be included in monthly reporting as required Section III.A.1.4.2.2 of the CWG transition proposal.

[27] For the IANA Functions Operator, audit reporting shall be incorporated into the audit report as articulated in Section III.A.1.4.2.7 of the CWG transition.

10 The Root Zone KSK Holder is a responsibility performed by the IANA Functions Operator.

11                    Note that FIPS 186-3 and FIPS 140-2 are referenced as requirements in sections a and b, rather than supplemental guidance.

[30] FIPS 140 defines hardware cryptographic modules, but this specification will use the more common HSM (for hardware security module) as the abbreviation.

[31] Note that FIPS 186-3 and FIPS 140-2 are referenced as requirements in sections a and b, rather than supplemental guidance.

[32] Backup locations are to be within the United States

[33] The CSC envisions the timeline for scheduled rollover of the RZ KSK to be jointly developed and proposed by the IANA Functions Operator and Root Zone Maintainer, based on consultation and input from the affected parties (e.g. root server operators, large-scale resolver operators, etc). Note that subsequent test plans may specify more or less frequent RZ KSK rollover to ensure adequate testing.

[34] The RZ ZSK holder is a function performed by the Root Zone Maintainer, NOT the IANA Functions Operator.

[35] Note that these requirements correspond to those articulated in NIST SP 800-78 for authentication keys. Since there is no forward security requirement for the DNSSEC signed data, the more stringent requirements imposed on long term digital signatures do not apply.

[36] Note that FIPS 186-3 and FIPS 140-2 are referenced as requirements in sections 8a and 8 b, rather than as supplemental guidance.

[37] Note that FIPS 186-3 and FIPS 140-2 are referenced as requirements in sections 8a and 8 b, rather than as supplemental guidance.

[38] The CSC expects backup locations to be within the United States.

[39] The timelines specified in this document apply to the operational system. Subsequent test plans may specify more or less frequent RZ ZSK rollover to ensure adequate testing.

[40] For the IANA Functions Operator, the transition plan shall be incorporated into that which is called for in Section III.A.1.4.3.15 of the CWG transition proposal.

[41] The CSC envisions the IANA Functions Operator and Root Zone Maintainer jointly agree to utilizing pre-existing processes and/or deciding and proposing new methods by which each of these requirements are designed and implemented, subject to CSC approval.

[42] To the extent possible, on 24 hour notice under the existing manual system and on 12 hours notice once the automated system is utilized.

[43] To the extent possible, this must be within 48 hours .