24 August, 2015

This page is also available in:
Français [PDF, 179 KB] | Español [PDF, 178 KB] | 中文 [PDF, 467 KB] | Pусский [PDF, 258 KB] | Português [PDF, 175 KB] | العربية [PDF, 254 KB]

This Frequently Asked Questions (FAQ) is intended as a guide only and is a living document. The previous versions are archived here.

  1. About the IANA Stewardship Transition Proposal

    1. Will the proposed transition affect end users in any perceptible manner?

      As the IANA functions operator’s responsibilities are pre-dominantly administrative, and the USG has traditionally had a very limited role in comparison to those of the Operational Communities’ (OC), it is not expected that end users will see any change as a result of this stewardship transition. The policy mechanisms employed in the three OC’s have been in existence for years/decades, and they continue to evolve in response to the needs of their communities. It is in these community policy and oversight mechanisms where the end user is most active.

    2. What does the overall oversight model of the combined proposal look like?

      There is no one overall oversight model. There are three oversight models of the substantive operational parts, reflecting today’s reality.

    1. Are the various oversight bodies in the Operational Communities – for Names: IFR and CSC, for Protocol Parameters: IAB, and for Numbers: RC, independently constituted from ICANN?

      Yes. While these bodies are different, they are each defined by their respective OC, and are responsible to/answer to those communities. It should be noted though that much of the Names community operates within ICANN and as such they may use ICANN processes to establish these oversight structures. More detail can be found in each OC’s proposal.

    2. Have the ICG identified any issues after the individual and collective proposals assessment?

      The ICG has identified a potential compatibility issue regarding the IANA trademarks and the iana.org domain name. The numbers community proposed that the trademarks and domain name be held by the IETF Trust. The protocol parameters proposal did not speak to this issue, but, in response to an ICG inquiry, indicated that it had no objection. The names proposal contained placeholder text in Annex S (in square brackets) that refers to the trademark but does not have consensus support of the CWG. Accordingly, the names proposal does not make a specific proposal with regard to the IANA trademarks (and it is completely silent as regards the domain name). Hence, the ICG considers the three proposals to be compatible, as long as the other two communities can accommodate the requirements specified by the numbers community as part of their implementation. The ICG requested that the operational communities continue to coordinate on this topic during the implementation phase to ensure that the requirements are met.

    3. What is the Post-Transition IANA (PTI)?

      In their proposal, the Names community proposed to form a new, separate legal entity (PTI) in the form of a non-profit corporation (i.e., a California public benefit corporation). They proposed that ICANN enter into a contract with PTI to serve as the IANA Functions Operator (IFO) for the naming functions. The entire IANA functions department staff currently housed in ICANN, and related resources, processes, data, and know-how will be legally transferred to PTI. The PTI will be an affiliate (subsidiary) of ICANN and ICANN will be responsible for its stewardship.

    4. Does this imply that the current US government role will be replaced by a single entity?

      No, it does not. Given the nature of the responsibilities that reside in the separate operational communities, the proposals reflect different subject matter and different desired outcomes. While they are naturally different in many respects, they all include a future ability to change their IANA functions operator (while establishing requirements to help ensure that any such future changes will not result in operational disruptions).

    5. What is the relationship between PTI and the existing IANA department within ICANN?

      PTI is expected to employ the same people and perform the same work using the same resources as the current IANA department within ICANN. The difference is that PTI will be a separate legal entity, while the current IANA department is legally part of ICANN.

    6. How will the three Operational Communities (OCs) interact with PTI?

      The Names community has proposed that ICANN (in its role as the policy coordinating body for the names community) will contract with PTI for operation of the IANA naming functions. The Number and Protocol Parameter communities have proposed to contract with ICANN for the operation of their IANA functions, and to allow ICANN to sub-contract to PTI.

    7. How will performance be evaluated?

      The 3 OCs based on their mandates, responsibilities and roles, and their desired relationship with PTI — whether a direct relationship (Names) or through contracts with ICANN (Number and Protocol Parameter communities) will be responsible for evaluating the performance of their respective IANA functions (through varying community managed monitoring mechanisms). The 3 OCs will also be responsible for ensuring that any deficiencies are brought back through their community approved mechanisms for remedial actions, as appropriate to maintain expected service levels. While today, the IFO for all 3 OCs is in one organization, the OCs have all made it clear in their proposals that the responsibility for who their IANA functions operator will be in the future will reside with the individual communities.

    8. How will the PTI be paid for?

      PTI and ICANN will have a contract, and the process for setting the funding level for PTI’s operations will be specified in this contract. This will make the costs associated with supporting IANA functions more open and explicit. ICANN will support these costs out of its budget, which is based on its collection of fees from contracted registries and registrars, and from some ccTLD registries and Regional Internet Registries that make contributions to ICANN.

    9. Concerns have been raised that the US Government’s role put too much control in the hands of one government. How does the transition of the IANA stewardship address that concern?

      The IANA transition completely eliminates the US Government’s role as the contracting authority over the IANA functions, as well as its approval authority over all DNS root zone changes. Thus, the US government no longer has any unique or special authority over this aspect of Internet governance.

    10. As the legal jurisdiction in which ICANN resides is to remain unchanged, and the PTI will also be incorporated in the US, does this mean there is effectively no change to the role of the US Government?

      No. As noted before, the US government no longer has root zone change approval authority or contracting authority over ICANN. While ICANN and PTI are still jurisdictionally based in California, their policies, bylaws and governance practices will be shaped by its board members, community accountability mechanisms, supporting organizations, and advisory committees. These entities are composed of people and organizations from all over the world.

      The IANA stewardship transition is the last piece in a long process transferring responsibility to multi-stakeholder communities. Oversight for the bulk of the IANA functions has practically and largely resided in the Operational Communities for many years. It is important to distinguish between the policy and oversight aspects of the IANA functions (which reside with the OCs) vs. questions of corporate performance which need to be addressed under the applicable corporate law. The OC’s are the appropriate venues for engagement, policy evolution, or issue resolution.

      It should further be recalled that the location of the companies has to do with where legal action can be brought in relation to their corporate operation and any related malfeasance or deviation from their chartered responsibilities. These topics are different than the functional elements which are administered through the OCs and where the USG had previously provided oversight through the role of NTIA. The CCWG on Accountability has some recommendations related to the broader discussion of Accountability and Jurisdiction and they can be found in Section 11.3 here: https://www.icann.org/en/system/files/files/ccwg-draft-2-proposal-work-stream-1-recs-03aug15-en.pdf.

  2. About the Transition Proposal and how to comment/participate

    1. Will the final combined proposal be posted for public comment?

      Yes. The final proposal is posted for public comment for 40 days prior to Dublin meeting (July 31 to September 8, 2015) and will be finalized at the Dublin meeting.

    2. Will the ICG edit the OC proposals in order to assemble the final proposal?

      No. The ICG intends to submit the 3 OC proposals as received. The combined proposal includes the three final community proposals as received by the ICG. The proposals are provided verbatim, without any changes by the ICG. The three proposals are summarized in an ICG report and an executive summary. However, the proposals themselves are authoritative and should be referenced for further details.

    3. Why wasn’t the proposal developed through a single global process instead of three separate processes?

      The proposal was developed through a single global process, with each of the Operational Communities responsible for determining the future of IANA’s stewardship for their operating needs.

    4. Is the CCWG timeline acceptable for ICG?

      So far the ICG timeline and the CCWG timeline are both aligned. Both public comment periods are running in parallel during the same intervals (July 31 – September 8, 2015). Expectation is that the ICG combined proposal and the CCWG accountability proposal will both be ready around the Dublin ICANN meeting.

    5. How is the community expected to comment on the combined proposal, before the CCWG work stream 1 proposal being finalized with the given interdependencies?

      The ICG is cognizant that the names community proposal is expressly conditioned on the implementation of ICANN-level accountability mechanisms proposed by work stream 1 of the CCWG. Those mechanisms are incorporated into a proposal the CCWG has released for public comment concurrently with the ICG’s call for public comment on this proposal. The ICG has committed to seeking confirmation from the names community that its accountability requirements have been met once the CCWG proposal is finalized. Members of the public providing comments on the transition proposal should therefore provide their comments under the assumption that the dependencies in the names portion of the proposal on the outcome of the CCWG’s work will be met by the CCWG.

  3. About the ICG

    1. What is the ICG?

      The ICG is the IANA Stewardship Transition Coordination Group.

      This group was established after the announcement by the U.S. Government Department of Commerce National Telecommunications and Information Administration (NTIA) of its intention to transfer the stewardship of the Internet Assigned Numbers Authority (IANA) Functions to the global multistakeholder community. NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to convene a global multistakeholder process to develop a transition plan.

      The Internet community took note of the guidance from the Internet Architecture Board (IAB) pointing out the division of IANA functions and customer communities into three categories related to domain names, number resources, and protocol parameters. The ICG was then formed in July 2014 to coordinate the development of a proposal amongst the communities affected by the IANA functions. The full role of the ICG is described in its charter [PDF, 45 KB].

    2. Who are members of the ICG?

      The ICG is comprised of 30 individuals representing 13 communities. Those communities include direct and indirect stakeholders. Direct stakeholders are those with direct operational or service relationships with the IANA functions operator; that is Internet names, numbers and protocol parameters. Indirect stakeholders are all the other interested and affected parties. ICG members were selected by their respective communities according to their own processes. ICG members are listed here.

    3. Is the ICG part of ICANN?

      No. The ICG is an independent coordination group that has been established as a result of a broad community consultation based on the guidance from the Internet Architecture Board (IAB). The ICG is conducting its work in an open, transparent and independent manner. The ICG is providing its report for public comment in order to ensure it has broad global community support. The ICG is supported by a neutral and independent secretariat. The role of the secretariat is strictly limited to the functions that support the ICG, and will report exclusively to the ICG, its Chair or Vice-Chair(s).

    4. What does the ICG do?

      The ICG’s mission is to coordinate the development of a proposal amongst the communities affected by the IANA functions. It has one deliverable which is a proposal to the U.S. Government NTIA regarding the transition of stewardship of the IANA functions to the global multistakeholder community. The coordination group has four main tasks:

      1. Act as liaison to all interested parties:
        1. Soliciting proposals from the operational communities
        2. Soliciting the input of the broad group of communities affected by the IANA functions
      2. Assess the outputs of the three operational communities for compatibility and interoperability
      3. Assemble a complete proposal for the transition
      4. Information sharing and public communication

      The ICG’s full charter is available here [PDF, 45 KB].

  4. About the IANA Functions

    1. What are the IANA functions?

      “IANA”, in this context, refers to the functions currently specified in the agreement between NTIA and ICANN “SA1301-12-RP-IANA” as well as any other functions traditionally performed by the IANA functions operator. More information about the activities of the IANA functions operator can be found in this presentation from ICANN 51. SAC-067 [PDF, 634 KB] and SAC-068 [PDF, 561 KB] also provide further information and may be useful reading in addition to the documents constituting the agreement itself. More information on IANA functions can be found in Wikipedia or in the IETF Request for Comments.

    2. Which aspects of IANA functions are to be covered in the stewardship transition?

      The only aspects of IANA functions subject to the transition arrangements are those of the administrator of registries containing Internet protocol parameters, Internet numbering resources, and the DNS root zone. Activities unrelated to the existing stewardship (for example, policy development processes) or unrelated to the aforementioned functions (for example, the administration of the Time Zone Database) are not the focus of the transition.

  5. About the process and how to participate

    1. How was the proposal developed?

      Based on the guidance from the Internet Architecture Board (IAB), pointing out the division of IANA functions and customer communities into three categories related to domain names, number resources, and protocol parameters, the ICG released a Request for Proposals (RFP) [PDF, 84 KB] for these communities interested in and/or affected by the transition of IANA stewardship. Each of the communities then used their own processes to develop a response to the RFP for transitioning its part of the IANA functions, and submitted their response to the ICG. The proposal contains the RFP responses from each of the three operational communities.

    2. Who are the ‘Operational Communities’?

      The ‘Operational Communities’ are communities with direct operational or service relationships with the IANA functions operator, in connection with internet names, numbers, or protocol parameters, namely the Generic Names Supporting Organization (GNSO), the Country Code Names Supporting Organisation (ccNSO), the Regional Internet Registries (RIRs), the Internet Architecture Board (IAB) and the Internet Engineering Task Force (IETF).

    3. Where can I find more information on the ‘Operational Communities’ processes for proposal development?

      Information about community processes and how to participate in them is available here, and will continue to be updated over time.

  6. About the decision making process for developing and submitting a unified proposal

    1. What are the criteria that need to be addressed in submitted proposals?

      Upon receipt of a formal transition proposal from any specific operational community, the ICG assessed each proposal individually to determine whether:

      • the community process used to develop each proposal was open and inclusive,
      • the proposal achieved consensus,
      • the proposal is complete and clear,
      • the proposal meets the NTIA criteria.

      The ICG then assessed the proposals collectively to determine whether the 3 proposals:

      • are compatible and interoperable, not suggesting any incompatible arrangements
      • work together without any gaps / overlaps when integrated
      • provide appropriate and properly supported accountability mechanisms
        collectively meet the NTIA criteria

      Issues identified within the proposals were discussed with the relevant community. Based on the community input, the ICG assembled the full proposal, put out for public comment on July 31st, 2015. The ICG will review comments and determine whether modifications are required. If changes are required, the ICG will work with the operational communities to address the required changes.

    2. How does the ICG make its decisions?

      Decisions over administrative matters may be approved on the basis of obvious agreement of all of those within the ICG expressing an opinion, or in cases where multiple different opinions have been expressed, may be reached by a majority vote. In all other decisions, the ICG aims to reach consensus recommendations or at least reach a recommendation that no ICG member opposes. If this is not possible, minority views opposing the recommendation will be documented and attributed in the report. It’s worth noting that decisions addressed here relate to the handling and assembling of submitted proposal(s) and not decisions related to approval/rejection of the content of the proposals. The ICG guidelines for decision making are here [PDF, 124 KB].

    3. How will ICANN Board handle the final proposal submitted by the ICG?

      The ICANN Board indicated that the final proposal will be forwarded within 14 days and without modification to the NTIA and that any accompanying comments will be on points already shared with the community.

    4. How will the community see the final proposal submitted by the ICG?

      When the ICG submits its final proposal to NTIA (via ICANN), it will be released to the general public and posted on the ICG website.

  7. About the timeline

    1. What is the timeline of the transition process?

      The ICG released an updated timeline graphic [PDF, 40 KB] on 6 July 2015. While this timeline is aggressive, every attempt has been made to be flexible and allow all communities to participate effectively. The goal is to submit the final proposal around the time of the ICANN 54 meeting in Dublin 18-22 October, 2015. The US government approval is expected to take 4-5 months. The ICG believes that at a minimum three to four additional months will be required to complete the implementation of the transition after the proposal is approved by the US government. This implies that at the earliest the transition could be completed in the July 2016 time frame. Here is a diagram illustrating the 3-phased timeline.

    2. Are there alternative scenarios if the submission target date (around ICANN Dublin meeting. 18-22 October, 2015) is not met?

      The ICG takes the task at hand very seriously and aims to meet the target date. This should not mean, in any way, compromising the quality or functionality of the submitted transition proposal or failing to meet any of the NTIA criteria. Yet, in the unlikely event of not meeting the target date, it’s up to the NTIA to decide on the next steps.

  8. Interaction with ICANN accountability process

    1. What is the relationship between the work of the ICG and the process concerning ICANN accountability?

      The ICG charter says that accountability is “central” to our process. The ICG has asked the operational communities to consider oversight and accountability in their proposals. The ICG notes that the names community proposal is expressly conditioned on the implementation of ICANN-level accountability mechanisms proposed by the CCWG. The ICG has designated two liaisons to the CCWG and has created a volunteer group to continue to flag issues that may impact the CWG proposal, ICG’s assessment process, and ultimately the final combined proposal. Once CCWG work Stream 1 concludes its work (estimated prior to the ICANN 54 meeting in Dublin 18-22 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 to whether it considers the names proposal to be complete.

  9. About ICG outreach activities

    1. How is the ICG reaching out to the community?

      A range of meetings were held over the past months. ICG members have scheduled several community discussions at ICANN 51-53 meetings in Los Angeles, Singapore and Buenos Aires. Community meetings were public, minuted, and, to the extent possible, transcribed and translated. The ICG has established a volunteer communications group to reach out to the community and keep them posted and involved throughout the rest of the process. Two webinars are scheduled for the week of August 3. Further details on the ICG communications strategy is available here.

    2. How is ICG reaching out beyond ICANN community?

      ICG members have participated in the IANA stewardship transition session held at the Internet Governance Forum in Istanbul, and the transition has been discussed in many regional and national forums. In addition, ICG members are reaching out to their own respective communities, to ensure an ongoing open two-way communication channel between the ICG and the wider community.

      Should you wish to invite members of the ICG to address your organisation or conference, please address your invitation to the secretariat at icg-meetingrequest@ianacg.org. Please note that while reasonable attempts will be made to accommodate requests, many of the members are volunteers and there are practical limits to the time available.

  10. About ICG resources, material and archives

    1. Where can I find more information on the transition process?

      More detailed information can be found on the ICG website.

    2. How can I follow the process development?

      The ICG operates under the principles of transparency and openness. The ICG mailing list is publicly archived, all ICG working documents are publicly available and accessible on Dropbox, recording, transcription and minutes of face-to-face meetings and conference calls are also publicly archived.

  11. Additional questions

    1. Can I submit a question?

      The ICG is always interested in receiving more questions so that we are sure to maximize the information made available to fulfill the needs and interests of the community. If you have a question that is not answered in this version of the FAQ, please send it to question-icg@ianacg.org. It should be noted that all communication with the ICG can be made public, including communication with the chair or vice-chairs.

    2. My question is not answered, what can I do?

      If you have a question that is still not answered, please send it to the following email address: question-icg@ianacg.org.