Skip to main content
Resources

ICANN org Service Level Targets and Guidelines for Response to Community Requests Implementation of Work Stream 2, Recommendation 7.2.2-7.3.3

What are WS2 Recommendations 7.2.2-7.3.3?

  • Recommendation 7.2.2 asks ICANN org to standardize and publish guidelines for appropriate timeframes for acknowledging requests made by the community, and for responding with a resolution or updated timeframe for when a full response can be delivered.
  • Recommendation 7.3-7.3.3 asks ICANN org to develop and publish service level targets and guidelines that define the services provided by ICANN org to the community. This includes developing clear and reasonable guidelines for expected behavior between the ICANN organization and the community for those newly identified activities.

Researching and analyzing ICANN org services suggested that in most cases, internal procedures already exist. In addition, much work related to improving ICANN org service level targets and guidelines for response to community requests has been underway since the publication of WS2 recommendations. However, the community might not be aware of this information about service level targets and timeframes for response to community requests, as this information is located in different places on ICANN.org and is often difficult to find. The purpose of this page is to help provide clarity around the ICANN org service level targets and timeframes for response to community requests described below.

Facilitation of Response to Advice Issued to the Board

ICANN org provides a service to the community and Board by facilitating the Board Advice process in drafting statements of understanding. The process is as follows; after ALAC, RSSAC, or SSAC submits advice to the ICANN Board, ICANN org acknowledges receipt to the Advisory Committee. After receipt and acknowledgment, ICANN org, on behalf of the ICANN Board, reviews the advice and seeks to ensure a fulsome understanding. The understanding is usually reflected through drafting a short summary of the perceived actionable item for the ICANN Board and/or organization. This draft statement of understanding is then sent to the respective Advisory Committee or its proxy for review. The Advisory Committee or its proxy then has the opportunity to provide confirmation that it agrees with the draft understanding or provide feedback as necessary.

The service level target between receipt of Board Advice and communicating the statement of understanding to the Advice Provider (following the process described above) is 14 calendar days. The timeframe for the steps that follow in the Board Advice process (evaluation, consideration, and implementation) are variable because they are dependent on the unique topics, complexities and actions that are related to each instance of Board Advice.

As part of the Process Documentation Initiative in 2017, a workflow document and handbook were created to provide more transparency into the Board Advice Process.

Response to Complaints Directed to the ICANN org Complaints Office

The Complaints Office is a function within the ICANN org that provides a service to facilitate community complaints. The Complaints Office:

  • Provides a centralized location to submit complaints related to the ICANN org.
  • Receives complaints, researches them, collects facts, reviews, analyzes, and resolves issues as openly as possible.
  • Helps the ICANN org build on its effectiveness, and contributes to increased transparency from the org.
  • Aggregates the data from complaints to identify and solve for operational trends that should be improved.

Once a complaint has been submitted, the Complaints Office sends a response within 1-3 business days to acknowledge receipt of the complaint, advise that the Complaints Office needs time to perform an initial assessment, and set expectations for its first follow-up, which is typically within 14 calendar days. The first follow-up then provides guidance and an estimation of time needed to respond to the complaint. The estimated time for responding to Complaints Office submissions varies as the actions taken by the Complaints Office vary based on the unique nature of each complaint received (length, topics, complexity, number of ICANN org functions involved, etc.).

For more information about the Complaints Office please click here.

Response to Correspondence Directed to ICANN Board or ICANN org

The correspondence process was created to support ICANN org's commitment to operate in an open and transparent manner in regard to written communications to the ICANN Board and ICANN org. The correspondence process provides a standard and consistent manner in which to accept, process, and respond to letters received from external sources and track outgoing letters. As part of its commitment to transparency, ICANN org publishes applicable written communication to the public correspondence page (https://www.icann.org/resources/pages/correspondence).

ICANN org acknowledges correspondence no later than two business days after it has been received by the correspondence team. The correspondence team aims to respond to correspondence within 30 calendar days, recognizing that some topics are complex, and may require further coordination between ICANN org and Board which may lead to a longer time to respond. Note that some correspondence directed to ICANN Board and ICANN org do not require a response beyond an acknowledgement.

As part of the Process Documentation Initiative in 2017, a workflow document and handbook were created to provide more transparency into the Correspondence Process.

Response to Requests under the Documentary Information Disclosure Policy (DIDP)

ICANN org's Documentary Information Disclosure Policy (DIDP) is intended to ensure that information contained in documents concerning ICANN org's operational activities, and within ICANN org's possession, custody, or control, is made available to the public unless there is a compelling reason for confidentiality.

If a member of the public requests information not already publicly available, ICANN org will respond, to the extent feasible, to reasonable requests within 30 calendar days of receipt of the request. If that timeframe cannot be met, ICANN org will inform the requester in writing as to when a response will be provided, setting forth the reasons necessary for the extension of time to respond. If ICANN org denies the information request, it will provide a written statement to the requestor identifying the reasons for the denial.

For more information about ICANN org's DIDP, please click here.

Response to inquiries directed to ICANN org Global Support

ICANN's Global Support Centers provide global, 5x24 support to contracted parties, new gTLD applicants, and the Internet community at large. Some examples include:

  • Registrants that have issues with a domain name are often given information about the domain name lifecycle, ICANN org policies, who their registrar is, etc. (The Global Support role in these instances is educational).
  • Contracted parties can ask for assistance with a number of services including contact updates, contact information for their account manager, escalations, etc.

When one of ICANN org's Global Support Centers receives a query, a confirmation email is sent to the enquirer within one business day. Global Support aims to provide an answer within seven days. If an answer is not available, it provides requestors an update every seven days. Calls to ICANN org's Global Support Center are typically from registrants and resolved in real time.

For more information about ICANN org's Global Support Centers, please click here.

Timely tracking and aggregation of Public Comment

Public Comment is a key means of gathering community input on policy and other proposals, draft reports, recommendations, etc. The Public Comment proceeding section on icann.org has undergone several enhancements to make it easier for the ICANN community members to track timing of the various proceedings as well as capture submissions from the community. ICANN org has a service level target to publish a staff report of public comments within two weeks after the Public Comment proceeding closes.

For more information about ICANN Public Comment, please click here.

Requests from community-led review teams

ICANN org provides a service to the community-led review teams (during the conduct of Specific Reviews) by tracking and coordinating responses to requests for information to facilitate the review team's work. This service supports the Bylaws mandated obligation to conduct Specific Reviews as set out in Article 4, Section 4.6 of the Bylaws.

In response to WS2 Recommendations 7.2.2 - 7.3.3, ICANN org recognized the need to establish clear timeframes for tracking and coordinating responses to requests for information to support community-led Specific Reviews. ICANN org will acknowledge requests from the review team within two business days and respond within 10 business days with fulfillment of the community requestor updated timeframe for when the request will be fulfilled. This will be updated in the next revision of the ICANN Operating Standards for Specific Reviews.

For more information about ICANN Specific Review Operating Standards, please click here.

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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