Skip to main content
Resources

ICANN Response to One World Trust Review of ICANN's Accountability and Transparency — Structures and Practices

  1. Transparency & access to Information
  2. Participation
  3. Monitoring, Evaluation and Learning
  4. Complaint and Response / Compliance Mechanisms
  5. Overarching Accountability issues
No. Background Recommendations Response
1 Transparency & access to Information
1.1 While ICANN is committed to transparency, the information (type and level of detail) made publicly available by its different bodies lacks consistency. For example, while Board minutes are publicly disseminated, only one of the Board’s eight subcommittees discloses minutes from its meetings via the ICANN website; this is also the case with meeting agendas. As a basic good practice principle for transparent decisions making, meeting agendas need to be made available to relevant stakeholders in advance of the meeting. In ICANN, this principle is currently only applied by the Board and the GNSO Council. ICANN should consider developing a formal Information Disclosure Policy that clearly states what, when and how information will be made available at different levels of the organisation An Information Disclosure Policy will be included in the draft Management Operating Principles document to be released for discussion at the San Juan meeting.
1.2 High levels of openness and transparency both at the Board level and among its Supporting Organisations and Advisory Committees is necessary. However, there are circumstances where information needs to remain confidential due to legal, contractual or security issues. This is acceptable (as full transparency can at times be detrimental to an organisation’s decision-making processes or activities) as long as narrowly defined criteria for nondisclosure are provided. ICANN should develop an Information Disclosure Policy that identifies a set of clear and narrowly defined conditions for nondisclosure that apply throughout the organisation. An Information Disclosure Policy will be included in the draft Management Operating Principles document to be released for discussion at the San Juan meeting.
1.3 To ensure compliance with any organisational policy, it is important that there is high level oversight and leadership. Without this, implementation will only ever be piecemeal. To ensure implementation of the information disclosure policy within ICANN, oversight responsibility should be assigned to a senior manager. An annual review should also be undertaken which identifies how ICANN is complying with the policy, where some of the gaps lie and how they will be addressed. A publicly named senior manager should be assigned ICANN should consider assigning responsibility for overseeing organisation-wide compliance with the Information Disclosure Policy to a publicly named senior manager; and making publicly available an annual review that documents compliance with the policy. The Vice President - Corporate Affairs will produce an annual review of compliance with the Information Disclosure Policy and publish the findings in the Annual Report.
1.4 ICANN discloses large amounts of information that, while reflecting the organisation’s openness, makes locating information difficult. Redesigning the website will make information more accessible; yet ICANN should also consider putting in place a function to support stakeholders in finding information. This could be similar to a ‘contact us’ function by enabling an individual to contact an ICANN staff member whose responsibility includes assisting stakeholders to locate information. ICANN should consider assisting stakeholders in locating online information through a function that enables them to contact a staff member with a specific document query. A "Need help locating a document" button will be placed on the website which will offer staged assistance with locating documents, beginning with existing search mechanisms and concluding with an email box.
1.5 On its website, ICANN has translated basic information about the organisation and its operations, and has done this in 10 languages (including English). Across other documents, however, there is less consistency. ICANN should identify the key documents that need to be accessible to a wide range of stakeholders to foster informed engagement in the policy development process, but also to enable stakeholders to exercise scrutiny over ICANN. ICANN should consider developing a translation policy that identifies which documents are translated and includes provisions on management and infrastructure issues for translation A Translation Policy will be included in the draft Management Operating Principles document to be released for discussion at the San Juan meeting.
1.6 Despite the openness of ICANN, there remains a lack of clarity among many in the ICANN community as to how and why the Board reaches certain decisions; specifically, how it weighs up the input of different stakeholders (Supporting Organisations, Advisory Committees and the public) and how it incorporates these into the decision-making process. The By-Laws already state that after taking action on policies that substantially affect the operation of the Internet or third parties the Board needs to "publish in the meeting minutes the reasons for any action taken, the vote of each director and the statements of directors requiring publication of such statement." The Board should take further steps in its reporting. For the most important decisions, specifically those that relate to policy considerations, the Board should consider producing a report (separate to the minutes) that explains how all stakeholder input was used in coming to a final decision. For decisions that have involved intense discussion in the community, the Board has historically provided a report and individual members have provided statements on why they have voted. Determining what decisions are ‘important’ requires further discussion. This will be done in the context of discussion about the draft Management Operating Principles. There is a need to summarise the inputs on issues and the impact they had on Board discussion. It may be that this amplification can be done in the context of the minutes although many have said a separate report is required.
1.7 Currently the main way through which the Board communicates future decisions is through the Board agendas; these are disclosed seven days in advance of the meeting (as stated in the By-Laws). While it is not practical to expect the Board to disclose the final agenda earlier than this, stakeholders need to have adequate warning of what issues are under consideration so as to prepare and provide meaningful input into Board decisions; for this to happen, the current period for agenda disclosure does not suffice. ICANN should consider providing stakeholders with advance warning of issues for consideration by the Board. ICANN should consider developing a web-based schedule of Board discussions that are planned over a twelve-week period where the agendas are updated in real time. A web based calendar will be developed, but a 12 week timeframe is not practical for the ICANN Board given the immediacy of many discussion items. The Board Secretary will examine any improvements that can be made to the timeframe.
1.8 The subcommittees play an important role in the governance of ICANN, having all the legal authority of the Board except for the authority to change the By-Laws, approve the budget and repeal a decision of the Board. It is imperative that they conform to the same standards of transparency as the rest of the organisation. The subcommittees of the ICANN Board should consider disclosing minutes of their meetings (this should be guided by the Information Disclosure Policy). This will be considered in the development of the Information Disclosure Policy and in the context of the Board Review.
1.9 It is currently difficult to follow the course of the policy development process (PDP) across each of the Supporting Organisations, because of how the information and documentation is structured on the website. The ccNSO, for example, places all the information related to a PDP under announcements (‘What’s New’ section of the website). Over time, this information gets lost within the other news items. Across Supporting Organisations, all documentation and information provided online that relates to policy development processes should be organised in a more accessible and consistent manner. The process page of the website now captures this information.
1.10 A result of the ICANN bottom up process is that each Supporting Organisation and Advisory Committee works according to its own procedures. While this is encouraging, it results in a lack of consistency in how information is presented across each of the respective websites. Not having information in similar places and formats reduces user accessibility. ICANN should consider developing a shared framework of presenting online information across its Supporting Organisations and Advisory Committees (e.g. rules of procedure, charter, minutes, agendas etc) to ensure user friendliness of web pages. Recommendation accepted. The process page of the website will be further developed to capture this information.

| back to top |

No. Background Recommendations Response
2 Participation
2.1 Public engagement is key to the legitimacy and relevance of ICANN decisions and policy. Supporting Organisations and Advisory Committees undertake consultations on policy, as does the Board. To foster consistency across the different Supporting Organisations in how consultations are conducted and to ensure their potential is maximised, ICANN should develop a set of guidelines for staff and volunteers on how to conduct online public consultations. Foster consistent engagement with the public across ICANN constituent bodies ICANN should consider developing a set of guidelines on how to conduct an effective and meaningful online public consultation and assign responsibility for oversight to a senior member of staff. A document providing guidelines for effective consultation will be included in the draft Management Operating Principles document to be released for discussion at the San Juan meeting. ICANN will commit to the adoption of the OECD guidelines public consultation.
2.2 To provide the Board of any organisation with the support they need to undertake their responsibilities and make informed decisions, it is good practice to have a secretariat. While a number of staff members within ICANN are assigned support roles to the Board, additional administrative support is required to facilitate more effective participation of Directors in the decision-making process. ICANN should consider establishing a small secretariat function to support the Board. This would facilitate communication from Staff to the Board, ensure documentation was disseminated in a timely manner and provide general administrative support to individual Board members. This recommendation is being implemented with the 2007-8 budget.
2.3 As ICANN grows and evolves and in parallel to ensuring fair representation of membership, the Board needs to take into account the qualifications of its members to ensure that they have the skills and the vision to respond to the organisation’s evolving needs. Given the role of the Nominating Committee in the selection of Board members, it is important that this body is aware of the skill needs of the Board when it nominates the eight of the 21 Directors. The ICANN Board should consider communicating its skill needs to the Nominating Committee. This process should be linked into an annual Board self-assessment (see recommendation 3.3). This does occur but the recommendation will be considered further as part of the Nominating Committee Review.
2.4 As well as selecting Board Directors, the Nominating Committee is also responsible for selecting members to the GNSO and ccNSO Councils and ALAC. Similar to the Board, these too need to ensure that they have the necessary skills on their governing bodies. In this respect, it is also important that the Nominating Committee is aware of the skill needs of the GNSO, ccNSO and ALAC when it selects members to these bodies. The GNSO Council, ccNSO Council and ALAC should consider communicating their skill needs to the Nominating Committee. This recommendation will be considered as part of the Nominating Committee Review.
2.5 The Nominating Committee forms for eight months of every year to nominate a total of 19 positions throughout the ICANN structure. The workload that comes with participation on this committee is considerable. A substantial amount of this work falls on the Chair. ICANN should consider providing additional administrative support to the Nominating Committee in the form of a small secretariat function. This recommendation will be considered as part of the Nominating Committee Review.
2.6 The role of the Nominating Committee Chair is complex as is the process of selecting a new one each year. Given the importance of this body, ICANN should consider extending the time that the Chair stays in their post from 1 year to 2 years to allow time for them to acclimatise to the position. ICANN should consider extending the time that the Nominating Committee Chair stays in their post from 1 year to 2 years. This recommendation will be considered as part of the Nominating Committee Review.
2.7 There is currently a lack of clarity around the roles and responsibility of Directors on the ICANN Board. This is manifesting itself at two levels. Firstly at the level of general duties that individual Directors need to fulfil as part of the wider Board membership; and secondly, the roles that Directors play in relation to the Supporting Organisations that elect them. Directors elected by Supporting Organisations should bring the needs and views of these constituencies to the attention of the Board without necessarily endorsing or voting in favour of that view. Although Directors are part of a collective governing body, they also have individual duties. They are expected to attend meeting regularly, contribute actively to deliberations and put the interests of ICANN above any other interests ICANN should consider ensuring more clarity around Board Directors’ duties, roles and responsibilities. One option would be to introduce a position description for Board members. This recommendation will be considered further as part of the Board Review to see if any further detail and information can be provided.
2.8 It is good practice among global organisations to enable those formally part of an organisation to hold Directors to account for gross negligence, misconduct, or dereliction of duty. ICANN’s By-Laws provide the Board of Directors with the authority to remove other Directors by a ¾ majority of all Directors. However, ICANN policies do not expand on how the process to remove a Director is initiated and who can initiate the process. ICANN should consider introducing a procedure to enable members of Supporting Organisations and Advisory Committees to initiate a process to dismiss Directors for negligence, misconduct, or dereliction of duty. Fiduciary and other responsibilities already apply to director misconduct and dereliction but this recommendation will be considered further as part of the Board Review.
2.9 GNSO needs to engage more with individual Internet users in public consultations. A non-voting liaison from ALAC that currently sits on the GNSO Council does provide a communication link between the two bodies, but this does not enable sufficient participation of individual users. To facilitate this process, more effective channels of communication need to be opened between the GNSO and ALAC. A more meaningful channel for ALAC to input into the policy process of the GNSO needs to be developed. The GNSO should consider ways of better integrating the views and perspectives of individual Internet users, through ALAC, into its policy activities. This recommendation will be considered as part of the work currently being undertaken by the GNSO Improvements Working Group.

| back to top |

No. Background Recommendations Response
3 Monitoring, Evaluation and Learning
3.1 ICANN produced its first Annual Report in 2006; while this represents an excellent first step and provides a level of detail that surpasses that of many international nongovernmental organisations, there are a number of ways in which it could be improved. It would benefit from more detail and the inclusion of information that would enable the reader to track progress year on year. Currently, the report identifies what activities ICANN has undertaken to achieve its goals; it makes no reference to challenges and how the organisation proposes to address them in the year ahead. ICANN already makes public the Operating Plan Status report. However, this is not accessible to the average Internet user. ICANN should consider engaging with the ICANN community to identify organisational goals and objectives that are perceived to be most important. ICANN should consider reporting on performance (including successes, setbacks and solutions) in the Annual Report. ICANN already identifies organisational goals and objectives through the Strategic Planning and the Operating Plan process. The next Annual Report will attempt to make a clearer link between goals and performance.
3.2 While as a small organisation ICANN could rely on more informal channels for disseminating lessons, as the organisation grows, it will become necessary for more formal mechanisms to be put in place to facilitate organisational learning across staff, volunteers, Supporting Organisations and Advisory Committees. ICANN should consider developing mechanisms to facilitate the dissemination of lessons learnt across Supporting Organisations, Advisory Committees, staff and volunteers. This recommendation will be examined further. Staff will work with Supporting Organizations and Advisory Committees to determine how this might be implemented.
3.3 Annual reviews of Board effectiveness are emerging as a key indicator of organisational performance across the public, private and non-profit sectors. It is considered good practice that the Board annually defines its duties, identifies performance in relation to the goals it set for itself, and suggests actions for better fulfilling them. Although the ICANN By-Laws already state that an independent review of the Board should take place, if feasible, at least once every three years, a Board self-assessment would be separate from this. Independent reviews provide an objective perspective on performance, while self-assessments are more focused on internal learning. The ICANN Board should consider undertaking an annual self-assessment, similar to that of the Nominating Committee. This would focus on decision making processes, skill needs on the Board, etc. This recommendation will be considered as part of the Board Review.
3.4 Creating the space at the end of a process to reflect on what worked well and what did not work so well can foster a culture of learning and strengthen organisational effectiveness. ICANN needs to be continually improving the policy development processes, as a key component of ICANN activities. Supporting Organisations should consider undertaking post-action reviews at the end of the policy development process. Staff will work with Supporting Organizations and Advisory Committees to determine how this might be implemented.
3.5 A number of Supporting Organisations and Advisory Committees, including ALAC, GNSO and GAC undertake self-evaluation of their activities (SSAC is in the process of conducting a self-evaluation for the first time). In all cases, this has been noted as a useful process that has led to learning and changes to operating practices. These however have not always been undertaken on a regular basis and the results have not always been publicly shared (ALAC is the exception to this). Given the role that self-assessments play in fostering learning and enabling increased effectiveness, such processes should become more formalised in ICANN. All ICANN Supporting Organisations and Advisory Committees should consider undertaking an annual self-assessment of their work and share key learning and ways forward. Staff will work with Supporting Organizations and Advisory Committees to determine how this might be implemented.
3.6 To assist Supporting Organisations and Advisory Committees in undertaking self-evaluations, to foster a degree of consistency in how the evaluations are undertaken and ensure that they meet accepted good practice principles, ICANN should produce a guiding document for staff and volunteers on how to undertake such exercises. Foster consistency in how self-assessments are undertaken and provide staff and volunteers with guidance on good practice principles for evaluations ICANN should consider developing evaluation guidelines and provide training to policy support officers. Staff will work with Supporting Organizations and Advisory Committees to determine how this might be implemented.

| back to top |

No. Background Recommendations Response
4 Complaint and Response / Compliance Mechanisms
4.1 The Ombudsman, Reconsideration Committee and the Independent Review Panel of Board actions, although independent of each other, function together to create a compliance system within ICANN. Each mechanism represents a step in a process of handling a complaint or grievance. As it stands, ICANN does not clearly describe the integrated nature of these mechanisms. Effort needs to be put into drawing the links between the three functions and communicating how they collectively make up the organisation’s complaints system ICANN should clearly describe the integrated nature of the Ombudsman, Reconsideration Committee and Independent Review Panel of Board actions. The links between the three functions and their integrated nature need to be properly communicated. The draft Management Operating Principles being developed for discussion in San Juan will include a section on dispute resolution processes that better explains the links between functions.
4.2 While ICANN has three mechanisms for investigating complaints from members of the ICANN community, the organisation does not have a policy or system in place that provides staff with channels through which they can raise complaints in confidentiality and without fear of retaliation. Having such a policy (often referred to as a whistleblower policy) is good practice among global organisations ICANN should consider developing a whistleblower policy that enables staff to raise concerns in a confidential manner and without fear of retaliation; and developing appropriate systems to foster compliance A whistleblower policy will be developed by General Counsel that outlines ICANN’s local obligations under law as well as a statement of principle to develop a uniform approach across ICANN offices.
4.3 Since the creation of the Ombudsman, the number of complaints handled through the formal complaint channel of the Reconsideration Committee has dropped. As the Ombudsman’s office continues to reach out to the community and raises awareness of the function within the ICANN community, there is the possibility that the number of complaints it has to handle will increase. The office’s user group is the entire Internet community, yet it is currently staffed by a single full time Ombudsman and an adjunct Ombudsman that provides holiday cover ICANN should consider recruiting full-time administrative support for the Ombudsman. ICANN will work with the Ombudsman’s office to determine the necessity for additional staffing given Budget considerations and the current review of administrative support being undertaken by the ICANN management.
4.4 To be effective as a mechanism that stakeholders can use to query Board decisions, it is important that the Reconsideration Committee is accessible to its users. Key to this is that stakeholders are aware of the mechanism and how to use it; and that they are not prevented from accessing it because of procedural barriers. There is currently no statement in the By-Laws or otherwise, stating that a request for reconsideration can be made in multiple languages. Likewise, the Reconsideration Committee needs to take more active steps in disseminating information on how the mechanism can be used. ICANN should consider making the Reconsideration Committee more accessible to all stakeholders. ICANN should consider developing systems to support the handling of requests for reconsideration in multiple languages and actively raising awareness of the mechanism and its use among the Internet community. This will be considered as part of a Translation Policy that will be included in the draft Management Operating Principles document for discussion at the San Juan meeting.
4.5 The ICANN By-Laws state that Board decisions on the recommendations of the Reconsideration Committee shall be made public as part of the preliminary report and minutes of the Board meeting at which action is taken. While this is good practice, the actions should also be reported online next to the documents on the Reconsideration Committee website that relate to the specific request for reconsideration. This would make it easier for the reader to follow the reconsideration process from start to finish (the initial request, the committee response, the recommendations and the board actions). This was something that ICANN seemed to do up until February 2000. Practice now however, is to state the date on which the Board took action, but not to provide a link to the appropriate minutes. The Reconsideration Committee should consider publicly disseminating the actions taken by the Board alongside the documentation relating to the specific request for reconsideration so that stakeholders are able to follow the process from start to finish. This will be implemented on publicly available information regarding consideration requests.
4.6 In the Ombudsman framework there is a specific commitment made by the Board to respond to Ombudsman recommendations within 60 days of the next Board meeting. There is no similar commitment made in relation to responding to Reconsideration Committee’s recommendations. The Board should consider making a commitment to responding to the recommendations of the Reconsideration Committee within a specific period of time. This recommendation will be considered further as part of the Board Review.
4.7 The By-Laws state that the Reconsideration Committee, upon deciding to take forward a reconsideration request will deliver its recommendations within 90 days. Of the eight requests for reconsideration (that have been made since the reconsideration policy was revised in Oct 2000 and the commitment to the 90 days was made), three have not been handled in the stated time. Based on the response rate of the Reconsideration Committee since 1999, of the 29 requests made only 13 recommendations were delivered within a 90 day period. This evidence suggests that the Reconsideration Committee has historically struggled to deliver their recommendations in the time period that it now commits to. ICANN should consider reviewing the capacity of the Reconsideration Committee to supply recommendations within 90 days of receiving a request for reconsideration with the purpose of either increasing the capacity of the Committee or increasing the stated response time. This recommendation will be considered as part of the Board Review.
4.8 When Board members who participated in the original decision are the only people reconsidering that decision possible issues arise related to the objectivity of the process. While having current Board members present for reconsideration does provide insight on the issue, there is a need for at least one non-executive individual to provide independent, objective thought. This role would essentially be one of facilitation where member would inject some impartiality into the Committee’s reconsiderations. ICANN should consider introducing an independent member onto the Reconsideration Committee to act as a facilitator. The individual would provide impartial and objective assessment to Committee members on reconsiderations. The purpose of the Reconsideration Committee is to review the processes that were followed to determine whether they were in accordance with the ICANN Bylaws. It is only one element in the suite of dispute resolution processes that are available. There are other separate, fully independent review processes if complainants feel that they need to pursue their claim beyond Reconsideration. These will be further examined in the process of the Board Review to see if further independence can be introduced across the different dispute mechanisms available.
4.9 The independent review of Board actions mechanism plays an important role in the accountability of ICANN. Although it has never been used to date, as the organisation evolves, ICANN needs to make sure it is well developed and meets the same high standards of the other parts of its complaints system. Currently, there is limited amount of information available on ICANN’s website on how it works. Other than what is in the By-Laws, there is no information on the ICANN website on how to initiate a complaint through this process and no information on how the complaint will be dealt with. ICANN should develop a separate page on their website that provides the rules of procedure for the Independent Review of Board actions, as mandated by the By-Laws, and which also provides an explanation of how to make a complaint through the Independent Review of Board actions function, and the steps that are involved in the review process. A page will be added to the website for this purpose.
4.10 The Independent Review states that the party that loses is liable to cover the costs of the Independent Review Panel, unless exceptional circumstances apply, then the winning party might be asked to cover half the costs. Understanding that this has been put in place to prevent frivolous complaints, there is the potential that the cost could pose a barrier to certain stakeholders using the mechanism. ICANN should consider strengthening the accessibility of the Independent Review Panel mechanism to the ICANN community. ICANN should consider removing the burden of making the losing party cover the costs of the Independent Review as a means of increasing the accessibility of the mechanism. This recommendation has multiple implications and will be explored in an issues paper that will be taken to the Board for consideration.
4.11 A major problem with the Independent Review mechanism is that it is not institutionalised; it only comes into being when a complaint is filed with the international arbitration provider. As a mechanism that plays an important role in overseeing the actions of the Board, it should have a more stable character and prominent role within ICANN. ICANN attempted to craft a more institutionalised and stable Independent Review Panel between 2000 and 2002. They should look at this option again, as good practice for external complaints mechanisms, suggests there are a number of areas where they might want to approach the issue differently (e.g. less stringent criteria for membership to the panel). ICANN should consider creating a more institutionalised and stable Independent Review Panel. This recommendation has multiple implications and will be explored in an issues paper that will be taken to the Board for consideration.

| back to top |

No. Background Recommendations Response
5 Overarching Accountability issues
5.1 Our review revealed that while ICANN has the policies and procedures in place to foster transparency and accountability, these are not always consistently followed. While the Ombudsman, Reconsideration Committee and the Independent Review of Board actions provide complaints based approaches to compliance, to generate greater trust among stakeholder, ICANN needs to take a more proactive approach. To address this issue, ICANN should consider a regular independent audit of their compliance with accountability and transparency commitments. Alternatively, it could develop a permanent compliance function to emphasize prevention by identifying shortcomings as they emerge and before they become systemic problems. ICANN should consider having an independent report produced, perhaps annually, that would measure the organisation’s compliance with transparency and accountability commitments made in its By-Laws. Recommendation accepted. This will be undertaken for inclusion in the next Annual Report.
5.2 In ICANN there is a mixture of volunteers and staff conducting the work; many people are working remotely. This creates challenges associated with ensuring all parties share the same values and beliefs about what kinds of goals the organization should pursue, how they should interact with the outside world and the appropriate kinds or standards of behaviour that should be used to achieve these goals. ICANN should consider developing a code of conduct for all staff and volunteers that identifies the goals of the organisation, the appropriate kinds or standards of behaviour that should be used to achieve these goals and how they should interact with the outside world. Discussion will occur in the context of the consultation on the draft management operating principles as to the appropriateness of such a code and what it might contain. This will be commenced at the San Juan meeting.
5.3 Within the ICANN community there is ambiguity around what it is that ICANN does (and should do). This has considerable impact on issues of accountability, as it ultimately relates to what people perceive the organisation as being accountable for. ICANN needs to communicate more effectively to the outside world what its core activities are. Standard language will be developed to more effectively communicate ICANN’s core activities. This is an ongoing task due to the technical nature of ICANN’s mission and the extent of the material already available.

| back to top |

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