Skip to main content

.AFRICA IRP Declaration – Clearing Up Some Facts

Dot africa 750x425 31jul15

John Jeffrey
ICANN's General Counsel & Secretary

Recently some questions have been raised regarding our posting of a partially redacted final "Declaration" issued by the Panel in the DotConnectAfrica Trust (DCA) v. ICANN independent review process (DCA .AFRICA IRP or IRP) proceedings.

Some misinformation and erroneous reporting have framed parts of the discussion. In this blog, I would like to present facts and clarify a number of points, including the reasons for posting a revised version of the Declaration.

Why Publish a Redacted Declaration?

As background, ICANN has a commitment to the community to post any IRP declaration as soon as reasonably possible. ICANN initially published a redacted version of the IRP Panel's Declaration in the DCA .AFRICA IRP on 9 July 2015, within 24 hours of receiving it.

Today we are publishing a second version [PDF, 1.04 MB] with fewer redactions. So, why are we publishing two versions with different levels of redaction?

Specifically, under ICANN's bylaws, an IRP Panel may grant requests to keep certain information confidential, such as personally identifiable information, trade secrets, internal correspondence, and correspondence with third parties. In the case of DCA v. ICANN, the IRP Panel determined that:

  • Documents exchanged as confidential by the parties could not be publicly disclosed.
  • Reference to information in these documents in parties' written submissions must be redacted prior to public posting. This is a noted common practice in similar commercial arbitrations and the practice has been adopted in the IRP proceedings so that as much information as possible can be placed in the record for the panel to make its decision.

Upon receiving the Declaration from the IRP Panel, we were under an affirmative obligation found in our confidentiality agreement and IRP Panel Procedural Order #4 to redact all confidential information exchanged during the IRP proceedings.

Immediately upon receipt of the Declaration, our legal counsel began to make obligatory redactions to protect material that the parties had mutually agreed was confidential. This was done in order to meet our obligation to post quickly (within the first business day following receipt of the Declaration).

In retrospect, we could have, and should have, noted on the posted document and on website that it contained redactions and explained the reasons for the redactions.

For the sake of increased clarity, we have now altered our process for posting IRP declarations. Going forward we will ensure that in addition to marking as "Redacted" each part of the document that is redacted, we will also make clear when posting a declaration whether there are redactions in it, and will state the reasons for the redactions, as we have done in today's posted version.

In the case of the DotConnectAfrica Trust (DCA) v. ICANN declaration, immediately after the initial posting of the declaration, ICANN's external legal counsel began reviewing each redaction to determine whether it could be released.

If the information redacted came from ICANN, we tried to answer several questions -- Did it contain confidential information? Did it contain privileged information? Could the privilege be waived? And, did it contain third party or applicant information that we did not have the right to publish without permission?

If the information under question had been requested to be confidential by a party or entity that was providing the information to ICANN, we tried to answer a different set of questions -- Have we gained their permission to publish it? If DCA's information -- has their counsel or DCA lifted their request that it be considered confidential? Will they do so if we ask them to lift confidentiality?

If the information in question was from ICANN, we were able to review it very quickly. But for the information supplied by others, we were required to reach out to each of the parties.

In the case of DCA, we initially reached out to DCA's lawyers, then when we learned that DCA was no longer represented by legal counsel and we had to reach out to DCA directly.

We also sought the release of information that other impacted parties had requested be kept confidential by reaching out directly to each of those involved.

The most recent version of the Declaration [PDF, 1.04 MB] that we are publishing is a result of our efforts to remove those redactions. There are still some redactions and we have indicated the reasons why they still exist in the revised version.

ICANN Staff Assistance on New gTLD Applications

Some have viewed the redactions as support for an allegation DCA made during the IRP proceedings that ICANN staff had not treated DCA fairly. Specifically, it has been suggested that staff improperly assisted the African Union Commission (AUC) by helping to ensure that its letter of support for another applicant satisfied the necessary criteria. The DCA IRP Declaration does not address this allegation, but since the allegation is being discussed, it warrants some clarification.

If an applicant has applied for a gTLD string that is a geographic name, such as .AFRICA, the applicant must submit documentation of support for, or nonobjection to, its application from the relevant governments or public authorities. The existence of support or nonobjection is the primary objective, and the manner in which it is documented is secondary.

ICANN staff has helped many applicants and their supporters understand how to properly document support. Not only did we make a template support letter publicly available to all as part of the New gTLD Program Applicant Guidebook (see Appendix to Module 2), we have answered questions, received through our customer service channel, as to how interested parties can document support for a given gTLD application. In the case of ZA Central Registry, ICANN appropriately assisted the applicant in documenting support from the AUC.

Our actions surrounding the .AFRICA applications were not unique, since we assist any applicant who requests assistance, or who needs clarification in learning how best to document support or other matters. We have provided assistance to all applicants regarding their applications to the maximum extent possible.

Impact on .AFRICA Delegation

Questions have also been raised regarding statements made by DCA about the impact of this decision on the other .AFRICA application. In a statement in recent days, DCA was quoted as saying that:

Going forward, we now expect ICANN to accept the binding IRP outcome, refrain from any further plans to delegate .Africa to the ZA Central Registry who should now be removed immediately from the new gTLD program; and cooperate fully with DCA Trust to ensure that the IRP Panel ruling is implemented so that .Africa can be delegated to DotConnectAfrica Trust under a cooperative framework that will satisfy the stipulations of DCA's charitable objectives." [bold emphasis added]

The ICANN Board adopted the panel's recommendation at its Board meeting on 16 July 2015.

This decision does not remove the ZA Central Registry from the New gTLD Program, nor is there any part of the Declaration that calls for that result. The impact on ZA Central Registry is that ICANN "will refrain from delegating .AFRICA" pending the outcome of the evaluation process on DCA's application.

As called for in the Board resolution, ICANN has "resume[d] the evaluation of DCA's application for .AFRICA. The evaluations will be performed in accordance with processes laid out in the Applicant Guidebook.

To summarize, ICANN's actions in redacting parts of the IRP Declaration at the outset were motivated by our obligation to the community to post the document quickly and the competing, yet mandatory obligation, to respect confidential information while being as transparent as possible.

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 labels, such as""icann.org"" is not an IDN."