Skip to main content

Welcome to the new ICANN.org! Learn more, and send us your feedback. Dismiss

Resources

Transition of NTIA's Stewardship of the IANA Functions

Process to Develop the Proposal and Next Steps

Overview

On 14 March 2014 the National Telecommunications and Information Administration (NTIA) announced its intent to transition 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), as the IANA functions contractor and global coordinator for the Domain Name System (DNS), to convene a multistakeholder process to develop a proposal for the transition. While looking to stakeholders and those most directly served by the IANA functions to work through the technical details, NTIA established a clear framework to guide the discussion and communicated to ICANN that the transition 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 expectation of the global customers and partners of the IANA services; and,
  • Maintain the openness of the Internet.

NTIA will not accept a proposal that replaces the NTIA role with a government-led or an inter-governmental organization solution.

Shortly after the NTIA announcement, ICANN launched a multistakeholder process and discussion to gather community views and input on the principles and mechanisms for the transition process.1 Based on initial community feedback, a Call for Public Input on the Draft Proposal of the Principles, Mechanisms and Process to Develop a Proposal to Transition NTIA's Stewardship of the IANA Functions was posted on 8 April, open to comments until 8 May 2014. Also posted was the scoping document [PDF, 456 KB], defining the scope of the process.

The wide range of comments received in response to the draft proposal consistently reinforced the importance of a process that is transparent, inclusive, representative, bottom-up and multistakeholder.

This document sets out the next steps and provides an overview of community input, including:

  • An overview of community input on the composition of the Coordination Group (formerly the proposed "Steering Group");
  • A call to the respective community members represented in the Coordination Group to launch their internal processes to select their representatives;
  • An overview of community input on topics related to the Coordination Group's work, for consideration and use, as appropriate.

It is important to note that during discussions around the transition of NTIA's stewardship of the IANA functions the community also raised the broader topic of the impact of the transition on ICANN accountability. While the community develops a proposal for the transition of NTIA's stewardship role, it is important that the community also address the separate issue of ICANN's accountability. As a result, ICANN has launched a separate process to look at enhancing ICANN's accountability in the absence of its historical contractual relationship to the U.S Government and the perceived backstop with regard to ICANN's organization-wide accountability provided by that role. These processes are interdependent (refer to the timeline graphic for an illustration of the relationship between the two processes). The process on Enhancing ICANN Accountability was posted on 6 May 2014.

ACTION: Call for Names and Creation of Coordination Group

  • Communities represented in the Coordination Group are urged to launch their internal processes to select their representatives, per the number of seats allocated.
  • Names of selectees should be provided no later than 23:59 UTC on 2 July 2014 through a submission form and will be made publicly available online.
  • Communities are encouraged to make their final selections by the end of the ICANN 50 meeting in London (22-26 June 2014).
  • The Coordination Group will meet in mid-July, tentatively on 16-18 July, to finalize its modes of operation, working methods and begin its work.
  • To ensure full transparency, the Coordination Group will hold open meetings accessible to all global stakeholders; relevant transcripts and recordings will be posted on the website.

Overview of Request for Input and Next Steps

As convener of the multistakeholder process to develop a proposal to transition NTIA's stewardship of the IANA functions, ICANN sought public input and dialogue on the community-suggested Draft Proposal of the Principles, Mechanisms and Process to Develop a Proposal to Transition NTIA's Stewardship of the IANA Functions from 8 April – 8 May 2014.

The draft proposal outlined a set of principles and mechanisms, a proposed process, including questions for further input, and a timeline of events. Also posted was the scoping document [PDF, 456 KB], defining the scope of the process.

The multitude of comments received reflects a broad range of views, consistent with the diversity of the global multistakeholder community.2 In addition to the written comments, community dialogues also contributed to increased understanding of the IANA functions, the DNS and protocol registries.

Comments received focused on the composition of the Coordination Group, and the revised composition of the Coordination group, together with comments addressing that ICANN, as convener and facilitator of the process, should have a neutral role, are incorporated as outlined below.

The overview of comments regarding the roles and responsibilities of the Coordination Group is intended to serve as input for the Coordination Group and its work moving forward, consistent with the scope [PDF, 456 KB]. That is, this document does not prescribe the roles and responsibilities for the Coordination Group. The Coordination Group may use the input at its discretion as it works toward defining its modes of operation and working methods. Comments regarding scope or ICANN accountability are not reflected here. The scoping document outlines the focus of this process.

The immediate next step in the process involves a call for names for the Coordination Group. Communities represented in the Coordination Group are urged to launch their internal processes to select their representatives by the end of the ICANN 50 meeting in London. The submission deadline is 23:59 UTC on 2 July 2014. Selected candidates should be prepared to meet in mid-July 2014, tentatively on 16-18 July, to begin developing modes of operation and working methods. ICANN will make available the requisite facilities and resources (see Travel Support for more info).

The Coordination Group will be responsible for preparing a transition proposal respective of the differing needs of the various affected parties of the IANA functions. It should be responsible for assembling the components from the respective communities into a single proposal meeting the criteria set out by NTIA. Namely, it 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 expectation of the global customers and partners of the IANA services; and,
  • Maintain the openness of the Internet.

NTIA will not accept a proposal that replaces the NTIA role with a government-led or an inter-governmental organization solution.

Once a proposal is developed, ICANN will review the proposal to ensure it is in compliance with the defined framework and criteria and determine: 1) adherence to the NTIA principles and 2) conformity with the principles outlined by the community input. The responsibility for consideration and acceptance (as appropriate) of the proposal is solely vested in NTIA. ICANN's assessment of whether or not the process met the above mentioned requirements will be communicated with the proposal.

Selection and Composition of the Coordination Group

A comparison table tracking changes between the original and the revised selection and composition can be found in Annex I.

Renaming the "Steering Group" to "Coordination Group"

To address a range of comments expressing concern that "steering" does not appropriately characterize the group's function, the proposed "Steering Group" is renamed the Coordination Group.3

Changes to the Proposed Selection Mechanisms and Composition of the Coordination Group

The selection methods and the composition of the Coordination Group received much community input. The majority of comments point to perceived inconsistencies in the different approaches vis-à-vis selection of members from affected and non-affected parties, calling for more direct representation. There was broad consensus support4 for selection of members by all communities.

To address these concerns and ensure greater balance, the changes reflect a revised selection mechanism that:

  • Eliminates the distinction between affected and non-affected parties;5
  • Assigns the respective communities the responsibility to identify their Coordination Group representatives using internal processes;6
  • No longer has a role for the Chair of the ICANN Board and Chair of the GAC to select group members;7
  • Strongly urges communities to adhere to diversity standards as they carry out their respective selection processes.8

With regards to representation on the Coordination Group, there were a range of comments9 seeking a composition that represents the customers of the IANA functions as well as the broader user community and stakeholders from the technical, governmental, civil society and business communities. Comments note that broadening the consultation to include parties that extend beyond the ICANN and technical communities will ensure maximum global support.

The revised composition:

  • Reaches beyond the ICANN community to include IANA customers and partner Internet organizations10;
  • Includes representation from the country code Top Level Domain (ccTLD)11 and Top-Level Domain (TLD) 12 registries;
  • Reflects comments calling for an increase in the number of GNSO representatives13;
  • Addresses comments14 regarding the overrepresentation from the IP numbering community, and adjusts it to achieve balance between the Address Supporting Organization (ASO) and the Number Resource Organization (NRO);
  • Includes broader cross-section of business representation beyond those involved in ICANN;15
  • Provides for a resource regarding IANA functions through a liaison seat allocated for a dedicated IANA staff expert;
  • Retains user community representation beyond ICANN.

Composition of the Coordination Group

The Coordination Group will be comprised of 27 individual members who will be selected through their respective communities and processes. Care is urged to ensure diligent observance to diversity standards and to guard against any conflict of interest.

The Coordination Group composition (see graphic):

Coordination Group Composition

Community Represented

Seats

At-Large Advisory Committee (ALAC)

2

Address Supporting Organization (ASO)

1

Country Code Names Supporting Organisation (ccNSO and non-ccNSO Country Code Top-Level Domain [ccTLD] operators, as selected by the ccNSO)

4

Generic Names Supporting Organization (GNSO). GNSO seats from non-Registry representation

3

Generic Top Level Domain Registries (gTLD Registries)

2

Governmental Advisory Committee (GAC)

2

International Chamber of Commerce/ Business Action to Support the Information Society (ICC/BASIS)

1

Internet Architecture Board (IAB)

2

Internet Engineering Task Force (IETF)

2

Internet Society (ISOC)

2

Number Resource Organization (NRO)

2

Root Server System Advisory Committee (RSSAC)

2

Security and Stability Advisory Committee (SSAC)

2

Total

27

There will be two liaisons to the Coordination Group:

  • One ICANN Board liaison for ICANN's convening role;
  • One dedicated IANA staff expert to provide information as needed.

In addition to the above, input also referenced:

Support Services

The Coordination Group may be supported by a small independent Secretariat (funded by ICANN and selected through an open process) that provides administrative and logistical support, and captures and synthesizes community submissions.

Engagement and Outreach

Engagement and outreach is taking place globally and in partnership among respective organizations. The [PDF, 2.07 MB]timeline of events is an example of the range of events and should be deemed as a non-exhaustive list. The Coordination Group and respective organizations should strive to ensure full outreach16 and engagement as they develop their engagement strategy.

Budget

Comments called for the establishment of a budget that is publicly available17 and accessible to ensure full transparency.

Travel Support

Coordination Group members will not be remunerated. However, travel, meal and lodging costs for Coordination Group members to participate in Coordination Group meetings will be covered by ICANN, upon request and in accordance with ICANN's community travel support guidelines.

Supported travelers must book their air travel with ICANN's authorized travel agent, where the cost will be billed directly to ICANN. Hotel rooms and tax for a specified meeting will be arranged and paid for directly by ICANN in accordance with the authorized arrival and departure dates for each supported traveler. ICANN will only book and pay for a non-refundable, lowest logical price airfare, and economy airfare. Reimbursement will be permitted for meeting attendance and other reasonable incidental expenses incurred.

For questions, or to make the necessary travel arrangements, please contact cgtravel@icann.org.

Overview of Comments received on Principles and Mechanisms, and responsibilities of the Coordination Group.

In addition to the above, there was a wide range of comments received on the principles and mechanisms, and responsibilities of the Coordination Group. These are provided below as input for the Coordination Group. A comparison table that tracks key changes between the original and the revised process can be found in Annex I.

Principles and Mechanisms

There was general agreement that the draft principles and mechanisms18 embody the appropriate characteristics to ensure an open, inclusive, transparent and accountable process that is carried out in a bottom-up fashion.19 The principle of diversity20 was added to the list in response to several comments that it would lend further legitimacy to the process. This is in line with the global scope of the transition and the values of the multistakeholder model. No new mechanisms were added.

Principles

Mechanisms

  • Inclusive
  • Transparent
  • Global
  • Accountable
  • Multistakeholder
  • Focused in scope
  • Pragmatic and evidence-based
  • Open to all voices
  • Do no harm (maintain security, stability, and resiliency)
  • Consensus-based
  • Diversity
  • Web-based platform
  • Working methods
  • Organized dialogues
  • Existing information and processes
  • Stress tests
  • Clear and visible timeline
  • Discussion in other fora
  • Widely accessible engagement platforms
  • Multilingual support
  • Multiple comment fora

Independent Secretariat

Several comments underlined the importance of having an independent,21non-ICANN staff secretariat to support the Coordination Group. The independent Secretariat (funded by ICANN) will include administrative and other support, as needed and appropriate. As convener, ICANN is committed to remaining impartial in facilitating the process.

Community-suggested Roles and Responsibilities of the Coordination Group

As noted above, no action was taken to address comments related to the roles and responsibilities of the group. Below is a non-exhaustive list22 of community suggestions for consideration and use at the Coordination Group's discretion:

  • Establish the process for development of the community-driven proposal by building on process principles and mechanisms;23
  • Encourage and facilitate broad and diverse working groups appropriately structured within and across communities to ensure discussion and understanding of the critical issues involved in this transition;24
  • Reflect to the rest of the Coordination Group the members' own community and the consensus within it;25
  • Coordinate which community to develop a transition proposal for each area of overlap (e.g. each special-use registry) while ensuring that those areas receive cross-community review;26
  • Affirm complete proposal within respective communities;27
  • Provide regular status updates about the progress of the respective communities of the IANA customers in developing a transition proposal component; 28
  • Adopt a consensus-driven modes of operation and document dissenting views;29
  • Conduct outreach and engagement;30
  • Ensure no conflict of interests and appropriate Coordination Group accountability.31

In relation to the questions posed to the community, this overview may also be useful.

Q1. Are these the correct principles to guide the process to develop a proposal to transition the stewardship of the IANA functions to the global multistakeholder community? If not, why not and what additional principles should be considered?

The comments received were supportive32 of the proposed principles, but suggested an additional principle and focus on diversity33. Subsequent to the comments, the principle of diversity was added to the list of guiding principles for the process.

Q2. Are these the correct mechanisms to use in the process to develop a proposal to transition the stewardship of the IANA functions to the global multistakeholder community? If not, why not and what additional mechanisms should be considered?

The comments received were generally supportive of the proposed mechanisms34.

Q3. Are there other factors ICANN as the convener of process should take into account relevant to principles and mechanisms to be used to develop a proposal to transition the stewardship of the IANA functions to the global multistakeholder community? If so, please describe:

Input was received for ICANN to maintain a neutral role35.

Q4. Is this the creation of a steering group to steward the process to develop a proposal to transition the stewardship of the IANA functions to the global multistakeholder community the right approach? If not, why not and what other approach should be used in its place?

The comments supported the idea, but called for a change in terminology and composition36. Subsequent to the comments received, the following changes were made:

  • The term "Steering Group" was changed to "Coordination Group" to more accurately reflect the desired role and purpose of the group37;
  • The categorical distinction between affected parties was removed since there was no consensus supporting such a distinction38;
  • The composition of the group was modified as outlined above.
  • The representative selection process was redesigned to allow for selection by community members, as comments called for community-driven selection processes39. Diversity standards were reinforced to reflect comments received regarding diversity40.

Q5. Are the steps outlined above to create and operate a steering group to steward the process to develop a proposal to transition the stewardship of the IANA functions to the global multistakeholder community the right approach? If not, why not and what steps are missing?

The comments received identified the need for a consensus-driven mode of operation, but called for documentation of dissenting views.41

Q6. Are there other factors ICANN as the convener of process should take into account relevant to the creation of a steering group to steward the process to develop a proposal to transition the stewardship of the IANA functions to the global multistakeholder community the right approach? If so, please describe.

The comments received called for an independent, non-ICANN Secretariat42. Subsequent to the comments received, the proposal reinforces an ICANN-funded independent Secretariat as outlined above.

Timeline

Transition Timeline

Coordination Group Composition

Annex I

Category

Original Suggested Text

Revised Text
(Includes community input for Coordination Group)

Terminology

Steering Group

Coordination Group

Principles & Mechanisms

  • Inclusive
  • Transparent
  • Global
  • Accountable
  • Multistakeholder
  • Focused in scope
  • Pragmatic and evidence-based
  • Open [to all voices]
  • Do no harm
  • Consensus-based
  • "Diversity" added to list of principles.
  • Do no harm was further defined to include "(maintain security, stability, and resiliency)."

Composition

  1. Distinction between SO/AC & affected parties.
  1. No distinction
  1. 22 seats and 1 liaison
  1. 27 seats, 1 liaison, 1 expert
  1. 2 ALAC
  1. 2 ALAC
  1. 2 GAC
  1. 2 GAC
  1. 2 RSSAC
  1. 2 RSSAC
  1. 2 SSAC
  1. 2 SSAC
  1. 2 GNSO
  1. 3 GNSO from non-Registry representation
  1. 2 ASO
  1. 1 ASO
  1. 2 IETF
  1. 2 IETF
  1. 2 IAB
  1. 2 IAB
  1. 2 NRO
  1. 2 NRO
  1. 2 ISOC
  1. 2 ISOC
  1. 2 ccNSO
  1. 4 ccNSO and non-ccNSO ccTLD operators
  1. N/A
  1. 2 gTLD Registries
  1. N/A
  1. 1 ICC/BASIS
  1. 1 ICANN Board Liaison
  1. 1 ICANN Board Liaison
  1. N/A
  1. 1 dedicated IANA staff expert to provide info, as needed.

Selection

Chair of the ICANN Board and Chair of the GAC select "non-affected parties' group members.

Communities select their own representatives.

Modes of operation

Consensus-driven.

Consensus-driven and document dissenting views.

Support

ICANN Secretariat.

The Coordination Group may be supported by an independent Secretariat (funded by ICANN and selected through an open process) that provides administrative and logistical support, and captures and synthesizes community submissions. It may also provide other services pending the requests of the Coordination Group.

Calendar

  1. Process-associated timeline events.
  2. Coordination Group formed by ICANN 50.
  1. Participative calendar (ability for community to add to the selection of events).
  2. Names of selectees should be provided no later than 23:59 UTC on 2 July 2014. Coordination Group will meet in mid-July, tentatively on 16-18 July, to finalize its modes of operation, working methods and begin its work.

Role

The role of the steering group is to coordinate and to ensure that the process proceeds appropriately. The relevant affected parties will lead their community processes to determine any necessary mechanism as appropriate. However, the steering group has to coordinate such results so that they fit the overall proposed mechanism.

The steering group would also establish the process for development of the community-driven proposal.

To be determined by the Coordination Group. Community feedback on this topic is provided as input.


1 At the ICANN 49 Meeting in Singapore during the 24 March session, ICANN launched a multistakeholder process to gather the community's views and contributions to address how the mechanisms for the transition of NTIA's stewardship functions should occur. In addition to public sessions held at the ICANN meeting, public comments were received online, and using the opportunity of the NETmundial meeting, a session was held on the process.

2 The full list of comments can be found in the publicly available archives of the ianatransition@icann.org mailing list, the mechanism established to collect community input.

3 Contributors during the call for input expressed the need for the terminology to be more neutral. For example, BC stated: "ICANN's management proposal to form a "Steering Committee' sends the wrong signal about ICANN's role as convener. For ICANN to maintain objectivity and credibility as a convener in this process, it must maintain a more neutral role. A more fitting title would be "Convening Committee' or "Coordinating Committee." The IAB noted that ….the group be re-named to "coordination group' or something similar, since "steering' does not appropriately characterize its functions."

4 Contributions highlighted the importance of a selection made through the community. For instance, NCSG stated: "the coordination group should be community led and appointed without approval from the ICANN Board or GAC Chairs". Also see e.g., comments for the need to remedy the inconsistency from auDA, RySG and CENTR.

5 It was expressed in multiple contributions that communities ought to be represented in affected parties. For instance, RySG noted: "we feel this list is incomplete as it does not include direct customers of the IANA functions, such as gTLD, nTLD and ccTLD registries, which is incomprehensible and appears to be self-serving of the convener".

6 A need for Coordinating Group Members to be selected through their communities using their internal process was expressed during the call for input. LACTLD stated: "We support a process whereby each of the respective affected communities that are the customers of IANA functions (i.e. protocols, names and numbers) discuss and select internally their own mechanisms and processes of representation to integrate the "steering committee".

7 The majority of contributions received objected to a selection made by the Chair of the Board and Chair of the GAC. For instance, CENTR stated, "it would not be appropriate for ICANN or the GAC to be a gatekeeper in the selection of the steering group".

8 A call for diversity was channeled through a number of comments, thus establishing it as a key selection requirement. For instance, CNNIC noted: "we would like to reemphasize the importance of "diversity" principle. Especially, we are concerning about the diversity of the steering group members in terms of geography and development level of their origin."

9 As articulated in the USCIB comment: "both the decision-making and consultation/commenting processes should include those who are not members of ICANN but will be affected by the transition". See also comments from: JPNIC, SIIA, USCIB and U.S. Chamber of Commerce.

10 Ibid., endnote 5.

11 See e.g., comments in support of ccNSO and ccTLD registries representation on the Coordination Group submitted by CENTR, CIRA, and APTLD. For instance, CIRA stated: "As direct customers of IANA, ccTLD operators must take a full and direct role in the overall transition coordination and management process on at least an equal footing as other stakeholders in the numbering and addressing community."

12 See e.g., comments seeking gTLD representation from ARI, DNA, and InternetNZ. ARI noted: "The composition also does not provide adequate representation from gTLD registry operators, who were also called out in the NTIA announcement as affected parties."

13 As articulated by Google, "… limiting the Generic Names Supporting Organization (GNSO) to only two representatives is not adequate and representation from the GNSO should be increased. The GNSO Council is currently comprised of 23 representatives, which stem from different stakeholder groups within ICANN – from business interests, to registries and registrars, as well as non-commercial stakeholders. To ensure a more equitable representation of these important viewpoints within the IANA discussion, we would recommend increasing this allotment to four …".

14 See e.g., comments calling for streamlined representation from the addressing community IPC, David Conrad. David Conrad noted: "The description of the creation of the steering group implies the addressing community gets 4 representatives (2 from the ASO and 2 from the NRO, which according to the ASO MoU, clause 1 are the same thing)".

15 See e.g., comments asking for large business representation from JPNIC, SIIA, and U.S. Chamber of Commerce. U.S. Chamber of Commerce notably stated: "In order to be truly inclusive, we recommend the Steering Committee expressly include representation from the business community."

16 See e.g., comments from the Persian IGF and the USCIB, with the former noting: "… support engagement with interested organizations and initiatives that are active in the field of Internet governance in under represented regions in a collaborative and participatory manner."

17 See e.g., comment from David Conrad, asking to make the "budget (and its components) public."

18 Draft principles and mechanisms assembled based on feedback received at ICANN49 in Singapore (23-27 March 2014) and informed by successful community-developed processes and mechanisms, including the review processes set out in the Affirmation of Commitments (AoC)

19 Draft principles and mechanisms are considered to be appropriate by numerous contributors. SIIA, auDA, Polish Ministry of Administration and Digitization, India, INTA, notably called for emphasis on specific principles and/or mechanisms.

20 Ibid., endnote 8.

21 In line with ICANN's commitment to its convener and neutral role, the secretariat will be independent of ICANN staff, as requested by contributors and notably by InternetNZ: "Staffing resources should be independent of ICANN and procured by the Steering Group, financed by ICANN."

22 Refer to comments related to the roles and responsibilities of the Coordination Group from: ARI, IAB, Avri Doria and CENTR (non exhaustive list).

23 IAB recommends an approach, which "allows the communities of interest to leverage their existing community-driven, consensus-based processes from the very outset of the transition discussion".

24 Avri Doria noted: "One of the things that is missing from ICANN process is the establishment of broad and diverse working groups to really discuss and understand some of the critical issues involved in this transition. This is an item that needs concentrated community discussion".

25 This suggestion was made by the IAB: "The role of a coordination group member during the development of the transition proposal should be limited to … reflecting to the rest of the coordination group the consensus within the member's own community".

26 This suggestion was made by the IAB: "The role of a coordination group member during the development of the transition proposal should be limited to … coordinating which community will develop a transition proposal for each area of overlap (e.g., each special-use registry) while ensuring that those areas receive cross-community review …

27 This suggestion was made by the IAB: ""The first step will be complete when the reports from the coordination group members from each of the three communities come back with an answer of, "Yes, there is consensus within my community in support of the complete proposal."

28 IAB suggested that "the coordination group should also publish progress reports on a regular basis, so that interested parties might follow along". This suggestion is notably echoed by SIIA, LACTLD and APTLD.

29 There is general support for a consensus-based approach and calls for a documented process to reflect any dissenting views, as notably requested by IAB: "In order to prevent capture … the group should operate by rough consensus and publicly document outlying views if full consensus cannot be achieved".

30 Contributions reveal a general agreement that significant outreach and engagement initiatives are needed throughout the process.

31 Contributors highlight the need for the process to channel voices of the global stakeholder community. For instance, ISOC notes: "Given the complexity of the issues and the diversity of opinions, it is critical to devise a process that is easily adjustable and capable of addressing the voices and needs of all different stakeholders".

32 For instance, the Polish Ministry of Administration and Digitization stated: "we endorse the principles of the process".

33 Ibid., endnote 8.

34 For instance, NRO expressed: "The NRO supports the guiding principles and mechanisms as proposed …. We agree that these are consistent both with established norms for such processes within our communities, and with the large majority of inputs received so far from the ICANN community".

35 Contributors highlight the need for ICANN to remain neutral. For instance, BC stated: "For ICANN to maintain objectivity and credibility as a convener in this process, it must maintain a neutral role."

36 Ibid., endnote 5.

37 Ibid., endnote 3.

38 Ibid., endnote 5.

39 Ibid.. endnote 4.

40 Ibid., endnote 8.

41 There is general support for a consensus-based approach and calls for a documented process to reflect any dissenting views, as notably requested by IAB: "In order to prevent capture … the group should operate by rough consensus and publicly document outlying views if full consensus cannot be achieved".

42 Ibid., endnote 22.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."