Skip to main content

Remote Participation Technologies Enable a Policy Win for Nairobi

During the run-up to ICANN’s Nairobi meeting, some corners of the community raised concerns. Many community members could not make it to Nairobi for a variety of reasons, and some interest groups, such as the Registries, were going to be under-represented as physical participants. Some folks predicted that overall low attendance would slow progress in certain areas because policy work would not be able to advance.

What actually happened? Score a big win for the ICANN community and remote participants. Several policy issues moved forward at the meeting. For example:

  • The GNSO Council approved a charter for the Vertical Integration Working Group, which can now pursue the PDP launched in January. (As of this writing, 65 participants have signed up and are already engaged in substantive discussions.)
  • The Registration Abuse Policies (RAP) Working Group conducted a successful information session on their Initial Report. The group’s Chair led the session remotely, and the ensuing discussion blended questions and comments from both local and remote participants.
  • The ccNSO and members of the ccTLD community engaged fully in discussing the idea of an ICANN DNS-CERT (Computer Emergency Response Team). The substantive discussion considered how the existing ccNSO Incident Response Working Group would interact with (or incorporate into its mandate) the DNS-CERT initiative.
  • At-Large held 11 formal and 4 informal Working Group meetings, with solid representation from all 5 Regional At-Large Organizations (RALOs). They moved efficiently through several issues, which included submitting their list of endorsed candidates to the Affirmation of Commitments Review Team and endorsing the members of the At-Large Board Candidate Evaluation Committee.
  • Related to SSAC, the Zone File Access Ad-hoc Group used remote participation uniquely: only one member was physically present, with 4 other members co-presenting from remote locations, and the session went well.
  • The ICANN Board passed a resolution adopting new trademark-related solutions for the new gTLDs, including a Trademark Clearinghouse and a Uniform Rapid Suspension Procedure.

In fact, the whole community delivered robust engagement in all Nairobi meetings.

Thanks to a terrific effort from the Meetings Team, Nick Ashton-Hart and the Public Participation committee ahead of the meeting, Rob Hoggarth at the meeting, ICANN’s ICT staff, and many others, remote participation worked. Credit also goes to the many Chairs and meeting moderators who bent over backwards to consistently include input from members observing sessions from thousands of miles away. Kudos also to volunteers many time-zones removed from Kenya, who cared enough about ICANN policy work to turn their sleep habits upside-down in order to participate.

This kind of innovative effort demonstrates once again that ICANN’s multi-stakeholder, consensus-driven policy approach works. Remote participation technologies enable it. But it’s the heart and enthusiasm of the ICANN community that empowers it.


    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"""" is not an IDN."