Proposal to Transition the Stewardship of theInternet Assigned Numbers Authority (IANA) Functions
from the U.S. Commerce Department’s National
Telecommunications and Information Administration (NTIA)
to the Global Multistakeholder Community

July 2015

Table of Contents
Executive Summary __________________________________________________________ 3
Part 0. Report from the IANA Stewardship Transition Coordination Group ____________ 7
Part 1. Response from the Domain Names Community ____________________________ 21
Part 2. Response from the Internet Number Community __________________________ 146
Part 3. Response from Protocol Parameters Registries Community ________________ 176

IANA Stewardship Transition Proposal Page 2 of 199

Executive Summary

X001

On March 14, 2014, the U.S. Commerce Department’s National Telecommunications andInformation Administration (NTIA) announced its intent to transition the stewardship of key
Internet functions to the global multistakeholder community.1 NTIA asked the Internet
Corporation for Assigned Names and Numbers (ICANN) to convene global stakeholders todevelop a proposal to replace NTIA’s current stewardship role over the Internet Assigned
Numbers Authority (IANA) functions.

X002

As a result of community discussions, the IANA Stewardship Transition Coordination Group(ICG)2 was formed in July 2014 to coordinate the transition planning process. The ICG iscomprised of 30 individuals representing 13 communities, and includes direct and indirect
stakeholders. These representatives were selected by their respective communities. 3

X003

The ICG took note of guidance from the Internet Architecture Board (IAB)4 pointing out thedivision of IANA functions and customer communities into three categories related todomain names, number resources, and protocol parameters. The ICG therefore chose to
ground the proposal development process in the three communities with direct operationalor service relationships with the IANA functions operator, reflecting the fact that the policy
and oversight responsibilities for the three functions resides in these three separate
communities (and has for decades). The three “operational communities” (OCs) are: thedomain names community (organized around ICANN’s supporting organizations andadvisory committees); the number resources community (organized around the regional
address registries); and the protocol parameters community (organized around the Internet
Engineering Task Force).

X004

The ICG was tasked to help assure that the proposals met the articulated NTIA
requirements and were supported by broad community consensus. The ICG developed arequest for proposals (RFP)5 that was provided to each of the communities setting forth
these conditions and the need to have open, inclusive processes. Each of the communities
then used their own processes to develop a response to the RFP for transitioning their partof the IANA functions, and submitted their response to the ICG. This document contains the
RFP responses from each of the three operational communities.

X005

The domain names community proposed to form a new, separate legal entity, PostTransition IANA (PTI), as an affiliate (subsidiary) of ICANN that would become the IANA
functions operator in contract with ICANN. The legal jurisdiction in which ICANN resides is toremain unchanged. The proposal includes the creation of a Customer Standing Committee(CSC) responsible for monitoring the operator’s performance according to the contractual

1 http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-

domain-name-functions
2 http://www.ianacg.org/
3 https://www.ianacg.org/coordination-group/icg-members/
4 https://www.iab.org/wp-content/IAB-uploads/2014/04/iab-response-to-2014040820140428a.pdf
5 https://www.icann.org/en/system/files/files/rfp-iana-stewardship-08sep14-en.pdf
IANA Stewardship Transition Proposal Page 3 of 199

requirements and service level expectations. The proposal establishes a multistakeholder
IANA Function Review process (IFR) to conduct reviews of PTI.
X006

The numbers community proposed that ICANN continue to serve as the IANA Functions
Operator and perform those services under a contract with the five Regional Internet
Registries (RIRs). The numbers community proposed a contractual Service Level
Agreement (SLA) between the Regional Internet Registries and the IANA Numbering
Services Operator and a Review Committee (RC) comprising community representatives
from each region to advise the RIRs on the IANA functions operator’s performance andadherence to identified service levels.

X007

For the protocol parameters, ICANN currently serves as the IANA registries operator. The
IETF community expressed satisfaction with the current arrangements and proposed that
the IANA protocol parameters registry updates continue to function day-to-day, as they havebeen doing for the last decade or more. The protocol parameters community proposed tocontinue to rely on the system of agreements, policies, and oversight mechanisms createdby the IETF, ICANN, and IAB for the provision of the protocols parameters-related IANA
functions.

X008

The ICG assessed the proposals individually and collectively to determine whether:

the community processes used to develop the proposals were open and inclusive,
and whether they achieved consensus;the proposals are complete and clear;

the three proposals together are compatible and interoperable, provide appropriate
and properly supported accountability mechanisms, and are workable; andthe proposals together meet the NTIA criteria.

Community Processes
X009

The ICG has concluded that each of the individual proposals was developed in an open andinclusive manner and that each proposal achieved consensus as defined by each
community.

Completeness and Clarity
X010

The ICG discussed the content of each proposal in depth and has published a matrix of
topics discussed.6 With the one exception below, the ICG is satisfied that the proposals arecomplete and clear.

X011

The ICG has noted that the names proposal is complete on the condition that thedependencies on ICANN-level accountability mechanisms, currently under development by
the Cross Community Working Group on Enhancing ICANN Accountability (CCWG), areconcluded as specified in the names proposal. Those mechanisms are incorporated into a
proposal that the CCWG has released for public comment concurrently with the ICG’s callfor public comment on this proposal.

6 http://www.ianacg.org/icg-files/documents/questions-and-answers-matrix_v4.xlsx

IANA Stewardship Transition Proposal Page 4 of 199

X012

Once the CCWG has concluded its work on these mechanisms (estimated to occur prior to
ICANN 54 in October 2015), the ICG will seek confirmation from the CWG that its
requirements have been met. At that point the ICG will make a final determination as towhether it considers the names proposal to be complete.

Compatibility and Interoperability
X013

The ICG identified a potential compatibility issue regarding the IANA trademarks and theiana.org domain name. The numbers proposal detailed specific requirements related to
IANA intellectual property, whereas the other two proposals are silent on this issue. As longas the other two communities can accommodate the specified requirements as part of theirimplementation, then the implementation of the proposals will be compatible. The ICG
expects the operational communities to continue to coordinate on this topic during theimplementation phase to ensure that the requirements are met.

Accountability
X014

The three proposals together include appropriate and properly supported independentaccountability mechanisms for running the IANA functions, relying mostly on the right ofeach operational community to select a new entity for the performance of the IANA
functions.

Workability
X015

Having been developed by the three operational communities, the three proposals arenaturally different in many respects, reflecting different subject matter, priorities, challenges
and processes involved in their production. However, the ICG regards the three proposals
as individually and collectively workable.

X016

Verisign currently serves as the Root Zone Maintainer and performs the Root Zone
Management functions pursuant to a cooperative agreement with NTIA. Since there iscurrently no agreement between the Root Zone Maintainer and the IANA functions operator
for the Root Zone Management process, some form of agreement between theseorganizations will be essential when NTIA withdraws from the Root Zone Management
process.

NTIA Criteria
1. Broad community support
X017

The ICG has concluded that each of the individual proposals has broad community support.
Each community ran an open and inclusive process in which any interested individual wasable to participate. Each community produced a consensus proposal.

X018

The ICG will make a determination about whether the combined proposal has achieved
broad community support following its solicitation of public comments on the combined
proposal.
2. Support and enhance the multistakeholder model

IANA Stewardship Transition Proposal Page 5 of 199

X019

The ICG has concluded that the combined proposal supports and enhances themultistakeholder model because it leverages existing multistakeholder arrangements,
processes, and paradigms in defining the post-transition IANA oversight and accountability
mechanisms. Each component of the proposal has this feature.
3. Maintain the security, stability, and resiliency of the Internet DNS

X020

Neither the numbers proposal nor the protocol parameters proposal suggest changes that
could affect the security, stability, or resiliency of the DNS.

X021

While the names proposal calls for the IANA functions operator to be transferred to the PTI,
the PTI will be an affiliate (subsidiary) of ICANN and ICANN will be responsible for the
stewardship of the PTI. Hence operational roles are maintained. The proposal envisages thenames aspect of the current NTIA oversight and contracting authority is transferred to
ICANN. The separation of PTI as a subsidiary will ensure the independence of that oversightrole from the contractor providing the service.

X022

This arrangement introduces minimum change and keeps the current IANA functions
operation team intact and carrying out the same role as it has today.
4. Meet the needs and expectations of the global customers and partners of the IANA
services

X023

All three communities determined that the global customers and partners of the IANA
services and their communities of stakeholders are presently satisfied with the performanceof the IANA functions by the IANA department of ICANN. The combined proposal is notexpected to impact that.
5. Maintain the openness of the Internet

X024

The combined proposal requires that the IANA services, associated policy development
processes, and IANA registries remain fully open and accessible just as they are today.
6. Does not replace NTIA role with a government or inter-governmental organization

X025

The combined proposal does not replace NTIA’s role with a government or intergovernmental organization.

ICG Recommendation
X026

After the conclusion of the ICG public comment period and the finalization of CCWG
Workstream 1, the ICG will make a final determination about whether to recommend that
NTIA approve the transition proposal. Based on the outcome of the evaluation described inPart 0, Section IV below, the ICG is planning to recommend that NTIA approve the transition
proposal, pending the resolution of the outstanding items highlighted in that section.

IANA Stewardship Transition Proposal Page 6 of 199

Part 0: Report from the IANA Stewardship Transition Coordination GroupPart 0. Report from the IANA Stewardship Transition
Coordination GroupI.

Introduction
On March 14, 2014, the U.S. Commerce Department’s National Telecommunications andInformation Administration (NTIA) announced its intent to transition the stewardship of key
Internet functions to the global multistakeholder community.7 NTIA asked the Internet
Corporation for Assigned Names and Numbers (ICANN) to convene global stakeholders todevelop a proposal to replace NTIA’s current stewardship role over the Internet Assigned
Numbers Authority (IANA) functions. This document is the mentioned proposal.

01

II.

Process Summary02

As a result of community discussions, the IANA Stewardship Transition Coordination Group(ICG)8 was formed in July 2014 to coordinate the transition planning process. The ICG iscomprised of 30 individuals representing 13 communities, and includes direct and indirect
stakeholders. These representatives were selected by their respective communities.903

The ICG took note of guidance from the Internet Architecture Board (IAB)10 pointing out thedivision of IANA functions and customer communities into three categories related todomain names, number resources, and protocol parameters. The ICG therefore chose to
ground the proposal development process in the three communities with direct operationalor service relationships with the IANA functions operator, reflecting the fact that the policy
and oversight responsibilities for the three functions reside in the three separate
communities (and has for decades). The three “operational communities” (OCs) are: thedomain names community (organized around ICANN’s supporting organizations andadvisory committees); the number resources community (organized around the regional
address registries); and the protocol parameters community (organized around the Internet
Engineering Task Force).

7

http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internetdomain-name-functions
8 http://www.ianacg.org/
9 https://www.ianacg.org/coordination-group/icg-members/
10 https://www.iab.org/wp-content/IAB-uploads/2014/04/iab-response-to-2014040820140428a.pdf
IANA Stewardship Transition Proposal Page 7 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group04

On September 8, 2014, the ICG issued a Request for Proposals (RFP)11 which provided atemplate to be used by each community. Each of the communities then used their own
processes to develop a response to the RFP for transitioning their part of the IANA
functions, and submitted their response to the ICG. The ICG then assessed the proposals,
individually and collectively, against a number of criteria,12 including those that NTIA
established for the transition. Finally, the ICG assembled the proposals in this document,
which contains the RFP responses from each of the three operational communities. Part 1 isthe proposal for domain names, Part 2 is the proposal for numbers, and Part 3 is the
proposal for protocol parameters.

05

More information about the community processes is available in Section VI of each Part.

III.

Proposal Summary

06

This proposal document includes the three final community proposals received by the ICG.
These proposals are provided verbatim, without changes by the ICG (aside from formattingchanges). The three proposals are summarized in this section. However, the proposals
themselves are authoritative and should be referenced for further details.

07Part 1 contains the domain names proposal. The names community proposed to form anew, separate legal entity, Post-Transition IANA (PTI), as an affiliate (subsidiary) of ICANN.
They proposed that the existing IANA functions administrative staff and related resources,
processes, data, and know-how be legally transferred to PTI and that ICANN enter into acontract with PTI to serve as the IANA Functions Operator (IFO) for the naming functions,11

https://www.icann.org/en/system/files/files/rfp-iana-stewardship-08sep14-en.pdf

12 https://www.icann.org/en/system/files/files/iana-transition-assembly-finalization-24dec14-

en.pdf
IANA Stewardship Transition Proposal Page 8 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group

including service level agreements for the naming functions. The legal jurisdiction in which
ICANN resides is to remain unchanged. The proposal includes the creation of a Customer
Standing Committee (CSC) responsible for monitoring IFO performance according to thecontractual requirements and service level expectations. The proposal establishes amultistakeholder IANA Function Review process (IFR) to conduct periodic and special
reviews of PTI. The IFR would have the ability to recommend a separation process that
could result in termination or non-renewal of the ICANN-PTI IANA functions contract, among
other actions. These reviews will focus on the names functions.
08

The names community proposed to discontinue the authorization of root zone changes thatis currently performed by NTIA. They also proposed to give to the ICANN Board theauthority to approve any major architectural and operational changes in the management of
the root zone. This approval is to be based on the recommendations of a standing
committee of stakeholders and experts (which is different from the CSC).

09

The names community proposal is expressly conditioned on the implementation of ICANNlevel accountability mechanisms proposed by the Cross Community Working Group on
Enhancing ICANN Accountability (CCWG). Those mechanisms are incorporated into a
proposal that the CCWG has released for public comment concurrently with the ICG’s callfor public comment on this proposal. The ICG has committed to seeking confirmation fromthe names community that its accountability requirements have been met once the CCWG
proposal is finalized.

10Part 2 contains the number resources proposal. The numbers community proposed that
ICANN continue to serve as the IANA Functions Operator and perform those services undera contract with the five Regional Internet Registries (RIRs).

11

The numbers community proposed a contractual Service Level Agreement (SLA) between
the Regional Internet Registries and the IANA Numbering Services Operator and a Review
Committee (RC) comprising community representatives from each region to advise the RIRs
on the IANA functions operator’s performance and adherence to identified service levels.
The implementation of these components of the proposal has commenced, with the draft
SLA and RC Charter being under development within the RIR communities.

12

The numbers community further proposed that the trademarks and domain names
associated with the provision of the IANA services be held by an entity that is not theprovider of the IANA numbering services, the IETF Trust being suggested as the repository.

13

Part 3 contains the protocol parameters proposal. ICANN currently serves as the IANA
protocol parameters registries operator. The IETF community expressed satisfaction withthe current arrangements and proposed that the IANA protocol parameters registry updates
continue to function day-to-day, as they have been doing for the last decade or more. The
protocol parameters community proposed to continue to rely on the system of agreements,
policies, and oversight mechanisms created by the IETF, ICANN, and IAB for the provisionof the protocols parameters-related IANA functions; specifically, RFC 2860,13 RFC 6220,14
and an annually updated service level agreement.15 The IETF asked for threeacknowledgements to be made as part of the transition: 1) That the protocol parameters
13 https://tools.ietf.org/html/rfc2860
14 https://tools.ietf.org/html/rfc6220
15 http://iaoc.ietf.org/contracts.html

IANA Stewardship Transition Proposal Page 9 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Groupregistries are in the public domain; 2) That ICANN carries out the obligations establishedunder C.7.3 and I.61 of the ICANN-NTIA IANA functions contract16 and 3) that ICANN, theIETF, and subsequent IANA functions operator(s) work together to minimize disruption in theuse of the protocol parameters registries or other resources currently located at iana.org.
14

A visual summary of the oversight components of the combined proposal appears below.
The operational interactions between the communities and the IANA functions operator are
not pictured.

16 http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf

IANA Stewardship Transition Proposal Page 10 of 199

Part 0: Report from the IANA Stewardship Transition Coordination GroupIV.

ICG Assessment

The ICG assessed the proposals to determine whether:15

the community processes used to develop the proposals were open and inclusive, andwhether they achieved consensus;the proposals are complete and clear;

the three proposals together are compatible and interoperable, provide appropriate andproperly supported accountability mechanisms, and are workable; andthe proposals together meet the NTIA criteria.

A. Community Processes: Openness, Inclusiveness, and Consensus
The ICG has concluded that each of the individual proposals was developed in an open andinclusive manner and that each proposal achieved consensus as defined by each
community. When the ICG received comments indicating process concerns via the ICG
forum,17 those comments were shared with the relevant operational communities andconsidered by the communities in depth. That process is ongoing as forum comments
continue to be received.

16

1.

Names

17

The names proposal was developed in the Cross Community Working Group to Develop an
IANA Stewardship Transition Proposal on Naming Related Functions (CWG). The CWG had
participation from 152 members and participants from across geographies and stakeholder
groups. The CWG was open to participation from any interested person and conducted its
work – over 100 calls and meetings and over 4,000 mailing list messages – in an open
manner. The CWG proposal included attention to the input of 115 comments received
through two public comment proceedings. The proposal received the consensus support of
the CWG, with no objections or minority statements recorded. All five CWG charteringorganizations – the At-Large Advisory Committee (ALAC), the Country Codes Names
Supporting Organization (ccNSO), the Governmental Advisory Committee (GAC), theGeneric Names Supporting Organization (GNSO), and the Security and Stability Advisory
Committee (SSAC) – approved the proposal at ICANN 53 in June 2015.

18

The CWG considered a wide variety of accountability models before settling on its final
proposal. Those are summarized here to illustrate why the PTI-based model was chosenover the other models and to demonstrate the rigor of the CWG’s process in identifying amodel that obtained consensus.

19

The CWG’s first draft proposal that was published for public comment was designed aroundthe idea of an independent and separate contracting entity (“Contract Co.”) to replace
NTIA’s stewardship role and contract with the IANA functions operator. Responses to the17 http://mm.ianacg.org/pipermail/icg-forum_ianacg.org/

IANA Stewardship Transition Proposal Page 11 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group

consultation showed that there were significant parts of this model that would not command
community consensus.
20

Subsequently the CWG identified seven potential models for the IANA stewardshiptransition. These models were discussed at a face-to-face meeting of the working group withsupporting advice from legal counsel.

21

The move from seven potential models down to two variants of an internal
accountability/hybrid model was iterative over a series of sessions. In one session, after
explanation of legal counsel’s findings, two models – the internal trust and the external trust– were deemed unsuitable to meet the CWG’s requirements because the structures were
not necessarily recognized legally outside of the U.S. Upon conclusion of these sessions,the CWG also agreed to defer further consideration of the “Contract Co.” model (in part,
because it did not receive sufficient support after the first public comment period), until theviability of the remaining models could be further considered. In addition, the CWG agreed
to defer further consideration of the fully internal model and the standalone IANA hybrid
model. The CWG agreed that the remaining models – two variants of an internal
accountability/hybrid model (the legal separation model and the functional separation model)– required further research on the part of legal counsel before the CWG could make adetermination.

22

Following the face-to-face meetings, the CWG, in consultation with its independent legal
counsel, held extensive discussions to determine which of the two variants of the internal
accountability/hybrid model would be recommended. The CWG determined that the legal
separation model was preferred because it would establish PTI as a separate legal entity at
the outset, allowing for possible separation from ICANN in the future, if necessary. In
addition, the legal separation model allowed for a contract between ICANN and PTI. With
that decision reached, the CWG turned its focus to developing an accountability framework
to support this model, while legal counsel assisted in addressing governance issues related
to the model.

2.

Numbers

23

The numbers proposal was prepared by the Consolidated RIR IANA Stewardship Proposal(CRISP) Team,18 which was established by the numbers community through the Regional
Internet Registries (RIRs) specifically for the purpose of producing the proposal.

24

Between August and November 2014, initial discussions were conducted on a regional
basis during the regular open meetings of each of the RIRs. During these discussions
proposal elements were developed and agreed, often building on prior discussions of other
RIR communities. After the 5th RIR meeting, the CRISP team consolidated the results in asingle global proposal on behalf of the Numbers Community. The first draft of the proposal
was released for public comment on 19 December 2014, and a second draft on 8 January
2015, before a final Proposal19 was submitted to the ICG on 15 January 2015.

18 https://www.nro.net/nro-and-internet-governance/iana-oversight/consolidated-rir-iana-

stewardship-proposal-team-crisp-team
19 https://www.nro.net/wp-content/uploads/ICG-RFP-Number-Resource-Proposal.pdf
IANA Stewardship Transition Proposal Page 12 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group25

The CRISP team conducted its work on an open mailing list20 with over a hundred
subscribers and in open conference calls which allowed the participation of any interested
parties and were publicly minuted. The 1st CRISP teleconference call was held on 9
December 2014, and the 14th on 15 January 2015.

26

During these meetings and in online discussions, consensus was determined when,
following discussions within the CRISP team, no further comments, concerns, or objections
were observed.

3.

Protocol Parameters

27

The protocol parameters proposal was developed in the IANAPLAN working group at theInternet Engineering Task Force (IETF). Anyone was welcome to join the discussion on the
open mailing list and participate in the development of this response.

28

The discussion converged early on a model based on further evolution of the current
arrangements, given that it is working well and there already were agreements, role
definitions, and processes in place between the IETF and ICANN. Further discussion
concentrated mainly on which specific further enhancements would be necessary before oras part of the transition.

29

Normal IETF procedures were used to determine rough consensus of the IETF community.
The chairs of the working group reviewed open issues and, after an internal working group
last call, determined that all had been satisfactorily addressed, and subsequently theInternet Engineering Steering Group (IESG) did a formal IETF-wide Last Call followed by aformal review and determined that the document had rough consensus.

B. Completeness and Clarity
30

The ICG discussed the content of each proposal in depth and has published a matrix of
topics discussed.21 With the one exception below, the ICG is satisfied that the proposals arecomplete and clear.

31

The ICG has noted that the names proposal is complete on the condition that thedependencies on ICANN-level accountability mechanisms, currently under development by
the Cross Community Working Group on Enhancing ICANN Accountability (CCWG), arefulfilled as specified in the names proposal. The dependencies are described in detail in
P1.III.A.i and are listed here in abbreviated fashion:
1. ICANN Budget and IANA Budget. The ability for the community to approve or veto the
ICANN budget after it has been approved by the ICANN Board but before it comes into
effect.
2. Community Empowerment Mechanisms. The empowerment of the multistakeholder
community to have the following rights with respect to the ICANN Board:

20 https://www.nro.net/pipermail/crisp/
21 http://www.ianacg.org/icg-files/documents/questions-and-answers-matrix_v4.xlsx

IANA Stewardship Transition Proposal Page 13 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Groupa. The ability to appoint and remove members of the ICANN Board and to recall theentire ICANN Board;b. The ability to exercise oversight with respect to key ICANN Board decisions(including with respect to the ICANN Board’s oversight of the IANA functions) byreviewing and approving (i) ICANN Board decisions with respect torecommendations resulting from an IFR or Special IFR and (ii) the ICANN
budget; andc. The ability to approve amendments to ICANN’s “fundamental bylaws,” asdescribed below.
3. IFR. The creation of an IFR which is empowered to conduct periodic and special reviewsof the IANA functions. IFRs and Special IFRs will be incorporated into the Affirmation ofCommitments mandated reviews set forth in the ICANN Bylaws.
4. CSC. The creation of a CSC which is empowered to monitor the performance of the
IANA functions and escalate non-remediated issues to the ccNSO and GNSO.
5. Separation Process. The empowerment of the Special IFR to determine that aseparation process is necessary and, if so, to recommend that a Separation CrossCommunity Working Group (SCWG) be established to review the identified issues andmake recommendations.
6. Appeal mechanism. An appeal mechanism, for example in the form of an Independent
Review Panel, for issues relating to the IANA functions.
7. Fundamental bylaws. All of the foregoing mechanisms are to be provided for in the
ICANN bylaws as “fundamental bylaws.” A “fundamental bylaw” may only be amended
with the prior approval of the community and may require a higher approval threshold
than typical bylaw amendments (for example, a supermajority vote).
32

Once the CCWG has concluded its work on these mechanisms (estimated to occur prior to
ICANN 54 in October 2015), the ICG will seek confirmation from the CWG that its
requirements have been met. At that point the ICG will make a final determination as towhether it considers the names proposal to be complete.

C. Combined Proposal Assessment
33

Individual assessments were followed by a combined assessment of all the proposals.22 In
conducting its assessment of the combined proposal, the ICG considered the following
questions:
8. Compatibility and interoperability: Do the proposals work together in a single proposal?
Do they suggest any incompatible arrangements where compatibility appears to berequired? Is the handling of any conflicting overlaps between the functions resolved in aworkable manner?
22 https://www.icann.org/en/system/files/files/iana-transition-assembly-finalization-24dec14-

en.pdf.
IANA Stewardship Transition Proposal Page 14 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group

9. Accountability: Do the proposals together include appropriate and properly supported
independent accountability mechanisms for running the IANA function? Are there any
gaps in overall accountability under the single proposal?
10. Workability: Do the results of any tests or evaluations of workability that were included in
the component proposals conflict with each other or raise possible concerns when
considered in combination?

1. Compatibility and Interoperability
34

The ICG identified a potential compatibility issue regarding the IANA trademarks and theiana.org domain name. The numbers community proposed that the trademarks and domainname associated with the provision of the IANA services be held by an entity that is not theprovider of the IANA numbering services, the IETF Trust being suggested as the repository.
Although the protocol parameters proposal did not speak to this issue, in response to an
ICG inquiry the protocol parameters community indicated that it had no objection to the IETF
Trust serving as the repository for the trademarks and domain name associated with theprovision of the IANA services.

35

The names proposal contains text that refers to the trademark in Annex S. In response to an
ICG inquiry about the text, the CWG indicated that the text is clearly defined as placeholder
text (in square brackets) within an initial draft proposed term sheet that does not have theconsensus support of the CWG. In effect, the names proposal does not make a specificproposal with regard to the IANA trademarks (and it is completely silent as regards thedomain name). Thus, the ICG considers the three proposals to be compatible in this regard,as the numbers proposal is the only one of the three proposals that includes requirements
related to IANA intellectual property. As long as the other two communities canaccommodate the specified requirements as part of their implementation, then theimplementation of the proposals will be compatible. The ICG expects the operational
communities to continue to coordinate on this topic during the implementation phase toensure that the requirements are met.

2. Accountability
36

The three proposals together include appropriate and properly supported independentaccountability mechanisms for running the IANA function, relying mostly on the right of each
operational community to select a new entity for the performance of the IANA function.

37

The RIRs and IETF proposals both build on accountability functions that have long been inplace and operate under mostly existing and independent mechanisms which are well
documented and operationally effective.

38

The names proposal is dependent and conditioned on the outcome of Workstream 1 of the
CCWG-Accountability process. The ICG will seek confirmation that the CCWGAccountability final proposal meets the CWG requirements. If the CCWG-Accountability
output does not meet the needs as contemplated by the names proposal, the CWG has
indicated it will revise its proposal. Because of this dependency it is impossible for the ICG
to conclude its assessment of the accountability mechanisms with regards to the names
functions at this time.
IANA Stewardship Transition Proposal Page 15 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group

3. Workability
39

Having been developed by the three operational communities, the three proposals arenaturally different in many respects, reflecting different subject matter, priorities, challenges
and processes involved in their production. However, the ICG regards the three proposals
as individually and collectively workable.

40

Dependency on the successful establishment of the PTI and the implementation of the CWG
accountability requirements exist. The proposals have indicated future ability to change the
IANA functions operator, but have established requirements to help ensure that any such
future changes will not result in operational disruptions.

41

Verisign currently serves as the Root Zone Maintainer and performs the Root Zone
Management functions pursuant to a cooperative agreement with NTIA. Since there iscurrently no written agreement between the Root Zone Maintainer and the IANA functions
operator for the Root Zone Management process, some form of agreement between theseorganizations will be essential when NTIA withdraws from the Root Zone Management
process.

D. NTIA Criteria
42

43

When NTIA announced its intent to transition its stewardship, NTIA established that thetransition proposal must have broad community support and address the following four
principles:Support and enhance the multistakeholder model;

Maintain the security, stability, and resiliency of the Internet DNS;Meet the needs and expectations of the global customers and partners of the IANA
services; and,

Maintain the openness of the Internet.

NTIA also explained that it would not accept a proposal that replaces the NTIA role with agovernment-led or an inter-governmental organization solution.

IANA Stewardship Transition Proposal Page 16 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group

1.

Broad community support

44

The ICG has concluded that each of the individual proposals has broad community support.
As explained in IV.A above, each community ran an open and inclusive process in which
any interested individual was able to participate. Each community produced a consensus
proposal. Together, the openness and inclusiveness of the processes and the consensus
results indicate broad community support.

45

The ICG will make a determination about whether the combined proposal has achieved
broad community support following its solicitation of public comments on the combined
proposal.

2.

Support and enhance the multistakeholder model

46

The ICG has concluded that the combined proposal supports and enhances themultistakeholder model because it leverages existing multistakeholder arrangements,
processes, and paradigms in defining the post-transition IANA oversight and accountability
mechanisms. Each component of the proposal has this feature.

47

The names proposal maintains the existing framework of ICANN for continued
multistakeholder oversight of the IANA functions operation. The proposal reinforces themultistakeholder model by retaining the functional separation between policy development
processes and IANA. The ICANN policy development process remains bottom-up,
transparent, and inclusive of all stakeholders. IANA remains focused on the needs of theoperational communities, with transparent oversight by the CSC and IFR, both of which
include non-ICANN participants and the latter of which is explicitly constituted as amultistakeholder entity.

48

The numbers proposal is based in the existing, long-established RIR structure. The RIRs arewidely regarded as healthy examples of the multistakeholder model. Structurally they are
open, transparent and accountable, not-for-profit organisations, with well-establishedgovernance mechanisms, and open participatory processes for policy development in theirrespective regions. In addition, they and their communities are active participants in andsupporters of multistakeholder processes of ICANN, IGF, and others. Accordingly, thenumbers proposal supports the existing multistakeholder mechanisms of the RIR system,and enhances them (and hence the overall multistakeholder model) by introducing
improvements in transparency and accountability related to the performance of the IANA
numbering functions.

49

The protocol parameters proposal is based in the IETF structure. Participation in the IETF is
open to all individuals regardless of which stakeholder group or sector they may be from.
The proposal supports and enhances the multistakeholder model by relying on IETF
processes and voluntary agreements between IETF and ICANN for the performance of the
IANA functions related to protocol parameters. IETF processes could be used to amend
governance of the protocol parameters function in the future. Anyone may propose
amendments to those processes, and anyone may take part in the decision processes.

IANA Stewardship Transition Proposal Page 17 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group

3.

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

50Neither the numbers proposal nor the protocol parameters proposal suggest changes that
could affect the security, stability, or resiliency of the DNS.

51

While the names proposal calls for the IANA functions operator to be transferred to the PTI,
the PTI will be an affiliate (subsidiary) of ICANN and ICANN will be responsible for the
stewardship of the PTI. Hence operational roles are maintained. The proposal envisages thenames aspect of the current NTIA oversight and contracting authority is transferred to
ICANN. The separation of PTI as a subsidiary will ensure the independence of that oversightrole from the contractor providing the service.

52

This arrangement introduces minimum change and keeps the current IANA functions
operation team intact and carrying out the same role as it has today. Only an organizationalchange is proposed to ensure that the independence of oversight is maintained.

53

Much of this approach is based on the principle of addressing and responding to issues
affecting the provision of the IANA functions operation. The ICG believes that this – ashared commitment to remedy shortfalls in performance – is inherently supportive of the
security, stability and resilience of the provision of the IANA functions operation.

54

The ICG notes that there is ongoing work on developing Service Level Expectations fornames, and that current or proposed expectations already exist for numbers and protocol
parameters. The ongoing work must be completed. Obviously, a failure to develop the
expectations or inability to meet them could be a threat to the security, stability andresilience of the operation of the DNS. However, we expect the ongoing work to lead toclear recommendations regarding the names part before this proposal is sent to NTIA. Clear
expectations are also fundamental to ensuring the healthy operation of the DNS.

55

The ICG notes that, under the current IANA Functions Contract, the DNS Root Zone
Management process currently has three functional roles, i.e., the IANA Functions Operator(IFO), the Root Zone Maintainer (RZM), and the Root Zone Administrator (RZA). The CWG
Stewardship proposal (paragraph 1150) states “Post-transition, no authorization for Root
Zone change requests will be needed.” Thus, the RZA role need not be continued.
However, since there is currently no agreement between the RZM and the IANA functions
operator for the Root Zone Management process, the ICG notes that some form of writtenagreement between the IANA functions operator and RZM that clearly defines the roles andresponsibilities of both parties is essential for the secure, stable and resilient operation of
the Root Zone of the DNS when the NTIA withdraws from the Root Zone Management
process.

IANA Stewardship Transition Proposal Page 18 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Group

4.

Meet the needs and expectations of the global customers and partners of
the IANA services
All three communities determined that the global customers and partners of the IANA
services, including the gTLD and ccTLD registries and their communities of stakeholders;the RIRs; and the IETF are presently satisfied with the performance of the IANA functions by
the IANA department of ICANN. The combined proposal is structured such that the PTI willcontinue to provide the IANA functions to its global customers and partners post-transition inessentially the same manner as ICANN’s IANA department does today. Thus the needs andexpectations of the global customers and partners should continue to be satisfied after thetransition just as they are currently.

56

5.

Maintain the openness of the Internet
The combined proposal requires that the IANA services, associated policy development
processes, and IANA registries remain fully open and accessible just as they are today.

57

6.

Does not replace NTIA role with a government or inter-governmentalorganization

58

The combined proposal does not replace NTIA’s role with a government or intergovernmental organization.

59

The names proposal replaces NTIA’s various roles as they relate to the naming functions
with the combination of ICANN, the CSC, and the IFR, none of which are governments orinter-governmental organizations. Establishing the PTI as an affiliate of ICANN allows thecommunity to rely on ICANN’s accountability mechanisms and safeguards to prevent
capture, including by governments.

60

Although a government that operates a ccTLD may become a member of the CSC,
governments are expected to comprise at most a minority of the CSC. The IFR is amultistakeholder entity with limited membership seats for governmental entities.

61

The numbers proposal essentially places the RIRs in the role currently occupied by the
NTIA. The RIRs are independent, non-governmental, self-funded not-for-profit
organizations, accountable to their regional memberships and communities through welldeveloped mechanisms. On behalf of their communities they will contract with ICANN,
through the proposed SLA, to provide the required number resource services.

62

The protocol parameters proposal relies on voluntary agreements between IETF, ICANN,
implementers and their users for the stewardship of the protocol parameters function.
ICANN’s structural safeguards are noted above; the IETF likewise has significant structuralsafeguards in place that prevent it from capture or take-over by a government or intergovernmental entity. Every decision made in the IETF is done in full public view.
Appointments to the IETF’s leadership committees are time-limited and are made by a
IANA Stewardship Transition Proposal Page 19 of 199

Part 0: Report from the IANA Stewardship Transition Coordination Grouprandomly selected group of volunteers. Any decision can be appealed by any IETF
participant, and anyone in a leadership position can be recalled for their actions. Alldecisions are made by the consensus of the participants – there is no voting or
campaigning. Collectively, these measures defend the IETF and the protocol parameters
registries from capture by any particular entity, governmental or otherwise.

E. ICG Recommendation
After the conclusion of the ICG public comment period and the finalization of CCWG
Workstream 1, the ICG will make a final determination about whether to recommend that
NTIA approve the transition proposal. Based on the outcome of the evaluation describedabove, the ICG is planning to recommend that NTIA approve the transition proposal,
pending the resolution of the outstanding items highlighted in this section.

63

V.

Implementation Items to be Completed

64

The operational communities have indicated that a number of items will need to be
implemented prior to the expiry of the NTIA contract.

65

For the names functions, implementation elements include establishing PTI, the CSC, acontract between PTI and ICANN, a framework to approve changes to the Root Zone
environment and a multistakeholder IFR, as well as ensuring a series of issue resolution
mechanisms and that ICANN accepts input from the multistakeholder community withrespect to the annual IANA operations budget. The CWG proposal requires ICANN
accountability with respect to the ability of the community to approve or veto the ICANN
budget and IANA budget, creating an IFR, a CSC, separation process, appeal mechanismand fundamental bylaws, as well as community empowerment mechanisms to have theability to appoint and remove members of the ICANN Board or the entire ICANN Board, theability to exercise oversight with respect to key ICANN Board decisions, and the ability toapprove amendments to ICANN’s fundamental bylaws. The bylaws changes necessary to
implement all of these items will need to be made prior to the transition.

66

For the numbers functions, the SLA and Review Committee charter are expected to becompleted by September 2015. Some elements described in the numbers community
proposal, such as appointees to the Review Committee, may not be finalized by that time,
but these are not considered prerequisites for the transition. As noted previously, thehandling of the IANA-related IPR is also a pending implementation issue.

67

For the protocol parameters functions, the IETF community has indicated that it is ready forthe transition now. Yet it is possible that further implementation details concerning PostTransition IANA (PTI) or IPR arrangements may lead to additional work at the IETF.

IANA Stewardship Transition Proposal Page 20 of 199

Part 1: Response from the Domain Names Community

Part 1. Response from the Domain Names Community

IANA Stewardship Transition Proposal Page 21 of 199

Part 1: Response from the Domain Names Community

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

GLOSSARY___________________________________________________________ 24

P1. Abstract __________________________________________________________________________________________ 26
P1. Proposal type _____________________________________________________________________________________ 26

P1.I

The Community’s Use of the IANA _______________________________________ 26

P1.I.A. The service or activity ____________________________________________________________________________ 26
P1.I.B. The customer of the service or activity _______________________________________________________________ 27
P1.I.C. Registries involved in providing the service or activity ___________________________________________________ 27
P1.I.D. Overlap or interdependencies between your IANA requirements and the functions required by other customer
communities _________________________________________________________________________________ 27

P1.II Existing Pre-Transition Arrangements ____________________________________ 28
P1.II.A Policy Sources __________________________________________________________________________________ 28
P1.II.A.i. Affected IANA Service (ccTLDs) ___________________________________________________________________ 28
P1.II.A.ii. Affected IANA Service (gTLDs) ___________________________________________________________________ 30
P1.II.B. Oversight and Accountability ______________________________________________________________________ 32
P1.II.B.i Which IANA service or activity is affected (NTIA IANA Functions Contract) __________________________________ 32

P1.III Proposed Post-Transition Oversight and Accountability _____________________ 37
P1.III.A The Elements of This Proposal ____________________________________________________________________ 37
P1.III.A.i. Proposed Post-Transition Structure _____________________________________________________________ 37
Post-Transition IANA (PTI) __________________________________________________________________________ 41
PTI Board _______________________________________________________________________________________ 42
IANA Contract and Statement of Work _________________________________________________________________ 42
IANA Function Review _____________________________________________________________________________ 42
Special IANA Function Review _______________________________________________________________________ 43
P1.III.A.ii. Proposed Oversight & Accountability Replacement ________________________________________________ 44
Customer Standing Committee (CSC) - Overseeing performance of IANA Functions as they relate to naming services __ 44
Service Level Expectations (SLEs)____________________________________________________________________ 45
Escalation Mechanisms ____________________________________________________________________________ 45
Separation Process _______________________________________________________________________________ 46
Framework for Transition to Successor IANA Functions Operator ____________________________________________ 47
P1.III.A.iii Proposed changes to Root Zone environment and relationship with Root Zone Maintainer _________________ 47
Recommendations related to the elimination of NTIA Authorization of changes to the Root Zone content and the associated
WHOIS database _____________________________________________________________________________ 48
Changes to the Root Zone Management Architecture and Operation _________________________________________ 49
Post-Transition ___________________________________________________________________________________ 49
Principles _______________________________________________________________________________________ 50
P1.III.A.iv. Other ____________________________________________________________________________________ 50
ccTLD Delegation Appeals __________________________________________________________________________ 51
IANA Budget _____________________________________________________________________________________ 51
Regulatory and Legal Obligations _____________________________________________________________________ 51
P1.III.B. Implications for the interface between the IANA Functions and existing policy arrangements ___________________ 52

P1.IV Transition Implications _________________________________________________ 52
P1.IV.A. Operational requirements to achieve continuity of service and possible new service integration throughout the transition52
P1.IV.B. Description of any legal framework requirements in the absence of the NTIA contract _________________________ 54
P1.IV.C. Workability of any new technical or operational methods ________________________________________________ 55
P1.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 ______________________________________________________________________ 56

P1.V NTIA Requirements ____________________________________________________ 59
P1.V.A. Support and enhance the multistakeholder model ______________________________________________________ 59
P1.V.B. Maintain the security, stability, and resiliency of the Internet DNS _________________________________________ 59
P1.V.C. Meet the needs and expectation of the global customers and partners of the IANA services _____________________ 60
P1.V.D. Maintain the openness of the Internet _______________________________________________________________ 61
P1.V.E. The proposal must not replace the NTIA role with a government-led or an intergovernmental organization solution ___ 61

IANA Stewardship Transition Proposal Page 22 of 199

Part 1: Response from the Domain Names Community

P1.VI Community Process ___________________________________________________ 62
P1.VI.A. Steps taken to develop the proposal and to determine consensus. ________________________________________ 62
P1.VI.B. Links to announcements, agendas, mailing lists, consultations, and meeting proceedings ______________________ 67
P1.VI.C. Assessment of the level of consensus behind your community’s proposal, including a description of areas of contention
or disagreement ______________________________________________________________________________ 68

The Community’s Use of the IANA Functions – Additional Information _ 70
Oversight Mechanisms in the NTIA IANA Functions Contract _________ 74
Principles and Criteria that Should Underpin Decisions on the Transitionof NTIA Stewardship for Names Functions _________________________ 76
P1. Annex D: Diagram _____________________________________________________ 79
P1. Annex E: IANA Contract Provisions to be Carried Over Post-Transition(Statement of Work) ___________________________________________ 79
P1. Annex F: IANA Function Reviews - Statement of Work Duration and Review
Periodicity ___________________________________________________ 82
P1. Annex G: Proposed Charter of the Customer Standing Committee (CSC) ________ 90
P1. Annex H: Service Level Expectations _____________________________________ 96
P1. Annex I:
IANA Customer Service Complaint Resolution Process for Naming
Related Functions _____________________________________________ 99
P1. Annex J: IANA Problem Resolution Process (for IANA naming services only) __ 101
P1. Annex J-1: Escalation Mechanisms Flow Charts ____________________________ 102
P1. Annex K: Root Zone Emergency Process _________________________________ 105
P1. Annex L: Separation Process ___________________________________________ 108
P1. Annex M: Framework for Transition to Successor IANA Functions Operator ____ 111
P1. Annex O: ccTLD Appeals Mechanism Background and Supporting Findings ___ 114
P1. Annex P: IANA Operations Cost Analysis _________________________________ 120
P1. Annex Q: IANA Budget ________________________________________________ 124
P1. Annex R: Evaluation Method for Implications ______________________________ 126
P1. Annex S: Draft Proposed Term Sheet (as proposed by Legal Counsel) ________ 131
P1. Annex T: ICANN Response to CWG-Stewardship Consultation _______________ 145
P1. Annex A:
P1. Annex B:
P1. Annex C:

IANA Stewardship Transition Proposal Page 23 of 199

Part 1: Response from the Domain Names Community

P1. GLOSSARY
Below are acronyms used throughout the document. Additional useful acronyms have been
provided as they may be referenced in related CWG-Stewardship documents.
 AC: Advisory Committee
 ALAC: At-Large Advisory Committee
 AOC: Affirmation of Commitments
 ASO: Address Supporting Organization
 ccNSO: Country Code Names Supporting Organization
 ccTLD: Country Code Top-Level Domain
 CCWG-Accountability: Cross Community Working Group on Enhancing ICANN
Accountability CO: Contracting Officer
 COR: Contracting Officer’s Representative
 CRISP Team: Consolidated RIR IANA Stewardship Transition Proposal Team
 CSC: Customer Standing Committee
 CSCRP: Customer Service Complaint Resolution Process CWG-Stewardship: Cross Community Working Group to Develop an IANA StewardshipTransition Proposal on Naming Related Functions
 DNS: Domain Name System
 DNSSEC: Domain Name System Security Extensions
 DRDWG: Delegation and Re-delegation Working Group DT: Design Team
 FOIWG: Framework of Interpretation Working Group GAC: Governmental Advisory Committee
 GNSO: Generic Names Supporting Organization
 gTLD: Generic Top-Level Domain
 IANA: Internet Assigned Numbers Authority
 ICANN: Internet Corporation for Assigned Names and Numbers
 ICC: International Chamber of Commerce ICG: IANA Stewardship Transition Coordination Group ICP: Internet Coordination Policy
 IDN: Internationalized Domain Name IETF: Internet Engineering Task Force IFO: IANA Functions Operator
 IFR: IANA Function Review
IANA Stewardship Transition Proposal Page 24 of 199

Part 1: Response from the Domain Names Community

 IFRT: IANA Function Review Team NIST: National Institute of Standards and Technologies
 NTIA: National Telecommunications and Information Administration (U.S. Department ofCommerce) OFAC: U.S. Department of the Treasury’s Office of Foreign Assets Control
 PDP: Policy Development Process
 PTI: Post-Transition IANA
 RFC: Request for Comments
 RFP: Request for Proposals
 RrSG: Registrar Stakeholder Group RIR: Regional Internet Registry
 RSSAC: Root Server System Advisory Committee RySG: Registry Stakeholder Group SCWG: Separation Cross-Community Working Group SLA/SLEs: Service Level Agreement/Service Level Expectations
 SO: Supporting Organization
 SOW: Statement of Work SSAC: Security and Stability Advisory Committee
 TLD: Top-Level Domain

IANA Stewardship Transition Proposal Page 25 of 199

Part 1: Response from the Domain Names Community

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

P1. Abstract

1002

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

1003

Please note that annexes are included at the end of this document.

1004

P1. Proposal type

1005

Identify which category of the IANA Functions this submission proposes to address:[ X ] Names

P1.I
1006

[ ] Numbers[ ] Protocol Parameters

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: A description of the service or activity.
 A description of the customer of the service or activity.
 What registries are involved in providing the service or activity.
 A description of any overlaps or interdependencies between your IANA requirements
and the functions required by other customer communities

1007

P1.I.A.

The service or activity

1008

The IANA activities, as described in the current IANA Functions Contract, relevant to theInternet Naming Community are:
1) Root Zone Change Request Management – not including delegation and redelegation(NTIA IANA Functions Contract: C.2.9.2.a).
2) Root Zone “WHOIS” Change Request and Database Management (NTIA IANA
Functions Contract: C.2.9.2.b).
3) Delegation and Redelegation of a Country Code Top-Level Domain (ccTLD) (NTIA IANA
IANA Stewardship Transition Proposal Page 26 of 199

Part 1: Response from the Domain Names Community

Functions Contract: C.2.9.2.c).
4) Delegation and Redelegation of a Generic Top-Level Domain (gTLD) (NTIA IANA
Functions Contract: C.2.9.2.d).
5) Redelegation and Operation of the .INT Top-Level Domain (NTIA IANA Functions
Contract: C.2.9.4).
6) Root Domain Name System Security Extensions (DNSSEC) Key Management (NTIA
IANA Functions Contract: C.2.9.2.f).
7) Root Zone Automation (NTIA IANA Functions Contract: C.2.9.2.e).
8) Customer Service Complaint Resolution Process (CSCRP) (NTIA IANA Functions
Contract: C.2.9.2.g).
1009

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:
9) Management of the Repository of IDN Practices (IANA service or activity beyond thescope of the IANA Functions Contract).
10) Retirement of the Delegation of TLDs (IANA service or activity beyond the scope of the
IANA functions contract).
11) For further details concerning each of these IANA activities, please see Annex A.

1010

P1.I.B.

The customer of the service or activity

1011

The primary customers of these IANA activities are TLD registry managers, .INT registrants,
Domain Name System (DNS) validating resolver operators. For further details on thecustomer(s) for each activity, please see Annex A.

1012

P1.I.C.

1013

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

1014

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

1015

The IETF, through its responsibilities for developing the underlying DNS protocol and its
extensions, could 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 the evolutionof the underlying DNS protocol and its extensions. It may also expand the scope ofnamespace to be managed through such changes. Additional overlap and/orinterdependencies have been identified for each activity in Annex A.

Registries involved in providing the service or activity

IANA Stewardship Transition Proposal Page 27 of 199

Part 1: Response from the Domain Names Community

P1.II Existing Pre-Transition Arrangements
1016

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

1017

P1.II.A

1018

This section should identify the specific source(s) of policy that 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:

Policy Sources 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.

1019

P1.II.A.i. Affected IANA Service (ccTLDs23)

1020

All functions that apply to Country Code Top-Level Domains (ccTLDs) and modify the Root
Zone database or its WHOIS database are affected.

1021

How policy is developed and established by whom (ccTLDs)

1022

RFC1591 was written in 1994 as a Request For Comments (RFC) by the original IANA
Functions Operator, Jon Postel. It is a short document intended to outline how the Domain
Name System (DNS) 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 Top
Level Domain (TLD) and what was expected of such a manager.

1023

Like all RFCs, this is a static document (RFCs are updated by the issuance of a new
RFC).There have been two significant attempts to revise it so it can be more easily applied
to the current context:
 Internet Coordination Policy 1 (ICP-1).

1024

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

1025

The ICP-1 document was a source of significant friction between ICANN and the ccTLD
community and the Country Code Names Supporting Organization (ccNSO) formallyrejected the ICP-1 document (final report of the ccNSO’s Delegation and Redelegation
Working Group or DRDWG) arguing that it modified policy but did not meet the

23 According to the Fast Track Methodology the rules for delegation and redelegation for ccTLD apply to delegation

and redelegation of IDN ccTLD.

IANA Stewardship Transition Proposal Page 28 of 199

Part 1: Response from the Domain Names Community

requirements for doing so at the time of its introduction in 1999.
 Framework of Interpretation Working Group (FOIWG) Recommendations.
1026

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

1027

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

 GAC Principles and Guidelines for the Delegation and Administration of Country
Code Top Level Domains 2005.
1028

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

1029

Section 1.2 of this document highlights one of the key principles for governments withrespect 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 aninternational 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.

1030

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 inaccordance 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 beenreached, ICANN should act promptly to initiate the process of delegation or redelegationin line with authoritative instructions showing the basis for the decision.
 Local laws applicable to ccTLDs, or Internationalized Domain Names (IDNs)
ccTLDs, associated with a specific country or territory are developed by thegovernments of those countries or territories.

24 Details at https://www.icann.org/resources/pages/bylaws-2012-02-25-en#XI

IANA Stewardship Transition Proposal Page 29 of 199

Part 1: Response from the Domain Names Community

1031

How disputes about policy are resolved (ccTLDs)

1032

Section 3.4 of RFC1591 provided for a dispute resolution mechanism. However, the bodylisted in the document does not currently exist. Most ccTLDs do not have any contracts thatspecify a dispute resolution mechanism with ICANN.

1033

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

1034

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

1035

It is also important to note that local laws applicable to ccTLDs, or IDN ccTLDs, associatedwith 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 competentjurisdiction.

1036

References to documentation of policy development and dispute resolution
processes (ccTLDs)
 RFC1591: https://www.ietf.org/rfc/rfc1591.txt.
 ICP 1: https://www.icann.org/icp/icp-1.htm.
 FOIWG Final Report: http://ccnso.icann.org/workinggroups/foi-final-resolutions-11feb15en.pdf.
 Independent Review Panel (IRP): https://www.icann.org/resources/pages/irp-2012-0225-en.
 ICANN Ombudsman: https://www.icann.org/resources/pages/governance/bylawsen#AnnexB.
 GAC Principles 2005:
https://gacweb.icann.org/download/attachments/28278844/ccTLD_Principles_0.pdf?vers
ion=1&modificationDate=1312385141000&api=v2.

1037

P1.II.A.ii. Affected IANA Service (gTLDs)

1038

Delegation and redelegation of Generic Top-Level Domains (gTLDs).

1039

How policy is developed and established by whom (gTLDs)

1040

The Generic Names Supporting Organization GNSO) is responsible for developing andrecommending to the ICANN Board substantive policies relating to gTLDs. The GNSO
policy development process is a complex and well-described process that would dwarf this
IANA Stewardship Transition Proposal Page 30 of 199

Part 1: Response from the Domain Names Community

document and as such will not be included. Details can be found at:https://www.icann.org/resources/pages/governance/bylaws-en#AnnexA.

1041

How disputes about policy are resolved (gTLDs)

1042

This is a complex and well-described process that would dwarf this document and as such
will not be included. Further details can be found at:
http://newgtlds.icann.org/EN/APPLICANTS/AGB, which outlines the procedures that were
designed with an eye toward timely and efficient dispute resolution. As part of the New
gTLD Program, these Procedures apply to all proceedings administered by each of the
Dispute Resolution Service Providers (DRSP). Each of the DRSPs has a specific set ofrules that will also apply to such proceedings. Furthermore, other ICANN-provided
escalation paths such as the ICANN Ombudsman and the ICANN Bylaws relating to the
Independent Review of ICANN Board Actions (which would only apply to the relevant Board
action) are available.

1043

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.
 Independent Review Panel (IRP): https://www.icann.org/resources/pages/irp-2012-0225-en.
 ICANN Ombudsman: https://www.icann.org/resources/pages/governance/bylawsen#AnnexB.

IANA Stewardship Transition Proposal Page 31 of 199

Part 1: Response from the Domain Names Community

1044

P1.II.B.

Oversight and Accountability

1045This 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 iscurrently 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 areaffected 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 thoseentities.
 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 themechanism rests.

1046

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

1047

For the purposes of this section, oversight and accountability of the IANA Functions
Operator (IFO) refers to independent oversight and accountability. Specifically, oversightand accountability are defined as: Oversight (of the IFO performing Root Zone-related actions and activities): Oversight isperformed by an entity that is independent of the Operator (as defined in the NTIA IANA
Functions Contract) and has access to all relevant information to monitor or approve theactions and activities that are being overseen.
 Accountability: Accountability provides the ability for an independent entity to impose
binding consequences to ensure the IFO meets its formally documented and accepted
agreements, standards, and expectations.

1048

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

1049

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)

1050

These oversight and accountability mechanisms in the NTIA IANA Functions Contract do
not affect the policies listed in Section II.A.

IANA Stewardship Transition Proposal Page 32 of 199

Part 1: Response from the Domain Names Community1051

The entity or entities that provide oversight or perform accountability
functions (NTIA IANA Functions Contract)

1052

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.

1053

A description of the mechanism (NTIA IANA Functions Contract)1054

One of the official accountability mechanisms included in the NTIA IANA Functions Contract
is the ability to cancel or not renew the contract. In addition, there is also a customer
complaint mechanism built into the contract.

1055

Jurisdiction and legal basis of the mechanism NTIA IANA Functions Contract1056

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

1057

Which IANA service or activity is affected (NTIA acting as Root Zone
Management Process Administrator)

1058

NTIA exercises oversight by 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. NTIA can refuse to authorize therequest. It affects all IANA Functions that modify the Root Zone and database or its WHOIS
database.

1059

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)

1060

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

1061

The entity or entities that provide oversight or perform accountability
functions (NTIA acting as Root Zone Management Process Administrator)

1062

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.

1063

A description of the mechanism (NTIA acting as Root Zone Management
Process Administrator)

1064

The accountability is exercised by the NTIA by not approving a change request by IANA for
the Root Zone or its WHOIS database.

IANA Stewardship Transition Proposal Page 33 of 199

Part 1: Response from the Domain Names Community

1065

Jurisdiction and legal basis of the mechanism (NTIA acting as Root Zone
Management Process Administrator)

1066

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

1067

Which IANA service or activity is affected (binding arbitration included in TLD
contracts)

1068

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 thesecontracts provide for binding arbitration of disputes. (The standard gTLD contract language
begins with: “Disputes arising under or in connection with this Agreement that are notresolved pursuant to Section 5.1, including requests for specific performance, will be
resolved through binding arbitration conducted pursuant to the rules of the International
Court of Arbitration of the International Chamber of Commerce.”) All IANA Functions which
modify the Root Zone file or database are affected.

1069

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)

1070

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

1071

The entity or entities that provide oversight or perform accountability
functions (binding arbitration included in TLD contracts)

1072

For most gTLDs the language is:1073

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 theInternational 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, thearbitration will be in front of three arbitrators with each party selecting one arbitrator and thetwo selected arbitrators selecting the third arbitrator.

1074

For the few ccTLDs with a contract, the language relating to this is usually a version of thefollowing:

1075

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.

1076

A description of the mechanism (binding arbitration included in TLD
contracts)
IANA Stewardship Transition Proposal Page 34 of 199

Part 1: Response from the Domain Names Community

1077

The results of the arbitration are binding on both parties.

1078

Jurisdiction and legal basis of the mechanism (binding arbitration included in
TLD contracts)

1079

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

1080

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 identifies the lawthat will be relevant in evaluating each party’s actions, such as the law of the country inwhich the ccTLD is operated for ccTLDs, and the laws of California for ICANN’s actions.

1081

Which IANA service or activity is affected (applicability of local law for theadministration by the IANA Functions Operator of ccTLDs associated with a
specific country or territory (ccTLDs))

1082

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

1083

As such, Section 1.7 of the GAC Principles 2005 clearly sets the stage for such oversight bygovernments:
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 domainname.” Any such involvement should be based on appropriate national laws andpolicies. It is recommended that governments should work with their local Internet
community in deciding on how to work with the ccTLD Registry.

1084

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

1085

The IFO currently seeks government approval for all ccTLD delegations and redelegations.

1086

ccTLD delegations and redelegations are affected.

1087

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 theadministration by the IANA Functions Operator of ccTLDs associated with a
specific country or territory (ccTLDs)

1088

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

IANA Stewardship Transition Proposal Page 35 of 199

Part 1: Response from the Domain Names Community1089

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

1090

Local law should prevail unless the decision has a global impact.

1091

A description of the mechanism (applicability of local law for theadministration by the IANA Functions Operator of ccTLDs associated with a
specific country or territory (ccTLDs)

1092

Variable depending on the specific government.

1093

Jurisdiction and legal basis of the mechanism (applicability of local law for theadministration by the IANA Functions Operator of ccTLDs associated with a
specific country or territory (ccTLDs)

1094

Jurisdiction lies in that of the country or territory concerned.

IANA Stewardship Transition Proposal Page 36 of 199

Part 1: Response from the Domain Names Community

P1.III Proposed Post-Transition Oversight and Accountability
1095This section should describe what changes your community is proposing to thearrangements 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 newarrangements. Your community should provide its rationale and justification for the newarrangements. If your community's proposal carries any implications for existing policy
arrangements described in Section II.A, those implications should be described here. If yourcommunity is not proposing changes to arrangements listed in Section II.B, the rationale
and justification for that choice should be provided here.

1096

P1.III.A

1097

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 theseeffects. In summary, the CWG-Stewardship recommends:

The Elements of This Proposal

 A new, separate legal entity, Post-Transition IANA (PTI), will be formed as an affiliate of
ICANN. The existing IANA functions, administrative staff, and related resources,
processes, data, and know-how will be legally transferred to PTI.
 ICANN will enter into a contract with PTI, granting PTI the rights and obligations to serveas the IANA Functions Operator (IFO) for the naming functions, and setting forth therights and obligations of ICANN and PTI. This contract will also include service levelagreements for the naming functions.
 Changes proposed to Root Zone environment and relationship with Root Zone
Maintainer.

1098

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

1099

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

1100

P1.III.A.i. Proposed Post-Transition Structure1101

The objective of Section III is to present the changes required to replace the oversight andaccountability performed by the NTIA via the NTIA IANA Functions Contract and NTIA’s roleas Root Zone Management Process Administrator for the naming functions.

1102

Specifically, the oversight and accountability roles of the NTIA include the following: In relation to the IANA Functions Contract:
 Contract process including selection of operator and cancellation of the contract(accountability).
 Formal definition of the requirements and expectations of IANA by the NTIA –IANA Stewardship Transition Proposal Page 37 of 199

Part 1: Response from the Domain Names Community

statement of work (oversight).
 Establishment and external monitoring of quality control and performance
evaluation mechanisms (oversight and transparency).
 Issue resolution (accountability).
 In relation to NTIA’s role as Root Zone Management Process Administrator:
 Approval of all changes to the content of the Root Zone (oversight andaccountability).
 Approval of all changes to the Root Zone environment, such as theimplementation of DNSSEC (oversight and accountability).
 Approval of all external communications and reporting by IANA to external
parties (oversight and accountability).

1103

The public consultation on the CWG-Stewardship’s initial transition proposal of 1 December
2014 confirmed that the respondents were satisfied with the current performance of ICANN
as the IFO. Therefore, any new arrangements should maintain ICANN as the IFO at thetime of transition and seek to implement mechanisms designed to provide similarly effective
oversight and accountability (as those currently in place), minimize complexity and costs
and maintain the security, stability, and resiliency of the DNS and the Internet. The public
consultation on the CWG-Stewardship’s second draft proposal in April-May 2015 confirmed
broad support for PTI and related structures, such as the IANA Function Review (IFR) andCustomer Standing Committee (CSC). The CWG-Stewardship reviewed all input received
and has updated the proposal accordingly.25

1104

In order to meet community expectations for the stewardship of the IANA Functions related
to naming, the CWG-Stewardship, working on the premise that there is current satisfaction
with ICANN’s IANA department performance and that ICANN should remain the IANA
Functions Operator, agreed that a satisfactory transition proposal for the names community
requires the following elements:
 A contract similar to the current NTIA IANA Functions Contract to perform the IANA
names functions post-transition; The ability for the multistakeholder community to ensure that ICANN acts according tocommunity requests with respect to IANA names operations; Additional insulation, as needed, between operational and policymaking responsibilities
and protections for the IFO;
 A mechanism to approve changes to the Root Zone environment (with NTIA no longer
providing an approval process);
 The ability to ensure that the IANA Functions are adequately funded by ICANN;
 The ability for the multistakeholder community to require, and if necessary after
substantial opportunities for remediation, the selection of a new operator for the IANA
Functions as they relate to names.

25 See public comment review tool (https://community.icann.org/x/x5o0Aw), which categorizes all the input received

according the sections of the proposal and responses to each of these comments from the CWG-Stewardship.

IANA Stewardship Transition Proposal Page 38 of 199

Part 1: Response from the Domain Names Community

1105

While this proposal originates from within the names community, it anticipates that, forreasons of coherence of the IANA function and overall operational logistics, all of the IANA
functions will be transferred to PTI. However, it is not clear at the time of writing whether theother operational communities will undertake to contract directly with PTI (similar to themanner in which this response envisages ICANN will do), or whether those communities will
have a contract with ICANN. If the other operational communities contract directly with PTI,
then those communities will need to determine the terms of their contract with PTI for the
support of their respective functions. On the other hand, if the other operational communities
enter into a contract with ICANN, then ICANN will need to subcontract the performance ofthe functions to PTI. Which of these approaches is followed by the other operational
communities is not relevant for the purposes of the present proposal, so long as thosedetails are not inconsistent with this proposal. In any case, the arrangements for the nonnames IANA functions are out of scope for this document except to the extent they impinge
directly on the names functions. The CWG-Stewardship has also agreed that approval of allchanges to the content of the Root Zone will no longer need authorization (as is currently
the case) and that external communications and reporting will no longer need external
approval post-transition. This final proposal attempts to meet all of the above requirementsby: Creating PTI, a separate legal entity that will be an affiliate26 controlled by ICANN27. The
creation of PTI ensures both functional and legal separation within the ICANN
organization.
 Establishing a contract between PTI and ICANN that will grant PTI the rights to act as
the IFO, and set out the rights and obligations of PTI and ICANN.
 Establishing the CSC that is responsible for monitoring IFO performance according tocontractual requirements and service level expectations, resolving issues directly with
the IFO or escalating them if they cannot be resolved.28
 Establishing a series of issue resolution mechanisms to ensure that problems areresolved effectively.
 Ensuring ICANN accepts input from the multistakeholder community with respect to theannual IANA operations budget.
 Establishing a framework to approve changes to the Root Zone environment (with NTIA
no longer providing oversight).
 Establishing a multistakeholder IANA Function Review (IFR) to conduct periodic andspecial reviews of PTI.29 The results of the IFR will not be prescribed or restricted andcould include recommendations to initiate a separation process (as described below),which could result in termination or non-renewal of the ICANN-PTI IANA functions
contract among other actions.

26 An affiliate of an entity means another entity that directly or indirectly controls, is controlled by, or is under common

control with the first entity. For example, a parent and its subsidiaries are affiliates because the parent controls thesubsidiaries; and two subsidiaries with a common parent are affiliates because the two subsidiaries are undercommon control by the parent.
27 Based on independent legal advice received, the CWG-Stewardship proposes that PTI will be an affiliate in theform of a California public benefit corporation with a single member and that member will be ICANN, with a Board
comprising a majority of PTI Board members appointed by ICANN.
28
The CSC is not a separate legal entity. The CSC would be authorized by the ICANN governance documents(including the ICANN Bylaws) and the ICANN-PTI Contract.
29 The IANA Function Review (IFR) would be convened periodically (first review two years after the transition iscomplete, and thereafter at intervals of no more than five years). It could also be convened for a special review undercertain circumstances further described in the escalation mechanisms section below. The review would be authorized
by ICANN’s governance documents (including the ICANN Bylaws) and referenced in the ICANN-PTI Contract.

IANA Stewardship Transition Proposal Page 39 of 199

Part 1: Response from the Domain Names Community

1106

The CWG-Stewardship proposal is significantly dependent and expressly conditioned on theimplementation of ICANN-level accountability mechanisms by the Cross Community
Working Group on Enhancing ICANN Accountability (CCWG-Accountability) as described
below. The co-chairs of the CWG-Stewardship and the CCWG-Accountability havecoordinated their efforts and the CWG-Stewardship is confident that the CCWGAccountability recommendations, if implemented as envisaged, will meet the requirementsthat the CWG-Stewardship has previously communicated to the CCWG. If any element ofthese ICANN level accountability mechanisms is not implemented as contemplated by the
CWG-Stewardship proposal, this CWG-Stewardship proposal will require revision.
Specifically, the proposed legal structure and overall CWG-Stewardship proposal requires
ICANN accountability in the following respects:
1. ICANN Budget and IANA Budget. The ability for the community to approve or veto the
ICANN budget after it has been approved by the ICANN Board but before it comes
into effect. The community may reject the ICANN Budget based on perceived
inconsistency with the purpose, mission and role set forth in ICANN’s Articles andBylaws, the global public interest, the needs of ICANN stakeholders, financial
stability or other matters of concern to the community. The CWG-Stewardshiprecommends that the IFO’s comprehensive costs should be transparent and
ICANN’s operating plans and budget should include itemization of all IANA
operations costs to the project level and below as needed. An itemization of IANA
costs would include “Direct Costs for the IANA department”, “Direct Costs for Sharedresources” and “Support functions allocation”. Furthermore, these costs should beitemized into more specific costs related to each specific function to the project leveland below as needed. PTI should also have a yearly budget that is reviewed andapproved by the ICANN community on an annual basis. PTI should submit a budget
to ICANN at least nine months in advance of the fiscal year to ensure the stability of
the IANA services. It is the view of the CWG-Stewardship that the IANA budget
should be approved by the ICANN Board in a much earlier timeframe than theoverall ICANN budget. The CWG (or a successor implementation group) will need todevelop a proposed process for the IANA-specific budget review, which may
become a component of the overall budget review.
2. Community Empowerment Mechanisms. The empowerment of the multistakeholder
community to have the following rights with respect to the ICANN Board, theexercise of which should be ensured by the related creation of a stakeholder
community / member group:(a) The ability to appoint and remove members of the ICANN Board and to recall theentire ICANN Board;(b) The ability to exercise oversight with respect to key ICANN Board decisions(including with respect to the ICANN Board’s oversight of the IANA
functions) by reviewing and approving (i) ICANN Board decisions withrespect to recommendations resulting from an IFR or Special IFR and (ii)the ICANN budget; and(c) The ability to approve amendments to ICANN’s “fundamental bylaws,” asdescribed below.

IANA Stewardship Transition Proposal Page 40 of 199

Part 1: Response from the Domain Names Community

3. IFR. The creation of an IFR which is empowered to conduct periodic and special reviewsof the IANA functions (see Annex F). IFRs and Special IFRs will be incorporated into
the Affirmation of Commitments mandated reviews set forth in the ICANN Bylaws.
4. CSC. The creation of a CSC which is empowered to monitor the performance of the
IANA functions and escalate non-remediated issues to the ccNSO and GNSO. The
ccNSO and GNSO should be empowered to address matters escalated by the CSC.
5. Separation Process. The empowerment of the Special IFR to determine that aseparation process is necessary and, if so, to recommend that a Separation CrossCommunity Working Group (SCWG) be established to review the identified issues
and make recommendations. See Annex L for more detailed information as toapproval requirements with respect to the formation of a SCWG and approval of
SCWG recommendations.
6. Appeal mechanism. An appeal mechanism, for example in the form of an Independent
Review Panel, for issues relating to the IANA functions. For example, direct
customers with non-remediated issues or matters referred by ccNSO or GNSO after
escalation by the CSC will have access to an Independent Review Panel. The
appeal mechanism will not cover issues relating to ccTLD delegation and redelegation, which mechanism is to be developed by the ccTLD community posttransition.
7. Fundamental bylaws. All of the foregoing mechanisms are to be provided for in the
ICANN bylaws as “fundamental bylaws.” A “fundamental bylaw” may only beamended with the prior approval of the community and may require a higher
approval threshold than typical bylaw amendments (for example, a supermajorityvote).

1107

Post-Transition IANA (PTI)

1108

In order to identify and isolate the IANA naming functions, both functionally and legally, fromthe ICANN entity, the CWG-Stewardship recommends the creation of a Post-Transition
IANA (PTI). PTI will be a new legal entity in the form of a non-profit corporation (i.e., a
California public benefit corporation). The existing IANA functions department,
administrative staff, and related resources, processes, data, and know-how will be legallytransferred to PTI.30 No further transfer of assets from PTI to another entity will be allowed
unless specifically approved by ICANN.

1109

At the outset, PTI will have ICANN as its sole member and PTI will therefore be a controlled
affiliate of ICANN. ICANN will provide funding and administrative resources to PTI throughan agreed-upon budget.

1110

A contract will be entered into between PTI and ICANN, which will grant PTI the rights to act
as the IFO and set out rights and obligations of PTI and ICANN. The contract will provide for
automatic renewal, subject to potential non-renewal by ICANN if recommended by the IANA
Function Review (see further details below).

30 In the case of any existing ICANN contracts, MoUs or other arrangements that relate to the IANA functions, these

could be assigned to and assumed by PTI, replaced by new arrangements at the PTI level or remain at ICANN with asubcontract to PTI.

IANA Stewardship Transition Proposal Page 41 of 199

Part 1: Response from the Domain Names Community

1111

PTI Board1112

As a separate legal entity, PTI will have a board of directors and have the minimum
statutorily required responsibilities and powers. The construct of the PTI Board will be arange of 3-5 people to be appointed by ICANN as the sole member of PTI. The PTI Board
could be comprised of three directors who are employed by ICANN or PTI (for example, theICANN Executive responsible for PTI, the ICANN CTO and the IANA Managing Director),and two additional independent directors. The two additional directors must be nominatedusing an appropriately rigorous nomination mechanism (e.g. through the use of the ICANN
Nominating Committee). The CWG-Stewardship expects that this will avoid the need toreplicate the complexity of the multistakeholder ICANN Board at the PTI level and maintain
primary accountability at the ICANN level. Any issues that arise concerning the PTI and the
PTI Board will therefore be able to be ultimately addressed through the overarching ICANN
accountability mechanisms.31

1113

The function of the PTI Board is to provide oversight of the operations of PTI in order to toensure that PTI meets, at a minimum, applicable statutory requirements under California
public benefit corporation laws and, importantly, fulfills its responsibilities under the IANA
functions contract with ICANN.

1114

The CWG-Stewardship recommends that the PTI Board skill set be evaluated as a wholeand not on a per member basis, while also ensuring that each individual member is suitable
and appropriately qualified to serve as a director of PTI in his or her own right. Accordingly,
the PTI Board’s complete skill set should be balanced and cover an appropriate andcomplete composite of executive management, operational, technical, financial andcorporate governance experience.

1115

IANA Contract and Statement of Work1116

The issues currently addressed in the NTIA ICANN Functions Contract and related
documents will be addressed in the ICANN-PTI IANA functions contract. Furthermore, theCWG-Stewardship expects that a number of existing provisions of the NTIA IANA Functions
Contract will be carried over to the PTI Contract in the form of a Statement of Work (SOW),
taking into account updates that will need to be made as a result of the changing
relationship between IANA and ICANN as well as other recommendations outlined in
Section III. In order for the community to have confidence in the robust and complete natureof the ICANN-PTI IANA Functions Contract, it is recommended that PTI have independent
legal counsel to advise on the contract. The ICANN bylaws will reference the need for
periodic and special review of the IANA Statement of Work through the IFR. An overview ofprovisions expected to be carried over into the ICANN-PTI IANA functions contract can befound in Annex E as well as Annex S which includes a draft proposed term sheet.

1117

IANA Function Review

1118

The CWG-Stewardship recommends an IANA Function Review (IFR), which will review
PTI’s performance against the ICANN-PTI Contract and the SOW. The IFR will be obliged totake into account multiple input sources including community comments, CSC evaluations,
reports submitted by PTI, and recommendations for technical or process improvements (seeCustomer Standing Committee section below). The outcomes of reports submitted to the
CSC, and reviews and comments received on these reports during the relevant time period

31 CCWG-Accountability Dependency – see https://community.icann.org/x/TSYnAw

IANA Stewardship Transition Proposal Page 42 of 199

Part 1: Response from the Domain Names Community

will be included as input to the IFR. The IFR will also review the SOW to determine if any
amendments should be recommended. The IFR mandate is strictly limited to evaluation of
PTI performance against the SOW and does not include any evaluation relating to policy orcontracting issues that are not part of the ICANN-PTI IANA functions contract or the
SOW. In particular it does not include issues related to policy development and adoption
processes, or contract enforcement measures between contracted registries and ICANN.
1119

The first IFR is recommended to take place no more than two years after the transition iscomplete. After the initial review, the periodic IFR should occur at intervals of no more than
five years. The IFR should be set out in the ICANN Bylaws and included as a “fundamental
bylaw” resulting from the work of the CCWG-Accountability and will operate in a manner
analogous to an Affirmation of Commitments (AoC) review. The “fundamental bylaws” will
be ICANN bylaws that will require the prior approval of the multistakeholder community toadopt or amend. The approval of an ICANN fundamental bylaw could also require a higher
threshold than typical bylaw amendments, for example, a supermajority. The members of
the IANA Function Review Team (IFRT) will be selected by the Supporting Organizations
and Advisory Committees and will include several liaisons from other communities. While
the IFRT is intended to be a smaller group, it will be open to non-member “participants” inmuch the same way as the CWG-Stewardship is.

1120

While the IFR will normally be scheduled based on a regular cycle of no more than five
years32 in line with other ICANN reviews, a Special IANA Function Review (Special IFR)
may also be initiated under certain circumstances, as discussed in the following section.

1121

For further details, please see Annex F.

1122

Special IANA Function Review

1123

As mentioned above, IFRs will occur periodically or, in special circumstances, may beinitiated outside of the normal periodic schedule. A non-periodic or “Special” IANA Function
Review (Special IFR) could only be initiated when the following escalation mechanisms andmethods have been exhausted: CSC Remedial Action Procedures are followed and fail to correct the identified
deficiency (see Annex G); and The IANA Problem Resolution Process is followed and fails to correct the identified
deficiency (see Annex J).

1124

For further details, please see Annex F.

1125

Following the exhaustion of the above escalation mechanisms, the ccNSO and GNSO will
be responsible for checking and reviewing the outcome of the CSC process (as defined in
Annex G), and the IANA Problem Resolution Process (as defined in Annex J) and for
determining whether or not a Special IFR is necessary. After consideration, which may
include a public comment period and must include meaningful consultation with other
SO/ACs, the Special IFR could be triggered. In order to trigger a Special IFR, it would
require a vote of both of the ccNSO and GNSO Councils (each by a supermajority voteaccording to their normal procedures for determining supermajority). The Special IFR will
follow the same multistakeholder cross community composition and process structure as the

32 If a Special IFR is initiated, some flexibility with regard to the pragmatic use of community resources should beallowed with regards to the timing of the next IFR.

IANA Stewardship Transition Proposal Page 43 of 199

Part 1: Response from the Domain Names Community

periodic IANA Function Review.The scope of the Special IFR will be narrower than aperiodic IFR, focused primarily on the identified deficiency or problem, its implications foroverall IANA performance, and how that issue is best resolved. As with the periodic IFR, theSpecial IFR is limited to a review of the performance of the IANA Functions operation,
including the CSC, but should not consider policy development and adoption processes or
the relationship between ICANN and its contracted TLDs.
1126

There is no prescribed outcome for an IFR, whether special or periodic. Recommendations
could span from “no action required” to the introduction of operational remediation
requirements, to the initiation of a separation process, described below. In the case of aSpecial IFR, it is expected that the recommendations of the IFRT will describe how the
proposed remedial procedures are expected to address the identified deficiency.

1127

As described in Annex L, an IFR may determine that a separation process is necessary. In
making this determination, the IFR is not responsible for recommending a type of
separation. If the IFR determines that a separation process is necessary, it will recommend
the creation of the Separation Cross-Community Working Group (SCWG). This
recommendation will need to be approved by both of the ccNSO and GNSO Councils (eachby a supermajority vote,according to their normal procedures for determining supermajority),
and will need to be approved by the ICANN Board after a public comment period, as well as
a community mechanism derived from the CCWG-Accountability process.33 A determinationby the ICANN Board to not approve an SCWG that had been supported by a supermajorityof the ccNSO and GNSO Councils will need to follow the same supermajority thresholds
and consultation procedures as ICANN Board rejection (by a supermajority vote) of a PDP
recommendation that is supported by a GNSO supermajority.

1128

P1.III.A.ii. Proposed Oversight & Accountability Replacement

1129

Customer Standing Committee (CSC) - Overseeing performance of IANA
Functions as they relate to naming services

1130

The CWG-Stewardship recommends the creation of a CSC to monitor the performance of
PTI with the following mission:“The Customer Standing Committee (CSC) has been established to perform theoperational oversight previously performed by the U.S. Department of Commerce’s
National Telecommunications and Information Administration as it relates to themonitoring 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 thenaming services are TLD registry operators, but also include root server operators andother non-root zone functions.
The mission will be achieved through regular monitoring by the CSC of the performanceof the IANA naming function against agreed service level targets and through33 This community mechanism could include ICANN membership, if ICANN were to become a membershiporganization per the CCWG-Accountability work efforts.

IANA Stewardship Transition Proposal Page 44 of 199

Part 1: Response from the Domain Names Community

mechanisms to engage with the IANA Functions Operator to remedy identified areas ofconcern.”
1131

The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special
IANA Function Review, but could escalate to the ccNSO and GNSO Councils or either bodyin the specific case where the issue in question applies only to ccTLDs or gTLDs
respectively, which might then decide to take further action using agreed consultation andescalation processes (see Annex J).

1132

The complete proposed charter of the CSC can be found in Annex G.

1133

Service Level Expectations (SLEs)

1134

The CWG-Stewardship reviewed the performance standards established under the IANA
contract between NTIA and ICANN and considered these inadequate for a registry serviceof such global importance. In light of the cessation of NTIA’s independent stewardship andauthorization role, it is an appropriate time for customers to re-evaluate the current minimum
acceptable service levels, reporting requirements and breach levels.

1135

The CWG-Stewardship is not proposing any changes to the current work flow process.

1136

The CWG-Stewardship is suggesting that there is a requirement placed on IANA staff, (aspart of the implementation phase) to measure, record and report additional details oftransaction times for each Root Zone Management process. Such transparency will provide
factual information to assist the CSC, IFRT and the Community to determine and confirm
that IANA Functions Operator is continuing to provide non-discriminatory service to thenaming community.

1137

The CWG-Stewardship also proposes a set of guiding principles that will help define theexpectation for the monitoring and reporting environment, and guide the definition of theindividual criteria used for reporting and assessment of the naming-related portions of the
IANA Functions. Work to define the final SLEs will be on-going in order to be included withthe proposal submitted to the NTIA and will be run in parallel with the ICG process to review
the CWG-Stewardship proposal. The objective is to ensure that the naming proposal is notdelayed by work to define the SLEs and so to optimize use of the time prior to the final
submission of a proposal to the NTIA.

1138

For further details, please see Annex H.

1139

Escalation Mechanisms

1140

The CWG-Stewardship recommends requiring the continuation, with minor modifications, ofa progressive set of escalation steps that can be performed for emergency situations as wellas customer service complaints and a new problem resolution process, as applicable, forindividual TLD registry operators, or others with relevant IANA Functions operational issues.
Three processes are recommended:34
1) Customer Service Complaint Resolution Process

34 Note, nothing in these processes prevents a TLD operator to pursue other applicable legal recourses that may beavailable.

IANA Stewardship Transition Proposal Page 45 of 199

Part 1: Response from the Domain Names Community

This process is for anyone who has a complaint about IANA services.35 The CWGStewardship has modified the current process used by ICANN by adding some steps at
the end. For further details, please see Annex I.
2) IANA Problem Resolution Process (for IANA naming services only)This is a new process created for persistent performance issues or systemic problems
associated with the provision of IANA naming services.36 For further details, please see
Annex J.
3) Root Zone Emergency ProcessThis 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.
1141

The details of these processes, including proposed modifications to the existing processes
to reflect the transition, can be found in Annexes I (IANA Customer Service Complaint
Resolution Process), J (Problem Resolution Process (for IANA naming services only)) and K(Root Zone Emergency Process). Furthermore a flow chart outlining the different steps andrelationship between the Customer Service Complaint Resolution Process and the IANA
Problem Resolution Process can be found in Annex J-1.

1142

Separation Process
The CWG-Stewardship recommends that an ICANN fundamental bylaw be created to define
a separation process that can be triggered by a Special IFR if needed. The Special IFR will
only occur if other escalation mechanisms and methods have been exhausted. If the Special
IFR recommends a separation process, a Separation Cross Community Working Group(SCWG) which will be formed to review the issues and make recommendations. The
recommendations of a Special IFR will need to be approved by a supermajority vote of eachof the ccNSO and GNSO Councils, the ICANN Board, and a community mechanism derived
from the CCWG-Accountability process before they can be moved to implementation.37 Any
new IFO (or other separation process) will be subject to the approval of the ICANN Board,and a community mechanism derived from the CCWG-Accountability process.38
There will be no prescribed result arising from the separation process. The SCWG will beempowered to make a recommendation ranging from “no action required” to the initiation ofan RFP and the recommendation for a new IFO, or the divestiture or reorganization of PTI.
In the case of a recommendation for any action, ICANN is expected to cover all costs i.e.
costs related to the then transition, costs related to the possible selection of a new IFO andthe ongoing operating costs of the successor operator. Moreover, in bearing such costs, it is
to be required of ICANN that it does not raise fees from TLD operators (registries, registrars
and, indirectly, for registrants) in order to do so.

1143

For further details please see Annex L.

35 This process exists today for all IANA services, but the CWG-Stewardship changes intend to apply only to the

IANA naming services.
36 It is beyond the scope of the CWG-Stewardship to propose processes that affect other IANA services customers(protocol parameters and numbers). However, should there be an interest in expanding this process to include thosecustomers, those discussions could be held at a later date.
37 This community mechanism could include ICANN membership, if ICANN were to become a membershiporganization per the CCWG-Accountability work efforts.
38 This community mechanism could include ICANN membership, if ICANN were to become a membershiporganization per the CCWG-Accountability work efforts.

IANA Stewardship Transition Proposal Page 46 of 199

Part 1: Response from the Domain Names Community

1144

Framework for Transition to Successor IANA Functions Operator

1145

The CWG-Stewardship recommends the continuation of the current transition framework for
the IANA Functions, with relevant modifications, should it be, for whatever reason,
necessary for the IANA Functions to be transitioned from the incumbent IFO to a successor
IFO. This framework will be set forth in the ICANN-PTI Contract and will be based upon thecurrent 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 andcontinuity of operations planning.39 This is a framework only and it is expected – as per thefollowing recommendations – that a full plan will be developed post-IANA StewardshipTransition. The principles and recommendations for the future evolution of the Framework
for Transition to Successor IANA Functions 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 be further developed and maintained by PTI, with ICANN
input, into a detailed, fully functional, transition plan within 18 months from thecompletion of the IANA Stewardship Transition.
3) The budget for IANA operations should be augmented with specific funding for thedetailed transition plan development referred to in 2 (above).
4) The process established for the potential transitioning of the IANA Functions to an
operator other than the incumbent should specifically recognize that the detailedtransition plan referred to in 2 (above) 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 tofacilitate a stable transition of the IANA Functions.
6) Once developed, the full Transition to Successor IANA Functions Operator Plan should
be reviewed every year by IANA staff, in conjunction with the CSC/Community asnecessary, to ensure that it remains up to date, and reviewed every five years to ensurethat it remains fit for purpose.

1146

For further information, see Annex M.

1147

P1.III.A.iii Proposed changes to Root Zone environment and relationship with
Root Zone Maintainer

1148

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

39 The CWG-Stewardship notes that the ICANN Contingency and Continuity of Operations Plan (CCOP) was not able

to be released as requested through the DIDP process due to security and stability related concerns.

IANA Stewardship Transition Proposal Page 47 of 199

Part 1: Response from the Domain Names Community

1149

Recommendations related to the elimination of NTIA Authorization of changes
to the Root Zone content and the associated WHOIS database

1150

Currently, changes to the Root Zone File, as well as changes to the Root Zone WHOIS
Database, are transmitted to the NTIA for authorization. Such changes cannot be enacted
without explicit positive authorization from the NTIA. Post-transition, no authorization for
Root Zone change requests will be needed.
1) Changes will be required to the IFO and Root Zone Maintainer software to remove thisrequirement. In the very short term, if making the software changes cannot becompleted before the transition and/or to avoid multiple coincident changes, the existing
software could be used and IANA staff could authorize the changes (effectively fulfillingthe current role of the NTIA at this point in the process).
2) Currently there is a Cooperative Agreement between the NTIA and the Root Zone
Maintainer. The NTIA has said that there will be a parallel but separate transition todisengage the NTIA from the Root Zone Maintainer. The exact form of this transition is
not currently known, nor what, if anything, will replace the current Cooperative
Agreement and the parties involved in providing the services currently covered under
the Cooperative Agreement.
a) If that transition is not completed prior to the IANA Stewardship Transition, theCooperative 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 IFO without requiring approval from NTIA.
b) If the Root Zone Maintainer transition is completed prior to, or in conjunction with,
the IANA Stewardship Transition, the new arrangements must provide a clear andeffective mechanism to ensure that PTI can have its change requests for the Root
Zone implemented in a timely manner by the Root Zone Maintainer (possibly via anagreement between the Root Zone Maintainer and the IFO).
3) It should be determined whether or not additional checks/balances/verifications are
required post transition. The CWG-Stewardship recommends that a formal study be
undertaken post transition to investigate whether there is a need to increase (and if so,how) the robustness of the operational arrangements for making changes to the Root
Zone content to reduce or eliminate single points of failure.40 This study should include arisk analysis and cost/benefit analysis factoring in the history and possibility of suchproblems. Any new procedures/processes should be designed to minimize:a) The potential for accidental or malicious changes or omissions by the IFO or Root
Zone Maintainer.
b) The potential for out-of-policy changes by the IFO. The term “policy” is used in its
most general sense, representing formal Policy adopted by ICANN as well as
established standards, practices, and processes.
c) The potential for accidental or malicious errors in the communications path from the
IFO to the Root Zone Maintainer.

40 If this recommendation is approved, the estimated costs for the study should be added to the PTI budget for theperiod(s) in which it will be performed.

IANA Stewardship Transition Proposal Page 48 of 199

Part 1: Response from the Domain Names Communityd) The potential for accidental outages or malicious actions related to thetelecommunications infrastructure serving the IFO and the Root Zone Maintainer.
Such outages or actions could be related to the infrastructure shared with ICANN.
1151

Any changes to procedures or processes should be based on a cost/benefit and risk
analysis factoring in the history and possibility of such problems. The review should involve
all parties that may be affected or impacted by any changes to be implemented.

1152

Changes to the Root Zone Management Architecture and Operation

1153

Per the NTIA IANA Functions Contract, NTIA approval was required for the implementationof all changes to the Root Zone environment such as DNSSEC as well as many classes ofchanges to IANA Functions Operator processes (including what may be published). The
NTIA has contributed and opened avenues to resources (such as those from NIST – theNational Institute of Standards and Technologies, a part of the U.S. Department ofCommerce in efforts surrounding DNSSEC). Moreover as the Root Zone Administrator, they
have been the entity to ultimately approve the changes going forward.

1154

Post-Transition

1155

The CWG-Stewardship recommends that a replacement of this approval function be put inplace for significant architectural and operational changes. Although it is clear that the DNSrelated technical and operational communities have both the technology skills andappropriate incentives to make prudent and cautious changes, the critical nature of the Root
Zone makes it necessary to formalize approval of major architectural and operationalchanges.
1) Formal approval to proceed with a change shall be granted by the ICANN Board.
2) The Board shall grant approval on the recommendation of a standing committee with aproposed membership of: an ICANN Board member (possibly as Chair), a senior IANA
Functions Operator administrator or delegate, and Chairs or delegates of the SSAC,RSSAC, ASO and IETF,41 a representative of the GNSO RySG, a representative of the
ccNSO and a representative of the Root Zone Maintainer. The standing committee will
select its chair. The RySG and ccNSO representatives will ensure appropriate
communications with the CSC.
3) The standing committee will not necessarily be the group that considers the details of
the issue under consideration, but it will be responsible for ensuring that those involvedin the decision include all relevant bodies and have access to necessary expertise.
4) Issues may be brought to the standing committee’s attention by any of its members, by
PTI staff, or by the CSC.
5) For architectural changes that impose potential risk to the security, stability, or resiliencyof the Root system (as identified by at least one standing committee member andagreed by a simple majority of members), there should be public consultation throughthe standard ICANN public comment process.

41 The CWG-Stewardship has not consulted with the IETF and other named parties as to whether or not they would

be willing to serve on such a committee, but sought to provide that option should these parties be interested andavailable.

IANA Stewardship Transition Proposal Page 49 of 199

Part 1: Response from the Domain Names Community

6) To the extent allowed based on the need for security and contractually required
confidentiality, the proceedings of the standing committee should be open andtransparent.
7) Since it is not possible to formally define “significant”, all parties should err on the side ofprudence and raise issues for the consideration of the standing committee when there is
any question of it being required. The standing committee may decide that it does notneed to consider the issue.
8) The standing committee should coordinate with the NTIA at the time of transition totransfer relevant information about any ongoing major architectural and operationalchanges so that any such ongoing activities are not delayed or lost due to the transition.
1156

The CWG-Stewardship further recommends that for changes internal to the IANA Functions
Operator and for those related to reports and communications, no external approval shall beneeded. Such decision should be made, where appropriate, in consultation with thecommunity, or the standing committee.

1157

The CWG-Stewardship recommends that post-transition IFO budgets must support theoperator’s capability to investigate, develop and deploy Root Zone enhancements required
to keep the Root Zone and its management evolving.

1158

Principles
1) Transparency: To the extent allowed by external agreements and as necessitated by
security and privacy issues, the IFO should operate in a transparent manner. Reports on
the IFO operations should not be withheld unless there are explicit and defendable
needs for confidentiality.
2) Control of Root Zone Management: Currently, updating the Root Zone requires theactive participation of three parties: the IFO, the Root Zone Maintainer and the NTIA.
The IFO receives change requests from various sources, validates them, and sends
them to the Root Zone Maintainer who, once they are authorized by the NTIA, updates
the Root Zone File, DNSSEC signs it and distributes it to the Root operators.
Post transition there will only be the IFO and the Root Zone Maintainer. The CWGStewardship is not recommending any change in the functions performed by these tworoles at this time. The CWG-Stewardship is recommending that should there be
proposals to make changes in the roles associated with Root Zone modification, thatsuch proposals should be subject to wide community consultation.
3) Future changes to the Root Zone Management process must be made with due
consideration to the IANA Functions Operator’s and Root Zone Maintainer’s abilities toprocess change requests expeditiously.

1159

P1.III.A.iv. Other

IANA Stewardship Transition Proposal Page 50 of 199

Part 1: Response from the Domain Names Community

1160

ccTLD Delegation Appeals
The CWG-Stewardship recommends not including any appeal mechanism that would apply
to ccTLD delegations and redelegations in the IANA Stewardship Transition proposal. For
further information, see Annex O.

1161

IANA Budget421162

In order for the multistakeholder community to steward the IANA Functions, the CWGStewardship recommends that:43
1) The IFO’s comprehensive costs should be transparent for any future state of the IANA
Function.
2) Future Fiscal Year (FY) ICANN Operating Plans & Budgets, and if possible even the
FY16 ICANN Operating Plan & Budget, include at a minimum itemization of all IANA
operations costs in the FY ICANN Operating Plan & Budget to the project level andbelow as needed.

1163

Further details on the expected detail, based on the information provided in relation to the
FY15 budget, can be found in Annex P. Furthermore, the CWG-Stewardship has identified anumber of items for future work that can be found in Annex Q. In relation to PTI, the CWGStewardship recommends that PTI should develop and annually update a four-year strategicplan, which should outline strategic priorities, while PTI should also have a yearly budgetthat is reviewed by the ICANN community. A fully approved budget should be developed on
an annual basis. PTI should submit a budget44 to ICANN at least nine months in advance ofthe fiscal year to ensure the stability of the IANA services. It is the view of the CWGStewardship that the IANA budget should be approved by the ICANN Board in a muchearlier timeframe than the overall ICANN Budget. PTI’s actual financial performance shouldbe measured monthly against the PTI budget, and should be reported to the PTI Board. In
addition to any statutory requirements, it is the view of the CWG that an independent
financial audit of PTI’s financial statements must also be required.

1164

Regulatory and Legal Obligations

1165

The handling of requests for statutory waivers or licenses relating to its IFO’s legal
obligations in its legal domicile (e.g., from the U.S. Department of the Treasury’s Office ofForeign Assets Control (OFAC)) is a generally-applicable legal obligation regardless of who
is serving as the IANA Functions Operator. ICANN already has a process in place forseeking any necessary licenses, and will continue to work with contacts at relevant
authorities to identify ways to streamline those requests. A statutory waiver of OFAC
requirements may be possible if a new statute authorizes the transition. Such a statutory
waiver could provide that the President of the United States may not use trade sanctions
with respect to the IANA Functions Operator. For licenses or waivers that relate to the IANA
Function, ICANN must commit that any licenses or waivers it seeks will also be sought for

CCWG-Accountability Dependency – see http://forum.icann.org/lists/comments-ccwg-accountability-draft-proposal04may15/msg00033.html
43 The names registries have long requested budget transparency and detail. See for example the work of the ccNSOStatement of Policy.
44 In developing its budget, the CWG-Stewardship recommends that PTI review best practices of other similarorganizations.
42

IANA Stewardship Transition Proposal Page 51 of 199

Part 1: Response from the Domain Names Community

the IANA Functions Operator and for the Root Zone Maintainer as well, so that a single
request for any applicable entity is required.

1166

P1.III.B. Implications for the interface between the IANA Functions andexisting policy arrangements

1167

For the IANA naming services, the proposal seeks to retain the functional separation
between the policy development processes and the IANA Functions.

P1.IV Transition Implications
1168

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, orother 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 establishedarrangements.
 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.

1169

P1.IV.A. Operational requirements to achieve continuity of service andpossible new service integration throughout the transition

1170

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.

1171

Continuity of service issues associated with the transition should be minimized given that
the CWG Stewardship transition proposal recommends the continuation of using ICANN as
the IFO.

1172

Although the CWG-Stewardship proposes a structural change with the legal separation of
the IFO from ICANN (with the IANA functions to be transferred to PTI, an ICANN affiliate),for practical and administrative reasons it is expected that this change will have little or no
impact on any of the IFO customer operations throughout the transition, given that the IFO
systems, processes, procedures and personnel for these activities will remain exactly the
same.

1173

For the naming community the services it requires from the IFO are:
IANA Stewardship Transition Proposal Page 52 of 199

Part 1: Response from the Domain Names Community Operating the public interface to the top level WHOIS database.
 Operating the .INT TLD.45
 Implementing, or participating in, the implementation of changes to the Root Zone
environment.
 Validation processes for adding, modifying or removing TLDs to the Root Zone and theassociated WHOIS database (and associated systems for supporting this).
 Requesting changes to the Root Zone upon validation of a request by the IFO (andassociated systems for supporting this).
1174

Operating the TLD WHOIS and the .INT TLD - The CWG-Stewardship does not propose
any material changes with respect to the IFO operating the top level WHOIS database.

1175

Implementing changes to the Root Zone environment - The implementation of changes
to the process to approve changes to the Root Zone environment are required with the NTIA
removing itself from the final approval of all such changes. The CWG-Stewardship transition
proposal recommends that the ICANN Board take over the responsibility of approving all
substantive (architectural) changes to the Root Zone environment (such changes being rare
events). In line with the NTIA process, the ICANN Board would only approve any suchchanges if these maintained the security, stability, and resiliency of the Internet (ICANN’s
first core value as per its Bylaws) and would be supported by a majority of the concernedand affected parties. ICANN will coordinate with the NTIA for any ongoing approval
processes for significant changes to the Root Zone environment to ensure continuity ofthese. As such it is expected that the transition should not generate any issues with
continuity of service associated with this for the IFO naming customers.

1176

Validation processes of customer requests for changes to the Root Zone – The CWGStewardship recommends removing the authorization requirement currently performed by
the NTIA for all change requests to the Root Zone or its associated WHOIS databasebecause it does not contribute in a significant fashion to the security, stability, and resiliencyof the Internet DNS. This approval function is currently underpinned by a secure computer
based system between IFO, NTIA, and Verisign acting as the Root Zone Maintainer. Until
such time as this system can be modified IANA has confirmed it could simply act as NTIA in
this system allowing it to approve its own requests for changes to the Root Zone, thus
removing the requirement for NTIA authorization. As such it is expected that this element of
the transition should not generate any issues with continuity of service for the IFO naming
customers.

1177

Requesting changes to the Root Zone - Requesting changes to the Root Zone and its
associated WHOIS database upon validation of a request. The Root Zone maintainer is
responsible for implementing change requests from the IFO. Given the NTIA has stated thatthe transition of the Root Zone Maintainer function will be a separate process (which is not
the responsibility of the CWG-Stewardship and has yet to be initiated),46 this element isbeyond the scope of the CWG-Stewardship. The CWG-Stewardship assumes that the NTIA
will ensure that there is a suitable Root Zone Maintainer service available to the IFO thatcan function using current systems.

45 The CWG-Stewardship has considered the .INT domain, and concluded that provided there is no policy change

under .INT done by ICANN/IANA the CWG-Stewardship does not see any need for changes in the management of
the .INT domain in conjunction with the transition. Future administration of the .INT domain should be subject toreview post transition.
46 The NTIA addressed this in its “IANA Functions and Related Root Zone Management Transition Questions andAnswers” on 18 March 2014. See http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-rootzone-management-transition-questions-and-answ for further details.

IANA Stewardship Transition Proposal Page 53 of 199

Part 1: Response from the Domain Names Community

1178

As described above, continuity of service is assured: there are no material changes to theoperation of the WHOIS database or the .INT TLD; and changes have been accounted for in
the Root Zone environment, to the extent of the CWG-Stewardship’s scope of work. The
CWG-Stewardship further ensures continuity of oversight of service by establishing the
CSC. The CSC would oversee operations for IANA naming services, replacing NTIA
oversight. The CSC is envisioned as customer-based, and inclusive of other operational
communities – should these communities wish to liaise expertise regarding naming services
operations. In the CSC, the CWG-Stewardship strengthens a customer-based stewardshipof the IANA functions.

1179

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

1180

This section should describe what your community views as the implications of the changes
it proposed in Section III.
 Description of any legal framework requirements in the absence of the NTIA contract.

1181

To provide IANA services to the naming community, the CWG-Stewardship recommends
that a new separate legal entity, PTI, be formed as an affiliate of ICANN. In this structure,
the existing IANA functions, administrative staff, and related resources, processes, data,
and know-how will be legally transferred into PTI. There will be a new ICANN-PTI contract
established as a replacement to the current NTIA IANA Functions Contract. The terms of
the ICANN-PTI contract will reflect the CWG-Stewardship proposed structure, including
escalation and review mechanisms.47 The CWG-Stewardship views the ICANN-PTI contract
as a legal framework requirement in the absence of the NTIA IANA Functions Contract:
however, given the implications of the proposed PTI structure are more importantly
anchored in its associated accountability mechanisms, this section will focus on PTI rather
than the contract to which it will be party.

1182

As stated above, the CWG-Stewardship proposal foresees moving all IANA functions to PTI.
If they decide to do so, the number and protocol communities can continue their agreementswith ICANN, which the CWG envisages will then subcontract all the IANA Functions related
work to PTI.

1183

The CWG-Stewardship proposal surrounds PTI with an accountability framework thatstrengthens the fulfillment of the NTIA requirements (see Section V). This framework
includes the CSC, the IFR, the Special IFR, and the enhanced customer complaint andescalation mechanisms.

1184

The establishment of the CSC and the IFR (periodic and special) should be ensured by
ICANN Bylaw changes. Since the CSC and IFRs are not separate legal entities, they can becreated within the ICANN community structure, similar to working groups, and formalized
through the related enhancements proposed in the CCWG-Accountability Work Stream 1
Proposal.

1185

The escalation mechanisms and customer service complaint procedures are described in
Annexes I and J; a flowchart of the escalation processes is provided in Annex J-1. Thesemechanisms are not by default legal recourse and therefore do not imply changes to be

47 A draft proposed term sheet for the ICANN-PTI Contract is available in Annex S.

IANA Stewardship Transition Proposal Page 54 of 199

Part 1: Response from the Domain Names Community

further developed in this section. These mechanisms and procedures, however, are part of
the accountability framework that will replace NTIA’s oversight and contract.
1186

In the proposed accountability structure, the CWG-Stewardship has focused exclusively on
the needs of the naming community. However, the CWG-Stewardship acknowledges that
there are elements of the proposed accountability structure that may be of interest to theother operational communities, including, but not limited to, options for existing or new
arrangements in contracting services to IFO.

1187

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

1188This section should describe what your community views as the implications of the changes
it proposed in Section III.
 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 establishedarrangements.

1189

No new technical or operational methods are being proposed beyond those necessary for
replacing the NTIA acting as the IANA Functions Contract Administrator and the Root Zone
Management Process Administrator. The necessary changes include the accountability
mechanisms associated with the creation of PTI as an affiliate of ICANN and the Root Zone
environment. Implications of the changes to the Root Zone environment are described in
Section IV. A, and implications of the proposed accountability framework, including the PTI,
the ICANN-PTI Contract, the IFR, the CSC, and the customer complaint and escalation
procedures are described in Section IV. B.

1190

The CWG-Stewardship has evaluated these elements and determined that all are workable.
A summary of the evaluations is provided below. The scores reflect a qualitative
assessment by the CWG-Stewardship of whether the specific element was workable on ascale of 0-3, with 0 indicating a significant requirement or negative impact and 3 indicating
no requirement or impact. For details of the methodology, please refer to Annex R.

Element Being Analyzed
PTI as an affiliate of ICANN
Contract between ICANN and
PTI
IFR
CSC
Customer complaint andescalation procedures
Approving changes to the
Root Zone environment
Replacing NTIA as the Root
Zone Management Processadministrator
1191

Score
score = 8/15 = 53%score = 12/15 = 80%

Evaluation
workableworkablescore = 9/15 = 60%score = 11/15 = 73%
score = 11/15 = 73%

workableworkableworkablescore = 8/15 = 53%

workablescore = 13/15 = 87%

workable

In addition to the CWG-Stewardship evaluation, the CCWG-Accountability Work Stream 1
Proposal further addresses “Stress Tests” that test the proposed structure against various
scenarios. Since the CCWG-Accountability document is currently in draft form, this section

IANA Stewardship Transition Proposal Page 55 of 199

Part 1: Response from the Domain Names Community

only refers to the relevant Stress Tests, and directs the reader directly to the CCWGAccountability document for further detail. Relevant CCWG-Accountability Stress Tests:48
 Failure to Meet Operational Expectations
 Stress Test #1: Change authority for the Root Zone ceases to function, in part orin whole.49
 Stress Test #2: Authority for delegations from the Root Zone ceases to function,in part or in whole.50
 Stress Test #11: Compromise of credentials.51
 Stress Test #17: ICANN attempts to add a new TLD in spite of security andstability concerns expressed by technical community or other stakeholder
groups.52
 Stress Test #21: A government official demands ICANN rescind responsibility for
management of a ccTLD from an incumbent ccTLD Manager.53
 Legal/Legislative Action
 Stress Test #19: ICANN attempts to redelegate a gTLD because the registry
operator is determined to be in breach of its contract, but the registry operator
challenges the action and obtains an injunction from a national court.54
 Stress Test #20: A court order is issued to block ICANN’s delegation of a new
TLD because of a complaint by an existing TLD operator or other aggrieved
parties.55
 Failure of Accountability to External Stakeholders
 Stress Test #25: ICANN delegates or subcontracts its obligations under a future
IFO agreement to a third party. Would also include ICANN merging with orallowing itself to be acquired by another organization.56

1192

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

1193

This section should describe what your community views as the implications of the changes
it proposed in Section III.
 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.

48 To access the CCWG-Accountability Work Stream 1 Proposal, please see:https://www.icann.org/en/system/files/files/cwg-accountability-draft-proposal-without-annexes-04may15-en.pdf.
49 See page 71 of CCWG-Accountability Proposal for further detail.
50 See page 71 of CCWG-Accountability Proposal for further detail.
51
See page 72 of CCWG-Accountability Proposal for further detail.
52 See page 73 of CCWG-Accountability Proposal for further detail.
53 See page 74 of CCWG-Accountability Proposal for further detail.
54 See page 77 of CCWG-Accountability Proposal for further detail.
55 See page 78 of CCWG-Accountability Proposal for further detail.
56 See page 88 of CCWG-Accountability Proposal for further detail.

IANA Stewardship Transition Proposal Page 56 of 199

Part 1: Response from the Domain Names Community

1194

The CWG-Stewardship’s proposed changes are to be implemented after NTIA approval of
the IANA Stewardship Transition plan. Some changes are ready to be implemented, andothers may require further assessment by the ICG as they may affect and be of interest toother communities involved in the IANA Stewardship Transition. For all changes, includingchanges that do not require further assessment by the ICG, the community will work withICANN in implementation. The CWG-Stewardship expects that the following implementation
items could be completed in approximately three to four months, in accordance with theadvice of independent legal counsel: (1) identifying the ICANN assets that relate to the IANA
functions to be assigned to PTI and assigning those assets to PTI pursuant to an
assignment agreement to be entered into between ICANN and PTI, (2) incorporating PTI
and drafting the PTI governance documents (i.e., articles of incorporation and bylaws) and(3) drafting, negotiating and finalizing the ICANN-PTI Contract.57 The CWG-Stewardshiphas attempted an initial list of elements for implementation as follows: Service Levels: A set of guiding principles for the review of the current SLEs used by
the IFO have been produced and accepted by the IFO. The sub-group of the CWGStewardship responsible for this work (DT-A) will continue its work, using theseprinciples, after the CWG has transmitted its proposal to the ICG, and prior to the ICG
submitting its proposal to the NTIA. The objective of this work is to produce a complete
and detailed set of recommendations in conjunction with the IFO for the updating of
SLEs used by the IFO (this pre-transition work requires approval by the NTIA before the
IFO can proceed). These recommendations would be provided to the CSC, posttransition, for its consideration, approval and implementation according to a scheduledeveloped jointly with the IFO.
 IANA Budget: The CWG-Stewardship worked closely with ICANN Finance indeveloping recommendations for transparent budget processes and itemizations
regarding IANA operations costs. Recommendations on ICANN’s budgeting process canbe implemented as further details of the CWG Accountability proposal are defined andapproved.58 Developing a PTI budget is part of, and dependent on, the establishment of
PTI. There are other recommendations (in particular, the ability of the community toapprove/veto the ICANN budget) that have been requested of the CCWG-Accountability
as part of a key dependency with the CCWG-Accountability as soon as their work is
finalized.
 PTI: The CWG-Stewardship worked closely with legal counsel in the reasoning anddevelopment of the PTI concept. Much research and many memoranda were provided
to the CWG-Stewardship that may be useful for consideration in implementation.59 At
this stage, considering possible interest and modifications pending from the otheroperational communities, the ICG may propose modifications to PTI.
 ICANN-PTI Contract: The CWG-Stewardship, with assistance from its legal counsel,
developed a draft proposed term sheet, which can be used as a basis to develop the
ICANN-PTI term sheet and ultimately the future contract with ICANN. PTI will need to beestablished, and have the benefit of advice from independent legal counsel, before it
can enter into this contract.
 CSC: The CWG-Stewardship has developed a charter for the CSC, which is usually the
first step in chartering a working group with ICANN. In this sense, the CSC is ready for

ICANN has not yet assessed the CWG-Stewardship’s proposal for an implementation timeline, and there are otherfactors to consider, such as maintaining ICANN’s tax-exempt status, for which the CWG-Stewardship’s independent
legal counsel could not estimate.
58 Documentations and details related to the IANA operations budget are available in Annex P, Q and T
59 All documents from legal counsel are available on the CWG-Stewardship Wiki athttps://community.icann.org/display/gnsocwgdtstwrdshp/Client+Committee.
57

IANA Stewardship Transition Proposal Page 57 of 199

Part 1: Response from the Domain Names Community

implementation. However, the CSC construct will need to be incorporated into the
ICANN Bylaws as a fundamental bylaw as part of a key dependency with the CCWGAccountability as soon as their work is finalized. A few elements to consider upon
implementation of the CSC, once established: What form of consultation is envisioned to take place between ccNSO andGNSO Councils in relation to approving the membership of the CSC?
 Are candidates who have been proposed to act as temporary replacements to
the CSC required to provide an Expression of Interest?
 Determine how CSC will decide on who will be liaison to the SCWG.
 What process should the CSC follow in the event it identifies a persistent
performance issue or systemic problem that is not serious? Is it still required tofollow a Remedial Action?
 The CWG-Stewardship recommends that a series of best practice governanceguidelines be established as part of the implementation process for the purposeof ensuring that the CSC manages issues such as potential or perceived conflictsof interest.
 IFR (Periodic and Special): Although the first periodic IFR will not commence until two
years after the IANA Stewardship Transition, it is possible that a Special IFR could betriggered prior to that time. As with the CSC, the IFR will need to be incorporated into
the ICANN Bylaws as a fundamental bylaw as part of a key dependency with the
CCWG-Accountability as soon as their work is finalized.
 Changes to customer complaints and escalation mechanisms: The CWGStewardship consulted ICANN’s IANA department in developing these mechanisms, andbelieves that these modifications are ready for implementation.
 Implementing changes to the Root Zone environment: The CWG-Stewardshiptransition proposal recommends that the ICANN Board take over the responsibility of
approving all substantive (architectural) changes to the Root Zone environment (suchchanges being rare events). ICANN will coordinate with the NTIA for any ongoingapproval processes for significant changes to the Root Zone environment to ensure
continuity of these. Note that changes to the Root Zone environment may be contingent
on what happens with the parallel Root Zone Maintainer Cooperative Agreement, which
is not in the scope of the CWG-Stewardship’s work.
 Community empowerment mechanisms: These have been requested of the CCWGAccountability as part of a key dependency with the CCWG-Accountability as soon as
their work is finalized. 60
 Appeal mechanism: This have been requested of the CCWG-Accountability as part ofa key dependency with the CCWG-Accountability as soon as their work is finalized.

60 In particular, mechanisms such as: the ability to recall the ICANN Board, the ability to exercise oversight withrespect to key ICANN Board decisions including decisions relating to periodic or special reviews of the IANA
functions undertaken through the IFR and approval of the ICANN budget, the ability to approve changes to ICANN’s
fundamental bylaws as well as the related creation of a stakeholder community / member group in order ensure theability to exercise these kinds of rights.

IANA Stewardship Transition Proposal Page 58 of 199

Part 1: Response from the Domain Names Community

P1.V NTIA Requirements
1195

Additionally, NTIA has established that the transition proposal must meet the following fiverequirements:
 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 intergovernmental organization solution.

1196

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

1197

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

1198

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

1199

The naming community depends upon ICANN’s multistakeholder policymaking structure todevelop its processes and policies. While the direct policymaking groups are the GNSO andthe ccNSO, the Advisory Committees – ALAC, GAC, RSSAC, and SSAC – are essential
parts of the multistakeholder model. Processes in the ICANN multistakeholder model arebottom-up, transparent, and inclusive of all stakeholders. The CWG-Stewardship reinforcesand enhances the multistakeholder model by keeping policy development separate from the
IANA operations and focusing on the needs of the operational community by establishingtransparent and direct control over PTI, specifically by: Replacing NTIA oversight of IANA with ICANN oversight of PTI ensured by the CSC andIFR Team, the latter being a multistakeholder entity. Both include non-ICANN
participants, thus maintaining and enhancing the multistakeholder model.
 CSC and IFR Team escalation mechanisms (developed in CWG-Stewardship and
CCWG-Accountability proposals) are based on open and transparent processes, andmultistakeholder decisions (which include non-ICANN naming related participants), thus
enhancing multistakeholder implication.

1200

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

1201

The security, stability and resiliency of the Internet DNS are core values for ICANN as
attested by the first item of Section 2 of the ICANN Bylaws which states:1202‘In performing its mission, the following core values should guide the decisions and actionsof ICANN:
IANA Stewardship Transition Proposal Page 59 of 199

Part 1: Response from the Domain Names Community

1. Preserving and enhancing the operational stability, reliability, security, and global
interoperability of the Internet.’
1203

This core value has been part of the ICANN Bylaws for well over a decade and there are noplans to modify it.

1204

Additionally, the security, stability, and resiliency of the Internet DNS was also assured by
the NTIA’s oversight of the IANA function which was carried out by the mechanisms
documented in Section II of this proposal. The CWG-Stewardship transition seeks tomaintain or improve on all of these as follows: Root Zone Management Process Administrator for changes to the Root Zone: The
CWG-Stewardship has recommended that the approval function of the NTIA forchanges to the Root Zone and its WHOIS database should not be replaced posttransition because it does not contribute in a significant fashion to the security, stability,
and resiliency of the Internet DNS.
 Root Zone Management Process Administrator for changes to the Root Zone
environment (such as the introduction of DNSSEC): This CWG-Stewardshiprecommends that this approval function be maintained via a standing committee (seeSection III.A.iii) because it is critical to maintaining the security, stability and resiliency of
the Internet DNS.
 IANA Functions Contract Administrator: The IANA Functions Contract and its oversightby the NTIA are considered key elements for the security, stability, and resiliency of theInternet DNS. As such, the CWG-Stewardship recommends the creation of the PTI as
an affiliate of ICANN and as the counterparty to a contract with ICANN, thus benefitingfrom the existing and strengthened accountability mechanisms and protections against
capture.
 Contract Oversight: As to the oversight of the contract, the NTIA’s role will be replaced
and augmented by the CSC and the IFR oversight mechanisms thus improving thesecurity, stability, and resiliency of the Internet DNS.

1205

P1.V.C. Meet the needs and expectation of the global customers and partnersof the IANA services

1206

The CWG-Stewardship’s 1 December public comment on its first transition proposal
confirmed the overwhelming satisfaction of the global customers and partners of ICANN’s
IANA department.

1207

As such, the CWG-Stewardship’s proposal ensures that PTI will continue to provide the
IANA Function to its global customers and partners post-transition in essentially the samemanner as ICANN’s IANA department does today.

1208

The CWG-Stewardship proposal is the result of extensive community dialogue and input.
Additionally, the CWG-Stewardship’s transition proposal has been approved by the multistakeholder community, which participated in its development as well as by the CWGStewardship’s designated chartering organizations.

IANA Stewardship Transition Proposal Page 60 of 199

Part 1: Response from the Domain Names Community

1209

P1.V.D. Maintain the openness of the Internet

1210

The CWG-Stewardship’s transition proposal does not contemplate any changes which
would in any way affect the openness of the Internet. This includes continued support for
IANA customers on the Office of Foreign Assets Control (OFAC) list of the U.S.
Government.

1211

P1.V.E. The proposal must not replace the NTIA role with a government-led oran intergovernmental organization solution
NTIA’s oversight of the IANA function is documented in Section II of this proposal andincludes the following roles:
 Establishment of PTI: Post-transition establishment of PTI as an affiliate of ICANN,
thus benefiting from the existing accountability mechanisms and prevention of capture,including by governments.
 Root Zone Management Process Administrator for changes to the Root Zone: The
CWG-Stewardship recommends that the approval function of the NTIA for changes to
the Root Zone and its WHOIS database should not be replaced post-transition.
 Root Zone Management Process Administrator for changes to the Root Zone
environment (such as the introduction of DNSSEC): The CWG-Stewardshiprecommends that this approval function be maintained via a multi-stakeholder process,which will not be government-led or an inter-governmental organization solution.

IANA Functions Contract Administrator: This was the NTIA’s oversight of the
IANA Functions Contract, which will be replaced and augmented by the CSC and the
IFR, which will not be government-led or an inter-governmental organization solution.

IANA Stewardship Transition Proposal Page 61 of 199

Part 1: Response from the Domain Names Community

P1.VI Community Process
1212

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 adescription of areas of contention or disagreement.

1213

P1.VI.A. Steps taken to develop the proposal and to determine consensus.

1214

Establishing the CWG-Stewardship

1215

In March 2014 the National Telecommunications and Information Administration (NTIA) has
requested that ICANN “convene a multi-stakeholder process to develop a plan to transition
the U.S. government stewardship role” with regard to the IANA Functions and related rootzone management. In making its announcement61, the NTIA specified that the transition
proposal must have broad community support and meet the following principles: Support and enhance the multi-stakeholder 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.

1216

NTIA also specified that it would not accept a proposal that replaces the NTIA role with agovernment-led or an intergovernmental organization solution.

1217

On June 6, 2014 ICANN proposed the creation of an IANA Stewardship Transition
Coordination Group (ICG) “responsible for preparing a transition proposal reflecting thediffering needs of the various affected parties of the IANA functions.” In July 2014 the ICG
was established, comprising of 30 members representing 13 communities.

1218

According to this charter,62 the ICG has one deliverable: a proposal to the NTIA regarding
the transition of NTIA’s stewardship of the IANA functions to the global multi-stakeholder
community. For that matter the ICG’s mission is to coordinate the development of a
proposal among the communities affected by the IANA Functions, which are divided into
three main categories: domain names, number resources, and other protocol parameters.
The ICG noted that the domain name category divides further into the country code andgeneric domain sub-categories. In the ICG charter, it also noted that “while there is someoverlap among all categories, each poses distinct organizational, operational and technicalissues, and each tends to have distinct communities of interest and expertise.”

61 http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions
62 https://www.icann.org/en/system/files/files/charter-icg-27aug14-en.pdf

IANA Stewardship Transition Proposal Page 62 of 199

Part 1: Response from the Domain Names Community1219

To achieve its deliverable the ICG identified four main tasks, which include among others,
the task to solicit proposals from the three operational communities, and solicit the input of
the broad group of communities affected by the IANA functions. In order to address thistask, the ICG seeks complete formal responses to its Request For Proposal (RFP)63,
through processes that are convened by each of the “operational communities” of IANA (i.e.
those with direct operational or service relationships with the IANA functions operator, inconnection with names, numbers or protocol parameters).

1220

In anticipation of the charter of the ICG, the operational community in connection with the
IANA names function, the ccNSO and GNSO, took the initiative to create a cross-community
working group to develop a proposal for the transition of NTIA’s stewardship in relation to
the naming related functions. At the ICANN 50 meeting in London, June 2014, the GNSO,
ccNSO, ALAC and the SSAC established a drafting team to prepare a charter for such a
Cross Community Working Group, which was finalized by mid August 2014. The charter
was approved by the GNSO, ccNSO, ALAC and SSAC, each according to their own rules
and procedures. The charter of the CWG-Stewardship as approved is available athttps://community.icann.org/display/gnsocwgdtstwrdshp/Charter.

1221

Members and participants

1222

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

1223

Following the approval of the CWG-Stewardship charter, the chartering organizations,selected members for the CWG-Stewardship, again in accordance with their own rules ofprocedure. Besides actively participating in the work of the CWG-Stewardship, members of
the CWG-Stewardship are expected to solicit, and communicate the views and concerns ofindividuals in the organization that appoints them. The list of the 19 members, theiraffiliation, originating organizations and geographic regions is included on the pagereferenced above.

1224

Separately, and in accordance with the charter of the CWG-Stewardship, a call forparticipants was sent out to invite all those who are interested in the work of the CWGStewardship. The list of names of participants from the community, their affiliation, if any,and originating Geographic Region can also be found on the relevant Wiki page. Further,and in accordance with the charter, the CWG-Stewardship members and participants havesubmitted Statements of Interest(s).64

1225

Working methods of the CWG-Stewardship

1226

Initial working method: developing the first CWG-Stewardship proposal (October 2014
through February 2015): Sub-teams addressing ICG Request for Proposal

1227

At its start the CWG-Stewardship agreed to divide its work into the following items, which
are derived from and in accordance with the RFP from the ICG:
3) Description of Community’s Use of IANA Functions (RFP 1)
4) Existing, Pre-Transition Arrangements

63 https://www.icann.org/en/system/files/files/rfp-iana-stewardship-08sep14-en.pdf
64 https://community.icann.org/display/gnsocwgdtstwrdshp/SOIs+Created+for+CWG

IANA Stewardship Transition Proposal Page 63 of 199

Part 1: Response from the Domain Names Communitya) Policy Sourcesb) Oversight and Accountability5) Proposed Post-Transition Oversight and Accountability Arrangements
6) Transition Implications
7) NTIA Requirements (RFP 5)8) Community Process (RFP 6)

1228

In addition the CWG-Stewardship agreed to work on two additional items:
 Existing, Pre-Transition Arrangements, NTIA IANA Functions Contract Triage: The goal
is to inform the CWG-Stewardship itself in its work and create a better understanding of
the elements in the IANA Functions Contract for the work of the CWG-Stewardship.
 Principles: For internal purposes the CWG-Stewardship agreed to develop a set ofprinciples and criteria on which the CWG-Stewardship itself could base its (draft)
proposals and against which these could be tested.

1229

For each of the work items identified above sub-groups were formed, with volunteer
rapporteurs and internal coordinators, with the exception for Section VI. These sub-groups
were created to focus the work of the group on the requirements of the ICG and develop
initial drafts. The sub-groups reported back to the full CWG-Stewardship, both online andduring the CWG-Stewardship meetings, and their output was discussed, edited andultimately accepted by the CWG-Stewardship as a whole, in accordance with the decisionmaking rules defined in the charter of the CWG-Stewardship.65

1230

The progress and intermediate results from the sub-teams can be viewed at:https://community.icann.org/display/gnsocwgdtstwrdshp/%5BArchive%5D+Work+Item+Sub+Groups1231

On 1 December 2014, the CWG-Stewardship published its first draft proposal for publiccomment. This first draft had been designed around the idea of an independent andseparate contracting entity, known as “Contract Co.”, to replace NTIA’s stewardship role andcontract with the IANA Functions Operator. The comments at the conclusion of the firstpublic comment outlined three key takeaways:
 Customers are currently satisfied with ICANN’s IANA department.
 There was concern over what was viewed as an overly complex structure that lacked
details and assurances on accountability.
 Professional and independent legal advice was required to make a determination on
post-transition structure1232

The CWG-Stewardship further discussed the different aspects, taking into the community
input. In part, this involved considering many more structural models (in addition to“Contract Co.”). By February 2015, prior to the ICANN 52 meeting in Singapore this resulted

65 CWG Charter, Section V: Rules of Engagement (https://community.icann.org/display/gnsocwgdtstwrdshp/Charter)

IANA Stewardship Transition Proposal Page 64 of 199

Part 1: Response from the Domain Names Community

in an additional set of questions for the community, to inform the discussions of the CWGStewardship.
1233

Going into ICANN 52, the CWG-Stewardship presented the community with an overview offour structural models: two were “internal” and two were “external” (including “ContractCo.”). This discussion document is available here:
https://www.icann.org/news/announcement-2015-02-06-en.67. During ICANN52, three
additional models were presented; each was a variation of a “hybrid” model. The discussion
document for these three models is available here:
https://community.icann.org/download/attachments/49351404/IntegratedIANA1.2.pdf?versio
n=1&modificationDate=1427102306000&api=v2. With the addition of these three models,the CWG-Stewardship effectively left the ICANN 52 meeting with seven potential models toevaluate and consider.

1234

Method used to develop second and final proposal (February 2015 throughJune 2015): Design Teams

1235

In February 2015, after the Singapore face-to-face meetings, the CWG-Stewardship
discussed and agreed in March 2015 on an alternative, focused, and agile method which
was to work on the remaining open issues through a so called Design Team method. Each
Design Team was established to focus on a specific, pre-defined work item and delivers its
output in a short timeframe.

1236

The list of work items was approved by the CWG-Stewardship and maintained by the CWGStewardship. Results of each Design Team were discussed and approved by the full CWGStewardship prior to integration into the evolving CWG-Stewardship Proposal. The results ofthe prioritized Design Teams were discussed by the CWG-Stewardship at its face-to-facemeetings that occurred in March 2015 in Istanbul, Turkey. At those meetings the initial list ofwork items was reviewed and work items were re-prioritized.

1237

The Co-Chairs managed creation of the Design Teams, prioritization of work items, andprogress of the teams, with input from the CWG-Stewardship. Members and participantsfrom the CWG-Stewardship composed the Design Teams, and in some cases external
observers with specific expertise were included.

1238

The register/list of work items, their priority, membership of Design Teams, meetings,
agendas, and mail archives are publicly available at:https://community.icann.org/display/gnsocwgdtstwrdshp/Design+Teams+List

1239

The CWG-Stewardship entered its Istanbul meetings with seven potential models for the
IANA Stewardship transition. These models had been studied and researched by newly
engaged independent legal counsel, Sidley Austin LLP. After a thorough discussion of thesepotential models with legal counsel and in a spirit of compromise, the CWG-Stewardshipnarrowed down its list of structural models to two variants of an internal accountability/hybrid
model: the legal separation mode and the functional separation model.

1240

The move from seven potential models to two variants of an internal accountability/hybrid
model was iterative over a series of sessions. In one session, after explanation of legal
counsel’s findings, two models: the internal trust and the external trust, were deemed
unsuitable to meet the CWG-Stewardship’s requirements because the structures were not

66 At this point, the CWG-Stewardship had still not secured professional legal advice.
67 At this point, the CWG-Stewardship had still not secured professional legal advice.

IANA Stewardship Transition Proposal Page 65 of 199

Part 1: Response from the Domain Names Community

necessarily recognized legally outside of the U.S. Upon conclusion of these sessions, theCWG-Stewardship also agreed to defer further consideration of the “Contract Co.” model (inpart, because it did not receive sufficient support after the first public comment period), untilthe viability of the remaining models could be further considered. In addition, the CWGStewardship agreed to defer further consideration of the fully internal model or the
standalone IANA hybrid model. The CWG-Stewardship agreed that the remaining models:
two variants of an internal accountability/hybrid model (the legal separation model and thefunctional separate model) required further research on the part of legal counsel before the
CWG-Stewardship could make a determination.
1241

Following the meetings in Istanbul, the CWG-Stewardship, in consultation with its
independent legal counsel, held various meetings and reviewed various memos from its
legal counsel to determine which of the two variants of an internal accountability/hybrid
model – the legal separation model and the functional separation model – would berecommended. The CWG-Stewardship determined that the legal separation model waspreferred because it would establish PTI as a separate legal entity at the outset, allowing forpossible separation from ICANN in the future, if necessary. In addition, the legal separation
model allowed for a contract between ICANN and PTI. With that decision reached, theCWG-Stewardship turned its focus to developing an accountability framework to support thismodel, while legal counsel assisted in addressing governance issues related to the model.
The consideration for the CWG-Stewardship, with consultation from its independent legal
counsel, became whether to support a functionally separate model or a legally separate
model. The group eventually chose the legally separate model because it would establish
the separate PTI entity at the outset, allowing for possible separation from ICANN in the
future, if necessary. With that compromise in place, the CWG-Stewardship turned its focus
to developing an accountability framework to support this model, while legal counsel
assisted in addressing governance issues.

1242

Client committee/independent, external legal services

1243

In March 2015, after an extensive request for proposal process, the CWG-Stewardship
obtained the services of an external law firm, Sidley Austin LLP, to provide relevant andindependent legal advice. The CWG-Stewardship agreed to channel their communication
with the law firm through a Client Committee,68 with the understanding that allcommunication (emails and conference calls, between the Client Committee and the lawfirm) would be publicly available as well as all deliverables prepared by the law firm.

1244

At the invitation of the Client Committee, Sidley Austin LLP attended full CWG-Stewardship
meetings to respond to questions and provide additional clarifications.

1245

Membership of the Client Committee, a list of the Sidley Austin team, meeting recordings,
agendas, research and memoranda, etc. are publicly available at:https://community.icann.org/display/gnsocwgdtstwrdshp/Client+Committee

1246

Through the Design Team method and taking into account external, independent legal
advice, the CWG-Stewardship developed its second draft proposal, which was published for
public comment from 22 April 2015 until 20 May 2015. During this public consultation period
the aspects of the second proposal were further refined and discussed, using the same
method for developing the second proposal.

68 The Client Committee was composed of the two co-chairs and two CWG-Stewardship members.

IANA Stewardship Transition Proposal Page 66 of 199

Part 1: Response from the Domain Names Community

1247

After closure of the public comment period (20 May 2015), the CWG-Stewardship reviewed
all comments received, and, where appropriate, the Design Teams prepared responses tothe comments received and refined their output.

1248

Based on the second proposal and further discussion by the full CWG-Stewardship and
Design Teams, taking into account the public comment analysis, the Final Proposal wasdeveloped.

1249

Determining consensus

1250

The proposal was developed in a bottom-up, multistakeholder manner, which included
multiple readings of the drafts. The drafts were posted publicly and open to comment by
CWG-Stewardship members and participants with respect to each of the draft proposal
iterations. The first draft of the Final Proposal was circulated for review and comment by the
CWG-Stewardship, on 1 June 2015, with a dedicated first reading during the 2 June 2015
plenary meeting. The second draft was delivered on 3 June 2015, with a dedicated second
reading during the 4 June 2015 call. A third and final reading took place on 9 June.

1251

Following the Final reading, the Final Proposal was sent to the CWG-Stewardship for a 24hour period during which any errors, comments, or statements could be noted for therecord. At the end of this 24-hour period (ending at 23:59 UTC on 10 June), the CWGStewardship co-Chairs added a note to Section VI.C., below, and sent the Final Proposal to
the SO/AC Chartering Organizations for their approval. Chartering Organizations’ approvalis requested by 25 June so as to deliver to the ICG.

1252

P1.VI.B. Links to announcements, agendas, mailing lists, consultations, andmeeting proceedings

1253

Meetings
 Full CWG–Stewardship (meeting dates, agendas, participants and meeting notes):
https://community.icann.org/display/gnsocwgdtstwrdshp/Meetings
 CWG-Stewardship Sub-Teams:
https://community.icann.org/display/gnsocwgdtstwrdshp/%5BArchive%5D+Work+Item+
Sub+Groups Design Teams: https://community.icann.org/display/gnsocwgdtstwrdshp/Design+Teams Client Committee:
https://community.icann.org/display/gnsocwgdtstwrdshp/Client+Committee

1254

Public consultations
 1 December public consultation on first CWG-Stewardship draft transition proposal:
https://www.icann.org/public-comments/cwg-naming-transition-2014-12-01-en
 Responses to the December 2014 public comment: https://www.icann.org/publiccomments/cwg-naming-transition-2014-12-01-en#summary
 February 2015 Discussion document for ICANN52 meeting:
IANA Stewardship Transition Proposal Page 67 of 199

Part 1: Response from the Domain Names Community

https://community.icann.org/pages/viewpage.action?pageId=52889457
 May 2015 public comment on second CWG-Stewardship draft transition proposal:
https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en

1255

Webinars and other public presentations
 Webinar 3-4 December 2014:
https://community.icann.org/pages/viewpage.action?pageId=50823496
 Webinar 3 February 2015:
https://community.icann.org/pages/viewpage.action?pageId=52232656
 Presentations at ICANN 52 Singapore: http://singapore52.icann.org/en/schedule/thucwg-stewardship Webinars 24 April 2015:
https://community.icann.org/pages/viewpage.action?pageId=52897455
 Webinars 6-7 May 2015:
https://community.icann.org/pages/viewpage.action?pageId=53772631.
 Webinars 11 June:
https://community.icann.org/pages/viewpage.action?pageId=53778352.

1256

Mailing list archives https://community.icann.org/display/gnsocwgdtstwrdshp/Mailing+List+Archives

1257

Correspondence https://community.icann.org/pages/viewpage.action?pageId=49355992

1258

Outreach https://community.icann.org/display/gnsocwgdtstwrdshp/Outreach+Tracking+CWGStewardship1259

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

1260

The Cross Community Working Group on Naming Related Functions (CWG-Stewardship) is
pleased to provide its Chartering Organizations with its proposed response to the IANA
Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA
Stewardship Transition for your consideration and approval as per its Charter.

1261

The response is the result of extensive work by the CWG’s 19 members, 133 participants
and a team of highly qualified legal advisors over the past year, which included over 100
calls or meetings, 2 public consultations and more than 4,000 email messages. It represents
a carefully crafted balance between key requirements, specific legal advice, and significant
compromises by all who participated and includes diligent attention to the input received
IANA Stewardship Transition Proposal Page 68 of 199

Part 1: Response from the Domain Names Community

through the Public Comment proceedings. The final proposal has received the consensus
support of the CWG-Stewardship with no objections or minority statements recorded forChartering Organization consideration.
1262

As noted in the CWG-Stewardship proposal itself, the proposal is significantly dependentand expressly conditioned on the implementation of ICANN-level accountability mechanisms
proposed by the Cross Community Working Group on Enhancing ICANN Accountability(CCWG-Accountability). The co-chairs of the CWG-Stewardship and the CCWGAccountability have coordinated their efforts and the CWG-Stewardship is confident that the
CCWG-Accountability recommendations, if implemented as expected, will meet therequirements that the CWG-Stewardship has previously communicated to the CCWG. If any
element of these ICANN level accountability mechanisms is not implemented ascontemplated by the CWG-Stewardship proposal, this proposal will require revision.

IANA Stewardship Transition Proposal Page 69 of 199

Part 1: Response from the Domain Names Community

P1. Annex A: The Community’s Use of the IANA Functions –Additional Information
1) Root Zone Change Request Management (NTIA IANA Functions Contract:
C.2.9.2.a)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.
b) Customers of the function: TLD registries.
c) What registries are involved in providing the function: Root Zone database.
d) Overlaps or interdependencies: Policy for entries in the Root Zone are determinedby the ICANN policy-setting mechanisms (e.g., for ccTLDs and gTLDs). The IETF
standardization process can create reservations from the global namespace so thatcertain names that otherwise would be valid in the DNS root are disallowed.
2) Root Zone WHOIS Change Request and Database Management (NTIA IANA
Functions Contract: C.2.9.2.b)a) Description of the function: The IFO maintains, updates, and makes publicly
accessible a Root Zone WHOIS database with current and verified contact
information for all TLD registry operators. The Root Zone WHOIS database, at aminimum, 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; thename, 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; 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.
b) Customers of the function: TLD registries.
c) What registries are involved in providing the function: Root Zone WHOIS
database.
d) Overlaps or interdependencies: None.
3) Delegation and Redelegation of a ccTLD (NTIA IANA Functions Contract:
C.2.9.2.c)a) Description of the function: Assigning or re-assigning a manager (sponsoringorganization) for a ccTLD registry (including IDN ccTLDs). The IFO applies existing
policy frameworks in processing requests related to the delegation and redelegation
IANA Stewardship Transition Proposal Page 70 of 199

Part 1: Response from the Domain Names Communityof a ccTLD, such as RFC 1591 Domain Name System Structure and Delegation, the
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 publicauthorities, 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 thejurisdiction that the TLD registry serves.
b) Customers of the function: ccTLD registries.
c) What registries are involved in providing the function: Root Zone, Root Zone
WHOIS database.
d) Overlaps or interdependencies: Policy for entries in the Root Zone are determinedboth by the ICANN policy setting mechanisms (e.g. for ccTLDs and gTLDs), and by
the IETF standardization process (e.g. for specially reserved names)4) Delegation and Redelegation of a gTLD (NTIA IANA Functions Contract: C.2.9.2.d)a) Description of the function: Assigning or re-assigning a Sponsoring Organization
for a gTLD registry. ICANN verifies that all requests related to the delegation andredelegation of gTLDs are consistent with the procedures developed by ICANN. In
making a delegation or redelegation recommendation ICANN must provide
documentation in the form of a Delegation and Redelegation Report verifying that
ICANN followed its own policy framework including specific documentation
demonstrating how the process provided the opportunity for input from relevant
stakeholders and was supportive of the global public interest.
b) Customers of the function: gTLD registries.
c) What registries are involved in providing the function: Root Zone, Root Zone
WHOIS database.
d) Overlaps or interdependencies: Policy for entries in the Root Zone are determinedboth by the ICANN policy-setting mechanisms (e.g. for ccTLDs and gTLDs), and by
the IETF standardization process (e.g. for specially reserved names).
5) Redelegation and Operation of the .INT TLD (NTIA IANA Functions Contract:
C.2.9.4)69a) Description of the function: Historically, the policy for .INT is described in IETF
RFC 1591. The policy allowed registration for both international organizations andfor use for international databases for infrastructure use. The policy for .INT related
to international databases for infrastructure use was determined by the IETF. RFC
3172 recommended that such uses move under.ARPA, and the only then-extant use
of .INT for such infrastructure (the IPv6 reverse mapping tree) was in fact moved
under .ARPA; all subsequent infrastructure uses have been under .ARPA. Since this69 The CWG-Stewardship has considered the .INT domain, and concluded that provided there is no policy change

under .INT done by ICANN/IANA the CWG-Stewardship does not see any need for changes in the management of
the .INT domain in conjunction with the transition. Future administration of the .INT domain should be subject toreview post transition.

IANA Stewardship Transition Proposal Page 71 of 199

Part 1: Response from the Domain Names Communitychange, it is only possible for an international treaty organizations to register domainnames under .INT for use for the organization itself.
b) Customers of the function: Eligible registrants for registration in .INT
(http://www.iana.org/domains/int/policy).
c) What registries are involved in providing the function: Root Zone database,
Root Zone WHOIS, .INT Zone database, .INT WHOIS database.
d) Overlaps or interdependencies: Historically policy has partially been determined
by IETF, however per RFC 3172, .INT is no longer used for international databases
for infrastructure use; .ARPA TLD is used instead.
6) Root DNSSEC Key Management (NTIA IANA Functions Contract: C.2.9.2.f)a) Description of the function: The IANA Functions Operator is responsible forgenerating the Key Signing Key (KSK) and publishing its public portion. The KSK
used to digitally sign the Root Zone Signing Key (ZSK) that is used by the Root Zone
Maintainer to DNSSEC-sign the Root Zone.
b) Customers of the function: Root Zone Maintainer, DNS validating resolver
operators.
c) What registries are involved in providing the function: The Root Zone Trust
Anchor.
d) Overlaps or interdependencies: IETF’s creation of algorithm numbers for key
types.
7) Root Zone Automation (NTIA IANA Functions Contract: C.2.9.2.e)a) 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 subsequentactions whereby each customer can see a record of their historic requests andmaintain visibility into the progress of their current requests; a test system, whichcustomers can use to test the technical requirements for a change request; and aninternal interface for secure communications between the IFO; the Administrator,
and the Root Zone Maintainer.
b) Customers of the function: TLD registries.
c) What registries are involved in providing the function: Root Zone database,
Root Zone WHOIS.
d) Overlaps or interdependencies: N/A.
8) Customer Service Complaint Resolution Process (CSCRP) (NTIA IANA Functions
Contract: C.2.9.2.g)a) Description of the function: A process for IANA Functions customers to submit
complaints for timely resolution that follows industry best practice and includes areasonable timeframe for resolution.
IANA Stewardship Transition Proposal Page 72 of 199

Part 1: Response from the Domain Names Communityb) Customers of the function: TLD registries.
c) What registries are involved in providing the function: N/A.
d) Overlaps or interdependencies: All IANA Functions that are customer facing forthe names registries.
9) Management of the Repository of IDN Practices (IANA service or activity beyond
the scope of the IANA functions contract)a) Description of the function: The IANA Repository of TLD IDN Practices, also
known as the “IDN Language Table Registry,” was created to support thedevelopment 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.
b) Customers of the function: TLD registries.
c) What registries are involved in providing the function: IDN Language Table
Registry.
d) Overlaps or interdependencies: IDNs are based on standards developed andmaintained by the IETF.
10) Retirement of the Delegation of TLDs (IANA service or activity beyond the scopeof the IANA functions contract)a) Description of the function: Retire TLDs from active use.
b) Customers of the function: TLD registriesc) What registries are involved in providing the function: Root Zone database,
Root Zone WHOIS database.
d)Overlaps or interdependencies: N/A.

IANA Stewardship Transition Proposal Page 73 of 199

Part 1: Response from the Domain Names Community

P1. Annex B: Oversight Mechanisms in the NTIA IANA
Functions Contract
1263

The following is a list of oversight mechanisms found in the NTIA IANA Functions Contract:
Ongoing Obligations
 C.2.12.a Program Manager --The contractor shall provide trained, knowledgeable
technical personnel according to the requirements of this contract. All contractor
personnel who interface with the CO and COR must have excellent oral and written
communication skills. "Excellent oral and written communication skills" is defined as
the capability to converse fluently, communicate effectively, and write intelligibly in
the English language. The IANA Functions Program Manager organizes, plans,
directs, staffs, and coordinates the overall program effort; manages contract andsubcontract activities as the authorized interface with the CO and COR and
ensures compliance with Federal rules and regulations and responsible for thefollowing: C.4.1 Meetings -- Program reviews and site visits shall occur annually.
 C.4.2 Monthly Performance Progress Report -- The Contractor shall prepare andsubmit to the COR a performance progress report every month (no later than 15
calendar days following the end of each month) that contains statistical andnarrative information on the performance of the IANA functions (i.e., assignment oftechnical protocol parameters; administrative functions associated with root zone
management; and allocation of Internet numbering resources) during the previous
calendar month. The report shall include a narrative summary of the work
performed for each of the functions with appropriate details and particularity. The
report shall also describe major events, problems encountered, and any projectedsignificant changes, if any, related to the performance of requirements set forth in
C.2.9 to C.2.9.4.
 C.4.3 Root Zone Management Dashboard -- The Contractor shall work
collaboratively with NTIA and the Root Zone Maintainer, and all interested andaffected parties as enumerated in Section C.1.3, to develop and make publicly
available via a website, a dashboard to track the process flow for root zone
management within nine (9) months after date of contract award.
 C.4.4 Performance Standards Reports -- The Contractor shall develop and publish
reports for each discrete IANA function consistent with Section C.2.8. The
Performance Standards Metric Reports will be published via a website every month(no later than 15 calendar days following the end of each month) starting no later
than six (6) months after date of contract award.
 C.4.5 Customer Service Survey (CSS) --The Contractor shall collaborate with NTIA
to develop and conduct an annual customer service survey consistent with theperformance standards for each of the discrete IANA functions. The survey shall
include a feedback section for each discrete IANA function. No later than 30 days
after conducting the survey, the Contractor shall submit the CSS Report to theCOR.
 C.5.1 Audit Data -- The Contractor shall generate and retain security process audit
record data for one year and provide an annual audit report to the CO and the
COR. All root zone management operations shall be included in the audit, andIANA Stewardship Transition Proposal Page 74 of 199

Part 1: Response from the Domain Names Community

records on change requests to the root zone file. The Contractor shall retain theserecords in accordance with the clause at 52.215-2. The Contractor shall provide
specific audit record data to the CO and COR upon request.
 C.5.2 Root Zone Management Audit Data -- The Contractor shall generate andpublish via a website a monthly audit report based on information in theperformance of Provision C.9.2 (a-g) Perform Administrative Functions AssociatedWith Root Zone Management. The audit report shall identify each root zone file androot zone “WHOIS” database change request and the relevant policy under which
the change was made as well as identify change rejections and the relevant policy
under which the change request was rejected. The Report shall start no later thannine (9) months after date of contract award and thereafter is due to the COR no
later than 15 calendar days following the end of each month.
 C.5.3 External Auditor -- The Contractor shall have an external, independent,
specialized compliance audit which shall be conducted annually and it shall be an
audit of all the IANA functions security provisions against existing best practices
and Section C.3 of this contract.

IANA Stewardship Transition Proposal Page 75 of 199

Part 1: Response from the Domain Names Community

P1. Annex C: Principles and Criteria that Should Underpin
Decisions on the Transition of NTIA
Stewardship for Names Functions
Final
1264

These principles and criteria are meant to be the basis upon which the decisions on thetransition of NTIA stewardship are formed. This means that the proposals can be tested
against the principles and criteria before they are sent to the ICG.
1) Security, stability and resiliency: Changes must not undermine the operation of the
IANA Functions 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 andshould be fit for purpose.
4) Support the open Internet: The transition proposal should contribute to an open andinteroperable Internet.
5) Accountability and transparency: The service should be accountable and transparent.
i)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 therationale for that decision should be made public or at least be subject to anindependent scrutiny as part of an ex-post assessment of service performance.
Unless prevented or precluded by confidentiality, any and all audit reports andother review materials should be published for inspection by the larger
community.

ii) Independence of accountability: Accountability processes should be
independent of the IANA Functions Operator70 and should assure theaccountability of the IANA Functions Operator to the inclusive global
multistakeholder community.
iii) Independence of policy from IANA: The policy processes should be
independent of the IANA Functions Operator. The IANA Functions Operator’srole is to implement changes in accordance with policy agreed through therelevant bottom-up policy process.
iv) Protection against Capture71: Safeguards need to be in place to prevent
capture of the service or of any IANA oversight or stewardship function.
70 The term IANA Functions Operator means the unit that provides the service.
71 A group can be considered captured when one or more members are able to effectively control outcomes despite alack of agreement from other stakeholders whose agreement or non-objection would be required to achieveconsensus. Conditions for consensus will need to be agreed appropriate for the group.

IANA Stewardship Transition Proposal Page 76 of 199

Part 1: Response from the Domain Names Communityv) 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 fallback provision also needs to be in place in case ofservice failure.
vi) Appeals and redress: Any appeals process should be independent, robust,
affordable, timely, provide binding redress open to affected parties and be open
to public scrutiny. Appeals should be limited to challenging the implementation ofpolicy or process followed, not the policy itself.
6) Service levels: The performance of the IANA Functions must be carried out in a
reliable, timely and efficient manner. It is a vital service and any proposal should ensure
continuity of service over the transition and beyond, meeting a recognized and agreed
quality of service that is in line with service-level commitments.
i)

Service level commitments should be adaptable to the developing needs of thecustomers of the IANA Functions and subject to continued improvement.

ii) Service quality should be independently audited (ex-post review) against agreed
commitments.
7) Policy based: The decisions and actions of the IANA Functions Operator should bemade objectively based on policy agreed to through the recognized bottom-up
multistakeholder processes. As such, decisions and actions of the IANA Functions
Operator should:i)Be predictable (i.e, decisions are clearly rooted in agreed and applicable policy
as set by the relevant policy body).

ii) Adhere to laws/processes (i.e., for ccTLDs: Respect national laws andprocesses, as well as any applicable consensus ICANN policies and IETF
technical standards). Post-transition of the IANA Functions, the IANA Functions
Operator will continue to provide service to existing registries in conformancewith prevailing technical norms, conforming with the policy decisions of registries
and the security and stability of the Root Zone itself.
iii) Be non-discriminatory.
iv) Be auditable (ex-post review).
v) Be appealable by significantly interested parties.
8) Diversity of the customers of the IANA Functions:i)

The IANA Functions operator needs to take account of the variety of forms of
relationship with TLD operators. The proposal will need to reflect the diversity ofarrangements in accountability to the direct users of the IANA Functions.

ii) For ccTLDs, the IANA Functions Operator should provide a service without
requiring a contract and should respect the diversity of agreements andarrangements in place for ccTLDs. In particular, the IANA Functions Operator
should not impose any additional requirements on the registry unless they are
directly and demonstrably linked to the global security, stability, and resilience of
IANA Stewardship Transition Proposal Page 77 of 199

Part 1: Response from the Domain Names Community

the DNS.
iii) For gTLDs, the IANA Functions Operator 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 the global security, stability and resilience of the DNS.
9) Separability: Any proposal must ensure the ability to:i)

Separate the IANA Functions from the current operator (i.e. ICANN) if warranted
and in line with agreed processes.

ii) Convene a process for selecting a new IANA Functions Operator.
iii) Consider separability in any future transfer of the IANA Functions.
10) Multistakeholderism: Any proposal must foster multistakeholder participation in the
future oversight of the IANA Functions.

IANA Stewardship Transition Proposal Page 78 of 199

Part 1: Response from the Domain Names Community

P1. Annex D: Diagram
This diagram is excerpted from a set of overview slides used for CWG-Stewardship briefing
webinars. To view the full set of slides, see https://community.icann.org/x/sJc0Aw.

IANA Stewardship Transition Proposal Page 79 of 199

Part 1: Response from the Domain Names Community

P1. Annex E: IANA Contract Provisions to be Carried Over
Post-Transition (Statement of Work)
1265

The following provisions of the IANA Functions Contract are expected to be carried over tothe IANA Statement of Work (and included in the ICANN-PTI Contract) noting that updates
will need to be made to reflect the changing relationship with NTIA post-transition, andensure consistency in terminology as well as updates as the result of otherrecommendations in the transition proposal:
 C.1.3. – Working relationship with all affected parties
 C.2.6 - Transparency and Accountability
 C.2.7. Responsibility and respect for stakeholders
 C.2.8 - Performance Standards
 C.2.9.2.a - Root Zone File Change Request Management
 C.2.9.2.b - Root Zone WHOIS Change Request and Database Management
 C.2.9.2.c - Delegation and Redelegation of a Country Code Top Level Domain (a similar
provision should be created concerning retirement of a Country Code Top Level
Domain) C.2.9.2.d - Delegation And Redelegation of a Generic Top Level Domain (gTLD) C.2.9.2.e – Root zone Automation
 C.2.9.2.f - Root Domain Name System Security Extensions (DNSSEC) Key
Management
 C.2.12.a – Qualified Program Manager
 C.3.1 – Secure Systems
 C.3.2. – Secure System Notification
 C.3.3. – Secure Data
 C.3.4. – Security Plan C.3.5. – Director of Security
 C.4.2. – Monthly Performance Progress Report C.4.3 – Root Zone Management Dashboard
 C.4.4 – Performance Standards Reports
 C.4.5. – Customer Service Survey
 C.5.1. – Audit Data
 C.5.2 – Root Zone Management Audit Data
 C.5.3 – External Auditor
 C.6.1. – Conflict of interest
 C.6.2. – Conflict of Interest Officer
 Sub-sections of C.6.2 (C.6.2.1-5) - additional conflict of interest requirements.
 C.7.1. – Redundancy
IANA Stewardship Transition Proposal Page 80 of 199

Part 1: Response from the Domain Names Community C.7.2. – Contingency plan C.7.3. – Transition to a Successor Contractor
 C.12.b – Key personnel
 Baseline requirements for DNSSEC in the authoritative root zone

IANA Stewardship Transition Proposal Page 81 of 199

Part 1: Response from the Domain Names Community

P1. Annex F: IANA Function Reviews - Statement of Work
Duration and Review Periodicity
1266

What period (duration) should be covered by the first statement of work posttransition?

1267

It is critical that any proposal provide opportunities to improve the performance of the IANA
Functions Operator as it relates to naming 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 IANA StewardshipTransition, to review the effectiveness of new structures created pursuant to the IANA
Stewardship Transition, and to address any implications for the IANA Functions Operator’s
performance. As a result, the CWG-Stewardship recommends that the review of PTI’s
performance against the ICANN-PTI Contract and the IANA Statement of Work (IANA
SOW) for the naming functions occur no more than two years from the date of the IANA
Stewardship Transition. This review will be led by a multistakeholder body drawn from theICANN community.

1268

Following the initial review period of two years from the date of the IANA StewardshipTransition, a longer period in between reviews will be advisable to avoid the constant flow ofreviews, while still accounting for the emerging or evolving needs of IANA customers andthe ICANN community. We recommend that subsequent reviews be initiated on a calendar
basis with a recommended standard period of no more than five-year intervals.

1269

While the IANA Function Review will normally be scheduled based on a regular rotation ofno more than five years in line with other ICANN reviews, a Special IANA Function Review
may also be initiated by community action.

1270

Periodic IANA Function Reviews will be focused on the performance of PTI against the
IANA SOW, as well as reviewing the IANA SOW to determine if any amendments should berecommended. The outcomes of an IANA Function Review are not limited and could include
a variety of recommendations.

1271

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

1272

The review could identify recommended amendments to the IANA SOW to address any
performance deficiencies, or to the CSC charter to address any issues or deficiencies. The
process of developing and approving amendments will take place through a defined processthat includes, at minimum, the following steps, in advance of an amendment to either
document being proposed: Consultation with the IANA Functions Operator;
 Consultation with the CSC;
 Public input session for ccTLD and gTLD operators; and Public comment period.
IANA Stewardship Transition Proposal Page 82 of 199

Part 1: Response from the Domain Names Community

1273

Drafted amendments will be subject to at least the following processes before they cameinto effect: Public comment period; Ratification by the ccNSO and the GNSO Councils by a supermajority threshold; and Approval by the ICANN Board.

1274

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

1275

Scope of IANA Function Reviews

1276

At minimum, the IANA Function Review will consider the following: The performance of the IANA Functions Operator against the requirements set forth in
the IANA SOW;
 Any necessary additions to the IANA SOW to account for the needs of consumers of the
IANA naming functions or the ICANN community at large;72
 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 toestablished service levels; and Discussion of process or other improvements (where relevant to the mandate of the
IANA Function Review) suggested by the CSC or community.
11.

1277

At minimum, the following inputs will be considered as a part of the review: The current IANA SOW.
 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;

72 Note: this does not include any review of policy developed or adopted through agreed processes or on ICANN’s

relationship with contracted TLDs.

IANA Stewardship Transition Proposal Page 83 of 199

Part 1: Response from the Domain Names Community

 Response to IANA Customer Satisfaction Surveys; and73
 Conflict of Interest Enforcement and Compliance Report.
 Inputs by the CSC, 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 IANA
Function Review Team, potentially including: Public comment periods.
 Input at in-person sessions during ICANN meetings.
 Responses to public surveys related to IANA Functions Operator performance;and Public inputs during meetings of the IANA Function Review Team.

1278

What are the goals of the reviews?

1279

In reviewing the above data points the goal of the IANA Function Review Team will be to: Evaluate the performance of the IANA Functions Operator and any related oversightbodies vis-à-vis the needs of its direct customers and the expectations of the broader
ICANN community; Evaluate the performance of any IANA oversight bodies with respect to the
responsibilities set forth in their charters;
 Consider and assess any changes put in place since the last IANA Function Review andtheir implications for the performance of the IANA Naming Functions; Determine if any amendments to the SOW should be recommended; and Identify areas for improvement in the performance of the IANA Functions and associatedoversight mechanisms.

1280

Any recommendations will 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.

1.

73 It is expected that these reports be retained for the duration of the reporting period,and be made available to members of the IANA Function Review Team (to the extent
that they are not published publically).
IANA Stewardship Transition Proposal Page 84 of 199

Part 1: Response from the Domain Names Community

1281

Composition of IANA Function Review Teams1282

Who are the relevant stakeholders?

1283

All stakeholder groups represented at ICANN will be relevant for the reviews done by the
IANA Function Review Team. Additionally, the Number and Protocol operational
communities will each be offered the opportunity to name a liaison to the review group. The
IANA Function Review Team will be composed as follows:

12. Group

13. IFRT Members

14. ccNSO

15. 2

16. ccTLDs (non-ccNSO)

17. 1

18. Registry Stakeholder Group (RySG)

19. 2

20. Registrar Stakeholder Group (RsSG)

21. 1

22. Commercial Stakeholder Group (CSG)

23. 1

24. Non-Commercial Stakeholder Group(NCSG)

25. 1

26. Government Advisory Committee (GAC)

27. 1

28. Security and Stability Advisory Committee(SSAC)

29. 1

30. Root Server Operators Advisory
Committee (RSSAC)

31. 1

32. At-Large Advisory Committee (ALAC)

33. 1

34. CSC Liaison

35. 1

1284

In any case where a recommendation focuses on a service specific to gTLDs or to ccTLDs,
or where the processes are different between the two, the final recommendation should not
be decided in the face of opposition from that community’s members. Solely gTLD issues
must not be decided in opposition to GNSO members and solely ccTLD issues (or issues
which are handled differently for ccTLDs) must not be decided in opposition to ccTLD
members of the IANA Function Review Team.

1285

Additionally, an IANA Functions Operator staff member will be appointed as a point ofcontact for the IANA Function Review Team.

1286

What body should coordinate reviews?

1287

The ICANN Board, or an appropriate sub-committee of the Board, must ensure that an IANA
Function Review Team is convened at no more than five-year intervals (or convened to
IANA Stewardship Transition Proposal Page 85 of 199

Part 1: Response from the Domain Names Community

enable the first periodic IANA Function Review to be completed) for the purpose of leading areview of the IANA SOW and the additional performance parameters defined above. The
IANA Function Review Team will not be a standing body and will be reconstituted for every
IANA Function Review.
1288

Individuals interested in participating in the IANA Function Review Team would submit an
Expression of Interest that includes a response addressing the following matters: Why they are interested in becoming involved in the IANA Function Review Team; What particular skills they would bring to the IANA Function Review Team; Their knowledge of the IANA Functions; Their understanding of the purpose of the IANA Function Review Team; and That they understand the time necessary required to participate in the review process
and can commit to this role.

1289

Supporting Organizations or Advisory Committees, in accordance with their respective
internally defined processes, will appoint individuals who have submitted Expressions ofInterest. In the case of the non-ccNSO ccTLD representative, the ccNSO will be theappointing body; in appointing the non-ccNSO representative it is strongly recommended
that the ccNSO also consult with the Regional ccTLD Organizations, namely AfTLD,
APTLD, LACTLD, and CENTR.

1290

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

1291

The IANA Function Review Team defined above will have the primary responsibility forcarrying out the IANA performance review, including: Review and evaluation 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 forcommunity input; and Development of recommendations on changes to the IANA SOW, and to IANA
Functions Operator performance.

1292

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

1293

The IANA Function Review Team will be an internal-to-ICANN body defined within the
ICANN bylaws as a fundamental bylaw. ICANN will provide secretariat and other support for
the IANA Function Review Team.

1294

What sort of process structure is warranted?

1295

The CWG-Stewardship recommends that the IANA Function Review be organized along thesame 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 IANA
Stewardship Transition recommendations. As with the CWG-Stewardship, this review groupwill be co-chaired by someone designated by the GNSO and someone designated by the
ccNSO. The groups will work on a consensus basis. In the event that consensus could not
be reached, the IANA Function Review Team could decide by a majority vote of the groupmembers.
IANA Stewardship Transition Proposal Page 86 of 199

Part 1: Response from the Domain Names Community

1296

The CWG-Stewardship expects that each IANA Function Review should take nine months
from the appointment of members to the IANA Function Review Team to the publication of a
final report, including conducting two 40-day public comment periods.

1297

How is the wider community involved in such a review?

1298

As with other Cross Community Working Groups, the CWG-Stewardship recommends that
all mailing lists and meetings will be open to interested participants and transparent, withrecordings and transcripts made available to the public. At several stages in the process,community comment will be requested: Near the beginning of the process, the community will be asked to consider issues
relevant to the review; and Midway through the process, a draft report will be provided for community review.

1299

Once the final report is prepared, it will be provided to the community.

1300

What should trigger reviews?

1301

Similar to the Affirmation of Commitment (AoC) Reviews, the IANA Function Review 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 IANA Function Review Team and complete the IANA Function Review within
two years of the date of the IANA Stewardship Transition. Subsequent reviews will bescheduled to occur at no more than five-year intervals from the date of the initial IANA
Function Review.

1302

A non-periodic or “Special” IANA Function Review (Special IFR) can only be initiated when
the following escalation mechanisms have been exhausted: CSC remedial action procedures are followed and fail to address the identified
deficiency (see Annex G); and The IANA Problem Resolution Process is followed and fails to correct the deficiency(See Annex J).

1303

Following exhaustion of the foregoing escalation mechanisms, the ccNSO and GNSO will
be responsible for checking and reviewing the outcome of the CSC process (as defined in
Annex G), and the IANA Problem Resolution Process (as defined in Annex J) and for
determining whether or not a Special IFR is necessary. After consideration, which may
include a Public Comment period and must include meaningful consulatation with other
SO/ACs. In order to trigger a Special IFR, it would require a vote of both of the ccNSO andGNSO Councils (each by a supermajority vote according to their normal procedures fordetermining supermajority). The Special IFR will follow the same multistakeholder crosscommunity composition and process structure as the periodic IANA Function Review.The
scope of the Special IFR will be narrower than a periodic IFR, focused primarily on theidentified deficiency or problem, its implications for overall IANA performance, and how thatissue is best resolved. As with the periodic IFR, the Special IFR is limited to a review of theperformance of the IANA Functions operation and should not consider policy development
and adoption processes or the relationship between ICANN and its contracted TLDs.

IANA Stewardship Transition Proposal Page 87 of 199

Part 1: Response from the Domain Names Community

1304

The requirement to conduct and facilitate the periodic and special IANA Function Reviews
would be articulated in the ICANN Bylaws and included as an ICANN fundamental bylaw
under consideration by CCWG-Accountability. In addition, the IFR and Special IFR
mechanisms could be set forth in the contract between ICANN and Post-Transition IANA or
PTI.

1305

CCWG Accountability Dependencies

1306

Enumeration of the relevant accountability mechanisms relating to the IFR and Special IFR:
 Creation of an ICANN fundamental bylaw to describe the IFR and Special IFR
mechanisms, including the above voting thresholds for triggering a Special IFR (i.e.,
after specified escalation methods have been exhausted and then upon a supermajority
vote of each of the ccNSO and GNSO Councils) and approval of the outcomes of an IFR
and Special IFR (which may include a separation process, as described in Annex L).

1307

Table of Reviews
36. Review Type

37. Frequency

38. Responsible

39. IANA Function
Review (IFR)
including:

41. Initially, twoyears, thenmoving to no
more than fiveyears

45. IANA Function
Review Team

40. Statement Of Work
(SOW)

46.

42.
43.
44. Special IFR canalso be triggeredby the ICANN
community
47. Review monthly
performance report

48. Monthly

49. CSC

50. Site visit

51. On-demand

52. IANA Function
Review Team

53. Review CSC reporton IANA Functions
Operator
performance SOW
report

54. Annual

55. AC/SO/ICANN

58. Review performance
metrics

59. Quarterly

56. Comment
period
57. ICANN Board
60. CSC

IANA Stewardship Transition Proposal Page 88 of 199

Part 1: Response from the Domain Names Community

61. Review customer
survey report

62. Yearly

63. CSC

64. Review security
audit process report

65. Annual

66. CSC

67. Review RZM audit
report

68. Quarterly

69. CSC
70. Root Zone
Operators

71. Review annual audit
report72. Annually

73. CSC with
community
input (i.e.,
open ICANN
comments)
74.

75. Review Conflict ofInterest Enforcement
Compliance audit
report76. Annually

77. Community
review(AC/SO/Board)
with comments
to IFO

IANA Stewardship Transition Proposal Page 89 of 199

Part 1: Response from the Domain Names Community

P1. Annex G: Proposed Charter of the Customer Standing
Committee (CSC)
1308

Mission1309

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

1310

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 thenaming services are top-level domain registry operators, but also include root server
operators and other non-root zone functions.

1311

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 toengage with the IANA Functions Operator to remedy identified areas of concern.

1312

The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special
IANA Function Review, but could escalate a failure to correct an identified deficiency to the
ccNSO and GNSO, which might then decide to take further action using agreed consultationand escalation processes, which may include a Special IANA Function Review.

1313

Scope of Responsibilities

1314

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

1315

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

1316

The CSC is authorized to undertake remedial action to address poor performance inaccordance with the Remedial Action Procedures (see illustrative procedures at the end of
this Annex). The Remedial Action Procedures are to be developed and agreed to by the
CSC and the IANA Functions Operator post-transition, once the CSC is formed.

1317

In the event performance issues are not remedied to the satisfaction of the CSC, despite
good-faith attempts to do so, the CSC is authorized to escalate the performance issues tothe ccNSO and GNSO for consideration.

1318

The CSC may receive complaints from individual registry operators regarding theperformance of the IANA Naming Function; however, the CSC will not become involved in a
direct dispute between any registry operator and IANA.

1319

The CSC will review individual complaints with a view to identifying any patterns of poor
performance by the IANA Functions Operator in responding to complaints of a similar
nature. In relation to problem resolution, if CSC determines that remedial action has been
IANA Stewardship Transition Proposal Page 90 of 199

Part 1: Response from the Domain Names Community

exhausted and has not led to necessary improvements, the CSC is authorized to escalate to
the PTI Board and further if necessary.
1320

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 the IANA Functions Operator.

1321

The CSC, in consultation with registry operators, is authorized to discuss with the IANA
Functions Operator ways to enhance the provision of IANA’s operational services to meetchanging 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 naming
services or operations would be beneficial, the CSC reserves the right to call for acommunity consultation and independent validation, to be convened by the IANA Functions
Operator, on the proposed change. Any recommended change must be approved by the
ccNSO and RySG.

1322

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

1323

The CSC will provide a liaison to the IANA Function Review Team and a liaison to any
Separation Cross Community Working Group.

1324

Conflict of Interest

1325

The ICANN Bylaws make clear that it must apply policies consistently, neutrally, objectively
and fairly, without singling any party out for discriminatory treatment; which would requiretransparent fairness in its dispute resolution processes. Members of the CSC should
accordingly disclose any conflicts of interest with a specific complaint or issue under review.
The CSC may exclude from the discussion of a specific complaint or issue any member
deemed by the majority of CSC members and liaisons to have a conflict of interest.

1326

Membership Composition

1327

The CSC should be kept small and comprise representatives with direct experience andknowledge of IANA naming functions. At a minimum the CSC will comprise: Two gTLD Registry Operators.
 Two ccTLD Registry Operators.
 One additional TLD representative not considered a ccTLD or gTLD registry operator
such as the IAB for .ARPA could also be included in the minimum requirements but is
not mandatory.
 One liaison from the IANA Functions Operator (PTI).

1328

Liaisons can also be appointed from the following organisations; however, providing a
Liaison is not mandatory for any group: One liaison each from other ICANN SOs and ACs:
IANA Stewardship Transition Proposal Page 91 of 199

Part 1: Response from the Domain Names Community

 GNSO (non-registry) ALAC NRO (or ASO)
 GAC
 RSSAC SSAC

1329

Liaisons shall not be members of or entitled to vote on the CSC, but otherwise liaisons shallbe entitled to participate on equal footing with members of the CSC.

1330

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, and cannot be the IANA Functions
Operator Liaison.

1331

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

1332

The CSC as a whole will decide who will serve as the Liaison to the IANA Function Review
Team. Preference should be given to the Liaison being a registry representative given thattechnical expertise is anticipated to be valuable in the role.

1333

Membership Selection Process

1334

Members and Liaisons to the CSC will be appointed by their respective communities inaccordance with internal processes. However, all candidates will be required to submit an
Expression of Interest that includes a response addressing the following matters: Why they are interested in becoming involved in the CSC.
 What particular skills they would bring to the CSC.
 Their knowledge of the IANA Functions.
 Their understanding of the purpose of the CSC.
 That they understand the time necessary required to participate in the CSC and cancommit to this role.

1335

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

1336

While the ccTLD and gTLD members will be appointed by the ccNSO and RySG
respectively and liaisons by their applicable groups, ccTLD or gTLD registry operators thatare not members of these groups will be eligible to participate in the CSC as members or
liaisons. The ccNSO and RySG should consult prior to finalizing their selections with a viewto providing a slate of members and liaisons that has, to the extent possible, diversity interms of geography and skill set.

IANA Stewardship Transition Proposal Page 92 of 199

Part 1: Response from the Domain Names Community

A representative for a TLD registry operator not associated with a ccTLD or gTLD registry,
will be required to submit an Expression of Interest to either the ccNSO and GNSO Council.
The Expression of Interest must include a letter of support from the registry operator. This
provision is intended to ensure orderly formal arrangements, and is not intended to imply
those other registries are subordinate to either the ccNSO or the GNSO.
1337

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

1338

Terms

1339

CSC appointments, regardless of whether members or liaisons, will be for a two-year periodwith the option to renew for up to two additional two-year terms. The intention is to stagger
appointments to provide for continuity and knowledge retention.

1340

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.

1341

CSC appointees must attend a minimum of nine meetings in a one-year period, and mustnot 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.

1342

Recall of members

1343

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

1344

In the event that a ccTLD or gTLD registry representative is recalled, a temporary
replacement may be appointed by the designating group while attempts are made to fill thevacancy. As the CSC meets on a monthly basis best efforts should be made to fill a vacancy
within one month of the recall date.

1345

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.

1346

Meetings

1347

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

1348

The CSC will provide regular updates, no less than three 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.

1349

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

IANA Stewardship Transition Proposal Page 93 of 199

Part 1: Response from the Domain Names Community

1350

Record of Proceedings

1351

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

1352

Any remedial action will also be reported by the CSC.

1353

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

1354

Secretariat

1355

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.

1356

Review

1357

The Charter will initially be reviewed by a committee of representatives from the ccNSO andthe RySG one year after the first meeting of the CSC. The review is to include theopportunity for input from other ICANN stakeholders, via a Public Comment process. Any
recommended changes are to be ratified by the ccNSO and the GNSO.

1358

Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO andmay also be reviewed in connection with the IANA Function Review.

1359

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.

1360

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

================================
1361

Proposed Remedial Action Procedures

1362

This proposal is illustrative of what could be included in the Remedial Action Procedures. It
is anticipated that the procedures would be agreed between the CSC and the IANA
Functions Operator prior to implementation.

Occurs

Notification

1st EscalationProcess
control limit
exceeded

Correctiveaction plan late





IANA
customerpresents
evidence that
IANA did not

Corrective
action plan
milestones
missed

2nd Escalation

Two or more
additional

3rd Escalation

Corrective action plan late

Corrective action
plan milestones
missed

Two or more
additional“notification”

Corrective action
plan from 2nd
escalation notdelivered or
executed timely.
Additional similar
violations occur
when corrective

IANA Stewardship Transition Proposal Page 94 of 199

Part 1: Response from the Domain Names Community“notification”
violations
occur while
corrective
action plan is
openmeet SLE

IANA periodic
reportindicates SLE
not metviolations occur
while corrective
action plan is
supposed to bein place

action from 2nd
escalation is
supposed to bein place

Addressee

IANA Manager

PTI Board

Global Domains
Division President

ICANN Board, CEO

Message
Content

Identify SLE
breach andevidenceSame aspreviousSame aspreviousConferencecall request to
discuss
issues raisedby CSCmessage.

Corrective
actionrequirement
Time frame

Same asprevious plus

Same asprevious plus

Organizational, operationalchanges tocorrect lack ofcorrective actionResponse
Requested 

Identify SLE
breach andevidence
Conference
call request to
discuss issues
raised by CSC
message.
Corrective
actionrequirement
Time frame

Identify party
requiring
response
Agreementthat SLE
violation
occurred (orevidence tocontrary)Reissuecorrective
action plan to:

Remediate
earlier failed
plan

Cause





Correction
made onindividual
caseInclude new
violations



Corrective
action plan
milestones
missed

Two or more
additional“notification”
violations
occur while
corrective
action plan isopen

Corrective
action plan to:remedycurrent
situation



prevent future
occurrence

Corrective
action planrequired in
14-daysRemediation
through the
ICANN-PTI
Contract and/orSpecial IFR

IANA Stewardship Transition Proposal Page 95 of 199

Part 1: Response from the Domain Names Community

P1. Annex H: Service Level Expectations
The CWG-Stewardship is not proposing any changes to the current work flow process. The
CWG-Stewardship is suggesting that there is a requirement placed on IANA staff, (as part ofthe implementation phase) to measure, record and report additional details of transaction times
for each Root Zone Management process.
Such transparency will provide factual information to assist the CSC, IFRT and the Community
to determine and confirm that the IANA Functions Operator is continuing to provide nondiscriminatory service to the naming community. Further by having clarity as to process, it canbe confirmed that IANA staff may not be the cause of the delay in the execution of the change
request. On other occasions due to the wide time window for current SLEs, there is an
opportunity for — or the perception for — certain TLD Managers to have preferential treatment
and change requests completed in a matter of days, whilst other requests take much longer andyet still be in the approved time.
Principles
These are a set of guiding principles that will help define the expectation for the monitoring andreporting environment, and guide the definition of the individual criteria used for reporting andassessment of the naming-related portions of the IANA Functions:
1. Attributable measures. Unless clearly impractical, individual metrics should bereported attributing time taken to the party responsible. For example, time spent by
IANA staff processing a change request should be accounted for distinctly from timespent waiting for customer action during a change request.
2. Overall metrics. In addition to the previous principle, overall metrics should be reported
to identify general trends associated with end-to-end processing times and processing
volumes.
3. Relevance. All metrics to be collected should be relevant to the validation of customer
service. In addition some are the critical metrics that are considered important to set
specific thresholds for judging breaches in the IANA Functions Operator’s ability toprovide an appropriate level of service.
4. Clear definition. Each metric should be sufficiently defined such that there is acommonly held understanding on what is being measured, and how an automatedapproach would be implemented to measure against the standard.
5. Definition of thresholds. The definition of specific thresholds for performance criteria
should be set based on analysis of actual data. This may require first the definition of a
metric, a period of data collection, and later analysis by IANA customers before defining
the threshold.
6. Review process. The service level expectations should be reviewed periodically, andadapted based on the revised expectations of IANA’s customers and relevant updates tothe environment. They should be mutually agreed between the community and the IANA
Functions Operator.
7. Regular reporting. To the extent practical, metrics should be regularly reported in anear real-time fashion.

IANA Stewardship Transition Proposal Page 96 of 199

Part 1: Response from the Domain Names Community

Capturing the current status-quo for IANA Root Zone Management
Introduction
Service Level Expectations (SLEs) for a domain name registry are typically based on
measuring specific transactions sent by a client to the registry. The metric for a transaction
is generally of the form of “Transaction A must complete within X period Y percent of thetime measured over Z”, for example, “a root zone update must complete within 72 hours
95% of the time measured on a monthly basis”. The Root Zone Management processcurrently presents unique challenges in that IANA is not responsible for all phases ofprocessing, therefore the SLEs must be written to accommodate the phases of the process,and to be mindful of the different attribution for these phases.
These SLE metrics are based on the following current assumptions:
A. For the purposes of the SLE discussion, the current process is simplified to five key
stages for all change requests (notification is implicit in each stage):
1. Confirm the details of the change.
2. Verify the change complies with documented technical standards and policies
and all applicable checks pass.
3. Obtain authorization/consent to proceed with the change.
4. Implement the change.
5. Notify the change requester of completion of the change.
B. Root Zone Management processes for routine change requests are largely automated.
This automation includes:
1.
A web-based interface for submitting change requests to the IANA Functions
Operator. The web-based interface authenticates the credentials presented by the change
requester and facilitates the creation of root zone file and root zone database change
requests.
2.
Near-real time confirmation email to the initiator of the change request of its safe
receipt by the IANA system. Note, in certain circumstances, the request is initiated byother means such as fax or written letter. In these situations, email may not necessarily be
used in communications.
3.
Automated technical checks conducted by the IANA system on the change
request. These checks ensure conformance of the technical data with agreed minimum
standards, and check for errors in the material submitted.
4.
Seeking consent from the relevant contacts for the domain, through an
automated email verification process where approval requests are sent to both, at aminimum, the admin and technical contacts at the Registry for both parties to consent tothe update. (Note: Some contacts are slow to respond which creates inefficiency in thevalidation process. In certain circumstances, third party verification is also required, e.g.
governmental approvals).

IANA Stewardship Transition Proposal Page 97 of 199

Part 1: Response from the Domain Names Community

5.
The verified change request is transmitted to NTIA for authorization. For changes
that impact the root zone file, the change request is also transmitted to the Root Zone
Maintainer This is performed via an online interface.
6.
Once confirmed, notification is sent by NTIA to the IANA Functions Operator, andfor changes that impact the root zone file, to the Root Zone Maintainer authorizing thechange request for implementation.
7.
Prior to implementation, the Root Zone Maintainer repeats automated technicalcompliance checks on the request and once verified, implements the change within theroot zone file. This file is typically published twice daily.
8.
On publication of updates to the Root Zone file, Root Zone Maintainer notifies
the IANA Functions Operator, who verifies the changes match the requested changes,
and notifies the Registry.

C. The processing role currently undertaken by the NTIA will no longer exist in a posttransition environment and those steps will no longer be undertaken. This means that IANA
will have responsibility for triggering implementation at the conclusion of processing andcommunicating directly with the maintainer of the Root Zone.

D. IANA’s online systems operate 24 hours a day, 365 days a year, except for maintenanceperiods, as befits a service that has customers around the globe.

Monitoring Past Performance:(We accept past performance is no indication of future performance but is does capture thestatus-quo).

The CWG-Stewardship conducted a historical analysis of IANA performance based on two
sources: data published in IANA performance reports, and transaction logs provided by
ccTLD registries interacting with the IANA root management function. The data sourceswere for the period September 2013 to January 2015, which provided approximately 565
total data points – only 27 transactions took longer than 9 days and 13 took longer than 12
days. It should also be highlighted that some/much of the delay is as a result of the Registry
not responding to the IANA Functions Operator to authorize the change request – so thedelay is not necessarily within the IANA Functions Operator’s control. Four transactions took
longer than one year (which is not necessarily a problem if the stability of the DNS isassured). A summary of this research is presented here.

Work to define the final SLE to be included with the proposal submitted to the NTIA will be
run in parallel with the ICG process to review the CWG-Stewardship proposal. The objective
is to ensure that the CWG-Stewardship proposal is not delayed by work to define the SLEs
and so to optimize use of the time prior to the final submission of a proposal to the NTIA.
Review of the ongoing work can be viewed here: https://community.icann.org/x/CA4nAw.
IANA Stewardship Transition Proposal Page 98 of 199

Part 1: Response from the Domain Names Community

P1. Annex I: IANA Customer Service Complaint Resolution
Process for Naming Related Functions
1363(Modified Procedure)

1364

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

1365

If anyone experiences an issue with the IANA Functions 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.

1366

Phase 1 – Initial remedial process for IANA naming functions

1367

The complainant could 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:
 IANA Function Liaison for Root Zone Management;
 IANA Functions Program Manager; and Ombudsman (voluntary step).

1368

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, thecomplainant is not satisfied with the resolution process, the complainant can use theOmbudsman (or similar process) instead.

1369

Who can use the process?

1370

This process is open to anyone.74 The functions include:Protocol Parameters management, including the management of the .ARPA TLD.

Root Zone Management;

Root DNS KSK Management;Internet Number Resources Allocation; andManagement of the .INT TLD.

1371
1372

What information must be provided?

1373

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

74 Including individuals, ccTLD regional organizations, ICANN SO/ACs, etc.

IANA Stewardship Transition Proposal Page 99 of 199

Part 1: Response from the Domain Names Community

1374

What is the expected time line?

1375

Receipt of a 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.

1376

Is there another resolution process?

1377

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

1378

Escalation contact information for the current IANA Functions Operator(ICANN)
Role

IANA
IANA Function Liaison for Technical Protocol
Parameters Assignment
IANA Function Liaison for Root Zone Management
IANA Function Liaison for Internet Number Resource
Allocation
IANA Functions Program Manager
Ombudsman

Name
Email Address
IANA Staff
iana@iana.org
Michellemichelle.cotton@icann.org
CottonKim Davies kim.davies@icann.org
Naela Sarras Naela.sarras@icann.org
Elise Gerich elise.gerich@icann.org
Chrisombudsman@icann.org
LaHatte1379

If an issue is escalated to members of the IANA team and/or to the Ombudsman orequivalent, the CSC is notified of the issue for informational purposes only.

1380

Phase 2 (for IANA naming services only)

1381

Should the issue not be resolved after Phase 1, the following escalation mechanisms will bemade available to direct customers, the IFO and the ICANN Ombudsman:75a) If issue is not addressed, the complainant (direct customer), IFO or the ICANN
Ombudsman may request mediation.76b) CSC is notified of the issue by complainant and/or the IANA Functions Operator.
CSC reviews to determine whether the issue is part of a persistent performanceissue and/or is an indication of a possible systemic problem. If so, the CSC may
seek remediation through the IANA Problem Resolution Process (see Annex J).
c) The complainant (direct customer) may initiate an Independent Review Process or
pursue other applicable legal recourses that may be available, if the issue is notaddressed.

75

Non-direct customers, including TLD organizations,that are of the view that an issue has not been addressed
through Phase 1 may escalate the issue to the ICANN Ombudsman or via the applicable liaisons to the CSC to
Phase 2.
76 The CWG-Stewardship recommends that as part of the implementation of this proposal, ICANN Staff explore
possible approaches with regards to mediation such as, for example, Section 5.1 of the Base gTLD Registry
Agreement (https://www.icann.org/resources/pages/registries/registries-agreements-en).

IANA Stewardship Transition Proposal Page 100 of 199

Part 1: Response from the Domain Names Community

P1. Annex J: IANA Problem Resolution Process (for IANA
naming services only)
1382(New procedure)

1383

Problem resolution (including responding to persistent performance issues orsystemic problems)

1384

The Customer Standing Committee (CSC) is authorized to monitor the performance of the
IANA Functions against agreed service level targets on a regular basis. In the event thatpersistent performance issues are identified by the CSC, the CSC will seek resolution inaccordance with a Remedial Action Plan, which includes:
1) CSC reports persistent performance issues to the IANA Functions Operator staff andrequests remedial action in a predetermined number of days.
2) CSC confirms completion of remedial action.
3) If CSC determines that the remedial action has been exhausted and has not led tonecessary improvements, the CSC is authorized to escalate to the PTI Board andfurther if necessary.
4) If the performance issues are still not resolved after escalation to the PTI Board, the
CSC is authorized to escalate to the ccNSO and/or the GNSO,77 which might thendecide to take further action including the initiation of a Special IFR.

1385

Systemic problems

1386

The IANA Function Review will include provisions to consider and address whether there
are any systemic issues that are impacting IANA naming services.

77 The roles of the ccNSO and GNSO in this step should be further investigated to ensure that this is consistent with

their missions as well as to identify any actions that may be needed by the SOs to allow for this role.

IANA Stewardship Transition Proposal Page 101 of 199

Part 1: Response from the Domain Names Community

P1. Annex J-1: Escalation Mechanisms Flow Charts

IANA Stewardship Transition Proposal Page 102 of 199

Part 1: Response from the Domain Names Community

IANA Stewardship Transition Proposal Page 103 of 199

Part 1: Response from the Domain Names Community

IANA Stewardship Transition Proposal Page 104 of 199

Part 1: Response from the Domain Names Community

P1. Annex K: Root Zone Emergency Process1387

In addition to 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 the IANA Functions
Operator to declare an emergency and seek to expedite a Root Zone change
request. The IANA Functions Operator will execute such changes in accordance withthe 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 of any pending changes that will require priority
authorization and implementation.

1388

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
TLD Manager
3. Call IANA FO
During Business
Hours

1. TLD Contacts
Call Center

END

Call Center
2. Does Caller
DeclareEmergency?

No

Yes

4. Follow Instructions
and ask Questions

6. Call Center reaches the
IANA FO Emergency
Response Team

5. Send email toroot-mgmt@iana.org

IANA Functions Operator

7. Has Someone
from RZM Been
Informed?

Yes

9. RZM Team
Contacts Respective
TLD and Gathers
Information

10. RZM Team
Confirms
Emergency

NoYes

12. Validate
Requested
Changes

13. Give
Heads Up to
RZM

14. Act According to
RZM Change
Request, Process
ExpeditiouslyNo

11. Inform TLD About
Appropriate Options

8. Pass Info on to
RZM Team

END

IANA_032v5

Process

Decision

Manual Process

Subprocess

A

B

C

On Page Reference

Start/End

Document

Off Page Reference

IANA Stewardship Transition Proposal Page 105 of 199

Part 1: Response from the Domain Names Community

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

1

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

2

DOES CALLER DECLARE AN EMERGENCY?
The caller is asked if the issue is an emergency that requires
an urgent root zone change, and can not wait until regularbusiness hours.
CALL IANA Functions Operator DURING BUSINESS HOURSIn the event the caller decides it is not an emergency, theircontact details are logged and they are advised to speak to
IANA Function staff during regular business hours.

Description

Description

3
Description

4

FOLLOW INSTRUCTIONS AND ASK QUESTIONS

5Call center staff follow a set of instructions to solicit relevant
information relating to the nature of the emergency, and thecontact details of the TLD manager.
SEND EMAIL TO ROOT-MGMT@IANA.ORG
The particulars of the emergency call are sent by the callcenter staff to the ticketing system. This opens a ticket andstarts an audit log of the specific request.

Description

Description

6

CALL CENTER REACHES THE IANA Functions Operator
EMERGENCY RESPONSE TEAM
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 theroster 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

HAS SOMEONE FROM THE ROOT ZONE MANAGEMENT(RZM) TEAM BEEN INFORMED?

Description

Description

8
Description
9
Description

10

The primary person responsible checks if the Root Zone
Management team within the IANA Functions staff is aware of
the issue.
PASS INFO ON TO RZM TEAM
If necessary, information relating to the emergency request iscommunicated to the Root Zone Management team.
RZM TEAM CONTACTS TLD MANAGER
The IANA Functions staff performing the root zone
management functions contacts the TLD manager using
the contact details provided to the call center. The natureof the issue is discussed in more detail, and a plan isdevised to resolve the issue.
RZM TEAM CONFIRMS EMERGENCY

IANA Stewardship Transition Proposal Page 106 of 199

Part 1: Response from the Domain Names Community

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

Description

11

INFORM TLD ABOUT APPROPRIATE OPTIONSIn 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

VALIDATE REQUESTED CHANGESIANA Functions Operator validates the request in accordancewith the standard procedures described in the Root Zone
Change process, including performing technical checks andperforming contact confirmations. IANA Functions Operator
takes steps to conduct these as quickly as possible.

13

GIVE HEADS UP TO Root Zone Maintainer
IANA Functions Operator takes all available steps to inform
personnel at the Root Zone Maintainer that there is an active
emergency change request being conducted, and encourages
the Root Zone Maintainer to process the request as quickly as
possible.
ACT ACCORDING TO ROOT ZONE CHANGE REQUESTPROCESS
EXPEDITIOUSLY
IANA Functions
Operator
executes the root zone change
request as quickly as possible according to all standard
policies and procedures. IANA Functions Operator prioritizes the
rapid implementation of the request above other requests at
normal priority.

Description

Description

Description

14
Description

IANA Stewardship Transition Proposal Page 107 of 199

Part 1: Response from the Domain Names Community

P1. Annex L: Separation Process1389

In the event that an IANA Function Review results in a decision to initiate aseparation process, the following processes must be followed.

1390

If the IFR determines that a separation process is necessary, it will recommend thecreation of a Separation Cross Community Working Group (SCWG). This
recommendation will need to be approved by a supermajority of each of the GNSO
and the ccNSO Councils, according to their normal procedures for determining
supermajority, and will need to be approved by the ICANN Board after a publiccomment period, as well as a community mechanism derived from the CCWGAccountability process.78 A determination by the ICANN Board to not approve a
SCWG that had been supported by a supermajority of the ccNSO and GNSO
Councils will need to follow the same supermajority thresholds and consultation
procedures as ICANN Board rejection (by a supermajority vote) of a PDP
recommendation that is supported by a GNSO supermajority.

1391

There will be no prescribed result arising from the separation process. It will beempowered to make a recommendation ranging from “no action required” to theinitiation of an RFP and the recommendation for a new IFO, or the divestiture or
reorganization of PTI. The SCWG will follow the overall guidelines and proceduresfor ICANN Cross Community Working Groups. The SCWG working proceduresshould ensure transparency to the fullest extent possible by creating open discussion
listservs and holding open calls, with read- or listen-only modes for non-participants.
79

1392

Composition

1393

The SCWG will be composed as follows:80
 ccNSO - 2
 ccTLDs (non-ccNSO) - 1
 Registry Stakeholder Group (RySG) - 3
 Registrar Stakeholder Group (RrSG) - 1
 Commercial Stakeholder Group (CSG) - 1
 Non-Commercial Stakeholder Group (NCSG) - 1
 Government Advisory Committee (GAC) - 1

78 This community mechanism could include ICANN membership, if ICANN were to become a membershiporganization per the CCWG-Accountability work efforts.
79 Any other recommendations produced by the Special IFR would need to include implementation
recommendations, including the possible initiation of an SCWG with a specific mandate, and would need tobe approved by a supermajority of each of the ccNSO and GNSO Councils, the ICANN Board and acommunity mechanism derived from the CCWG-Accountability process.
80 Given the unique purpose and task of the Separation Cross Community Working Group, if thiscomposition diverges from the recommendation of the Cross Community Working Group on Principles for
Cross Community Working Groups, the structure in this proposal shall prevail.

IANA Stewardship Transition Proposal Page 108 of 199

Part 1: Response from the Domain Names Community

 Security and Stability Advisory Committee (SSAC) - 1
 Root Server Operators Advisory Committee (RSSAC) - 1
 At-Large Advisory Committee (ALAC) - 1
 CSC Liaison (selected by CSC) - 1
 Special IFR Team Liaison (selected by IFR Team) - 1
 Liaison from Protocol operational community - 1 (TBD with their approval)
 Liaison from Numbers operational community - 1 (TBD with their approval)
1394

Each group will be responsible for appointing its own representative to the SCWG. In
the case of the non-ccNSO ccTLD representative, the ccNSO will be the appointing
body; in appointing the non-ccNSO representative it is strongly recommended thatthe ccNSO also consult with the Regional ccTLD Organizations, namely AfTLD,
APTLD, LACTLD, and CENTR.

1395

It is strongly recommended that the representatives appointed to the SCWG be
different representatives than those that participated in the Special IFR (with the
exception of the liaison to the IANA Function Review Team appointed by the CSC).
This will provide an additional check, accounting for the fact that different skill sets
may be required for the two processes, and provide for broader community
representation in the IANA oversight process.

1396

To the extent possible, it is recommended that individuals with experience managing
an RFP process be appointed to the SCWG. For communities appointing more than
one representative to the SCWG it is strongly advised that, to the extent possible, theappointed representatives come from different ICANN geographic regions, to provide
for diversity on the SCWG.81

1397

Responsibilities

1398

The SCWG will be responsible for:
 Determine how to resolve the issue(s) which triggered formation of the SCWG;
and If the decision is to issue an RFP: Developing RFP Guidelines and Requirements for the performance of the
IANA Naming Functions; Soliciting input on requirements to plan, and participation in, the RFP
Process;
 Reviewing responses to the RFP82;
 Selecting the entity that will perform the IANA Naming Functions; and81 One specific expectation is that with six total registry seats on the SCWG, including ccTLD and gTLD

registries, all five ICANN geographical regions be represented.
82 The then current IFO would not be prevented from participating in the RFP. In the event of the PTI, it
would be possible for either the S-IFR or the PTI itself to recommend changes to its structure to betteraccomplish it task and to remediate any problems. This remediation could include recommendations forfurther separation.

IANA Stewardship Transition Proposal Page 109 of 199

Part 1: Response from the Domain Names Community

 Managing any other Separation Process.
 If a different process such as PTI divestiture or other reorganization is to berecommended, develop recommendations for that process.
1399

The selection of a new operator to perform the IANA Naming Functions or otherseparation process will be subject to approval by the ICANN Board, and acommunity mechanism derived from the CCWG-Accountability process.83 A
determination by the ICANN Board to not approve a recommendation by the SCWG
that had been supported by a supermajority of the ccNSO and GNSO Councils willneed to follow the same supermajority thresholds and consultation procedures as
ICANN Board rejection (by a supermajority vote) of a PDP recommendation that is
supported by a supermajority of the GNSO.
The entity prevailing in the RFP will carry out the role currently performed by PTI for
the IANA naming functions. ICANN will remain the contracting party for the
performance of the IANA naming functions and would enter into a contract, including
a statement of work, with this entity. If PTI were selected to continue performance of
the IANA Functions, it would remain an affiliate of ICANN (unless a structural change
was a condition of the bid proposal or of the selection). Otherwise, the newentity would be a subcontractor for the performance of the IANA Functions. It should
be noted that this does not address the way that non-naming IANA functions would
be provided; depending on the arrangements with other communities, it is possiblethat those functions would move in concert with the naming functions; it is equallypossible that they would not.

1400

CCWG Accountability Dependencies

1401

Enumeration of the relevant accountability mechanisms that could or must be
exhausted before a separation process could be triggered: Creation of an ICANN fundamental bylaw to describe the IANA Function Review(IFR) and establish the above voting thresholds for triggering a Special IFR andapproving the outcomes of an IFR.
 Creation of an ICANN fundamental bylaw to describe the procedure for creating
the SCWG and its functions and establish the voting thresholds for approval of anew operator for the performance of the IANA Functions or other end-result of
the SCWG process.
 Approval by a community mechanism derived from the CCWG-Accountability
process to approve the final selection of the SCWG (if this tenet of the CCWGAccountability proposal is not implemented a new approval mechanism will haveto be put in place.
 Per the above separation process the selection of the entity that would
perform the IANA naming functions following a separation process will
require community approval through the established mechanism derived
from the CCWG-Accountability process.

83 This community mechanism could include ICANN membership, if ICANN were to become a membershiporganization per the CCWG-Accountability work efforts.

IANA Stewardship Transition Proposal Page 110 of 199

Part 1: Response from the Domain Names Community

P1. Annex M: Framework for Transition to Successor
IANA Functions Operator
1402

Framework principles
 The integrity, stability, and availability of the IANA Functions must be the core
concern during any transition of the IANA Functions.
 Both the incumbent and any possible future IANA Functions Operator will be
required to fully engage in the transition plan.
 All involved parties will be required to provide appropriate transition staff andexpertise to facilitate a stable transition of the IANA operations.

1403

Framework recommendations
1) The transition framework outlined in this document must 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 forthe detailed transition plan development referred to in 1 (see above).
3) The process established for the potential transitioning of the IANA Functions toan operator other than the incumbent operator should specifically recognize thatthe detailed transition plan referred to in 1 (see above) must be in place before
the commencement of the transitioning process.
4) Once developed, the full Transition to Successor IANA Functions Operator Planshould be reviewed every year to ensure that it remains up to date and every five
years to ensure that it remains fit for purpose.

1404

Dependencies

1405

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

1406

Additionally, part of the final proposal development work will need to identify thoseelements/clauses of the CWG-Stewardship’s proposal that are relevant to thetransition framework (using the NTIA-ICANN Functions Contract clauses table in
C.7.3 for guidance).

1407

Note on terminology: While the current plan is based on a contractual relationshipbetween the NTIA and ICANN, the CWG-Stewardship has elected to refer to the“operator” of the IANA Functions rather than “contractor” for the purposes of this

IANA Stewardship Transition Proposal Page 111 of 199

Part 1: Response from the Domain Names Community

annex. So ICANN as the current operator is referred to as the Incumbent IANA
Functions Operator (IIFO) and the successor operator is referred to as the
Successor IANA Functions Operator (SIFO) in this Annex M.

1408(Revised) plan: framework for transition to Successor IANA Operator

1409

This framework plan outlines key actions that will allow the incumbent IANA
Functions Operator (IIFO) to ensure an orderly transition of the IANA Functions to a
successor IANA Functions Operator (SIFO) while maintaining continuity and securityof operations.

1410

Document structure1411

This document identifies those functions, systems, processes and documents thatmight need to be transitioned by the incumbent IANA Functions Operator, including
actions that would be required to allow a successor operator to perform the IANA
Functions.

1412

Additional documents of importance to a transition include:84
 Current KSK Operator Function Termination Plan.
 Current CCOP (DIDP was not able to be released as requested through the
DIDP process due to security and stability related concerns).
 Current ICANN Plan for Transition to Successor Contractor.

1413

Transition actions
1) IANA website: The Incumbent IANA Functions Operator will transfer the content
of the IANA 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. Intellectual property
rights related to the IANA website and published documents will need to be
assigned or licensed to the successor operator.
2) IANA Functions registry data: Data held by IANA Functions Operator will alsoneed to transition, and some of that data will affect other communities; details of
the data that is being transitioned will be determined when the full transition planis produced.
3) Root Zone automation system: The Incumbent IANA Functions Operator willtransfer relevant information and management software, as appropriate and as
determined by the transition plan.
4) Request history data: The Incumbent IANA Functions Operator will provide a

84 All documents are available on the CWG-Stewardship Wiki here:

https://community.icann.org/display/gnsocwgdtstwrdshp/DT-L+Transition+Plan.

IANA Stewardship Transition Proposal Page 112 of 199

Part 1: Response from the Domain Names Community

copy of the databases it has used to store requests data, including ticketingsystems and workflow management systems used for protocol parameterregistries and the maintenance of the DNS Root Zone. The Incumbent IANA
Functions Operator will also provide copies of any published reports and paper
records it holds supporting these request histories.
5) Documentation and knowledge: The Incumbent IANA Functions Operator will
provide a copy of all documentation that captures formalized processes,
institutional knowledge and experience related to the operation of the IANA
Functions. The IIFO is also encouraged to provide documentation related toMonthly Performance Progress reports, Customer Satisfaction Surveys, External
Auditor reports, Conflicts of Interest processes established by the IIFO, and the
IIFO’s Contingency and Continuity of Operations Plan.
6) Secure notification system data The Incumbent IANA Functions Operator will
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 will take if required totransition its duties and responsibilities as the Root Zone Key Signing Key (KSK)
operator to another entity. This plan was provided to NTIA in 2010.85 That planrequires that a full KSK rollover be done so the successor starts fresh.86
8) Transition assistance: The Incumbent IANA Functions Operator will assist thesuccessor IANA Functions Operator during the transition period until the time therequisite service levels, security and stability are achieved. Such assistancewould include training the employees of the successor IANA Functions Operator
and developing training material.
9) Security for data retention: The Incumbent IANA Functions Operator willcontinue to provide security for any data retained by it after transferring such data
to the successor IANA Functions Operator.

85 KSK Termination Plan (June 2010)
86 Given that there has up to now never been such a KSK roll-over and given the desire to maintain stabilityof security of the root zone a somewhat lighter procedure can be followed (TBD). The important part is thetransfer of administration of the HSMs, related infrastructure and the operation of the key ceremonies. This
is not unlike the process that took place in April 2015 when the Hardware Security Modules (HSM) were
replaced - see: https://www.icann.org/news/announcement-3-2015-03-23-en

IANA Stewardship Transition Proposal Page 113 of 199

Part 1: Response from the Domain Names Community

P1. Annex O: ccTLD Appeals Mechanism Backgroundand Supporting Findings
1414

While the CWG-Stewardship’s 1 December, 2014 draft proposal contained an appeal
mechanism that would have applied to ccTLD delegation and redelegations, somequestion arose as to the level of support within the ccTLD community on aspects ofthis proposal (see below). 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 thesurvey and the results summarized below).

1415

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 3 April 2015. Overall, responses onbehalf of just 28 managers were received (see below). Such a low level of response
was judged to be an insufficient basis to provide a mandate for the inclusion of an
appeal mechanism in the CWG-Stewardship’s proposal. While acknowledging thelimitations of drawing any conclusions from a survey with such a low response rate, itis nevertheless worthwhile pointing out that these limited responses tended toreinforce the overall recommendation.

1416

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 Stewardship Transition and 73% (Q.3) agreed that it should be developed andintroduced after the IANA Stewardship 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 takeconsiderable time for the ccTLD community to come to a consensus view on thedetails of an appeal mechanism. Some 71% of respondents (Q.3) indicated that theywould not wish to see the design of such a mechanism delay the finalization of the
IANA Stewardship Transition.

1417

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

On 1 December 2014, the Cross Community Working Group on NTIA StewardshipTransition issued a draft proposal which contained a proposal for an “independent
appeals panel”:

1419“Independent Appeals Panel (IAP) - The CWG-Stewardship 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 ascommercial disputes are often resolved, through the use of a binding arbitration

IANA Stewardship Transition Proposal Page 114 of 199

Part 1: Response from the Domain Names Community

process using an independent arbitration organization (e.g., ICDR, ICC, AAA) or astanding list of qualified people under rules promulgated by such an organization.”
1420

There exists in the ccTLD community an apparent lack of consensus on the questionof the introduction of an ‘appeals mechanism’ in respect of ccTLD delegations andredelegations. At ICANN 51 in Los Angeles an overwhelming majority of ccTLD
representatives at the 15 October 2014 ccNSO meeting indicated their wish for an‘appeal mechanism’ as part of the IANA transition, though what was meant by ‘anappeal 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 ofneed resulted in the appeal mechanism proposal that the CWG-Stewardshipreleased on 1 December 2014. The proposal indicates that such a mechanism could
be used in disputes over the consistency of ccTLD delegation or redelegation
decisions.

1421

A survey was undertaken in January of this year of CWG-Stewardship members andparticipants (this includes representation from many communities, not just ccTLD
managers) on many aspects of the CWG-Stewardship’s 1 December proposal. It
found that 97% of respondents agreed that, “ccTLD registry operators should havestanding 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 ofsuch 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 arecontrary to applicable laws and/or applicable approved ccTLD policy, even if theoperator 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 toapplicable laws”.

1422

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 aspectsof such a mechanism, including: Who would ‘have standing’ to appeal 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.

1423

As a consequence, this survey is intended to determine whether they might besufficient consensus within the ccTLD community as a whole to seek a binding

IANA Stewardship Transition Proposal Page 115 of 199

Part 1: Response from the Domain Names Community

appeal mechanism and if so, whether this should be sought as part of the IANA
Stewardship Transition process.

1424

Questions

1425

Overall Need for an Appeal Mechanism
1) Do 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 bea) Developed now and introduced as part of the IANA Stewardship Transition,orb) 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 proceedingwith a separate process).

1426

Form of Appeal Mechanism and Composition of Panel4) The CWG-Stewardship indicated it believes that an appeal need not be apermanent 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 astanding list of qualified panelists under established rules promulgated by suchan organization. The CWG-Stewardship 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 thisoverall approach to establishing an appeal mechanism? Do you have anotheridea – please indicate.
5) Where there is a panel of individuals, should they be chosen:a) From a list of recognized international experts regardless of country, orb) From individuals the country that the ccTLD represents.
c) In another manner (please specify).

1427

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

IANA Stewardship Transition Proposal Page 116 of 199

Part 1: Response from the Domain Names Communitya) 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 anddemonstrable interest in the operation?
7) Should any of the parties referenced above be excluded from the appeals
process? If yes, please indicate.

Scope and Authority of the Appellant Organization
8) Should there be any limit on the scope of the appeal?
a) Should the scope be limited to questions about whether procedures havebeen followed properly?
b) Should a panel have the authority to order that an existing delegation process
be done again?
c) Should it have the authority to suspend a pending delegation?
d) Should it have authority to order to revoke and existing delegation?
e) Should it have the authority to order that another party be delegated the
ccTLD?

1428

Survey Results
Data

Question
1. Do you as a ccTLD manager believe that there is aneed for an appeal mechanism on ccTLD (re)delegation
decisions?
2. If you answered ‘yes’ should such a mechanism be a. Developed now and introduced as part of the IANA
Stewardship Transition
b. Developed later and introduced after the IANA
transition has taken place.
3. If the design of this appeal mechanism werepreventing the finalization of the IANA StewardshipTransition, 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).
4. The CWG-Stewardship indicated it believes that an
appeal mechanism need not include a permanent body. It
suggested that disputes could be handled the same way

Percentage

Yes

No

Total

Yes

26

2

28

93

7

14

10

24

58

42

11

4

15

73

27

20

8

28

71

29

13

8

21

62

38

IANA Stewardship Transition Proposal Page 117 of 199

NoPart 1: Response from the Domain Names Community

as many commercial disputes, through the use of abinding arbitration process, using an independent
arbitration organization, such as the ICC, ICDR or AAA, ora standing list of qualified panelists under establishedrules promulgated by such an organization.
The CWG-Stewardship recommended using this approachand that it use a three person panel, with each party to a
dispute choosing one of the three panelists, with these twopanelists choosing the third panelist. Do you agree withthis overall approach to establishing an appeal
mechanism?
Do you have another idea – please indicate.
The approach should not be designed now.
However I do not see any reason 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 byparties to a delegation dispute. One can have more confidence in a decision taken by ajointly 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 listof 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 nationallaws 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 Appeal 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 thatthey just look to see whether due process has been followed and documented. In the firstcase, 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
11
13
24
46
54
regardless of country
b. From individuals the country that the ccTLD
11
10
21
52
48
represents.

IANA Stewardship Transition Proposal Page 118 of 199

Part 1: Response from the Domain Names Communityc. 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
23
3
26
88
12
with the ccTLD?
b. The incumbent ccTLD manager?
24
0
24
100
0
c. Other individuals, organizations, companies,
5
16
21
24
76
associations, educational institutions, or others thathave a direct, material, substantial, legitimate anddemonstrable interest in the operation?
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 theappeal 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 themechanism 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 befrom the concerned ccTLD country. Rather, let us keep the appeal process to theconcerned government & to the incumbent ccTLD manager.
No, but there should be clear guidelines on what issues can trigger a valid appeal toprevent 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 thedevelopment of thatanyone 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 legestionnaire du CCTLD. Les autres parties, qui doivent être consultées (consensus de lacommunauté 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
18
8
26
69
31
whether procedures have been followed properly
a. Should a panel have the authority to order that an
17
8
25
69
31
existing delegation process be done again?
b. Should it have the authority to suspend a pending
14
6
20
70
30
delegation?
c. Should it have authority to order to revoke and
4
21
25
16
84
existing delegation?
d. Should it have the authority to order that another
2
22
24
8
92
party be delegated the ccTLD?

IANA Stewardship Transition Proposal Page 119 of 199

Part 1: Response from the Domain Names Community

P1. Annex P: IANA Operations Cost Analysis
1429

Preamble:1430

The cost estimate below corresponds to a "fully absorbed" IANA Functions
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 Functions operations cost within another entity would be different,
as would be a "standalone" cost estimate as the cost of a fully operational andmature IT infrastructure would be higher, economies of scale would not exist, andadditional costs of operating a separate organization would be created (relative forexample to governance, communication, reporting...).

1431

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

9) US Dollars in millions11) [A]

Using the10) Description
FY15
Budgetbasis$2.4

These costs cover direct and dedicated personnel (12 employees)
and associated costs assigned to delivering the12) Direct Costs (IANA
department)

IANA functions: registration and maintenance of protocol
parameter registries; allocation of Internet numbers and themaintenance of the Internet number registries; validation andprocessing 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.

IANA Stewardship Transition Proposal Page 120 of 199

Part 1: Response from the Domain Names Community$1.913) [B]
14) Direct Costs (Shared

Within ICANN departments other than the IANA department
perform or participate in processes directly related to the deliveryof the IANA functions.

resources)
The costs of the activities carried out by other departments toperform the IANA Functions were evaluated by eachdepartment's budget owners by identifying the direct externalcosts (professional services, infrastructure,...), and estimating
the time spent by personnel from the department on theidentified activities valued at the annual cost of each employee(base+benefits).
The full description of the activities that are carried out by thosedepartments are summarized below:- Request processing - IT
- Root Key Signing - IT, Registry technical Services, SSR, GSE$2.016) [C]- IANA Website- IT,
Legal,
Web-admin18) Support
functionswhichorganize
the ability for operational-activities
Protectionof dataandout.
systems - IT, Security, Legal
to becarried17) Support functions
allocation- Continuity and Contingency of service - IT
-The
Conflict
Interest
assertions- IT,[D],Legaltotal ofcosts
of thesefunctionsafter excluding the shared-fromMonthly
ofincluded
performance
Legal,
Gov.byEngagement
thosereporting
functionsin [B],- IT,
weredividedthe total-costsAdministrative
support(sharedwithCompliance)of operational
functions[E],
to determine
a percentage of-support
Annual functions
updates toAgreements- Legalof ICANN Operations).
([D]+[E]=total costs

15)
The Direct costs of shared resources also include a19) Thispercentage
was thenappliedto the total
costs
of IANA(both
placeholder
estimate
for thedepreciation
costs
of capital
assetsIANA
department direct costs and shared resources direct costsof 0.5m.
as defined above), to determine a cost of support function
allocated to IANA. This cost [C] is additive to [A] and [B].

20) 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 $6.3
of IANA F u n c t i o n soperations

1432[B] Direct costs (shared resources), associated with operations of the IANA
Functions and dependencies on other ICANN departments:21) Request processinga) RT trouble ticketing system supported and provided by IT

IANA Stewardship Transition Proposal Page 121 of 199

Part 1: Response from the Domain Names Communityb) RZMS software development, support and maintenance by ITc) Email system provided and supported by ITd) Online connectivity provided and supported by ITe) OFAC checks supported by Legalf) Board resolutions reviewed by Legal/sometimes drafted by Legal.
Delegation/Redelegation Reports reviewed by Legal on an as-needed basisg) All hardware and infrastructure provided and supported by ITh) Support from GSE to gather information for ccTLD requests
22) Root Key Signinga) Roles in ceremonies by IT, Registry Technical Services, SSR, Strategy,
GSE, and program departmentb) Suite of Security documents reviewed and adopted by SSR and IT
departmentsc) Facility rent and connectivity to the Key Management Facility (KMF) provided
by ITd) DNSSEC SysTrust Audit requires work samples from IT, Legal, and SSRe) Third Party Contract/RFP prepared by Procurement and reviewed by Legal
23) IANA Websitea) Hardware provided, administered, and supported by ITb) Contract compliance requirements reviewed by Legalc) Web-admin support to post reports and documents on ICANN website24) Security to protect data and systemsa) Security plan reviewed and accepted by IT and SSRb) Reviewed by Legal prior to submission to NTIA
25) Continuity and Contingency of servicea) Dependent on IT and Financeb) Plan reviewed by IT, SSR, HR, Legal, and Finance prior adoption26) Conflict of Interest compliance

IANA Stewardship Transition Proposal Page 122 of 199

Part 1: Response from the Domain Names Communitya) Annual report prepared by HR and Legal27) Monthly reporting of performancea) Posted on hardware maintained and administered by ITb) Contract compliance requirements reviewed by Legal
28) Customer Service Surveya) RFP prepared by Procurementb) Final report from 3rd party reviewed by Legal prior to posting29) Administrative supporta) Share Administrative Assistant with Contractual Compliance – 50%
dedicated to supporting IANA department
30) Annual updates to Agreementsa) Legal review of annual Supplemental Agreement to the IETF MOU

IANA Stewardship Transition Proposal Page 123 of 199

Part 1: Response from the Domain Names Community

P1. Annex Q: IANA Budget
1433

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 Functions operations costs is consistent withcurrent 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 Functions operations. As a result, the CWG-Stewardship 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 (seeSection III.A, paragraph 161).

1434

In addition, the CWG-Stewardship recommends three areas of future work that canbe 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 thetransition.
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.
CCWG Accountability Dependencies
Enumeration of the relevant accountability mechanisms relating to the IANA Budget:

The ability for the community to approve or veto the ICANN budget after it has
been approved by the ICANN Board but before it comes into effect. The
community may reject the ICANN Budget based on perceived inconsistency withthe purpose, mission and role set forth in ICANN’s Articles and Bylaws, theglobal public interest, the needs of ICANN stakeholders, financial stability orother matters of concern to the community. The CWG-Stewardship recommends
that the IFO’s comprehensive costs should be transparent and ICANN’s
operating plans and budget should include itemization of all IANA operations
costs to the project level and below as needed. An itemization of IANA costs
would include “Direct Costs for the IANA department”, “Direct Costs for sharedresources” and “Support functions allocation”. Furthermore, these costs should
be itemized into more specific costs related to each specific function to theproject level and below as needed. PTI should also have a yearly budget that isreviewed and approved by the ICANN community on an annual basis. PTI should
submit a budget to ICANN at least nine months in advance of the fiscal year toensure the stability of the IANA services. It is the view of the CWG-Stewardship

IANA Stewardship Transition Proposal Page 124 of 199

Part 1: Response from the Domain Names Communitythat the IANA budget should be approved by the ICANN Board in a much earlier
timeframe than the overall ICANN budget. The CWG (or a successor
implementation group) will need to develop a proposed process for the IANAspecific budget review, which may become a component of the overall budget
review.

IANA Stewardship Transition Proposal Page 125 of 199

Part 1: Response from the Domain Names Community

P1. Annex R: Evaluation Method for Implications
1435

For the purposes of this document “workability” will be defined as per the following
methodology:
 Criteria to be evaluated: Complexity of the new method.
 Implementation requirements for the new method.
 Impact on the IFO for working with the new method.
 Impact on the IFO customers resulting from using the new method.
 Potential impact on the security, stability and resiliency of the DNS.
 Classification of evaluation of criteria:
 0 - signifies significant requirements or negative impact.
 1 - signifies moderate requirements or negative impact.
 2 - signifies minor requirements or impact.
 3 - signifies no requirements or impact.

1436

Scoring method: Add the score of all the criteria to generate a workability evaluation.
The best possible score is 15 = 100% which would be judged very workable. The
worst score possible would be 0 = 0% and should be considered completely
unworkable. Beyond the total score other factors may influence the final workability
assessment, such as considering changes which are evaluated as having asignificant negative impact on the security, stability, and resiliency of the DNS, as
being automatically unworkable. Overall unless there are special factors being
considered, a score of 50% or above would be considered workable.

Summary of evaluations:
Element Being Analysed
PTI as an affiliate of ICANN
Contract between ICANN
and PTI
IFR
CSC
Customer complaint andescalation procedures
Approving changes to the
Root Zone environment
Replacing NTIA as the Root
Zone Management Processadministrator

Score
score = 8/15 = 53%score = 12/15 = 80%,

Evaluation
workableworkablescore = 9/15 = 60%

workablescore = 11/15 = 73%
score = 11/15 = 73%

workableworkablescore = 8/15 = 53%

workablescore = 13/15 = 87%

workable

IANA Stewardship Transition Proposal Page 126 of 199

Part 1: Response from the Domain Names Community

1437

Detailed Evaluation
 PTI as an affiliate of ICANN (total score = 8/15 = 53%, workable)
 What is changing: IANA is currently internal to ICANN. Creating aseparate legal entity for the IANA functions will obviously require changes
to the procedures as to how the IFO relates to ICANN.
 Complexity of the new method: 1 – IANA is currently operating as a division of the Global
Domains Division; further separation into PTI is an important step
but can be considered moderate in this case.
 Implementation requirements for the new method:
 0 – Establishing PTI involves significant implementation work.
 Impact on the IFO for working with the new method: 1 – The actual impact on the IFO of transitioning to the PTI as anaffiliate of ICANN should be moderate.
 Impact on the IFO customers resulting from using the new method: 3 – This should be transparent for the IANA naming customers.
 Potential impact on the security, stability and resiliency of the DNS:
 3 – Given the current IFO systems, processes, procedures andpersonnel for these activities to be transferred to PTI, as anaffiliate of ICANN, no additional risks are foreseen for the security,
stability, or resiliency of the Internet.
 Total score = 8/15 = 53%, workable.
 Contract between ICANN and PTI (total score = 12/15 = 80%, very workable)
 What is changing: Currently the contract is between ICANN and the NTIA.
The new contract will be between ICANN and PTI. This will require newprocesses and procedures.
 Complexity of the new method: 2 – IANA currently works under the NTIA IANA Functions Contract
and the PTI-ICANN Contract should mirror this contract in most
aspects. As such the impact should be considered minor.
 Implementation requirements for the new method: 2 – The new contract will have to be adjusted to reflect thewithdrawal of NTIA and the addition of PTI but this should beconsidered minor.
 Impact on the IFO for working with the new method: 2 – Given IANA currently reports and ICANN and is subject to the
NTIA IANA Functions Contract it is estimated that the ICANN-PTI
Contract will only have a minor impact on the IFO.

IANA Stewardship Transition Proposal Page 127 of 199

Part 1: Response from the Domain Names Community Impact on the IFO customers resulting from using the new method: 3 – This should be transparent for the IANA naming customers.
 Potential impact on the security, stability and resiliency of the DNS:
 3 – None compared to the current NTIA IANA Functions Contract.
 Total score = 12/15 = 80%, very workable.
 IFR (total score = 9/15 = 60%, workable)
 What is changing: Currently the NTIA is responsible for the evaluation of
IANA services and the decision to extend the current contract orundertake an RFP. The IFR is the proposed mechanism to replace themore complex oversight elements.
 Complexity of the new method:
 0 – Given this requires the creation of a non-standing committee
for each review and detailed processes around these reviews, thiswill be complex.
 Implementation requirements for the new method: 1 – Adding the IFR and its powers to the ICANN Bylaws will be asignificant undertaking.
 Impact on the IFO for working with the new method: 3 – Given the last NTIA Process, which led to the IANA Functions
Contract this should not represent any additional impact to theIFO.
 Impact on the IFO customers resulting from using the new method: 3 – This should be transparent for the IANA naming customers.
 Potential impact on the security, stability and resiliency of the DNS:
 2 – Given the IFR can recommend a change in IFO provider(subject to further approvals) this could have some impact on the
security, stability and resiliency of the DNS, if a transition is
ultimately required.
 Total score = 9/15 = 60%, workable.
 CSC (total score = 11/15 = 73%, workable)
 What is changing: Currently IANA is responsible for ongoing monitoring of
IANA performance of its functions. The CSC is the proposed mechanism
to replace this function.
 Complexity of the new method: 1 – Given this requires the creation of a new ICANN standing
committee with a new charter this is considered moderately
complex.
 Implementation requirements for the new method:

IANA Stewardship Transition Proposal Page 128 of 199

Part 1: Response from the Domain Names Community 1 – Adding the CSC and its powers to the ICANN Bylaws will be asignificant undertaking.
 Impact on the IFO for working with the new method: 3 – Given IANA currently works with the NTIA for performancetracking and that the CSC role is limited to this. It should have no
additional impact on the IFO.
 Impact on the IFO customers resulting from using the new method: 3 – This should be transparent for the IANA naming customers
while providing mew mechanisms for resolving customer issues.
 Potential impact on the security, stability and resiliency of the DNS:
 3 – None foreseeable.
 Total score = 11/15 = 73%, workable.
 Customer complaint and escalation procedures (total score = 11/15 = 73%,
workable) What is changing: The NTIA had its internal procedures for addressing
lack of performance and complaints by IANA customers. These customer
complaint and escalation procedures seek to replace these.
 Complexity of the new method: 1 – More complex than current methods.
 Implementation requirements for the new method: 2 – Most of the implementation should have been covered in the
IFR and CSC.
 Impact on the IFO for working with the new method: 2 – Some changes required – limited impact.
 Impact on the IFO customers resulting from using the new method
 3 – There should be no negative impact on the IFO customers ascomplaint and escalation procedures are either similar or
improved.
 Potential impact on the security, stability and resiliency of the DNS:
 3 – None foreseeable.
 Total score = 11/15 = 73%, workable.
 Approving changes to the Root Zone environment (total score = 8/15 =53%, workable)
 What is changing: NTIA was responsible for approving all changes to the
Root Zone environment. This section proposes a replacement for thisprocess.
 Complexity of the new method:

IANA Stewardship Transition Proposal Page 129 of 199

Part 1: Response from the Domain Names Community

 0 – Significantly more complex than current NTIA-only approval.
 Implementation requirements for the new method: 1 – This should include procedure for creating review teams, draft
terms of reference for review teams and process for obtaining
ICANN Board approval for changes.
 Impact on the IFO for working with the new method: 3 – Not different than the current process for IFO.
 Impact on the IFO customers resulting from using the new method: 3 – There should be no negative impact on the IFO customers –possibly more transparency about the process.
 Potential impact on the security, stability and resiliency of the DNS:
 1 – Changes to the Root Zone environment have a potential tothreaten the security, stability and resiliency of the DNS. Although
one expects the same participants would be involved as would beunder the current process and the safeguards should be the sameor better, any change to the Root Zone environment should be
evaluated as moderate.
 Total score = 8/15 = 53%, workable.
 Replacing NTIA as the Root Zone Management Process administrator (total
score = 13/15 = 87%, very workable)
 What is changing: NTIA currently approves all changes to the Root Zone
or its WHOIS database. This will no longer be required.
 Complexity of the new method: 3 – Removing the requirement for a third party approval of allchanges to the Root Zone removes a layer of complexity.
 Implementation requirements for the new method: 2 – Minor coding and process documentation changes.
 Impact on the IFO for working with the new method: 3 – Lowering the complexity produces a positive impact on the
IFO.
 Impact on the IFO customers resulting from using the new method: 3 – From a process point of view this will be transparent to clientswith the possible exception of some performance increases.
 Potential impact on the security, stability and resiliency of the DNS:
 2 – Although basically considered a formality the NTIA
authorization could be considered as providing a minor added
value to the security, stability and resiliency of the Internet.
 Total score = 13/15 = 87%, very workable.

IANA Stewardship Transition Proposal Page 130 of 199

Part 1: Response from the Domain Names Community

P1. Annex S: Draft Proposed Term Sheet (as proposed by
Legal Counsel)
What follows below is an initial draft proposed term sheet that could be the precursor to the
ICANN-PTI Contract. This is based on a legal memorandum prepared by legal counsel to the
CWG-Stewardship on May 18, 2015. To the extent this term sheet is inconsistent with thecurrent proposal, the current proposal governs. The term sheet will be subject of negotiation
between PTI and ICANN (with PTI having independent legal advice).
PROPOSED KEY TERMS FOR ICANN-PTI CONTRACTAll terms are subject to further review and discussion

Terms in [square brackets] are placeholders onlyTerms connected by “or” are alternatives

TBD means To Be Determined

PROVISIONPARTIESSUMMARY OF KEY TERMSCurrent
IANA
Contract
SectionIII.A

The Parties to the ICANN-PTI Contract are:
o

ICANN

o

PTI (IANA Functions Operator fornaming functions)

DURATION
Initial Term



The period of performance of the ICANNPTI Contract shall commence on [October
1, 2015] (the “Commencement Date”) andshall end on the [fifth (5th)] anniversary of
the Commencement Date.

Renewal Terms



The ICANN-PTI Contract will provide for
automatic renewal, unless ICANN elects
not to renew the ICANN-PTI Contract uponrecommendation by an IANA Function
Review Team (IFRT), with support of theICANN Board.

Any ICANN election of non-renewal shallbe provided with not less than [[__] months]
prior written notice, and PTI shall provide
full support and cooperation to ICANN, andto any successor entity to PTI, in order toeffect an orderly, stable, secure andefficient transition of this Contract and

Final
Proposal
SectionF
F.1, I.70

I.59, I.70

III.A.

IANA Stewardship Transition Proposal Page 131 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Sectionservices and obligations provided by PTI
hereunder. See also the Continuity ofOperations provisions below.

IANA Function
Review

Performance
Monitoring

If the ICANN-PTI Contract automaticallyrenews, the extended contract shall include
this automatic renewal clause.



The renewal period shall commence
immediately following the end of the initial
term and shall end on the [fifth (5th)]
anniversary of the commencement of therenewal term [TBD]The IANA Function Review (IFR) of PTI’s
performance will be conducted by the IFRT
in accordance with the processes set forthin ICANN’s governance documents.



PTI shall submit to the procedures andscope of the IFR. PTI agrees to make anynecessary changes, including amendment
to the ICANN-PTI Contract, as adopted andimplemented by ICANN and approved by
the Members of ICANN following an IFR.

An initial IFR shall take place two years
following the transition of the IANA
functions to PTI.



Subsequent IFRs shall occur at no morethan five-year intervals.

A Special IFR may also be initiated by the
ccNSO and GNSO Councils, following theexhaustion of the identified escalation
mechanisms.



The CSC will be established to monitor PTI
performance of the IANA naming function
according to the ICANN-PTI Contract andService Level Expectations (SLEs).



PTI shall act in good-faith to resolve allissues identified by CSC directly and to
submit to the escalation mechanics set
forth in the ICANN-PTI Contract and ICANN
governance documents.



The CSC shall be empowered to escalate
identified areas of concern as set forth in

III.A./Ann
ex F

III.A./Ann
ex G

IANA Stewardship Transition Proposal Page 132 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Section“Escalation Mechanisms” below.
ESCALATIONMECHANISMS(IANA Customer
Service Complaint
Resolution
Process)

ESCALATIONMECHANISMS(IANA Problem
Resolution
Process)Phase 1: If anyone experiences an issue
with PTI’s delivery of IANA naming
functions, the complainant can send an
email to PTI, which will escalate thecomplaint internally as required. This
process is open to anyone, including
individuals, registries, ccTLD regionalorganizations and ICANN SO/ACs.



Phase 2: If the issue identified in Phase 1 is
not addressed by PTI to the reasonablesatisfaction of the complainant, thencomplainants that are direct customers only
may request mediation. ICANN and CSC
will be notified of the issue and CSC willconduct a review to determine whether theissue is part of a persistent performanceissue or an indication of a systemic
problem. If so, the CSC may seek
remediation through the Problem
Resolution Process described below. This
process is only open to direct customers.
Non-direct customers, including TLD
organizations, who have issues unresolvedin Phase 1, may escalate the issues to theombudsman or the applicable liaisons to
the CSC.

The complainant may also initiate an
Independent Review Process if the issue is
not addressed in the steps above.

The CSC may seek resolution with PTI
performance issues in accordance with theRemedial Action Plan which includes:
 CSC reports persistent issues to PTI andrequests remedial action in [TBD] days.


CSC confirms completion of the remedialaction by PTI.



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, who
might then decide to take further action using

III.A./
Annex I

III.A/
Annex J

IANA Stewardship Transition Proposal Page 133 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Sectionagreed consultation and escalation processes
to be finalized post-transition.
ESCALATIONMECHANISMS(Root Zone
Emergency
Process)
ESCALATIONMECHANISMS(Separation
Review)

CONTINUITY OF
OPERATIONSCOST/PRICE[Retain provisions from current ICANN-NTIA
Contract.]

III.A/
Annex K

A separation review can be triggered by IFRT
in accordance with provisions to be inserted in
ICANN governance documents. PTI shallsubmit to and comply with the IFR mechanics,
including the separation review mechanics,
adopted and implemented by ICANN.

III.A/
Annex L

All recommendations resulting from theseparation review must be approved by the
ICANN board.

Retain provisions from current ICANN-NTIA
Contract, except that ICANN will perform dutiesof the Contract Officer (CO) and Contract
Officer Representative (COR). PTI agrees tobe fully engaged in the transition plan and toprovide appropriate transition staff andexpertise to facilitate a stable transition of the
IANA functions on terms more fully developedin the ICANN-PTI Contract.



ICANN, in conjunction with CSC as necessary,
shall review the transition plan every five years.
Fees, if any, will be based on direct costs
and resources incurred by PTI.



After one year of charging fees, PTI must
collaborate with all Interested and Affected
Parties to develop the fee structure and amethod to tracks costs for each IANA
function. PTI must submit copies of theabove and a description of the collaboration
efforts to ICANN.

“Interested and Affected Parties” means themultistakeholder, private sector led, bottomup policy development model for the DNS
that ICANN represents; [the IETF, the IAB,
5 RIRs;] ccTLD and gTLD operators;
governments; and the Internet user

C.7

III.A/
AnnnexM

B.2

IANA Stewardship Transition Proposal Page 134 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Sectioncommunity.
CONSTRUCTIVE
WORKINGRELATIONSHIPSPTIREQUIREMENTS
Subcontracting;[U.S. Presence
Requirements]

Performance of
IANA Functions

Separation of Policy
Development andOperational Roles

Transparency andAccountability

Performance;
Service Levels

PTI must maintain constructive working
relationships with all Interested and Affected
Parties to ensure quality and satisfactory
performance.
No subcontracting.



PTI must be U.S. owned and operated,
incorporated and organized under U.S. law.



Primary IANA functions must be performedin the U.S.



PTI must have a U.S. physical address.



IANA functions must be performed in astable and secure manner.



IANA functions are administrative andtechnical in nature based on establishedpolicies developed by the Interested andAffected Parties.



PTI must treat each IANA function withequal priority and process all requests
promptly and efficiently.

PTI staff members will not initiate, advance, or
advocate any policy development related to the
IANA functions. This section shall not be
construed to prevent contributions by staff
members by way either of background information
or direct text contribution to any document,
provided both that the PTI staff are not the only
authors of the contribution and that the primaryfunction of the staff member's contribution is insupplying relevant IANA experience and insight.
PTI shall collaborate with all Interested andAffected Parties to develop and post user
instructions including technical requirements for
the IANA naming function.
PTI shall collaborate with all Interested andAffected Parties to develop, maintain, enhance andpost performance standards for each IANA
function. ICANN and PTI shall develop service
level agreements (SLAs) to be annexed to theContract in accordance with the SLEs attached as

C.1.3

C.2.1

C.2.4

C.2.5

C.2.6

Annex C

C.2.8

Annex C/
Annex H

IANA Stewardship Transition Proposal Page 135 of 199

Part 1: Response from the Domain Names Community

PROVISIONInternet Assigned
Numbers Authority(IANA) Naming
Functions
IANA Functions

Responsibility and
Respect for
Stakeholders

Perform
Administrative
Functions
Associated With
Root Zone
Management

Root Zone File
Change Request
Management

SUMMARY OF KEY TERMS
Annex I hereto for the performance of thesefunctions.
IANA naming functions include: the administrationof certain responsibilities associated with theInternet DNS root zone management; and otherservices related to the management of the ARPA
and INT top-level domains (TLDs).
IANA functions include (1) the IANA Naming
Functions, (2) the coordination of the assignmentof technical Internet protocol parameters, and (3)the allocation of Internet numbering resources.
PTI shall collaborate with all Interested andAffected Parties to develop and post for each IANA
function a process for documenting the source ofpolicies and procedures and how each will be
implemented.
 PTI will facilitate and coordinate the rootzone of the DNS and maintain 24/7
operational coverage.
Current
IANA
Contract
Section

Final
Proposal
Section

C.2.9

C.2.7

C.2.9.2

III.A./

C.2.9.2.a

III.A.

Process flow for root zone management
involves two roles that are performed by
two different entities:o

PTI as the IANA Functions OperatoroVeriSign (or its successor) as the
Root Zone Maintainer (RZM).



PTI shall work collaboratively with the RZM.



Any amendment to the roles andresponsibilities of PTI and the RZM withrespect to root zone management will
require approval of the ICANN Board [andthe Members of ICANN or a Special IFR.]The RZM will receive and process from PTI
root zone file change requests for TLDs,
including addition of new or updates toexisting TLD name servers (NS) anddelegation signer (DS) resource record(RR) information along with associated'glue' (A and AAAA RRs). A change request
may also include new TLD entries to theroot zone file. No authorization for TLDchange requests will be needed.



RZM shall process root zone file changes

IANA Stewardship Transition Proposal Page 136 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Sectionas expeditiously as possible.
Root Zone “WHOIS”
Change Request
and Database
Management

Delegation andRedelegation of aCountry Code Top
Level -Domain(ccTLD)

PTI will maintain, update, and makepublicly accessible a Root Zone “WHOIS”
database with current and verified contact
information for all TLD registry operators, ata minimum:o

TLD name;othe IP address of the primarynameserver and secondarynameserver for the TLD;othe corresponding names of such
nameservers;othe creation date of the TLD;oname, address, email, phone andfax numbers of the TLD registry
operator;oname, address, email, phone andfax numbers of the technical contact
for the TLD registry operator;oname, postal address, email
address, phone and fax numbers of
the administrative contact for the
TLD registry operator;oreports;odate record last updated;o

any other information relevant to the
TLD requested by the TLD registry
operator.



The RZM shall receive and process rootzone “WHOIS” change requests for TLDs
from PTI. No authorization for TLD change
requests shall be required.



PTI shall apply existing policy frameworks
in processing requests related to thedelegation and redelegation of a ccTLD,
such as RFC 1591, the GAC Principles(2005) and any further clarification of thesepolicies by Interested and Affected Parties.



If a policy framework does not exist tocover a specific instance, PTI will consult

C.2.9.2.b

III.A.,
paragrap
h 150

C.2.9.2.c

III.A,
paragrap
h 160/
Annex O

IANA Stewardship Transition Proposal Page 137 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Sectionwith the Interested and Affected Parties;
relevant public authorities; andgovernments on any recommendation thatis not within or consistent with an existing
policy framework.

Delegation andRedelegation of aGeneric Top Level
Domain (gTLD)

Root Zone
Automation



PTI shall also take into account the relevant
national frameworks and applicable laws of
the jurisdiction that the TLD registry serves.



PTI shall submit its recommendations to the[[CSC] or [RZM] or [Independent
Evaluator]] via a Delegation andRedelegation Report.



PTI shall verify that all requests related tothe delegation and redelegation of gTLDs
are consistent with the procedures
developed by ICANN.



PTI shall submit its request to the RZM via
a Delegation and Redelegation Report, witha copy to ICANN and the registry
operator(s) involved.



PTI shall work with ICANN, the CSC andthe RZM, and collaborate with all Interested
and Affected Parties, to deploy a fully
automated root zone management systempromptly, including, at a minimum:oa secure (encrypted) system forcustomer communications;oan automated provisioning protocol
allowing customers to manage theirinteractions with the root zone
management system;oan online database of change
requests and subsequent actions
whereby each customer can see arecord of their historic requests andmaintain visibility into the progressof their current requests;otest system, which customers canuse to meet the technicalrequirements for a change request;oan internal interface for secure

C.2.9.2.d

C.2.9.2.e

IANA Stewardship Transition Proposal Page 138 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Sectioncommunications between ICANN,
PTI, and the RZM.
Root DNSSEC KeyManagement



PTI shall be responsible for the
management of the root zone Key Signing
Key (KSK), including generation,
publication, and use for signing the Root
Keyset.

C.2.9.2.f.INT TLD

PTI shall operate the .INT TLD within thecurrent registration policies for the TLD.

C.2.9.4

If ICANN designates a successor registry,
PTI will facilitate a smooth transition.

Inspection Of All
Deliverables And
Reports Before
Publication

[ICANN] will perform final inspection andacceptance of all deliverables and reports,
including those articulated as Contractor
Requirements in the NTIA-ICANN Contract.

C.2.11PTI To Provide
Qualified Program
Manager

PTI shall provide trained, knowledgeable
technical personnel with excellent oral andwritten communication skills (i.e., thecapability to converse fluently,
communicate effectively, and write
intelligibly in the English language).

C.2.12.a

PTI’s IANA Functions Program Manager
organizes, plans, directs, staffs, andcoordinates the overall program effort;
manages contract and subcontract
activities as the authorized interface withICANN, including CSC, and the IFRT and is
responsible for the following:oShall be responsible for the overall ICANNPTI Contract performance and shall notserve in any other capacity under the
ICANN-PTI Contract.

oShall have demonstrated communications
skills with all levels of management.

oShall meet and confer with ICANN
regarding the status of specific PTI
activities and problems, issues, or conflicts
requiring resolution.

oShall be capable of negotiating and making
binding decisions for PTI within his or her
scope of delegated authority.
IANA Stewardship Transition Proposal Page 139 of 199

Part 1: Response from the Domain Names Community

PROVISIONKey Personnel

Changes to Key
Personnel

Budget Meetings;
Funding

TRANSPARENCY
OF DECISIONMAKINGSUMMARY OF KEY TERMSo

Shall have extensive experience andproven expertise in managing similar multitask contracts of this type and complexity.



In addition to the Qualified Program
Manager, PTI shall assign to the ICANNPTI Contract the following key personnel:o

IANA Functions Program ManageroIANA Function Liaison for Root
Zone Management



PTI shall obtain PTI Board consent prior to
making key personnel substitutions.



Replacements for key personnel mustpossess qualifications equal to or
exceeding the qualifications of thepersonnel being replaced, unless an
exception is approved.



Requests for changes in key personnel
shall be submitted to the PTI Board at least
15 working days prior to making any
permanent substitutions. The request
should contain a detailed explanation of thecircumstances necessitating the proposed
substitutions, complete resumes for the
proposed substitutes, and any additional
information requested by the PTI Board.
The PTI Board will notify PTI within 10
working days after receipt of all required
information of the decision on substitutions.

Current
IANA
Contract
Section

Final
Proposal
Section

C.2.12.b

H.8

ICANN will meet [annually] with the [President of
PTI] to review and approve the budget for the IANA
Naming Services for the next [three] years. ICANN
shall fund PTI at agreed budget levels.
To enhance consistency, predictability and integrityin decision-making of IANA related decisions, PTI
shall:
 Continue the current practice of public
reporting on naming related decisions.


Make public all recommendations by PTI on
naming related decisions.



Agree not to redact any PTI Board minutes
related to naming decisions.

IANA Stewardship Transition Proposal Page 140 of 199

Part 1: Response from the Domain Names Community

PROVISIONSECURITYREQUIREMENTSPERFORMANCE
METRICREQUIREMENTS
Program Reviews
and Site Visits

Monthly
Performance
Progress Report

Root Zone

SUMMARY OF KEY TERMSHave the President and PTI Board Chairsign an annual attestation that it hascomplied with the above provisions.



ICANN shall provide PTI a budget sufficient
to allow it to hire independent legal counsel
to provide advice on the interpretation ofexisting naming related policy.

These provisions regarding reporting andtransparency, along with the availability of
independent legal advice, are intended to
discourage decisions that may not be fully
supported by existing policy.

Retain from current ICANN-NTIA Contract.

Program Reviews shall be conductedmonthly by CSC and ICANN.

Site Visits shall be conducted on-demandby the IFRT.



PTI shall prepare and submit to the CSC
and ICANN a performance progress report
every month (no later than 15 calendar
days following the end of each month) that
contains statistical and narrative
information on the performance of the IANA
functions (i.e., assignment of technicalprotocol parameters; administrative
functions associated with root zone
management; and allocation of Internet
numbering resources) during the previous
calendar month.

The report shall include a narrative
summary of the work performed for each of
the functions with appropriate details andparticularity. The report shall also describe
major events, problems encountered, andany projected significant changes, if any,
related to the performance of requirements
set forth in C.2.9 to C.2.9.4 of the ICANNNTIA Contract.



PTI shall work collaboratively with ICANN

Current
IANA
Contract
Section

Final
Proposal
Section

C.3

C.4.1

Annex F

C.4.2

Annex F

C.4.3

IANA Stewardship Transition Proposal Page 141 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMSManagement
dashboard

Current
IANA
Contract
Sectionand the RZM, and all Interested andAffected Parties, to maintain and enhancethe dashboard to track the process flow forroot zone management.

PerformanceStandards Reports

PTI shall publish reports for each discrete
IANA function consistent with Section C.2.8
of the ICANN-NTIA Contract. The
Performance Standards Metric Reports will
be published via a website every month (nolater than 15 calendar days following theend of each month).

C.4.4

Customer Service
Survey

PTI shall collaborate with the CSC andICANN to maintain and enhance the annual
customer service survey consistent with theperformance standards for each of thediscrete IANA functions. The survey shall
include a feedback section for eachdiscrete IANA function. No later than 30days after conducting the survey, PTI shallsubmit the CSS Report to ICANN andpublicly post the CSS Report.

C.4.5

Final Report

PTI shall prepare and submit a final reporton the performance of the IANA functions
that documents standard operatingprocedures, including a description of thetechniques, methods, software, and tools
employed in the performance of the IANA
functions. PTI shall submit the report to the
CSC and ICANN no later than 30 days after
expiration of the ICANN-PTI Contract.

C.4.6

Inspection andacceptance

The CSC and ICANN will perform final
inspection and acceptance of alldeliverables and reports articulated in
Section C.4 of the ICANN-NTIA Contract.

C.4



Retain provisions from current ICANN-NTIA
Contract, except that ICANN is the CO and
COR.

C.5



PTI shall submit to the procedures and scopeof the IFR and CSC as set forth in ICANN
governance documents.



PTI agrees to make any necessary changes,
including amendment to the ICANN-PTI
Contract, as adopted and implemented by

AUDIT
REQUIREMENTS /IANA FUNCTION
REVIEW & IFRT

Final
Proposal
SectionAnnex F

Annex F

IANA Stewardship Transition Proposal Page 142 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
SectionICANN following an IFR.
CONFLICT OF
INTERESTREQUIREMENTSPERFORMANCEEXCLUSIONSPTI not authorized tomake changes to
Root Zone; link to
VeriSign
Cooperative
Agreement

PTI not to change
policies andprocedures or
methods

Relationship to othercontracts

Baseline
Requirements for
DNSSEC in the
Authoritative RootZone

INSPECTION AND
ACCEPTANCE

Retain provisions from current ICANN-NTIA.

C.6, H.9

PTI not authorized to make modifications,additions, or deletions to the root zone file orassociated information. (The ICANN-PTI Contract
will not alter the root zone file responsibilities as
set forth in Amendment 11 of the [Cooperative
Agreement NCR-9218742 between the U.S.
Department of Commerce and VeriSign, Inc. or
any successor entity]). See Amendment 11
athttp://ntia.doc.gov/files/ntia/publications/amend11_052206.pdf.
PTI not authorized to make material changes in thepolicies and procedures developed by the relevant
entities associated with the performance of the
IANA functions. PTI shall not change theestablished methods associated with theperformance of the IANA functions without priorapproval of ICANN.
The performance of the functions under the
ICANN-PTI Contract, including the development ofrecommendations in connection with Section
C.2.9.2 of the ICANN-NTIA Contract, shall not be,in any manner, predicated or conditioned on theexistence or entry into any contract, agreement or
negotiation between PTI and any party requestingsuch changes or any other third-party. Compliancewith this Section must be consistent with C.2.9.2dof the ICANN-NTIA Contract.
DNSSEC at the authoritative Root Zone requires
cooperation and collaboration between the rootzone management partners and ICANN. The
baseline requirements encompass the
responsibilities and requirements for both PTI andthe RZM, to be retained as set forth in Appendix 2
to the ICANN-NTIA Contract.
ICANN will perform representative final inspection
and acceptance of all work performed, written
communications regardless of form, reports, andother services and deliverables related to Section
C prior to any publication/posting called for by the
ICANN-PTI Contract. Any deficiencies shall be

C.8.1

C.8.2

C.8.3
(whichcrossreferencesC.2.9.2)

Appendix
2

E

IANA Stewardship Transition Proposal Page 143 of 199

Part 1: Response from the Domain Names Community

PROVISIONSUMMARY OF KEY TERMS

Current
IANA
Contract
Section

Final
Proposal
Sectioncorrected by PTI and resubmitted to ICANN within
10 workdays after notification.
INTELLECTUAL
PROPERTY
Trademarks

Patents, Inventions,
Copyrights,
Copyrightable Works
and Trade Secrets

CONFIDENTIALITYAND DATAPROTECTION
INDEMNIFICATION[ICANN will grants PTI an exclusive, royalty-free,
fully-paid, worldwide license to use the IANA
trademark and all related trademarks in connection
with PTI’s activities under the ICANN-PTI
Contract.]
ICANN shall own all intellectual property
conceived, reduced to practice, created orotherwise developed by PTI under the Contract.
PTI shall assign, and shall cause any employees
or contractors to assign, all rights in any patentablesubject matter, patent applications, copyrights,
trade secrets and all other intellectual property
created by the PTI during the course of PTI’s
duties under the ICANN-PTI Contract to ICANN.
With respect to copyright, the ICANN-PTI Contract
is a “work for hire” agreement and ICANN shall bedeemed the author and shall own all copyrightableworks created by PTI hereunder, and all copyright
rights thereto. In the event this is not deemed awork for hire agreement, PTI shall assign
ownership of the copyrightable works andcopyrights to ICANN.
ICANN shall license back any patents, patentapplications, copyrights and trade secrets to PTI
for the duration of the ICANN-PTI Contract solely
to the extent necessary for PTI to perform its
obligations under the ICANN-PTI Contract. Thislicense shall be non-exclusive and royalty-free.
The ICANN-PTI Contract will contain reasonable
and customary provisions relating to confidentialityand data protection.
[ICANN shall indemnify, defend and hold harmless
PTI from all claims arising from PTI’s performanceor failure to perform under the ICANN-PTI
Contract.]

H.2

H.10

H.13

IANA Stewardship Transition Proposal Page 144 of 199

Part 1: Response from the Domain Names Community

P1. Annex T: ICANN Response to CWG-Stewardship
Consultation
See https://community.icann.org/x/-Zk0Aw.

IANA Stewardship Transition Proposal Page 145 of 199

Part 2: Response from the Internet Number Community

Part 2. Response from the Internet Number Community

IANA Stewardship Transition Proposal Page 146 of 199

Part 2: Response from the Internet Number Community

Response to the IANA Stewardship Transition Coordination
Group Request for Proposals on the IANA from the Internet
Number Community
P2. Abstract ___________________________________________________________ 149
P2. Proposal type ________________________________________________________ 149
P2.I. The Community’s Use of the IANA ______________________________________ 149
P2.I.A.
P2.I.B.
P2.I.C.
P2.I.D.

The service or activity _________________________________________________________________________ 149
The customer of the service or activity ____________________________________________________________ 150
Registries are involved in providing the service or activity _____________________________________________ 150
Overlaps or interdependencies between your IANA requirements and the functions required by other customer
communities ________________________________________________________________________________ 151

P2.II. Existing Pre-Transition Arrangements ___________________________________ 152
P2.II.A.

Policy Sources_______________________________________________________________________________ 152

P2.II.A.1.
P2.II.A.2.
P2.II.A.3.
P2.II.A.4.
P2.II.B.

Affected IANA service or activity ___________________________________________________________ 152
How policy is developed and established and by whom _________________________________________ 152
How disputes about policy are resolved ______________________________________________________ 153
References to documentation of policy development and dispute resolution processes _________________ 154

Oversight and Accountability ____________________________________________________________________ 154

P2.II.B.1.
P2.II.B.2.

Which IANA service or activity is affected? ___________________________________________________ 155
If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in whatway. _________________________________________________________________________________ 155
P2.II.B.3.
The entity or entities that provide oversight or perform accountability functions _______________________ 155
P2.II.B.3.i.
NTIA ____________________________________________________________________________ 155
P2.II.B.3.ii.
The Regional Internet Registries ______________________________________________________ 156
P2.II.B.4.
Description of the mechanism _____________________________________________________________ 156
P2.II.B.5.
Jurisdiction and legal basis of the mechanism _________________________________________________ 157

P2.III. Proposed Post-Transition Oversight and Accountability ____________________ 157
P2.III.A. The elements of this proposal ___________________________________________________________________ 157
P2.III.A.1.
P2.III.A.2.
P2.III.A.3.
P2.III.A.4.

ICANN to continue as the IANA Numbering Services Operator via a contract with the RIRs _____________ 158
IPR related to the provision of the IANA services remains with the community ________________________ 158
Service Level Agreement with the IANA Numbering Services Operator _____________________________ 159
Establishment of a Review Committee _______________________________________________________ 161

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

P2.IV. Transition Implications ________________________________________________ 162
P2.IV.A. Operational requirements to achieve continuity of service throughout the transition _________________________ 163
P2.IV.B. Description of any legal framework requirements in the absence of the NTIA contract _______________________ 163
P2.IV.C. Workability of any new technical or operational methods ______________________________________________ 164

P2.V. NTIA Requirements ___________________________________________________ 164
P2.V.A.
P2.V.B.
P2.V.C.
P2.V.D.
P2.V.E.

Support and enhance the multistakeholder model ___________________________________________________ 164
Maintain the security, stability, and resiliency of the Internet DNS _______________________________________ 164
Meet the needs and expectation of the global customers and partners of the IANA services __________________ 165
Maintain the openness of the Internet _____________________________________________________________ 165
Not a government-led or inter-governmental solution _________________________________________________ 165

P2.VI.

Community Process __________________________________________ 166

P2.VI.A. Steps taken to develop consensus and the proposal _________________________________________________ 166
P2.VI.B. Regional Processes __________________________________________________________________________ 166
P2.VI.B.1.
P2.VI.B.2.
P2.VI.B.3.
P2.VI.B.4.
P2.VI.B.5.
P2.VI.B.6.
P2.VI.B.7.

AFRINIC regional process ________________________________________________________________ 167
APNIC regional process __________________________________________________________________ 168
ARIN regional process ___________________________________________________________________ 168
LACNIC regional process _________________________________________________________________ 169
RIPE regional process ___________________________________________________________________ 170
Internet Number Community Process (CRISP Team) ___________________________________________ 170
CRISP Team Methodology ________________________________________________________________ 171

P2.VI.C. Level of consensus behind the community’s proposal ________________________________________________ 172

P2. Appendix: Definitions ___________________________________________________ 174
IANA Stewardship Transition Proposal Page 147 of 199

Part 2: Response from the Internet Number Community

IANA Stewardship Transition Proposal Page 148 of 199

Part 2: Response from the Internet Number Community

Response to the IANA Stewardship Transition Coordination
Group Request for Proposals on the IANA from the Internet
Number Community
P2.

Abstract

2001

This document is a response from the Internet Number Community to the IANA StewardshipTransition Coordination Group (ICG) Request for Proposals made on September 8, 2014.
This document was prepared by the CRISP Team, which was established by the Internet
Number Community through the Regional Internet Registries specifically for the purpose of
producing this document.

2002

Please note that an appendix, including uncommon acronyms and defined terms, is included
at the end of this document.

P2.
2003

Proposal type

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

P2.I.
2004

[X] Numbers[ ] Protocol Parameters

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 thefollowing:• A description of the service or activity.
• A description of the customer of the service or activity.
• What registries are involved in providing the service or activity.
• A description of any overlaps or interdependencies between your IANA requirements andthe functions required by other customer communities

2005

P2.I.A.

The service or activity

2006

The IANA activities relevant to the Internet Number Community are:• the allocation of blocks of Internet Number Resources (namely IPv4 addresses, IPv6
addresses, and Autonomous System Numbers, AS Numbers, or ASNs) to the Regional
Internet Registries (RIRs);• the registration of such allocations in the corresponding IANA Number Registries;

IANA Stewardship Transition Proposal Page 149 of 199

Part 2: Response from the Internet Number Community• other related registry management tasks including the management of returned IP address
space, and general registry maintenance; and• the administration of the special-purpose “IN-ADDR.ARPA” and “IP6.ARPA” DNS zones, inaccordance with IPv4 and IPv6 allocations, respectively.
2007

These activities are referred to in this document, collectively, as “IANA Numbering Services.”

2008

P2.I.B.

2009

The RIRs, the not-for-profit membership-based organizations accountable to the Internet
Number Community, manage the registration and distribution of Internet Number Resources(as defined above) on a regional basis. The five RIRs are:

The customer of the service or activity

AFRINIC Serving Africa
APNIC Serving the Asia-Pacific Region
ARIN Serving Canada, some North Atlantic and Caribbean islands, Antarctica, andthe United States
LACNIC Serving Latin America and portions of the Caribbean
RIPE NCC Serving Europe, Central Asia, and the Middle East2010

The RIRs receive blocks of Internet Number Resources from the IANA Number Registries
managed by the IANA Numbering Services Operator and distribute and register thosenumber resources at the regional level. The RIRs also fill a secretariat role, facilitating theopen, transparent, and bottom-up number resource Policy Development Process.

2011

The RIRs have a long-standing and straightforward operational relationship with the IANA.
The IANA maintains the IANA Number Registries from which the RIRs receive allocations to
distribute to the community. The RIRs also coordinate with the IANA to correctly register any
resources that are returned to the IANA Number Registries. Collectively, the system foradministering Internet Number Resources is referred to as the Internet Number Registry
System and is described in detail in RFC 7020.

2012

P2.I.C.

2013

The relevant IANA registries are:

Registries are involved in providing the service or activity• the IPv4 address registry: http://www.iana.org/assignments/ipv4-address-space• the IPv6 address registry: http://www.iana.org/assignments/ipv6-unicast-addressassignments• the ASN registry: http://www.iana.org/assignments/as-numbers• the IN-ADDR.ARPA DNS zone
• the IP6.ARPA DNS zone
IANA Stewardship Transition Proposal Page 150 of 199

Part 2: Response from the Internet Number Community

2014

Collectively these registries are referred to as the IANA Number Registries.

2015

P2.I.D. Overlaps or interdependencies between your IANA requirements andthe functions required by other customer communities

2016

The Internet Engineering Task Force (IETF) is responsible for the specification of the entire
IP address space and AS number space. Through the respective IANA Number Registries(see above), the IETF delegates unicast IP address and AS number space into the Internet
Numbers Registry System (RFC 7020). These registries are published via the IANA.ORG
web site.

2017

Within the IANA Number Registries, there may be reserved values or ranges and specialpurpose registries which are outside the Internet Number Registry System and insteadadministered under the direction of the IETF. The delineation of the specific ranges
delegated to the Internet Numbers Registry System is provided in RFC 7249. It is expectedthat this delineation may change from time to time by actions of the IETF (through the RFC
process) or the RIRs (through the global policy development process). Potential reasons forchanges include the release of previously reserved space for general use and thereservation of previously unused space for a special purpose.

2018

The global Internet community also depends upon the IANA Numbering Services Operator
for administration of the special-purpose IN-ADDR.ARPA and IP6.ARPA DNS zones which
are associated with IPv4 and IPv6 address spaces, respectively. These zones are delegatedto the IANA by the Internet Architecture Board (IAB) and “[s]ub-delegations within thishierarchy are undertaken in accordance with the IANA’s address allocation practices” (RFC3172). The Internet Corporation for Assigned Names and Numbers (ICANN), in its role as
the IANA Numbering Services Operator, administers these zones as “agreed technical work
items” per the IETF-IANA MoU. This work is outside the scope of the National
Telecommunications and Information Administration (NTIA) contract.

2019

Provision of reverse DNS services in the IN-ADDR.ARPA and IP6.ARPA domains may also
require interaction with the .ARPA registry. Collectively these registries are referred to as the
IANA Number Registries.

2020

The Internet Number Community also makes use of the term IANA in the description of theirprocesses, policies, and public database records.

2021

Relevant links:
IETF-ICANN MoU Concerning the Technical Work of the Internet Assigned Numbers
Authority: https://www.icann.org/resources/unthemed-pages/ietf-icann-mou-2000-03-01-en
NTIA IANA Functions Contract: http://www.ntia.doc.gov/page/iana-functions-purchase-order
RFC 3172, Management Guidelines & Operational Requirements for the Address andRouting Parameter Area Domain (”arpa”): https://tools.ietf.org/html/rfc3172
RFC 7020, The Internet Numbers Registry System: https://tools.ietf.org/html/rfc7020
RFC 7249, Internet Numbers Registries: https://tools.ietf.org/html/rfc7249
IANA Stewardship Transition Proposal Page 151 of 199

Part 2: Response from the Internet Number Community

P2.II.

Existing Pre-Transition Arrangements

2022

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

2023

P2.II.A.

2024

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:

Policy Sources• 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.

2025

P2.II.A.1. Affected IANA service or activity

2026

The affected services and activities are those describe in I.A and I.C above.

2027

IANA Numbering Services are provided without involvement by the NTIA.

2028

P2.II.A.2. How policy is developed and established and by whom2029

The policies under which the IANA Numbering Services are provided are developed andagreed within the Internet Number Community via an open, transparent, and bottom-up
policy development process. The community engages in regional policy development
processes facilitated by each RIR; these processes are open to all stakeholders regardlessof specific background or interest or geographic location of residence or activity. Links to theregional Policy Development Processes (PDPs) are included in the RIR Governance Matrix
published on the Number Resource Organization (NRO) web site: www.nro.net/about-thenro/rir-governance-matrix

2030

Any individual may submit a global policy proposal to the Global Policy Development
Process, or gPDP. The community must ratify the proposed policy within each RIR. The
NRO Executive Council (NRO EC) then refers the proposal to the Address Supporting
Organization Address Council (ASO AC), which reviews the process by which the proposal
was developed and, under the terms of the ASO Memorandum of Understanding (ASO
MoU), passes it to the ICANN Board of Directors for ratification as a global policy.

IANA Stewardship Transition Proposal Page 152 of 199

Part 2: Response from the Internet Number Community

2031

There are currently three global policies related to management of the IANA Number
Registries of IPv4 addresses, IPv6 addresses, and Autonomous System Numbers:
https://www.nro.net/policies• IANA Policy for Allocation of IPv6 Blocks to Regional Internet Registries;• IANA Policy for Allocation of ASN Blocks to Regional Internet Registries; and• Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA.

2032

A fourth global policy, ICP-2, Criteria for Establishment of New Regional Internet Registries,
governs the community’s formation of new RIRs.

2033

The global gPDP described in the Global Policy Development Process Document(https://www.nro.net/documents/global-policy-development-process) is used for all of thenumber-related IANA activities described in Section I, but the policy by which “INADDR.ARPA” and “IP6.ARPA” domains must be delegated following IPv4 and IPv6 address
allocations is specified by the IETF in RFC 3172.

2034

P2.II.A.3. How disputes about policy are resolved

2035

The gPDP mentioned above is formally defined in Attachment A of the ASO MoU, signed by
ICANN and the RIRs in 2004 (and signed by AFRINIC when it was established as the fifth
RIR in 2005). This MoU includes provisions for resolving disputes between the IANA
Numbering Services Operator and the Internet Number Community. Although the gPDP
allows for the ICANN Board to dispute the outcome of a consensus community decision(escalating to mediation between ICANN and the RIRs), it does not include any role for the
IANA contract holder (currently the NTIA). The ASO MoU is an agreement between theInternet Number Community and ICANN; the NTIA has no oversight role in policy-making for
IANA Numbering Services, and its transition out of its current role would have no effect on
the policy-making framework.

2036

A separate MoU, the NRO MoU, establishes the NRO as “ a coordinating mechanism of the
RIRs to act collectively on matters relating to the interests of the RIRs” and includes
provisions for dispute resolutions between RIRs on issues relating to global policy
development or implementation.

2037

It is the responsibility of the NRO Number Council (”NRO NC”), a group comprising fifteencommunity members to confirm that the documented RIR PDPs have been followed in thedevelopment of policy. Further, this group reviews the policy followed by the Internet
Number Community to assure itself that the significant viewpoints of interested parties areadequately considered, and only after this confirmation does it then consider forwarding
global policy proposals to the ICANN Board for ratification.

2038

The NRO NC also acts in the role of the ICANN ASO AC, and as such it presents theagreed global policy proposal to the ICANN Board for ratification and operational
implementation.

2039

The ICANN Board reviews the received global number resource policy proposals and may
ask questions and otherwise consult with the ASO Address Council and/or the individual
RIRs acting collectively through the NRO. The ICANN Board may also consult with other
IANA Stewardship Transition Proposal Page 153 of 199

Part 2: Response from the Internet Number Community

parties as the Board considers appropriate. If the ICANN Board rejects the proposed policy,
it delivers to the ASO AC a statement of its concerns with the proposed policy, including inparticular an explanation of the significant viewpoints that were not adequately consideredduring the RIR processes. By consensus of the Internet Number Community in accordancewith the PDPs, the ASO AC may forward a proposed new or modified policy to the ICANN
Board. If the resubmitted proposed policy is rejected for a second time by ICANN, then the
RIRs or ICANN shall refer the matter to mediation.
2040

In case of disputes where mediation has failed to resolve the dispute, the ICANN ASO MoU
provides for arbitration. Via the ASO, the RIRs have been participating in the periodic
independent reviews by the Accountability and Transparency Review Team (ATRT) that are
called for in ICANN’s Bylaws.

2041

P2.II.A.4. References to documentation of policy development and dispute
resolution processes

2042

Relevant links:
ICANN ASO MoU: https://www.nro.net/documents/icann-address-supporting-organizationaso-mou
NRO MoU: https://www.nro.net/documents/nro-memorandum-of-understanding
About the NRO Number Council: https://www.nro.net/about-the-nro/the-nro-number-council
RIR Governance Matrix: https://www.nro.net/about-the-nro/rir-governance-matrix
Global Policies: https://www.nro.net/policies
RFC 3172, Management Guidelines & Operational Requirements for the Address andRouting Parameter Area Domain (”arpa”): https://tools.ietf.org/html/rfc3172

2043

P2.II.B.

Oversight and Accountability

2044

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 iscurrently 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 thoseentities.

IANA Stewardship Transition Proposal Page 154 of 199

Part 2: Response from the Internet Number Community• 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 themechanism 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.

2045

P2.II.B.1. Which IANA service or activity is affected?

2046

The IANA Numbering Services and IANA Number Registries as defined above.

2047

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

2048

A decision by the NTIA to discontinue its stewardship of the IANA Numbering Services, andtherefore its contractual relationship with the IANA Functions Operator, would have nosignificant impact on the continuity of IANA Numbering Services currently provided by
ICANN. However, it would remove a significant element of oversight from the current
system.

2049

ICANN has historically provided IANA Numbering Services via the IANA Number Registries
under the terms of the NTIA IANA Functions contract, and therefore IANA Numbering
Services for the RIRs are currently subject to change in accordance with that agreement.

2050

P2.II.B.3. The entity or entities that provide oversight or perform accountability
functions

2051

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

2052

All institutional actors with a role in management of Internet Number Resources areaccountable to the open community that develops the policies under which those resources
are distributed and registered. The mechanisms used to ensure and enforce thisaccountability differ for each of these actors.

2053

P2.II.B.3.i.

2054

ICANN, as the current IANA Numbering Services Operator, is obligated by the NTIA
agreement to manage the IANA Number Registries according to policies developed by theInternet Number Community.

2055

Although the IANA operator escalation and reporting mechanisms are public in nature, the
NTIA has an oversight role in the provision of the services through its contract with ICANN.
The ultimate consequence of failing to meet the performance standards or reporting

NTIA

IANA Stewardship Transition Proposal Page 155 of 199

Part 2: Response from the Internet Number Community

requirements is understood to be a decision by the contracting party (the NTIA) to terminate
or not renew the IANA Functions Agreement with the current contractor (ICANN).

2056

P2.II.B.3.ii.

The Regional Internet Registries

2057

Administration by the IANA Numbering Services Operator consists predominantly ofprocessing of requests from the RIRs for issuance of additional number resources. The five
RIRs are intimately familiar with global numbering policies under which the requests are
made and maintain communications with the IANA Numbering Services Operator
throughout the request process.

2058

The RIRs are not-for-profit membership-based organizations, and as such they areaccountable to their members by law. The specific governance processes for each RIR differ
depending on where they have been established and the decisions made by theirmembership, but in all RIRs members have the right to elect individuals to the governing
board and to vote on matters related to the respective RIR.

2059

At the same time, an RIR’s registration and allocation practices are directed by policies
developed by the community. Each RIR’s PDP defines how these policies are developed,
agreed, and accepted for operational implementation.

2060

The corporate governance documents and PDPs of each RIR are accessible via the RIR
Governance Matrix, published on the NRO web site: www.nro.net/about-the-nro/rirgovernance-matrix

2061

P2.II.B.4. Description of the mechanism

2062(e.g., contract, reporting scheme, auditing scheme, etc.). This should include a descriptionof the consequences of the IANA functions operator not meeting the standards establishedby the mechanism, the extent to which the output of the mechanism is transparent and theterms under which the mechanism may change.

2063

The NTIA IANA Agreement currently defines obligations of the IANA Operator for Internet
Number Resources.

2064

This obligation is specifically noted in section C.2.9.3 of the NTIA agreement:
C.2.9.3 Allocate Internet Numbering Resources – The Contractor shall have responsibility forallocated and unallocated IPv4 and IPv6 address space and Autonomous System Number (ASN)
space based on established guidelines and policies as developed by interested and affectedparties as enumerated in Section C.1.3.

2065

The NTIA agreement also lays out specific deliverables for the IANA Numbering Services
Operator (ICANN) to produce as a condition of the agreement (see “Section F – Deliveries
and Performance”), including performance standards developed in cooperation with theaffected parties (in the case of the IANA Number Registries, the affected parties are the
RIRs and the Internet Number Community), customer complaint procedures, and regularperformance reporting.

IANA Stewardship Transition Proposal Page 156 of 199

Part 2: Response from the Internet Number Community

2066

These deliverables are met by ICANN via monthly reporting on their performance inprocessing requests for the allocation of Internet Number Resources; these reports include
IANA operational performance against key metrics of accuracy, timeliness, andtransparency, as well as the performance metrics for individual requests. The IANA
operations team also provides escalation procedures for use in resolving any issues withrequests, as per the “IANA Customer Service Complaint Resolution Process.”

2067

P2.II.B.5. Jurisdiction and legal basis of the mechanism

2068

Jurisdiction for the current mechanism is the United States of America under applicable
federal government contracting laws and regulations.

2069

Relevant links:
NTIA IANA Agreement: http://www.ntia.doc.gov/page/iana-functions-purchase-order
ICANN ASO MoU: https://www.nro.net/documents/icann-address-supporting-organizationaso-mou
NRO MoU: https://www.nro.net/documents/nro-memorandum-of-understanding
IANA Customer Service Complaint Resolution Process: http://www.iana.org/help/escalationprocedure
IANA Performance Standards Metrics Report: http://www.iana.org/performance/metrics
RIR Governance Matrix: https://www.nro.net/about-the-nro/rir-governance-matrix

P2.III.

Proposed Post-Transition Oversight andAccountability

2070

This section should describe what changes your community is proposing to thearrangements 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 newarrangements.

2071

If your community’s proposal carries any implications for the interface between the IANA
functions and existing policy arrangements described in Section II.A, those implications
should be described here.

2072

If your community is not proposing changes to arrangements listed in Section II.B, therationale and justification for that choice should be provided here.

2073

P2.III.A. The elements of this proposal

IANA Stewardship Transition Proposal Page 157 of 199

Part 2: Response from the Internet Number Community•

ICANN to continue as the IANA Functions Operator for the IANA Numbering Services,hereinafter referred to as the IANA Numbering Services Operator, via a contract with the
RIRs;

•

IPR related to the provision of the IANA services remains with the community;•

Service Level Agreement with the IANA Numbering Services Operator; and•Establishment of a Review Committee, with representatives from each RIR, to advise
the NRO EC on the review of the IANA functions operator’s performance and meeting ofidentified service levels.

2074

This proposal assumes that specific IANA customers (i.e., the number community, theprotocol parameter community, and the name community) will have independent
arrangements with the IANA Functions Operator related to maintenance of the specificregistries for which they are responsible. At the same time, the Internet Number Community
wishes to emphasize the importance of communication and coordination between thesecommunities to ensure the stability of the IANA services. Such communication andcoordination would be especially vital should the three communities reach different
decisions regarding the identity of the IANA Functions Operator after the transition. Efforts tofacilitate this communication and coordination should be undertaken by the affected
communities via processes distinct from this stewardship transition process.

2075

P2.III.A.1. ICANN to continue as the IANA Numbering Services Operator via acontract with the RIRs

2076

To maintain stability and continuity in operations of the IANA Numbering Services, veryminimal changes to the arrangements listed in Section 2.2 are proposed, including theidentification of the proposed initial IANA Numbering Services Operator. As noted innumerous NRO communications over the past decade, the RIRs have been very satisfied
with the performance of ICANN in the role of the IANA Numbering Services Operator.
Taking this into account, and considering the Internet Number Community’s strong desire forstability and a minimum of operational change, the Internet Number Community believes
that ICANN should remain in the role of the IANA Numbering Services Operator for at least
the initial term of the new contract.

2077

Although there are no concrete needs or plans to do so at this point, the Internet Number
Community may in the future determine that the IANA Numbering Services related tonumber resources should be transferred to a different contractor. In such a case, selectionof a new contractor shall be conducted in a fair, open, and transparent process, consistent
with applicable industry best practices and standards.

2078

P2.III.A.2. IPR related to the provision of the IANA services remains with thecommunity

2079

There are several intellectual properties related to the provision of the IANA services whose
status should be clarified as part of the transition: the IANA trademark, the IANA.ORG
domain name, and public databases related to the performance of the IANA Numbering
Services, including the IANA Numbers Registries.
IANA Stewardship Transition Proposal Page 158 of 199

Part 2: Response from the Internet Number Community

2080

It is important that the IPR status of the registries remains clear and ensures free andunrestricted access to the public registry data throughout the stewardship transition. It is the
expectation of the Internet Number Community that the IANA Number Registries are in the
public domain.

2081

It is also the expectation of the Internet Number Community that non-public information
related to the IANA number resource registries and corresponding services, including theprovision of reverse DNS delegation in IN-ADDR.ARPA and IP6.ARPA, is managed by the
IANA operator and will be transferred to its successor(s). All rights on non-public information
related to the IANA number resource registries and corresponding services must betransferred to the RIRs.

2082

It is the preference of the Internet Number Community that all relevant parties agree tothese expectations as part of the transition.

2083

With regards to the IANA trademark and the IANA.ORG domain, it is the expectation of theInternet Number Community that both are associated with the IANA Numbering Services
and not with a particular IANA Numbering Services Operator. Identifying an organizationthat is not the IANA Numbering Services Operator and which will permanently hold theseassets will facilitate a smooth transition should another operator (or operators) be selectedin the future. It is the preference of the Internet Number Community that the IANA trademark
and the IANA.ORG domain name be transferred to an entity independent of the IANA
Numbering Services Operator, in order to ensure that these assets are used in a nondiscriminatory manner for the benefit of the entire community. From the Internet Number
Community’s perspective, the IETF Trust would be an acceptable candidate for this role.

2084

The transfer of the IANA trademark and IANA.ORG domain to the IETF Trust will require
additional coordination with the other affected communities of the IANA Services, namely,
protocol parameters and names. It is the preference of the Internet Number Community that
all relevant parties agree to these expectations as part of the transition.

2085

P2.III.A.3. Service Level Agreement with the IANA Numbering Services
Operator

2086

The Internet Number Community proposes that a new contract be established between the
IANA Numbering Services Operator and the five RIRs. The following is a proposal to replace
the current NTIA IANA agreement with a new contract that more directly reflects andenforces the IANA Numbering Services Operator’s accountability to the Internet Number
Community. The proposal attempts to ensure the continuity of processes and mechanismsthat have proved successful and with which the community is satisfied.
•

The services provided by the IANA Numbering Services Operator in relation to the IANA
Numbering Services remain unchanged.

•

The policy sources identified in Section II.A are unaffected.

•

The oversight and accountability mechanisms detailed in Section II.B remainunchanged.

IANA Stewardship Transition Proposal Page 159 of 199

Part 2: Response from the Internet Number Community•

The entities that provide oversight or perform accountability functions (the RIRs) remain
the same.

•

The consequence of failure to meet performance standards remains unchanged:
termination or non-renewal of the contract.

2087

The agreement, essentially a Service Level Agreement for the IANA Numbering Services,would obligate the IANA Numbering Services Operator to carry out the IANA Numbering
Services according to policies developed by the Internet Number Community via thegPDP as well as management of the delegations within IN-ADDR.ARPA and IP6.ARPA
domains. The agreement would include specific requirements for performance and reporting
consistent with current mechanisms and would specify consequences should the IANA
Numbering Services Operator fail to meet those requirements, the means for the resolutionof disputes between the parties, and the terms for renewal or termination of the agreement.
IANA Numbering Services should be reliable and consistent, with any registry changes
made in an open and transparent manner to the global community. The agreement should
also require the IANA Numbering Services Operator to appropriately coordinate with anyother operator of IANA services. The agreement would also provide for jurisdiction andgoverning law regarding the new arrangement.

2088

It is expected that the RIRs, as the contractual party of this agreement, will draft the specificlanguage of this agreement. During the drafting process, the RIRs are expected to consult
their respective RIR communities, and that the drafting process will be guided by theprinciples listed below. References to relevant sections of the current NTIA agreement arealso noted, as it is expected the new agreement will share many of the same contractual
goals and mechanisms.

2089

IANA Service Level Agreement Principles
1. Separation of Policy Development and Operational Roles
The IANA Numbering Services Operator will merely execute the global policies adopted
according to the global Policy Development Process defined in the ASO MoU.
Relevant section(s) in the NTIA contract: C.2.4, C.2.5
2. Description of Services Provided to RIRs
The IANA Numbering Services Operator will maintain the IANA Number Registries andprovide IANA Numbering Services to the RIRs in accordance with the specific processes
and timelines described in this section of the agreement.
Relevant section(s) in the NTIA contract: C.2.9.3
3. Obligation to Issue Reports on Transparency and Accountability
The IANA Numbering Services Operator will commit to certain obligations so as toperform the function as expected by the Internet Number Community and will be obliged
to periodically issue reports illustrating its compliance with the Internet Number
Community’s expectations.
Relevant section(s) in the NTIA contract: C.2.6, C.2.7, C.2.8
4. Security, Performance, and Audit Requirements

IANA Stewardship Transition Proposal Page 160 of 199

Part 2: Response from the Internet Number Community

The IANA Numbering Services Operator will commit to specific security standards,
metric requirements, and audit requirements and will be obliged to periodically issue
reports illustrating its compliance with them.
Relevant section(s) in the NTIA contract: C.3, C.4, C.5
5. Review of the IANA Operations
The RIRs will perform reviews to assess whether the IANA Numbering Services
Operator complies with all requirements described in the agreement whenever they
deem appropriate. The IANA Numbering Services Operator will be obliged to facilitate
this review.
6. Failure to Perform
If the IANA Numbering Services Operator fails to perform as agreed, there will be
specific consequences. One of these consequences may be termination of theagreement.
Relevant section(s) in the NTIA contract: E.2, I.67
7. Term and Termination
RIRs will be able to periodically review the agreement and evaluate whether they want torenew the agreement. Either party may terminate the agreement with reasonable priornotice.
Relevant section(s) in the NTIA contract: Page 2 of Award, I.51, I.52, I.53
8. Continuity of Operations
If, at the end of the term, the RIRs decide to sign an agreement for provision of IANA
Numbering Services by a different party, the previous IANA Numbering Services
Operator will be obliged to ensure an orderly transition of the function while maintaining
continuity and security of operations.
Relevant section(s) in the NTIA contract: C.7.3 and I.61
9. Intellectual Property Rights and Rights Over Data
The contract will implement the RIR community expectations as described in section
III.A.2.
Relevant section(s) in the NTIA contract: H.4, H.5
10. Resolution of Disputes
Disputes between the parties related to the SLA will be resolved through arbitration.
11. Fee
The fee is based on costs incurred by the IANA Numbering Services Operator inproviding the IANA Numbering Service.
Relevant section(s) in the NTIA contract: B.2

2090

P2.III.A.4. Establishment of a Review Committee

2091

To ensure that the service level defined in the proposed agreement is maintained by the
IANA Numbering Services Operator, the NRO EC will periodically review the service level ofthe IANA Numbering Services provided to the Internet Number Community.

IANA Stewardship Transition Proposal Page 161 of 199

Part 2: Response from the Internet Number Community

2092

The RIRs shall establish a Review Committee that will advise and assist the NRO EC in its
periodic review. The Review Committee will, as needed, undertake a review of the level ofservice received from the IANA Numbering Services Operator and report to the NRO EC
any concerns regarding the performance of the IANA Numbering Services Operator,
including especially any observed failure or near-failure by the IANA Numbering Services
Operator to meet its obligations under the proposed agreement. Any such Review
Committee will advise the NRO EC in its capacity solely to oversee the performance of the
IANA Numbering Services, and the Review Committee’s advice and comment will be limited
to the processes followed in the IANA Numbering Services Operator’s performance under
the proposed agreement. Activities of the Review Committee shall be conducted in an open
and transparent manner. Reports from the Review Committee shall be published.

2093

The Review Committee should be a team composed of suitably qualified Internet Number
Community representatives from each RIR region. The selection of the Review Committee
members should be conducted in an open, transparent, and bottom-up manner appropriate
for each RIR region. There should be equal representation from each RIR region within the
Review Committee.

2094

P2.III.B. Implications for the interface between the IANA functions andexisting policy arrangements

2095

This proposal carries no implication for the interface between IANA Numbering Services andexisting policy arrangements described in Section II.A. The text in Attachment A of theICANN ASO MoU meets the current and anticipated requirements for a community-driven
global policy development process.

2096

As an additional measure of security and stability, the RIRs have documented theirindividual accountability and governance mechanisms and asked the community-based
Number Resource Organization Number Council (NRO NC) to undertake a review of thesemechanisms and make recommendations for improvements that may be warranted given
the nature of the stewardship transition for Internet Number Resources.

P2.IV. Transition Implications
2097

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, orother 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 establishedarrangements.

IANA Stewardship Transition Proposal Page 162 of 199

Part 2: Response from the Internet Number Community

2098

2099

P2.IV.A. Operational requirements to achieve continuity of service throughout
the transition•

Describe operational requirements to achieve continuity of service and possible newservice integration throughout the transition.

•

Risks to operational continuity and how they will be addressed.

The intent of the proposal described above is to:•

Minimize risks to operational continuity of the management of the IANA Numbering
Services, and;•Retain the existing framework for making those policies that describe the managementof the IANA Number Registries, as this framework is already structured to ensure open,transparent, and bottom-up development of such policies.

2100

Under current arrangements, the NTIA is responsible for extending or renewing the IANA
functions agreement and setting the terms of that contract. A new agreement with the five
RIRs and the IANA Numbering Services Operator as signatories would shift the
responsibility for renewing, setting terms, or terminating the contract to the RIRs, who would
coordinate their decisions via the NRO EC. Decisions made regarding the agreement would
be based on operational circumstances, past performance, and input from the Internet
Number Community.

2101

The shift from the existing contractual arrangement to one or more new contracts covering
the IANA Numbering Services Operator’s ongoing management of the IANA Numbering
Services should result in no operational change for management of the IANA Number
Registries. This will help minimize any operational or continuity risks associated withstewardship transition.

2102

By building on the existing Internet registry system (which is open to participation from allinterested parties) and its structures, the proposal reduces the risk associated with creating
new organizations whose accountability is unproven.

2103

A new agreement specifying IANA operation of the IANA Number Registries can and shouldbe established well before the September 2015 transition target, as we propose to simply
reconcile the contracting party with the policy authority, without changing service levels orreporting.

2104

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

2105

The necessary legal framework in the absence of the NTIA contract will be fulfilled by the
proposed agreement between the IANA Numbering Services Operator and the RIRs. As
stated in Section III above, the Service Level Agreement for the IANA Numbering Services,would obligate the IANA Numbering Services Operator to carry out those IANA Numbering
Services according to policies developed by the community via the gPDP, as well as
management of the delegations within IN-ADDR.ARPA and IP6.ARPA domains.

IANA Stewardship Transition Proposal Page 163 of 199

Part 2: Response from the Internet Number Community

2106

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

2107

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

2108

This proposal does not propose any new technical or operational methods. There isinclusion of a proposed Review Committee to be established by the five RIRs acting
cooperatively and coordinating through the NRO EC; however, this does not carry any new
operational method, as the IANA Numbering Services Operator would remain accountable
to the party with whom it is contracting, in this case the five RIRs in place of the NTIA. The
proposed Review Committee is a tool for the Internet Number Community to evaluate andreview performance of the IANA Numbering Services provided.

P2.V.
2109

NTIA Requirements

Additionally, NTIA has established that the transition proposal must meet the following fiverequirements:•

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 intergovernmental organization solution.

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

This proposal addresses each of the NTIA’s requirements:

2111

P2.V.A.

2112

The RIRs are not-for-profit membership-based organizations accountable to theircommunity. The processes developed by the community over time are open, transparent,
and bottom-up, and inclusive of all stakeholders, ensuring the opportunity for anyone with aninterest in management of Internet Number Resources to participate in policy-making.

2113

Shifting stewardship of the IANA Numbering Services to the Internet Number Community is
an important step in acknowledging the maturity and stability of the multistakeholder
governance model and in recognizing the success and de facto authority of that model
under the current arrangement.

2114

P2.V.B.

Support and enhance the multistakeholder model

Maintain the security, stability, and resiliency of the Internet DNS
IANA Stewardship Transition Proposal Page 164 of 199

Part 2: Response from the Internet Number Community2115

No changes are proposed in this document that affect the security, stability, or resiliency of
the DNS.

2116

This proposal is chiefly concerned with Internet Number Resources, which also needsecurity, stability, and resiliency. The existing operational and policy-making structures
related to management of the IANA Number Registries have served the Internet community
well over time, and the Internet Number Community has expressed a strong desire forstability and operational continuity of this critical element of the Internet infrastructure.
Accordingly, this proposal suggests minimal changes to existing processes.

2117

P2.V.C. Meet the needs and expectation of the global customers andpartners of the IANA services

2118

The Internet Number Community is the customer of the Internet number resource IANA
Numbering Services. The Internet Number Community has often expressed its satisfaction
with the current management of the IANA Numbering Services, which have effectively
implemented policies developed by the community and efficiently provided Numbering
Services to the RIRs. This proposal has been developed by the Internet Number
Community, as the customer of the IANA Numbering Services, and meets its need forcontinuity and stability in the operation of the IANA Numbering Services. It does this bysolidifying the IANA Numbering Services Operator’s accountability to the Internet Number
Community.

2119

P2.V.D.

2120

An open Internet relies on the effective implementation of policies developed via open,transparent, and bottom-up processes, ensuring the transparent and coordinated distribution
and registration of Internet Number Resources. The Internet Number Community has a longstanding history of open, transparent, and bottom-up policy-making and operational
processes (including the transparent publication of all registration information). By buildingon the structures developed by the Internet Number Community, this proposal ensures thatin this regard the openness of the Internet is maintained.

2121

In addition, the proposed community Review Committee will ensure community involvementin the open and transparent evaluation of the IANA Numbering Services.

2122

P2.V.E.

2123

This proposal does not replace the NTIA role with a government-led or an intergovernmental organization solution. This proposal places the RIRs in the role currently
occupied by the NTIA. The RIRs are not-for-profit organizations, accountable to thecommunity. The Internet Number Community is open to anyone who wishes to contributeand includes participants from all Internet stakeholder groups, including operators, civilsociety, business, the technical community, and governments. Open, community-driven, andconsensus-based policy development processes mean that no single stakeholder group has
a dominant role in policy-making.

Maintain the openness of the Internet

Not a government-led or inter-governmental solution

IANA Stewardship Transition Proposal Page 165 of 199

Part 2: Response from the Internet Number Community

P2.VI.
2124

Community ProcessThis 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 adescription of areas of contention or disagreement.

2125

P2.VI.A. Steps taken to develop consensus and the proposal

2126

The Internet Number Community process is open, transparent, and bottom-up, with theinitial discussions and proposal elements agreed on a regional basis in each region of theInternet Number Community. The consensus output of these five regional discussions has
been consolidated in a single global proposal.

2127

This process was deliberately modeled on the processes that the Internet Number
Community has successfully employed for policy-making at the regional and global levels. It
reflects the strong commitment emerging from all community discussions to employing
proven structures and mechanisms in this process.

2128

The proposal development can therefore be seen as two distinct phases, first at the regional
level and then at the global level. It is important to emphasize that neither of these phases
occurred in isolation; throughout the first phase there was communication between the five
regions, and during the second phase each region remained apprised of progress andprovided feedback on successive iterations of the global proposal.

2129

P2.VI.B. Regional Processes

2130

The Internet Number Community’s process for developing a new agreement for operation of
the IANA Numbering Services was founded on the regional Internet Number Community
structure, in which stakeholders discuss policies and other issues relevant to numbers
resources. The Internet Number Community has for many years fostered the open,transparent, and bottom-up participation of a broad range of stakeholders. Existingmechanisms and communication channels therefore existed to facilitate the IANA
stewardship transition discussion, eliminating the need for new processes, communication
channels, or bodies. The RIRs have worked actively over the years to engage the full rangeof stakeholders via outreach activities within their regions as part of their commitment toopenness, inclusiveness, and transparency. Building on these outreach activities, the RIRs
and the CRISP Team have ensured that this proposal has been the product of input andfeedback from the full range of stakeholders with an interest in Internet Number Resources.

2131

The RIRs operate according to open, transparent, bottom-up, and consensus-based
processes, allowing anyone with an interest to participate in the discussions on an equal
footing. Holding the IANA stewardship discussion within this community has ensured broad
participation and facilitated examination of the issues raised in the context of local and
IANA Stewardship Transition Proposal Page 166 of 199

Part 2: Response from the Internet Number Community

regional circumstances. The very active community engagement within all regions not onlyshows the positive commitment of the Internet Number Community to this process but also
demonstrates the Internet Number Community’s mature and well-functioning decisionmaking processes.
2132

The Internet Number Community discussed the IANA stewardship issues on five regional
and two global mailing lists and at RIR and other public meetings, both face-to-face and via
remote participation. Although the discussions have been uniformly open and transparent,with all discussions archived on mailing lists and meeting records, each region has
contributed to the community consensus via regionally defined processes suitable to their
particular local needs and culture.

2133

Links to specific output documents and archives of all of the Internet Number Community
discussions are available at https://www.nro.net/nro-and-internet-governance/ianaoversight/timeline-for-rirs-engagement-in-iana-stewardship-transition-process

2134

P2.VI.B.1.

2135

The AFRINIC community held an IANA oversight transition workshop during the May 25
through June 6, 2014, Africa Internet Summit in Djibouti. As a follow-up to the meeting,
AFRINIC set up a mailing list to provide a platform for the African Internet community to
discuss the IANA oversight transition process. The mailing list was announced on July 4,
2014. The list and its archives can be found athttps://lists.afrinic.net/mailman/listinfo.cgi/ianaoversight2136

AFRINIC has a dedicated web portal for sharing information on the IANA stewardshiptransition: http://afrinic.net/en/community/iana-oversight-transition

2137

AFRINIC also conducted a survey seeking community input on the IANA StewardshipTransition:
http://afrinic.net/images/stories/Initiatives/%20survey%20on%20the%20iana%20stewardshi
p%20transition.pdf

2138

The last face-to-face meeting at which IANA oversight transition consultations were heldwith the community was during the AFRINIC-21 meeting, held in Mauritius from November
22 through 28, 2014. Recordings of the session are available:
http://meeting.afrinic.net/afrinic-21/en/vod

2139

Discussions continued on the ianaoversight@afrinic.net mailing list until the closure ofcomments set by the CRISP Team on January 12, 2015.

2140

The AFRINIC region CRISP Team was appointed by the AFRINIC Board of Directors. Key
milestones of the appointment process were:2141

October 27, 2014: Public Call for nominations — The call was sent by the AFRINIC CEO tomajor community mailing lists, indicating intent of the Board to make appointments by
November 12, 2014: https://lists.afrinic.net/pipermail/announce/2014/001326.html

2142

November 8, 2014: The AFRINIC CEO announced the 5 nominated candidates:
https://lists.afrinic.net/pipermail/ianaoversight/2014-November/000099.html

AFRINIC regional process

IANA Stewardship Transition Proposal Page 167 of 199

Part 2: Response from the Internet Number Community

2143

November 13, 2014: The AFRINIC Board Chair announced the three CRISP Team
members selected to the community: https://lists.afrinic.net/pipermail/rpd/2014/004381.html

2144

The AFRINIC IANA oversight transition information page:
http://www.afrinic.net/en/community/iana-oversight-transition

2145

P2.VI.B.2.

2146

APNIC set up a public mailing list on April 1, 2014, to develop a regional position on the
IANA stewardship transition: http://mailman.apnic.net/mailman/listinfo/IANAxfer

2147

A web site dedicated to sharing up-to-date information on the IANA stewardship transition
was set up: http://www.apnic.net/community/iana-transition

2148

A draft proposal was discussed at the dedicated session at the APNIC 38 Meeting in
September 2014, and a regional community consensus was reached. The meeting included
bidirectional remote participation via live webcast and a virtual conference room:https://conference.apnic.net/38/program#iana2149

On October 23, 2014, through a post to the APNIC IANAxfer mailing list, APNIC sought
volunteers from the Asia Pacific community to nominate to join the CRISP Team. The
nominees were asked to provide information about their qualifications and interest to the
APNIC Executive Council for its consideration. The nomination period was open for two
weeks. On November 12, 2014, the APNIC Executive Council announced the three APNIC
representatives selected to join the CRISP Team: http://blog.apnic.net/2014/11/13/drgovind-and-ms-okutani-appointed-to-nro-crisp-team

2150

Information was also posted on APNIC’s IANA oversight transition web site:
http://www.apnic.net/community/iana-transition

2151

Discussion continued on the ianaxfer@apnic.net mailing list until the closure of thecomments on January 12, 2015.

2152

P2.VI.B.3.

2153

ARIN held a community consultation from October 1 through October 10, 2014, including alive session on October 9, during the ARIN 34 meeting in Baltimore, USA.

2154

On October 13, ARIN established a mailing list, iana-transition@arin.net, to facilitate
regional discussion of the IANA stewardship transition planning process. This mailing list
remained open for comments and updates throughout the transition planning process. The
archives are open and available for all Internet community members to view:
http://lists.arin.net/pipermail/iana-transition

2155

A regional survey was conducted from October 13 through 20, 2014, eliciting 64 responses:
https://www.arin.net/participate/governance/iana_survey.pdf

APNIC regional process

ARIN regional process

IANA Stewardship Transition Proposal Page 168 of 199

Part 2: Response from the Internet Number Community

2156

On October 25, 2014, ARIN put a call out for volunteers to serve on the CRISP Team ascommunity representatives of the ARIN region. The call for volunteers ended on October 31,
2014. The ARIN Board of Trustees considered all the resulting nominees and on November
8 announced the appointment of its three CRISP Team members.

2157

On November 21, 2014, the first ARIN draft proposal was shared on ianatransition@arin.net and discussion followed: http://teamarin.net/wpcontent/uploads/2014/03/ARIN_draft_proposal.pdf

2158

ARIN has set up a web portal dedicated to the IANA Stewardship Transition planning
process: http://teamarin.net/education/internet-governance/iana-transition

2159

P2.VI.B.4.

2160

The LACNIC community began a consultative process on August 15, 2014, with a public
teleconference in which LACNIC’s CEO discussed the methodology, expected timeline, andconsultation scope with the community. The primary goal was to obtain the region’s input tothe multistakeholder debate on the transition of stewardship of the IANA Numbering
Services, gathering regional points of view, concerns, suggestions, and recommendations,specifically concerning Internet number resource management.

2161

From that starting point, three representatives from the community guided the regional
debate: http://www.lacnic.net/en/web/transicion/representantes

2162

Discussion took place on the internet-gov@lacnic.net mailing list.

2163

From August 15 through September 15, 2014, open discussion was held.

2164

On September 23, moderators presented a preliminary transition document summarizing allcontributions and discussions.

2165

A thirty-day community discussion of the preliminary document ended on October 24.

2166

During the October 27 through 31 LACNIC meeting in Santiago, the preliminary transition
document was discussed in two sessions. The first session focused on the global IANA
oversight transition process and the work done by the name, number, and protocol
communities. The second focused on the proposals from the mailing list and began theprocess of drafting a final LACNIC regional community proposal.

2167

Following these sessions, there was an additional week of community discussion ending
November 15, before the proposal was ratified by LACNIC’s Board of Directors andsubmitted to the CRISP Team.

2168

Announcement of the appointment of the LACNIC region members of the CRISP Team:
http://www.lacnic.net/en/web/anuncios/2014-crisp-team

2169

After the board appointed the CRISP Team members, there was continued dialog between
the Community Leaders and the LACNIC CRISP Team representatives through email andteleconferences.

LACNIC regional process

IANA Stewardship Transition Proposal Page 169 of 199

Part 2: Response from the Internet Number Community

2170

The final result of the Consultation at LACNIC Community:
http://www.lacnic.net/en/web/transicion/resultado-consulta-publica

2171

The list internet-gov@lacnic.net remained open for regional discussion until the closure of
the comments on January 12, 2015.

2172

P2.VI.B.5.

2173

The RIPE community agreed at the RIPE 68 Meeting in May 2014 that the development of acommunity position on IANA stewardship should take place in the existing RIPE
Cooperation Working Group and via that working group’s public mailing list:
https://www.ripe.net/ripe/mail/wg-lists/cooperation

2174

The RIPE NCC, as secretariat for the RIPE community, also facilitated discussion of the
IANA stewardship in national and regional forums across the RIPE NCC service region from
May through November, 2014. Some of these forums also included remote participation
facilities. Summaries of all discussions were posted to the RIPE Cooperation Working Group
mailing list and on the RIPE web site: https://www.ripe.net/iana-discussions

2175

Although there were active, and at times passionate, discussions in the community
throughout the consultation period, there was clearly strong agreement on the needs of theInternet Number Community and the general principles that should underpin transition of
IANA stewardship. From September through November 2014, RIPE community discussion
converged on a set of principles reflecting the community’s primary concerns and needs inthe development of an IANA stewardship transition proposal. These discussions arereflected in the discussions on the mailing list from that time:
http://www.ripe.net/ripe/mail/archives/cooperation-wg

2176

Discussions at the RIPE 69 meeting in November 2014 reached consensus on theprinciples discussed on the mailing list. During the RIPE 69 meeting a general invitation forcommunity volunteers to the CRISP Team was distributed via various RIPE NCC
membership and RIPE community mailing lists: http://www.ripe.net/ripe/mail/archives/ripelist/2014-November/000877.html

2177

This announcement noted the procedure whereby the RIPE Chair, in consultation with the
RIPE NCC Executive Board, would select two community representatives and a staff
representative. At the conclusion of RIPE 69, the community expressed its support for thethree RIPE representatives to the CRISP Team.

2178

RIPE Cooperation Working Group Session: https://ripe69.ripe.net/programme/meetingplan/coop-wg/#session1

2179

RIPE 69 Closing Plenary Session: https://ripe69.ripe.net/archives/video/10112

2180

P2.VI.B.6.

2181

Following the broad consultations and active discussion within the five regions, amechanism was established to develop a single proposal from the Internet Number
Community, based on the consensus of the five regions.

RIPE regional process

Internet Number Community Process (CRISP Team)

IANA Stewardship Transition Proposal Page 170 of 199

Part 2: Response from the Internet Number Community

2182

On October 16, 2014, the Internet Number Community proposed the formation of the CRISPTeam to develop a single Internet Number Community proposal to the IANA Stewardship
Coordination Group (ICG). Established around a model similar to the community-based
NRO Number Council, the CRISP Team comprises three community members from each of
the RIR regions (two community members and one RIR staff). The selection of the CRISPTeam members from each region was facilitated via transparent but distinct processes
within each RIR. Details of these selection processes are included in the RIR processdescriptions above.

2183

The CRISP Team members are:
AFRINIC Region:
Alan P. Barrett – Independent Consultant
Mwendwa Kivuva – Network Infrastructure Services, University of Nairobi
Ernest Byaruhanga (Appointed RIR staff)
ARIN Region:
Bill Woodcock – Executive Director, Packet Clearing House
John Sweeting – Sr. Director Network Architecture & Engineering, Time Warner Cable
Michael Abejuela (Appointed RIR staff)
APNIC Region:
Dr Govind – CEO, NIXI
Izumi Okutani – Policy Liaison, JPNIC
Craig Ng (Appointed RIR staff)
LACNIC Region:
Nico Scheper – Manager, Curacao IX
Esteban Lescano – Vice Chairman, Cabase Argentina
Andrés Piazza (Appointed RIR staff)

RIPE NCC Region:
Nurani Nimpuno – Head of Outreach & Communications, Netnod
Andrei Robachevsky – Technology Programme Manager, Internet Society
Paul Rendek (Appointed RIR staff)

2184

P2.VI.B.7.

CRISP Team Methodology

2185

The charter of the CRISP Team describes its methodology, to ensure maximum
transparency and openness of the process. The charter is available on the NRO web site:
https://www.nro.net/crisp-team

2186

From that charter:

IANA Stewardship Transition Proposal Page 171 of 199

Part 2: Response from the Internet Number Community•

The CRISP Team shall meet entirely via teleconference for its activities; theseteleconferences will be open to the public who wish to listen to the CRISP Team
discussions, and will be facilitated by the Regional Internet Registries.

•

The CRISP Team shall also work through a public mailing list and the archive of suchmailing list will be publicly available. The name of the mailing list will beianaxfer@nro.net.

•

The results of each CRISP Team meeting shall be published on the ianaxfer@nro.net
mailing list and additionally by each RIR to the community. The CRISP Team members
from the region shall monitor and participate in the community discussion in their region
regarding CRISP Team outputs.

2187

The CRISP Team held its first teleconference on December 9, 2014. At that meeting, Izumi
Okutani (APNIC region) and Alan Barrett (AFRINIC region) were selected as the Chair andVice-Chair, respectively. A timeline for the process was defined, published, and announced.
All CRISP teleconferences have been announced on the relevant regional mailing lists aswell as the global ianaxfer@nro.net list. As stipulated in the charter, all CRISP
teleconferences have been open to observers. Archives of the audio, video, and minutes of
all CRISP teleconferences, as well as several iterations of the proposal draft and a
spreadsheet of issues raised by community members and their current status, have been
made available online: https://www.nro.net/crisp-team

2188

Additionally, the CRISP Team decided that in the interests of efficiency an “internal” CRISP
mailing list would be established – only members of the CRISP Team would be able to send
mail to this list or receive mail sent to the list, but the list content would be archived publicly
on the NRO web site. This archive is available: https://www.nro.net/pipermail/crisp/

2189

Throughout the CRISP Team process, CRISP Team members have engaged with theirregional communities, ensuring that the communities are informed and sharing information
with other CRISP Team members on key events and discussions in their regional forums.
They have also consulted the discussion archives of their regional communities asnecessary throughout the process to ensure the fair and accurate representation of theircommunity’s views. CRISP Team members have been active in encouraging feedback fromtheir regions, whether on the global ianaxfer@nro.net mailing list or in the regional
discussion forums.

2190

P2.VI.C. Level of consensus behind the community’s proposal

2191

Throughout CRISP Team deliberations, consensus was determined when, following
discussions within the team, no further comments, concerns, or objections were observed. A
24-hour window was set for decisions made during CRISP Team teleconferences andshared on the CRISP Team mailing list to allow those who were not at the call to provide
input.

2192

A similar approach was taken for the ianaxfer@nro.net list. Consensus was determinedfollowing discussions on the list around an issue raised or a new suggestion when no further
comments, concerns, objections were observed.

2193

Prior to submitting this proposal to the ICG, two drafts were published, along with calls for
feedback from the global community. These two comment periods were important in
IANA Stewardship Transition Proposal Page 172 of 199

Part 2: Response from the Internet Number Community

ensuring that the community had a chance to actively contribute to resolving issues
identified during the process.
2194

In addition, the CRISP Team has called for community feedback on this current draft of the
proposal. ICG members and other interested parties can observe the level of support for the
proposal in the archives of ianaxfer@nro.net mailing list.

2195

In comparing output coming from each RIR region, many commonalities were identified
early in the process, and there was a clear consensus across the five RIR communities on
the basic principles for this proposal. The Internet Number Community tradition of open,transparent, and bottom-up processes defined the discussions in all regions, and a solid
trust in the RIR system was consistently expressed throughout the process. Although all five
regional inputs differed, no major conflicts or irreconcilable points of contention wereidentified.
Notable points of difference included the views on the format of the agreement to beestablished between the IANA Numbering Services Operator and the RIRs, and on the needfor an oversight body to periodically review the agreement. The current proposal reflects theconsensus agreement reached on these issues through discussion within the CRISP Teamand in public forums, especially the ianaxfer@nro.net mailing list.

2196

In the global discussions at ianaxfer@nro.net, several issues received close attention andprovoked significant discussion. These issues included:•

Composition of Review Committee•

Details of the agreement, including its term and termination conditions, dispute
resolution and the need of SLA text to be submitted•Intellectual property rights of the data and trademarks associated with the IANA
Numbering Services

2197

Comments mainly focused on clarification of details of these issues. Support was expressedby several people on the ianaxfer@nro.net mailing list on the final, agreed elements of the
proposal listed in Section III.

2198

There was clear agreement from the global community on positions regarding each of theseissues, as reflected in the content of the current proposal. The CRISP Team believes
therefore that the current proposal fully reflects the consensus of the global Internet Number
Community.

IANA Stewardship Transition Proposal Page 173 of 199

Part 2: Response from the Internet Number Community

P2. Appendix: Definitions
Address Supporting Organization (ASO): a Supporting Organization in the ICANN structure, as
defined in the ICANN Bylaws, and was formed in 2004 by the ICANN ASO MoU. The ASO's role is toreview and develop recommendations on Internet Protocol (IP) address policy and to advise the ICANN
Board. The functions of the ASO are carried out by the Address Supporting Organization Address
Council (ASO AC). https://aso.icann.org/about-the-aso/
Address Supporting Organization Address Council (ASO AC): has the following responsibilities in the
ICANN structure and processes: undertaking a role in the global policy development process; defining
procedures for the selection of individuals to serve on other ICANN bodies, in particular seats 9 and 10 on
the ICANN Board, and implementing any roles assigned to the AC in such procedures; and providing
advice to the ICANN Board on number resource allocation policy, in conjunction with the RIRs. The ASO
AC function is carried out by the members of the NRO NC.
CRISP Team: The Consolidated RIR IANA Stewardship Proposal (CRISP) team was established by thefive RIRs specifically for the purpose of producing this document.
Global Policies: Internet number resource policies that have the agreement of all RIRs according to theirpolicy development processes and ICANN, and require specific actions or outcomes on the part of IANA
or any other external ICANN-related body in order to be implemented.
Global Policy Development Process (gPDP): The RIR communities’ process for the development ofpolicy relating to management of the global Internet number registries. The gPDP is employed in thedevelopment of policies relating to all of the number-related IANA activities described in Section I, except
those relating to maintenance of the “IN-ADDR.ARPA” and “IP6.ARPA” domains. The gPDP is formallydefined in Attachment A of the ASO MoU and posted on the NRO website:
https://www.nro.net/documents/global-policy-development-process
IANA Number Registries: Refers collectively to the IPv4, IPv6, and ASN registries, as well as theassociated IN-ADDR.ARPA and IP6.ARPA DNS zones. The registries can be found here:
http://www.iana.org/numbers
IANA Numbering Services Operator: The party contractually engaged to perform the IANA Numbering
Services.
IANA Numbering Services: The IANA activities relevant to the Internet Number Community, which are
the allocation of blocks of Internet Number Resources (namely IPv4 addresses, IPv6 addresses, andAutonomous System Numbers or ASNs) to the Regional Internet Registries (RIRs); the registration ofsuch allocations in the corresponding IANA Internet Number Registries; other related registry
management tasks including the management of returned IP address space, and general registry
maintenance; and the administration of the special-purpose “IN-ADDR.ARPA” and “IP6.ARPA” DNS
zones, in accordance with IPv4 and IPv6 allocations, respectively.
ICANN Address Supporting Organization Memorandum of Understanding (ICANN ASO MoU): A
Memorandum of Understanding signed by ICANN and the NRO in 2004, under which the NRO shall fulfill
the role, responsibilities and functions of the ASO (including that the NRO NC shall carry out the functionsof the ASO AC).
Internet Number Community or RIR Community: Collaborative forum operating through decisionmaking processes that are bottom-up, inclusive and open to all parties interested in the IANA numbering
services as well as in the services of the five RIRs.
Internet Number Registry System: The system for administering Internet Number Resources, whereby
the IANA maintains the Number Registries from which the RIRs receive allocations to distribute to the
IANA Stewardship Transition Proposal Page 174 of 199

Part 2: Response from the Internet Number Community

community and the RIRs coordinate with the IANA to correctly register any resources that are returned to
the Number Registries. This system is described in detail in RFC 7020.
Internet Number Resources: IP addresses (IPv4, IPv6) and Autonomous System (AS) Numbers.
Number Resource Organization (NRO): A coordinating mechanism of the RIRs to act collectively on
matters relating to the interests of the RIRs, established by an MoU between the RIRs.
Number Resource Organization (NRO): The Number Resource Organization (NRO) is a coordinating
mechanism of the RIRs to act collectively on matters relating to the interests of the RIRs. It wasestablished in 2003 by a Memorandum of Understanding between the four RIRs in operation at that time(and signed by AFRINIC upon its establishment in 2005). https://nro.net/
Number Resource Organization Executive Council (NRO EC): A group of appointed representativesof each RIR, normally the CEOs.
Number Resource Organization Executive Council (NRO EC): Body that represents the NRO and its
suborganizations in all matters. Made up of one representative from each RIR, generally the CEO or
Director of the RIR. Chairmanship of the NRO EC rotates through each of the RIRs on an annual basis.
Number Resource Organization Memorandum of Understanding (NRO MoU): A Memorandum ofUnderstanding signed in 2003 by the four RIRs in operation at the time, and subsequently signed by
AFRINIC in 2005. The MoU established the Number Resource Organization and defines its activities andsub-organizations.
Number Resource Organization Number Council (NRO NC): A body made up of three community
members from each RIR community. It acts in an advisory capacity to the NRO Executive Council and toreview of any global policy proposal to confirm that the documented RIR PDPs and relevant procedures
were followed in its development and approval. In the ICANN structure, the members of the NRO NC
serve the functions of the Address Supporting Organization Address Council (ASO AC).
Policy Development Process (PDP): The process within each RIR by which the community makes
policies relating to the distribution and registration of Internet number resources within its service region.
While these PDPs differ in some specifics, the share common characteristics: all RIR PDPs are open to
all and follow an established, bottom-up process of collaboration; all RIR PDPs are transparent in theirworking methods, utilizing public mailing lists and open community forums; all RIR PDPs reachconclusions by community consensus; and the policies produced by an RIR PDP are made freely andpublicly available.
Regional Internet Registry (RIR): The not-for-profit membership-based organizations responsible for the
distribution and registration of Internet Number Resources in continent-sized geopolitical regions, as first
proposed by the IETF in RFC 1366. The RIRs are an important element in the Internet Number Registry
System as defined in RFC 7020. The RIRs were established in a bottom-up fashion and serve asecretariat role for their communities, facilitating the open, inclusive, bottom-up development of number
resource policy. There are currently five RIRs in operation, as described in Section 1.B. of this document.

IANA Stewardship Transition Proposal Page 175 of 199

Part 3: Response from the Protocol Parameters Registries Community

Part 3. Response from Protocol Parameters Registries
Community

IANA Stewardship Transition Proposal Page 176 of 199

Part 3: Response from the Protocol Parameters Registries Community

Draft Response to the IANA Stewardship Transition
Coordination Group Request for Proposals on the IANA
Protocol Parameters Registries
P3. Abstract ____________________________________________________________ 179
P3.1. IETF Introduction _____________________________________________________ 179
P3.2. The Formal RFP Response _____________________________________________ 180
Proposal type ___________________________________________________________________________________ 180

P3.I. The Community’s Use of the IANA ______________________________________ 180
P3.I.A.
P3.I.B.
P3.I.C.
P3.I.D.

The service or activity _________________________________________________________________________ 181
The customer of the service or activity ____________________________________________________________ 181
What Registries are involved in providing the service or activity ________________________________________ 181
Overlaps or interdependencies between your IANA requirements and the functions required by other customer
communities ________________________________________________________________________________ 182

P3.II. Existing Pre-Transition Arrangements ___________________________________ 183
P3.II.A.

Policy Sources_______________________________________________________________________________ 183

P3.II.A.1.
P3.II.A.2.
P3.II.A.3.
P3.II.A.4.
P3.II.B.

Affected IANA service or activity ___________________________________________________________ 183
How policy is developed and established and by whom _________________________________________ 183
How disputes about policy are resolved ______________________________________________________ 184
References to documentation of policy development and dispute resolution processes _________________ 184

Oversight and Accountability ____________________________________________________________________ 184

P3.II.B.1.
P3.II.B.2.
P3.II.B.3.
P3.II.B.4.
P3.II.B.5.

Which IANA service or activity is affected? ___________________________________________________ 185
If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in whatway. _________________________________________________________________________________ 185
The entity or entities that provide oversight or perform accountability functions _______________________ 185
Description of the mechanism _____________________________________________________________ 186
Jurisdiction and legal basis of the mechanism _________________________________________________ 186

P3.III. Proposed Post-Transition Oversight and Accountability ____________________ 187
P3.IV. Transition Implications ________________________________________________ 189
P3.V. NTIA Requirements ___________________________________________________ 190
P3.V.A.
P3.V.B.
P3.V.C.
P3.V.D.
P3.V.E.

P3.VI.

Support and enhance the multistakeholder model ___________________________________________________ 190
Maintain the security, stability, and resiliency of the Internet DNS _______________________________________ 190
Meet the needs and expectation of the global customers and partners of the IANA services __________________ 190
Maintain the openness of the Internet _____________________________________________________________ 191
Not a government-led or inter-governmental solution _________________________________________________ 191

Community Process __________________________________________ 191

P3.VI.A. Steps taken to develop consensus and the proposal _________________________________________________ 191
P3.VI.B. Links to announcements, agendas, mailing lists, consultations and meeting proceedings ____________________ 192
P3.VI.C. Level of consensus behind the community’s proposal ________________________________________________ 192

P3.3. IANA Considerations __________________________________________________ 193
P3.4. Security Considerations _______________________________________________ 193
P3.5. IAB Note 193
P3.6. Acknowlegments _____________________________________________________ 193
P3.7. References __________________________________________________________ 194
P3.7.1P3.7.2

Normative References ________________________________________________________________________ 194
Informative References ________________________________________________________________________ 195

P3. Appendix A. Changes ___________________________________________________ 197
P3. Appendix B. The Charter of the IANA Stewardship Coordination Group _________ 198
P3. Appendix C . IANA Stewardship Transition Coordination Group RFP ____________ 199

IANA Stewardship Transition Proposal Page 177 of 199

Part 3: Response from the Protocol Parameters Registries Community

IANA Stewardship Transition Proposal Page 178 of 199

Part 3: Response from the Protocol Parameters Registries Community

Draft Response to the IANA Stewardship Transition
Coordination Group Request for Proposals on the IANA
Protocol Parameters Registries
P3.

Abstract

3001

The U.S. NTIA has solicited a request from ICANN to propose how the NTIA should end its
oversight of the IANA functions. After broad consultations, ICANN has in turn created the
IANA Stewardship Transition Coordination Group. That group solicited proposals for thre
three major IANA functions: names, numbers, and protocol parameters. This document
contains the IETF response to that solicitation for protocol parameters. It is meant to be
included in an aggregate response to the NTIA alongside those for names and numberingresources that are being developed by their respective operational communities.

3002

Status of This Memo

3003

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP
79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).
Note that other groups may also distribute working documents as Internet-Drafts. The list of
current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft
documents valid for a maximum of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as "work in progress."

3004

This Internet-Draft will expire on July 10, 2015.

3005

Copyright Notice3006

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights
reserved.

3007

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of thisdocument. Please review these documents carefully, as they describe your rights andrestrictions with respect to this document. Code Components extracted from this document
must include Simplified BSD License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in the Simplified BSD License.

P3.1. IETF Introduction
3008

In March of 2014 the U.S. National Telecommunications & Information Administration (NTIA)
announced its intent to transition oversight of Internet Assigned Numbers Authority (IANA)
functions [NTIA-Announce]. In that announcement, NTIA asked the Internet Corporation for
Assigned Names and Numbers (ICANN) to establish a process to deliver a proposal fortransition. As part of that process, the IANA Stewardship Transition Coordination Group(ICG) was formed. The charter for the ICG can be found in Appendix B. The ICG in turn
IANA Stewardship Transition Proposal Page 179 of 199

Part 3: Response from the Protocol Parameters Registries Community

solicited proposals regarding post-transition arrangements from the names, numbers, andprotocol parameters communities in order to put forth a proposal to the NTIA. The final
request for proposal (RFP) can be found in Appendix C.
3009

While there are interactions between all of the IANA functions and IETF standards, thisdocument specifically addresses the protocol parameters registries function. Section 1 (thissection) contains an introduction that is sourced solely within the IETF. Section 2 contains
the questionnaire that was written by the ICG and a formal response by the IETF.87

3010

We note that the following text was stated as footnote in the original RFP:In this RFP, "IANA" refers to the functions currently specified in the agreement between NTIA andICANN [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well as any otherfunctions traditionally performed by the IANA functions operator. SAC-067[https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides one description of the manydifferent meanings of the term "IANA" and may be useful reading in addition to the documents
constituting the agreement itself.

P3.2. The Formal RFP Response3011

The entire Request for Proposals, including introduction, can be found in Appendix C.

3012

Proposal type3013

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

3014[X] Protocol Parameters

This response states the existing practice of the IETF, and also represents the views of theInternet Architecture Board and the IETF.

P3.I.
3015

[ ] Numbers

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 thefollowing:• A description of the service or activity.
• A description of the customer of the service or activity.
• What registries are involved in providing the service or activity.
• A description of any overlaps or interdependencies between your IANA requirements andthe functions required by other customer communities

87 This proposal has been reformatted.

IANA Stewardship Transition Proposal Page 180 of 199

Part 3: Response from the Protocol Parameters Registries Community

3016

P3.I.A.

The service or activity

IETF Response:
3017

Many IETF protocols make use of commonly defined protocol parameters. These
parameters are used by implementers, who are the primary users of the IETF standards andother documents. To ensure consistent interpretation of these parameter values by
independent implementations, and to promote universal interoperability, these IETF protocol
specifications define and require globally available registries containing the parametervalues and a pointer to any associated documentation. The IETF uses the IANA protocol
parameters registries to store this information in a public location. The IETF community
presently accesses the protocol parameter registries via references based on the iana.org
domain name, and makes use of the term "IANA" in the protocol parameter registry
processes [RFC5226].

3018

P3.I.B.

The customer of the service or activity

IETF Response:3019

The IANA protocol parameters registries operator maintains the protocol parameters
registries for the IETF in conformance with all relevant IETF policies, in accordance with theMemorandum of Understanding [RFC2860] and associated supplemental agreements that
include service level agreements (SLAs) established between the IETF and ICANN[MOUSUP].

3020

The IETF is a global organization that produces voluntary standards, whose mission is to
produce high quality, relevant technical and engineering documents that influence the way
people design, use, and manage the Internet in such a way as to make the Internet work
better [RFC3935]. IETF standards are published in the RFC series. The IETF is responsible
for the key standards that are used on the Internet today, including IP, TCP, DNS, BGP, andHTTP, to name but a few.

3021

The IETF operates in an open and transparent manner [RFC6852]. The processes thatgovern the IETF are also published in the RFC series. The Internet Standards Process is
documented in [RFC2026]. That document explains not only how standards are developed,
but also how disputes about decisions are resolved. RFC 2026 has been amended anumber of times [BCP9info]. The standards process can be amended in the same mannerthat standards are approved. That is, someone proposes a change by submitting atemporary document known as an Internet-Draft, the community discusses it, and if roughconsensus can be found the change is approved by the Internet Engineering Steering Group(IESG), who also have day-to-day responsibility for declaring IETF consensus on technicaldecisions, including those that affect the IANA protocol parameters registries. Anyone may
propose a change during a Last Call, and anyone may participate in the community
discussion.

3022

P3.I.C.

What Registries are involved in providing the service or activity

IETF Response:

IANA Stewardship Transition Proposal Page 181 of 199

Part 3: Response from the Protocol Parameters Registries Community

3023

The protocol parameters registries are the product of IETF work. These also include the toplevel registry for the entire IP address space and some of its sub-registries, autonomous
system number space, and a number of special use registries with regard to domain names.
For more detail please refer to the documentation in the "overlaps or interdependencies"
section.

3024

Administration of the protocol parameters registries is the service that is provided to the
IETF.

3025

P3.I.D. Overlaps or interdependencies between your IANA requirements andthe functions required by other customer communities
IETF Response:3026

In this context, the IETF considers "overlap" to be where there is in some way shared
responsibility for a single registry across multiple organizations. In this sense, there is nooverlap between organizations because responsibility for each registry is carefully
delineated. There are, however, points of interaction between other organizations, and a few
cases where the IETF may further define the scope of a registry for technical purposes. Thisis the case with both names and numbers, as described in the paragraphs below. In allcases, the IETF coordinates with the appropriate organizations.

3027

It is important to note that the IETF does not have formal membership. The term "the IETF"
includes anyone who wishes to participate in the IETF, and IETF participants may also be
members of other communities. Staff and participants from ICANN and the Regional Internet
Registries (RIRs) regularly participate in IETF activities.
o

The IETF has specified a number of special use registries with regard to domain names.
These registries require coordination with ICANN as the policy authority for the DNS
root, including community groups that are responsible for ICANN policy on domainnames such as the Generic Names Supporting Organization (GNSO) and the Country
Code Names Supporting Organization (ccNSO). There are already mechanisms in place
to perform this coordination, and the capacity to modify those mechanisms to meet new
conditions as they might arise. [RFC6761]o

The IETF specifies the DNS protocol. From time to time there have been and will be
updates to that protocol. As we make changes we will broadly consult the operational
community about the impact of those changes, as we have done in the past.

o

The IETF specifies minimum requirements for root servers. [RFC2870] Thoserequirements are currently under review, in consultations with the root server
community.

o

The routing architecture has evolved over time, and is expected to continue to do so.
Such evolution may have an impact on appropriate IP address allocation strategies. If
and when that happens, the IETF will consult and coordinate with the RIR community, as
we have done in the past.

o

The IETF is responsible for policy relating to the entire IP address space and AS number
space. Through the IANA protocol parameters registries, the IETF delegates unicast IP
address and AS number ranges to the RIRs [RFC7020], [RFC7249]. Special address
IANA Stewardship Transition Proposal Page 182 of 199

Part 3: Response from the Protocol Parameters Registries Community

allocation, such as multicast and anycast addresses, often require coordination. Anotherexample of IP addresses that are not administered by the RIR system is Unique Local
Addresses (ULAs) [RFC4193], where local networks employ a prefix that is not intended
to be routed on the public Internet. New special address of the standards. In all cases,
these special assignments are listed in the IANA protocol paramters registries.
o

The IETF maintains sub-registries for special IPv4 and IPv6 assignments. These are
specified in [RFC3307], [RFC5771], and [RFC6890]. The IETF coordinates suchassignments with the RIRs.

o

Changes to IETF standards may have impact on operations of RIRs and service
providers. A recent example is the extensions to BGP to carry the Autonomous System
numbers as four-octet entities [RFC6793]. It is important to note that this change
occurred out of operational necessity, and it demonstrated strong alignment between the
RIRs and the IETF.

P3.II.

Existing Pre-Transition Arrangements

3028

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

3029

P3.II.A.

3030

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:

Policy Sources• 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.

3031

P3.II.A.1. Affected IANA service or activity
IETF Response:3032

The protocol parameters registries.

3033

P3.II.A.2. How policy is developed and established and by whom
IETF Response:

IANA Stewardship Transition Proposal Page 183 of 199

Part 3: Response from the Protocol Parameters Registries Community

3034

Policy for overall management of the protocol parameters registries is stated in [RFC6220]
and [RFC5226]. The first of these documents explains the model for how the registries areto be operated, how policy is set, and how oversight takes place. RFC 5226 specifies thepolicies that specification writers may employ when they define new protocol registries in the"IANA Considerations" section of each specification. All policies at the IETF begin with aproposal in the form of an Internet-Draft. Anyone may submit such a proposal. If there issufficient interest, a working group whose scope includes the proposed work may choose to
adopt it, the IESG may choose to create a working group, or an Area Director may chooseto sponsor the draft. In any case, anyone may comment on the proposal as it progresses. A
proposal cannot be passed by the IESG unless it enjoys sufficient community support as toindicate rough consensus [RFC7282]. In each case, a "Last Call" is made so that there isnotice of any proposed change to a policy or process. Anyone may comment during a Last
Call. For example, this process is currently being used to update RFC 5226 [I-D.leibacotton-iana-5226bis].

3035

P3.II.A.3. How disputes about policy are resolved
IETF Response:

3036

Most disputes are handled at the lowest level through the working group and roughconsensus processes. Should anyone disagree with any action, Section 6.5 of [RFC2026]
specifies a multi-level conflict resolution and appeals process that includes the responsible
Area Director, the IESG, and the IAB. Should appeals be upheld, an appropriate remedy isapplied. In the case where someone claims that the procedures themselves are insufficient
or inadequate in some way to address a circumstance, one may appeal an IAB decision to
the Internet Society Board of Trustees.

3037

P3.II.A.4. References to documentation of policy development and dispute
resolution processes
IETF Response:3038

As mentioned above, [RFC2026] Section 6.5 specifies a conflict resolution and appeals
process. [RFC2418] specifies working group procedures. Note that both of these documents
have beenamended in later RFCs as indicated in the [RFC-INDEX].

3039

P3.II.B.

3040

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 iscurrently held accountable for the provision of those services. For each oversight or
accountability mechanism, please provide as many of the following as are applicable:

Oversight and Accountability• 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.
IANA Stewardship Transition Proposal Page 184 of 199

Part 3: Response from the Protocol Parameters Registries Community• A description of the entity or entities that provide oversight or perform accountability
functions, including how individuals are selected or removed from participation in thoseentities.
• 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 themechanism 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.

3041

P3.II.B.1. Which IANA service or activity is affected?
IETF Response:3042

The protocol parameters registries.

3043

P3.II.B.2. If the policy sources identified in Section II.A are affected, identify
which ones are affected and explain in what way.
IETF Response:3044

All policy sources relating to the protocol parameters registry are affected.

3045

P3.II.B.3. The entity or entities that provide oversight or perform accountability
functions

3046

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

3047

The Internet Architecture Board (IAB) is an oversight body of the IETF whose responsibilities
include, among other things, confirming appointment of IESG members, managing appeals
as discussed above, management of certain domains, including .ARPA [RFC3172], andgeneral architectural guidance to the broader community. The IAB must approve theappointment of an organization to act as IANA operator on behalf of the IETF. The IAB isalso responsible for establishing liaison relationships with other organizations on behalf of
the IETF. The IAB’s charter is to be found in [RFC2850].

3048

The IAB members are selected and may be recalled through a Nominating Committee(NOMCOM) process, which is described in [RFC3777] and its updates. This processprovides for selection of active members of the community who themselves agree upon aslate of candidates. The active members are chosen randomly from volunteers with a historyof participation in the IETF, with limits regarding having too many active members with thesame affiliation. The selection of the active members is performed in a manner that makes it
possible for anyone to verify that the correct procedure was followed. The slate of
IANA Stewardship Transition Proposal Page 185 of 199

Part 3: Response from the Protocol Parameters Registries Community

candidates selected by the active members are sent to the Internet Society Board ofTrustees for confirmation. In general, members are appointed for terms of two years. The
IAB selects its own chair.
3049

The IAB provides oversight of the protocol parameters registries of the IETF, and is
responsible for selecting appropriate operator(s) and related per-registry arrangements.
Especially when relationships among protocols call for it, registries are at times operated by,
or in conjunction with, other bodies. Unless the IAB or IETF has concluded that special
treatment is needed, the operator for registries is currently ICANN.

3050

P3.II.B.4. Description of the mechanism

3051(e.g., contract, reporting scheme, auditing scheme, etc.). This should include a descriptionof the consequences of the IANA functions operator not meeting the standards establishedby the mechanism, the extent to which the output of the mechanism is transparent and theterms under which the mechanism may change.
IETF Response:3052

A memorandum of understanding (MoU) between ICANN and the IETF community has beenin place since 2000. It can be found in [RFC2860]. The MoU defines the work to be carriedout by the IANA functions operator for the IETF and the Internet Research Task Force(IRTF), a peer organization to the IETF that focuses on research.[RFC2014] Each year aservice level agreement is negotiated that supplements the MoU.

3053

Day-to-day administration and contract management is the responsibility of the IETF
Administrative Director (IAD). The IETF Administrative Oversight Committee (IAOC)
oversees the IAD. The members of the IAOC are also the trustees of the IETF Trust, whose
main purpose is to hold certain intellectual property for the benefit of the IETF as a whole.
IAOC members are appointed by the Internet Society Board of Trustees, the IAB, the IESG,
and the NOMCOM [RFC4071]. The IAOC works with the IANA functions operator toestablish annual IANA performance metrics [METRICS] and operational procedures, andthe resulting document is adopted as an supplement to the MoU each year [MOUSUP].
Starting from 2014, in accordance with these supplements, an annual audit is performed toensure that protocol parameter requests are being processed according to the establishedpolicies. The conclusions of this audit will be available for anyone in the world to review.

3054

To date there have been no unresolvable disputes or issues between the IETF and thecurrent IANA functions operator. [RFC2860] specifies that should a technical dispute arise,"the IANA shall seek and follow technical guidance exclusively from the IESG." In theunlikely event that a more difficult situation should arise, the IAOC and the IAB would
engage ICANN management to address the matter. The MoU also provides an option for
either party to terminate the arrangement with six months notice. Obviously such action
would only be undertaken after serious consideration. In that case a new IANA functions
operator would be selected, and a new agreement with that operator would be established.

3055

P3.II.B.5. Jurisdiction and legal basis of the mechanism
IETF Response:

IANA Stewardship Transition Proposal Page 186 of 199

Part 3: Response from the Protocol Parameters Registries Community

3056

This mechanism is global in nature. The current agreement does not specify a jurisdiction.

P3.III.

Proposed Post-Transition Oversight andAccountability

3057

This section should describe what changes your community is proposing to thearrangements 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 newarrangements.

3058

If your community’s proposal carries any implications for the interface between the IANA
functions and existing policy arrangements described in Section II.A, those implications
should be described here.

3059

If your community is not proposing changes to arrangements listed in Section II.B, therationale and justification for that choice should be provided here.
IETF Response:3060

No new organizations or structures are required. Over the years since the creation of
ICANN, the IETF, ICANN, and IAB have together created a system of agreements, policies,
and oversight mechanisms that already cover what is needed. This system has worked wellwithout any operational involvement from the NTIA.

3061

IANA protocol parameters registry updates will continue to function day-to-day, as they havebeen doing for the last decade or more. The IETF community is very satisfied with thecurrent arrangement with ICANN. RFC 2860 remains in force and has served the IETF
community very well. RFC 6220 has laid out an appropriate service description andrequirements.

3062

However in the absence of the NTIA contract a few new arrangements may be needed inorder to ensure the IETF community’s expectations are met. Those expectations are thefollowing:o

The protocol parameters registries are in the public domain. It is the preference of the
IETF community that all relevant parties acknowledge that fact as part of the transition.

o

It is possible in the future that the operation of the protocol parameters registries may betransitioned from ICANN to subsequent operator(s). It is the preference of the IETF
community that, as part of the NTIA transition, ICANN acknowledge that it will carry out
the obligations established under C.7.3 and I.61 of the current IANA functions contract
between ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition tosubsequent operator(s), should the need arise. Furthermore, in the event of a transition
it is the expectation of the IETF community that ICANN, the IETF, and subsequent
operator(s) will work together to minimize disruption in the use the protocol parameters
registries or other resources currently located at iana.org.

IANA Stewardship Transition Proposal Page 187 of 199

Part 3: Response from the Protocol Parameters Registries Community

3063

In developing our response we have been mindful of the following points that the IETF
community has discussed over the last year [ProtoParamEvo14] that have led to thefollowing guiding principles for IAB efforts that impact IANA protocol parameter registries.
These principles must be taken together; their order is not significant.
1. The IETF protocol parameters registries function has been and continues to be capably
provided by the Internet technical community. The strength and stability of the function
and its foundation within the Internet technical community are both important given how
critical protocol parameters are to the proper functioning of IETF protocols. We think the
structures that sustain the protocol parameters registries function need to be strong
enough that they can be offered independently by the Internet technical community,
without the need for backing from external parties. And we believe we largely are there
already, although the system can be strengthened further, and continuous improvements
are being made.
2. The protocol parameters registries function requires openness, transparency, andaccountability.
Existing documentation of how the function is administered and overseen is good
[RFC2860], [RFC6220]. Further articulation and clarity may be beneficial. It is importantthat the whole Internet community can understand how the function works, and that theprocesses for registering parameters and holding those who oversee the protocol
parameters function accountable for following those processes are understood by allinterested parties. We are committed to making improvements here if necessary.
3. Any contemplated changes to the protocol parameters registries function should respect
existing Internet community agreements.
The protocol parameters registries function is working well. The existing Memorandum ofUnderstanding in RFC 2860 defines "the technical work to be carried out by the Internet
Assigned Numbers Authority on behalf of the Internet Engineering Task Force and theInternet Research Task Force." Any modifications to the protocol parameters registries
function should be made using the IETF process to update RFC 6220 and other relevant
RFCs. Put quite simply: evolution, not revolution.
4. The Internet architecture requires and receives capable service by Internet registries.
The stability of the Internet depends on capable provision of not just IETF protocol
parameters, but IP numbers, domain names, and other registries. Furthermore, DNS
and IPv4/IPv6 are IETF-defined protocols. Thus we expect the role of the IETF in
standards development, architectural guidance, and allocation of certain name/number
parameters to continue. IP multicast addresses and special-use DNS names are two
examples where close coordination is needed. The IETF will continue to coordinate withICANN, the RIRs, and other parties that are mutually invested in the continued smooth
operation of the Internet registries. We fully understand the need to work together.
5. The IETF will continue management of the protocol parameter registry function as anintegral component of the IETF standards process and the use of resulting protocols.

IANA Stewardship Transition Proposal Page 188 of 199

Part 3: Response from the Protocol Parameters Registries Community

RFC 6220 specifies the role and function of the protocol parameters registry, which is
critical to IETF standards processes and IETF protocols. The IAB, on behalf of the IETF,
has the responsibility to define and manage the relationship with the protocol registry
operator role. This responsibility includes the selection and management of the protocol
parameter registry operator, as well as management of the parameter registration
process and the guidelines for parameter allocation.
6. The protocol parameters registries are provided as a public service.
Directions for the creation of protocol parameters registries and the policies for
subsequent additions and updates are specified in RFCs. The protocol parameters
registries are available to everyone, and they are published in a form that allows theircontents to be included in other works without further permission. These works include,
but are not limited to, implementations of Internet protocols and their associateddocumentation.
These principles will guide the IAB, IAOC, and the rest of the IETF community as theywork with ICANN to establish future IANA performance metrics and operational
procedures.

P3.IV.
3064

Transition Implications

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, orother 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 establishedarrangements.

IETF Response:
3065

No structural changes are required for the handling of protocol parameters. The principles
listed above will guide IAB, IAOC, and the rest of the IETF community as they work withICANN to establish future IANA performance metrics and operational procedures, as they
have in the past.

3066

As no services are expected to change, no continuity issues are anticipated, and there are
no new technical or operational methods proposed by the IETF to test. The IETF leadership,
ICANN, and the RIRs maintain an ongoing informal dialog to spot any unforeseen issues
that might arise as a result of other changes.

IANA Stewardship Transition Proposal Page 189 of 199

Part 3: Response from the Protocol Parameters Registries Community

3067

What is necessary as part of transition is the completion of any supplemental agreement(s)necessary to achieve the requirements outlined in our response in Section III of this RFP.

P3.V.
3068

NTIA Requirements

Additionally, NTIA has established that the transition proposal must meet the following fiverequirements:•

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 intergovernmental organization solution.

3069

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

3070

This proposal addresses each of the NTIA’s requirements:

3071

P3.V.A.

Support and enhance the multistakeholder model

IETF Response:
3072

Because the IETF is open to everyone, participation is open to all stakeholders. IETF
processes outlined in Section I were used to develop this proposal. Those same processes
have been and shall be used to amend governance of the protocol parameters function. As
mentioned previously, anyone may propose amendments to those processes, and anyone
may take part in the decision process.

3073

P3.V.B.

Maintain the security, stability, and resiliency of the Internet DNSIETF Response:3074

No changes are proposed in this document that affect the security, stability, and resiliency of
the DNS.

3075

P3.V.C. Meet the needs and expectation of the global customers andpartners of the IANA services
IETF Response:

IANA Stewardship Transition Proposal Page 190 of 199

Part 3: Response from the Protocol Parameters Registries Community

3076

Implementers and their users from around the world make use of the IETF standards andthe associated IANA protocol parameters registries. The current IANA protocol parameters
registries system is meeting the needs of these global customers. This proposal continues
to meet their needs by maintaining the existing processes that have served them well in the
past.

3077

P3.V.D.

Maintain the openness of the Internet

IETF Response:
3078

This proposal maintains the existing open framework that allows anyone to participate in thedevelopment of IETF standards, including the IANA protocol parameters registries policies.
Further, an implementer anywhere in the world has full access to the protocol specification
published in the RFC series and the protocol parameters registries published at iana.org.
Those who require assignments in the IANA protocol registries will continue to have theirrequests satisfied, as specified by the existing policies for those registries.

3079

P3.V.E.

Not a government-led or inter-governmental solution

IETF Response:
3080

Policy oversight is performed by the IAB, which is neither a government-led or anintergovernmental organization.

P3.VI.
3081

3082

Community ProcessThis 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 adescription of areas of contention or disagreement.

P3.VI.A. Steps taken to develop consensus and the proposal
IETF Response:

3083

The IESG established the IANAPLAN working group to develop this response. Anyone waswelcome to join the discussion and participate in the development of this response. An open
mailing list (ianaplan@ietf.org) has been associated with the working group. In addition,
IETF’s IANA practices have been discussed in the broader community, and all input has
been welcome. Normal IETF procedures [RFC2026] [RFC2418] were used to determinerough consensus. The chairs of the working group reviewed open issues and, after aninternal working group last call, determined that all had been satisfactorily addressed, andIANA Stewardship Transition Proposal Page 191 of 199

Part 3: Response from the Protocol Parameters Registries Community

subsequently the IESG did a formal IETF-wide Last Call followed by a formal review anddetermined that the document had rough consensus.

3084

P3.VI.B. Links to announcements, agendas, mailing lists, consultations andmeeting proceedings
IETF Response:

3085

The following list is not exhaustive, as there have been many open discussions about thistransition within the IETF community in the past few months.

3086

Creation of an open mailing list to discuss the transition:
http://mailarchive.ietf.org/arch/msg/ietf-announce/Ztd2ed9U04qSxIk9-Oj80jJLXc

3087

Announcement of a public session on the transition:
http://mailarchive.ietf.org/arch/msg/ietf-announce/M5zVmFFvTbtgVyMB_fjUSW4rJ0c

3088

Announcement by the IESG of the intent to form a working group:
http://mailarchive.ietf.org/arch/msg/ietf-announce/QsvU9qX98G2KqB18jy6UfhwKjXk

3089

The working group discussion:
http://www.ietf.org/mailarchive/web/ianaplan/current/maillist.html

3090

2014-10-06 Interim Meeting Agenda, Minutes, and presentations:
http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/proceedings.html

3091

Working group last call:
http://mailarchive.ietf.org/arch/msg/ianaplan/EGF9rfJxn5QpQnRXmS2QxYKYR8k

3092

Agenda from IETF 91 IANAPLAN WG meeting:
http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan

3093

Minutes of IETF 91 IANAPLAN WG meeting:
http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan

3094

Shepherd write-up: http://datatracker.ietf.org/doc/draft-ietfianaplan-icgresponse/shepherdwriteup/

3095

IETF last call: http://mailarchive.ietf.org/arch/msg/ietfannounce/i5rx6PfjJCRax3Lu4qZ_38P8wBg

3096

P3.VI.C. Level of consensus behind the community’s proposal
IETF Response:

3097

This document has attained rough consensus of the IETF Working Group and of the IETF
community as a whole, as judged first by the working group chairs and then by the
IANA Stewardship Transition Proposal Page 192 of 199

Part 3: Response from the Protocol Parameters Registries Community

sponsoring Area Director, and then by the IESG in accordance with [RFC2026] during the
18 December 2014 IESG telechat. The IESG has approved the draft, pending insertion ofthis answer in this section and the IAB approval note. The IAB approved a statement forinclusion in the document on 19 December 2014.
3098

Over the course of the development of the document, several suggestions were raised that
did not enjoy sufficient support to be included. Two general areas of suggestion thatgenerated much discussion wereo

A suggestion for a stronger statement over what terms the IAOC should negotiate.

oA suggestion that "iana.org" and other associated marks be transferred to the IETF trust.

3099

At the end of the working group process, although there was not unanimous support for the
results, the working group chairs concluded that rough consensus existed in the working
group. The document shepherd’s summary of the WG consensus for this document can befound here:

3100

https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/shepherdwriteup/

3101

During IETF last call, additional people voiced support for the document. There were several
editorial comments that resulted in changes, as well as some discussion of more substantialcomments some of which resulted in text changes. There was some discussion ofcomments already discussed earlier in the process, and but no new objections were raised
during the IETF last call. A summary of the last call comments can be found from here:3102

http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html

3103

New draft versions were prepared that took into account all the agreed changes from thelast call. The final version was then approved by the IESG.

3104

P3.4.

3105

This memo is a response to a request for proposals. No parameter allocations or changes
are sought.

3106

P3.5.

3107

While the agreement, supplements, policies, and procedures around the IANA function haveshown strong resiliency, the IETF will continue to work with all relevant parties to facilitate
improvements while maintaining availability of the IANA registries.

3108

P3.6.

3109

The IAB supports the response in this document.

3110

P3.7.

IANA Considerations

Security Considerations

IAB Note

Acknowlegments

IANA Stewardship Transition Proposal Page 193 of 199

Part 3: Response from the Protocol Parameters Registries Community

3111

This document describes processes that have been developed by many members of thecommunity over many years. The initial version of this document was developed
collaboratively through both the IAB IANA

3112

Strategy Program and the IETF IANAPLAN WG. Particular thanks go to Jari Arkko, Marc
Blanchet, Brian Carpenter, Alissa Cooper, John Curran, Leslie Daigle, Heather Flanagan,
Christer Holmberg, John Klensin, Barry Leiba, Milton Mueller, Andrei Robachevsky, Andrew
Sullivan, Dave Thaler, Greg Wood, and Suzanne Woolf.

3113

P3.8.References

3114

P3.8.1

Normative References[BCP9info]"Information on "The Internet Standards Process -- Revision 3"", <http://www.rfceditor.org/info/rfc2026>.

[METRICS]"Performance Standards Metrics Report",<http://www.iana.org/performance/metrics>.

[MOUSUP]"Supplements to RFC 2860 (the Memorandum of Understanding between the IETF
and ICANN)",<http://iaoc.ietf.org/contracts.html>.

[NTIA-Announce]"NTIA Announcement of Intent to Transition Key Internet Domain Name Functions",
March 2014,<http://www.ntia.doc.gov/press-release/2014/ntiaannounces-intent-transition-keyinternet-domain-namefunctions>.

[NTIA-Contract]"The NTIA Contract with ICANN",<http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2final_award_and_sacs.pdf>.

[RFC2026]

Bradner, S., "The Internet Standards Process – Revision 3", BCP 9, RFC 2026,
October 1996.

[RFC2418]

Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418,
September 1998.

[RFC2850]

Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture
Board (IAB)", BCP 39, RFC 2850, May 2000.

[RFC2860]

Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding
Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC
2860, June 2000.

[RFC3307]

Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307,
August 2002.

[RFC3777]

Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
IANA Stewardship Transition Proposal Page 194 of 199

Part 3: Response from the Protocol Parameters Registries Community[RFC3935]

Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October
2004.

[RFC4071]

Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity(IASA)", BCP 101, RFC 4071, April 2005.

[RFC5226]

Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Sectionin RFCs", BCP 26, RFC 5226, May 2008.

[RFC5771]

Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address
Assignments", BCP 51, RFC 5771, March 2010.

[RFC6220]

McPherson, D., Kolkman, O., Klensin, J., Huston, G., and Internet Architecture
Board, "Defining the Role and Function of IETF Protocol Parameter Registry
Operators", RFC 6220, April 2011.

[RFC6761]

Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February
2013.

[RFC6890]

Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address
Registries", BCP 153, RFC 6890, April 2013.

[RFC7282]

Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, June 2014.

3115

P3.7.2

Informative References[I-D.leiba-cotton-iana-5226bis]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations
Section in RFCs", draftleiba-cotton-iana-5226bis-11 (work in progress), November
2014.
[ProtoParamEvo14]"IAB statement on Guiding the Evolution of the IANA Protocol Parameter Registries",
March 2014,<http://mailarchive.ietf.org/arch/msg/internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM
03k>.
[RFC-INDEX]

RFC Editor, , "Index of all Requests for Comments", RFC Index, August 2014.

[RFC2014]

Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP
8, RFC 2014, October 1996.

[RFC2870]

Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational
Requirements", BCP 40, RFC 2870, June 2000.

[RFC3172]

Huston, G., "Management Guidelines & Operational Requirements for the Address
and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, September
2001.

IANA Stewardship Transition Proposal Page 195 of 199

Part 3: Response from the Protocol Parameters Registries Community[RFC4193]

Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193,
October 2005.

[RFC6793]

Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS)
Number Space", RFC 6793, December 2012.

[RFC6852]

Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. Amour, "Affirmation of theModern Paradigm for Standards", RFC 6852, January 2013.

[RFC7020]

Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry
System", RFC 7020, August 2013.

[RFC7249]

Housley, R., "Internet Numbers Registries", RFC 7249, May 2014.

IANA Stewardship Transition Proposal Page 196 of 199

Part 3: Response from the Protocol Parameters Registries Community

P3. Appendix A.

Changes

NOTE: This section to be removed by RFC Editor at publication.
A.1.Changes from -08 to -09
o Update URL for summary of the IETF Last Call.
o Two minor editorial improvements.
A.2. Changes from -07 to -08
o Update text describing the consensus process.
o Insert IAB approval text.
o Point to the proceedings of IETF 91 for IANAPLAN WG agenda and minutes.
A.3. Changes from -06 to -07
o Merge "No new changes are needed" with "No new organizations or structures are required".
Fewer words to say the same thing.
o consult to consult and coordinate.
o RFC Editor comments.
o Edits resulting from Security Area review by Sean Turner.
o Edits resulting from AD comments.
A.4. Changes from -05 to -06
o Inclusion of agreed substantial comments from the AD.
o Editorial changes.
A.5. Changes from -04 to -05
o Change to simpler text for answer about stability and security.
o Mention of RFC 5226bis.
A.6. Changes from -03 to -04
o Additional text regarding what is needed in Section III.
o Appropriate language modifications in section IV to match the above changes in III.
o Acknowledgments edits.
A.7. Changes from -02 to -03
o Terminology consistency.
o Add IAB section.
o Changes based on WG discussion on what we prefer as part of the transition regarding IPR.
o Add discussion about .ARPA domain.
o Elaboration of what registries are involved.
o Additional text around coordination with ICANN.
o Working groups can adopt items within their charters.
o IAB appointments generally last two years.
o Add mention of the Trust.
o Security Considerations update.
A.8. Changes from -01 to -02
o A better description special registries and BGP ASNs.
o Clarity on how the address space and ASNs are delegated.
o Many editorials corrected.
o Mention of the annual review as part of the SLAs.
o Change about how overlap is presented.
o A number of small wording changes based on feedback.
A.9. Changes from -00 to -01
o Front matter greatly reduced.
o Appendices with charter and RFP added.
o Jurisdiction text changed.
o Proposed changes include supplemental agreement(s) to address jurisdiction, dispute resolution,and IPR, including names and marks.
o Transition implications slightly modified to reference supplemental agreement

IANA Stewardship Transition Proposal Page 197 of 199

Part 3: Response from the Protocol Parameters Registries Community

P3. Appendix B.

The Charter of the IANA Stewardship
Coordination Grouphttps://www.icann.org/en/system/files/files/charter-icg-27aug14-en.pdf

IANA Stewardship Transition Proposal Page 198 of 199

Part 3: Response from the Protocol Parameters Registries Community

P3. Appendix C

IANA Stewardship Transition
Coordination Group RFP

https://www.icann.org/en/system/files/files/rfp-iana-stewardship-08sep14-en.pdf

IANA Stewardship Transition Proposal Page 199 of 199