Skip to main content

ようこそ!Yokoso! Welcome to Kobe for ICANN64!

If this is your first time attending an ICANN Public Meeting, let me start with a couple of insider tips:

  • Please bookmark the ICANN64 Meetings page and download the Meetings app. These tools will help you navigate some 300 sessions taking place over the week.
  • Join us for Newcomers Day to get acclimated.
  • If you are interested in technical topics, you can also join our popular “How it Works” sessions taking place throughout 10 March to learn more.

ICANN64 is a Community Forum, and the six-day meeting will focus on outreach, capacity building, and showcasing ICANN’s work to a broader global audience. The last time we held an ICANN meeting in Japan was in Yokohama in 2000. Fast forward 19 years, and a lot has changed at ICANN. I will list three key milestones from our recent past and how they relate to the upcoming discussions in Kobe:

June 2011 – The ICANN Board approved the launch of the New Generic Top-Level Domain (gTLD) Program, enabling the largest expansion of the Domain Name System (DNS).

We are now much more familiar about the availability of an additional 1200 top-level domains in English and other scripts. However, a lot more work is required to make domain names in local scripts (also known as Internationalized Domain Names) an everyday tool. This is especially important to the Asia Pacific (APAC) community, as we believe many of the next billion Internet users will come from our region, and many do not speak English.

You will see discussions about promoting a multilingual Internet take place here in Kobe. Watch out for sessions related to Internationalized Domain Names (IDNs) and Universal Acceptance (UA) such as the Cross-Community Session on Universal Acceptance/IDNs.

August 2013 – The ICANN Asia Pacific Regional Office (formerly known as ICANN APAC Hub) was established.

Prior to the establishment of our Regional Office, our community was known to be under-represented in ICANN. Working more closely with stakeholders in the region has been a priority, and we are proud to report that our community now has a presence in each of ICANN’s Supporting Organizations (SOs) and Advisory Committees (ACs). More APAC community members have also taken up leadership positions in the SOs, ACs, and policy working groups.

Our office has also trained over 3,000 community members to strengthen their DNS operations and to adopt DNS Security Extensions (DNSSEC). DNSSEC and DNS Security will also be discussed in Kobe. We want to thank the participating community members for contributing to ICANN’s mission to ensure the stable and secure operation of the Internet’s unique identifier system.

October 2016 – The IANA Functions Stewardship Transition was completed.

The IANA Stewardship Transition marked a historic moment when the coordination and management of the Internet’s unique identifiers was transitioned to the global community.

Amidst the many changes over the years, one of the things that remained unchanged is the principle of the multistakeholder model which governs ICANN. The ICANN64 Kobe meeting is hosted by a Local Host Committee comprised of 18 organizations including domain name registries and registrars, companies, and associations from the local technology industry, and supported by the Ministry of Internal Affairs and Communications. This is a remarkable showcase of Japan’s longstanding support of the multistakeholder model that governs ICANN.

Looking Ahead

The multistakeholder model and ICANN will need to continue to evolve with the global landscape. Help us set ICANN’s future direction as your input is needed on ICANN’s 2021-2025 Strategic Plan. There will also be a dialogue on the evolution of ICANN’s multistakeholder model of governance. These critical discussions are not one-offs, and I hope that the ICANN64 Kobe meeting will be a starting point for your longer-term participation.

I look forward to your contributions in shaping the future of the Internet’s unique identifier system.

Comments

    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 label