Skip to main content

Transitioning ICANN's Remote Participation Platform to Zoom

After careful consideration, ICANN org has decided to transition our official remote participation platform from Adobe Connect to Zoom. In January 2019, we entered into a contract with Zoom to license its product for widespread deployment. Plans are being executed now so that we can completely replace Adobe Connect & PGi by ICANN65 in Marrakech, Morocco. Our intent is to run ICANN65 using Zoom as our sole web conference platform.

This decision comes as the result of a comprehensive evaluation of alternative remote participation and collaboration tools. The evaluation began in March 2018, after a security researcher brought several issues with Adobe Connect to ICANN's attention. This resulted in ICANN suspending services until multiple forensic investigations were completed. ICANN reinstated Adobe Connect, but some of the fixes made behind the scenes to increase security and data privacy came at the cost of flexibility.

ICANN org is committed to providing the community with the best, safest tools that scale globally. Our tests have shown that Zoom handles ICANN's information security considerations well, while providing nearly all of the same features as Adobe Connect. More security-sensitive groups, such as the Security and Stability Advisory Committee (SSAC) and Board Operations, chose to continue using Zoom even after Adobe Connect was restored to service.

ICANN org is currently spending nearly $500,000 a year to support telephone bridges for Adobe Connect sessions. Zoom provides a built-in Voice-Over-Internet-Protocol (VoIP) solution as well as integrated telephony, allowing us to retire PGi as a supported telephony platform. Our tests have reflected that this solution scales well, with high voice-quality even when extended globally. At this stage, switching to Zoom promises to save over US $100,000 in recurring annual expenses – yet another reason to make the switch.

Early adopters of Zoom have been enthusiastic about its features and ease of use, especially when they participate from a mobile phone or while in transit. Based on feedback, Zoom's voice connectivity and overall experience seem to be superior to equivalent Adobe Connect experiences.

Change isn't always easy or smooth – especially when it's a platform we've all gotten used to. The ICANN org is committed to ensuring that everyone in the community is fully equipped with the tools necessary to make full use of Zoom and its features. We will offer training resources in conjunction with the Zoom team, so please keep an eye out for more information. In the meantime, please take a look at the Zoom Help Center, with some FAQs and a wealth of support articles, as well as this table showing all of the familiar features from Adobe Connect, and how they translate to Zoom.

Comments

    Rubens Kuhl  08:32 UTC on 08 April 2019

    Will the version to be deployed by ICANN IPv6-enabled ? It would be curious for an organisation that coordinates number resources use the depleted IPv4 protocol.

    Mike Brennan  13:44 UTC on 24 April 2019

    Hi Rubens - Zoom is still working on implementing pure IPv6 support, but does not have an estimated date of completion. In the meantime, Zoom works with IPv6 if your environment is dual protocol stack, and works as compatible mode to support both IPv4 & IPv6.

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