Response to the IANA Stewardship Transition Coordination Group Request for Proposals on the IANA Stewardship Transition from the Cross Community Working Group (CWG) 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

 


Appendix: Definitions


Response to the IANA Stewardship Transition Coordination Group Request for Proposals on the IANA Stewardship Transition from the Cross Community Working Group (CWG) 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 , including uncommon acronyms and defined terms [MK2] , 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 De-Allocated ISO 3166-1 ccTLD Code s 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 registr y managers ies , .INT registrants, the Root Zone Maintainer, DNS [MK3] 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 [MK4] . 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. The DNS requires IP addresses to function (both IPV4 and IPV6) from the A ddress R egistries and as such is an interdependency for many of the IANA functions. 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 original IANA Functions Operat ions, or Jon Postel. It is a short document intended to outline how the domain Domain name Name system 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 for ICANN but 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 “interpret” 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 unilaterally created by ICANN staff shortly after its creation. It attempted to clarify key 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 DRD 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 Delegation and Redelegation Working Group ( DRDWG ) , the FOIWG was joint effort between the ccNSO and the G overnmental Advisory Committee (G AC ) 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 applicatio i n 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

The This document, GAC’s ‘ Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains ’ ( also known as the 2005 GAC Principles 2005) , 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

 

Currently RFC1591 only applies to ccTLDs , .GOV, and .MIL and most of these 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 only options 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 I nternational C hamber of C ommerce (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 (IDN ccTLDs)

Delegations and redelegation of IDN ccTLDs.

 

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

The Fast Track is the application process for obtaining country and territory names in local scripts (IDN ccTLDs). This was not developed using the ccNSO PDP due to timing requirements . The ccNSO used a cross community working group approach which generated a recommendation to the ICANN Board wh o accepted it. Fast Track Methodology: http://ccnso.icann.org/workinggroups/idnc-wg-board-proposal-25jun08.pdf  

 

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

The only options that are available are the ICANN Ombudsman or the ICANN Bylaws relating to the Independent Review of ICANN Board Actions (which only apply to delegations and redelegations). Given these mechanisms are non-binding on the Board or ICANN they are perceived by many ccTLDs as being of limited value.

 

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

            Fast Track Methodology: http://ccnso.icann.org/workinggroups/idnc-wg-board-proposal-25jun08.pdf  

            Implementation Planfor IDN ccTLDs: https://www.icann.org/en/resources/idn/fast-track/idn-cctld-implementation-plan-05nov13-en.pdf  

            And Board resolution on methodology: https://www.icann.org/resources/board-material/resolutions-2008-06-26-en#_Toc76113172  

            Independent Review Panel (IRP) - https://www.icann.org/resources/pages/irp-2012-02-25-en  

            ICANN Ombudsman - https://www.icann.org/resources/pages/governance/bylaws-en#AnnexB  

 

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 p resumed 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)

All 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 or its WHOIS database are affected ( TBCONFIRMED ) .

 

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 . For ccTLDs with contracts the jurisdiction needs to be agreed to by both parties. If no agreement can be reached the jurisdiction is usually New York, New York, USA.

 

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 names N am ing Related   f F unctions” 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

 

Post-Transition IANA (PTI)

[To be completed following receipt of legal memo]

 

PTI Board

[To be completed following receipt of legal memo]

 

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. 

 

IANA Function Review [ DT N [MK6] ]

The CWG -Stewardship recommends that the Statement of Work ( SOW ) review be done as part of a n IANA Function R eview. The IANA Function   R eview 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 tech nical or process improvements.   The outcomes of report s submitted to the CSC , reviews and comments received on these reports during the relevant time period will be included as input to the IANA F unction R eview.

 

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 [MK7] every 5 years. The IANA Function R eview is expected to be assured in a “Fundamental Bylaw” [3] as part of the work of the CCWG- Accountability [MK8] and would operate in a manner analogous to an A ffirmation of Commitments (A OC ) 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 O VERSIGHT & ACCOUNTABILITY REPLACEMENT

III.A.i.                  ICANN to continue as IANA Naming Services Operator  

[High level recommendations to be provided by relevant DTs – details to be included in annex]

III.A.i.a.              Structure (legal input/CWG) Periodic review (DT N) Periodic IANA Function Review [ DT N [MK9] ]

The CWG recommends that the SOW review be done as part of a Periodic IANA Function review . The first Periodic Review of the IANA Function can be done 2 years after the transition. After that the Periodic Reviews   can occur every 5 years. The Periodic 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 tech nical or process improvements. The r eview would be defined in a Fundamental Bylaw and would operate in a manner analogous to an AOC review. Its members would be selected by the Supporting Organizations and Advisory Committees and would include several liaisons. While the Periodic Review Team is intended to be a smaller group, it will be open to participants in much the same way as the name community transition cross community working group.

 

Additionally a number of reports, similar to the reports required by NTIA, will be produced by IANA and be reviewed . For the most part these will reviewed by the CSC, though some will be open to comment by the ICANN community and other interested parties. The comments would directed to IANA. The long term outcomes from these report, reviews and comments will be included as input to the Periodic IANA f unction r eview. For further details, please see Annex D.

 

III.A.i.                  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 M m ission 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.ii.                Service Level Expectations (DT A)

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

 

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 e mergency situations as well as c ustomer s ervice c omplaints 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 .

[MK10]

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) .

 

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 [MK11] be further developed into a detailed, fully functional, transition plan within 18 months from the completion of the IANA S tewardship T ransition;
  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. [MK12]

For further information, please see Annex E.

 

 

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

 

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. C hanges to the Root Zone C ontent 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 c hange s no longer require NTIA approval.

 

  1. Ensure that post transition , the Root Zone Maintainer can and will make changes to the Root Zone as requ ested 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, t o 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.i.b.                         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 operator to a successor IANA 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. [6]   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 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;
  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.

For further information, please see Annex E.

 

III.A.iii.               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.iv.               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 F iscal Y ear (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 H I .

 

III.A.v.                 Regulatory and Legal Obligations   Structure (legal input/CWG)

The process for handling the requests for waivers or licenses relating to its legal obligations in its place of business (suc h 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.A.ii.                Service Level Agreement with IANA

[High level recommendations to be provided by relevant DTs – details to be included in annex]

Service Level Expectations (DT A)

III.A.ii.a.            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 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 [MK13] .

 

III.A.ii.b.           The complete charter of the Customer Standing Committee can be found in Annex J . Escalation Mechanisms [DT M] [MK14]

The CWG recommends requiring the continuation, with minor modifications, of a progressive set of escalation steps that can be performed for E mergency situations as well as C ustomer S ervice C omplaints and a new Problem Management Process for C ritical, P ersistent or S ystemic F ailures , as applicable, for individual TLD registry operators, or others with relevant IANA functions operational issues. Three processes [7] are recommended:

  1. Root Zone Emergency Proc ess

This process is for TLD managers in cases where expedited handling is required and is essentially the same as the process currently used by ICANN.

  1. Customer Service Complaint Resolution Process

This process is for anyone who has a complaint about IANA services. It is modified somewhat from the current process used by ICANN with some added steps at the end.

  1. Problem Management Escalation Process
  2. This is a new process for critical, persistent or systemic failures of IANA services. Root Zone Emergency Process

This process is for TLD managers in cases where expedited handling is required and is essentially the same as the process currently used by ICANN.

[MK15]

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.ii.c.            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 D .  

 

III.A.vi.               Root Zone Management Process Administrator Role to be discontinued

[High level recommendations to be provided by relevant DTs – details to be included in annex]

 

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 following updates / changes will need to be made: [ to be completed following the finalisation of work of DT D/ F ].  

 

Authorization Function (DT D)

Relationship between IANA and Root Zone Maintainer (DT F)

 

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 – not including delegation and redelegation (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) . The DNS requires IP addresses to function (both IPV4 and IPV6) from the Address Registries and offers its services based on a large number of protocols

 

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: Root Zone database (indirect for nameservers). 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) The DNS requires IP addresses to function (both IPV4 and IPV6) from the Address Registries and offers its services based on a large number of protocols developed and maintained by the IETF.

 

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. IANA 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 IANA 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) The DNS requires IP addresses to function (both IPV4 and IPV6) from the Address Registries and offers its services based on a large number of protocols developed and maintained by the IETF.

 

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 TLD registrants 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. The DNS requires IP addresses to function (both IPV4 and IPV6) from the Address Registries and offers its services based on a large number of protocols developed and maintained by the IETF .

 

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: - The DNS requires IP addresses to function (both IPV4 and IPV6) from the Address Registries and offers its services based on a large number of protocols developed and maintained by the IETF .

 

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: - The DNS requires IP addresses to function (both IPV4 and IPV6) from the Address Registries and offers its services based on a large number of protocols developed and maintained by the IETF .

 

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 De-Allocated ISO 3166-1 ccTLD Codes TLDs (IANA service or activity beyond the scope of the IANA functions contract)

  • Description of the function: Retire TLDs from ISO3166-1 entries from active use as ccTLDs if the ISO3166-1 entr y   is no longer allocated .
  • Customers of the function: cc TLD registries
  • What registries are involved in providing the function: Root Zone database, Root Zone WHOIS database.
  • Overlaps or interdependencies: ISO-3166-1 Alpha 2, the DNS requires IP addresses to function (both IPV4 and IPV6) from the Address Registries and offers its services based on a large number of protocols developed and maintained by the IETF.


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 : c hanges 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. A ccountability 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 [8] 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 [9] : 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 an y 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 recogni ze d 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 : dec isions 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: d ecisions 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 impo se 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. Sep a rability : any proposal must ensure the ability:
      1. To separate the IANA F unctions 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.  

[to be included once finalised]


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, we the CWG   recommend s 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 [10] 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. [MK18]

 

Opinion in the DT regarding whether this review could precipitate a yet to be defined RFP process regarding the IANA contract is divided .

 

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; [11] 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 [12] .  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

PRT I RT

Review CSC report on IANA performance SOW report

Annual

AC/SO/ICANN

Comment period

ICANN Board Community Function

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 F 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 [13] . 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 [14] . That plan requires that a full KSK rollover be done so the successor starts fresh. [15]
  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 G 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   an d 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] [MK19]

 

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 [MK20] .

 

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 [MK21] .

 

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. [MK22]

 

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 K J   IANA Customer Service Complaint Resolution Process [MK23] [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 [16] . 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 through the involvement of the IANA Functions Team and/or the Ombudsman , the following escalation mechanisms will be made available to direct customers [17] :

  1. If issue is not addressed, the complainant (direct customer) may request mediat ion   [18]
  2. CSC is notified of the issue by complainant and/or IFO. to take action. 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. decides to take action or not.
  3. If deemed appropriate and feasible by the CSC, CSC to mediate directly with IFO
  4. If issue is not addressed, CSC assigns a mediator [19]
  5. If issue is not addressed, CSC to decide whether issue is problem (critical, persistent or systematic failure) and escalates to problem management procedure
  6. If issue is not addressed and not considered to be a problem (critical, persistent or systematic failure), registry operator could decide to initiate an Independent Review Process The complainant (direct customer) may initiate an Independent Review Process, if the issue is not addressed.


Annex L K   - IANA Problem Management Escalation Resolution Process [DT M]

 

(New procedure)

 

Problem Management ( including responding to p Critical, P ersistent performance issues or Systemic s ystemic Failures 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 : empowered to determine a significant failure of the IANA Functions Operator either due to the outcome of periodic audits or the CSC’s evaluation of a rising number of TLD registry operator complaints .

 

  1. CSC reports persistent performance issues significant failure to the IANA Functions Operator and requests response remedial action   in a predetermined number of days.
  2. If CSC determines the IANA Functions Operator response to be inadequate, the CSC directs remedial action in a specified period of time.
  3. CSC confirms completion of remedial action.
  4. 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 [20] .

 

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 [21]

  1. If remediation is unsatisfactory, CSC involves a mediator.
  2. If mediation fails, a binding Independent Appeals Panel [MK24] [MK25] is initiated.
  3. [ After CCWG work stream 1 accountability mechanisms are approved, the applicable steps for the IANA processes should be added to this process [MK26] ]

 



Annex J 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 [22] 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