Skip to main content
Resources

Work Stream 2 – Recommendations on Jurisdiction

Recommendation 4.1 and its components relate to the impact of trade regulations, such as those from the U.S. Government's Office of Foreign Asset Control (OFAC), that impose restrictions on whom ICANN may provide with goods and services.

Recommendation 4.2, and its components, relate to the Choice of Law and Choice of Venue provisions in ICANN Agreements.

The implementation of this set of recommendations is owned by ICANN org.

Rec Description Implementation Status

4.1 Recommendations Relating to OFAC Sanctions and Related Sanctions Issues

4.1.1

4.1.1 ICANN Terms and Conditions for Registrar Accreditation Application Relating to OFAC Licenses

For ICANN to enter into a Registration Accreditation Agreement (RAA) with an applicant from a sanctioned country, it will need an OFAC license. Currently, "ICANN is under no obligation to seek such licenses and, in any given case, OFAC could decide not to issue a requested license." This uncertainty could discourage residents of sanctioned countries from applying for accreditation. The sub-group recommends that the above sentence should be amended to require ICANN to apply for and use best efforts to secure an OFAC license if the other party is otherwise qualified to be a registrar (and is not individually subject to sanctions). During the licensing process, ICANN should be helpful and transparent with regard to the licensing process and ICANN's efforts, including ongoing communication with the potential registrar.

Complete. Completion date: Q1 2022.

4.1.2

Approval of gTLD Registries

In the 2012 round of the New gTLD program, it was difficult for residents from sanctioned countries to file and make their way through the application process. The Applicant Guidebook (AGB) states: "In the past, when ICANN has been requested to provide services to individuals or entities that are not SDNs (specially designated nationals) but are residents of sanctioned countries, ICANN has sought and been granted licenses as required. In any given case, however, OFAC could decide not to issue a requested license."

The sub-group recommends that ICANN should commit to applying for and using best efforts to secure an OFAC license for all such applicants if the applicant would otherwise be approved (and is not on the SDN list). ICANN should also be helpful and transparent with regard to the licensing process, including ongoing communication with the applicant.

Not started. Due to the dependency on the Subsequent Procedures and the Applicant Guidebook-related updates, ICANN org cannot estimate the completion date.

4.1.3

Application of OFAC Limitations by Non-U.S. Registrars

It appears that some non-U.S.-based registrars might be applying OFAC sanctions with registrants and potential registrants, based on a mistaken assumption that they must do so simply because they have a contract with ICANN. Non-U.S. registrars may also appear to apply OFAC sanctions, if they "cut and paste" registrant agreements from U.S.-based registrars. While ICANN cannot provide legal advice to registrars, it can bring awareness of these issues to registrars. The sub-group recommends that ICANN clarify to registrars that the mere existence of their RAA with ICANN does not cause them to be required to comply with OFAC sanctions. ICANN should also explore various tools to remind registrars to understand the applicable laws under which they operate and to accurately reflect those laws in their customer relationships.

In Progress. Targeted completion date: Q2 2022.

4.1.4

General licenses

OFAC "general licenses" cover particular classes of persons and types of

transactions. ICANN could pursue general licenses to cover transactions integral to ICANN's role in managing the DNS and contracts for Internet resources, such as registries and registrars entering into Registry Agreements (RAs) and Registrar Accreditation Agreements (RAAs), Privacy/Proxy Accreditation, support for ICANN-funded travelers, etc. This would enable individual transactions to proceed without the need for specific licenses. A general license would need to be developed in conjunction with the U.S. Department of the Treasury, which must amend OFAC regulations to include the new license. This regulatory process may be a significant undertaking. The sub-group recommends that ICANN take steps to pursue one or more OFAC "general licenses." ICANN should first prioritize a study of the costs, benefits, timeline and details of the process. ICANN should then pursue general licenses as soon as possible, unless it discovers significant obstacles. If so, ICANN should report this to the community and seek its advice on how to proceed. If unsuccessful, ICANN needs to find other ways to remove "friction" from transactions between ICANN and residents of sanctioned countries. ICANN should communicate regularly about its progress, to raise awareness in the ICANN community and with affected parties.

In progress. Targeted completion date: Q2 2022.

4.2 Recommendations Relating to Choice of Law and Choice of Venue Provisions in ICANN Agreements

4.2

4.2.1 Choice of Law and Venue Provisions in the Registry Agreement The sub-group identified several alternative approaches for the RA, which could also apply to the RAA. The body of the report discusses the advantages and disadvantages of each approach.

4.2.1.1 Menu Approach. The sub-group supports a "Menu" approach, where the governing law would be chosen before the contract is executed from a "menu" of possible governing laws. The menu needs to be defined; this could best left to ICANN and the registries. The sub-group discussed a number of possible menus, which could include one country, or a small number of countries, from each ICANN geographic region, plus the status quo (no choice of law) and/or the registry's jurisdiction of incorporation and/or the countries in which ICANN has physical locations. The sub-group has not determined what the menu items should be, but believes there should be a balance between the advantages and disadvantages of having different governing laws apply to the same base RA, which likely suggests having a relatively limited number of choices on the menu. The sub-group recommends that the Registry choose from among the options on the menu (i.e., the choice would not be negotiated with ICANN).

4.2.1.2 "California" (or "fixed law") Approach. A second possible option is for all RAs to include a choice of law clause naming California and U.S. law as the governing law.

4.2.1.3 Carve-Out Approach. A third possible option would be a "Carve-Out" approach, whereby parts of the contract that would benefit from uniform treatment are governed by a uniform predetermined law (e.g., California) and other parts are governed either by the law of the registry's jurisdiction or by a jurisdiction chosen using the "Menu" approach.

4.2.1.4 Bespoke Approach. In the "Bespoke" approach, the governing law of the entire agreement is the governing law of the Registry Operator.

4.2.1.5 Status Quo Approach. A fifth possible approach is to retain the status quo, (i.e., have no "governing law" clause in the RAA).

4.2.2 Choice of Law Provisions in Registrar Accreditation Agreements The options for the RAA are essentially the same as for the RA.

4.2.3 Choice of Venue Provisions in Registry Agreements Under the RA, disputes are resolved by "binding arbitration," pursuant to ICC rules. The RA contains a choice of venue provision stating that the venue is Los Angeles, California as both the physical place and the seat of the arbitration. When entering into contracts with registries, ICANN could offer a list of possible venues for arbitration rather than imposing Los Angeles, California. The registry that enters into a registry agreement with ICANN could then choose which venue it prefers at or before the execution of the contract.

Not started. Due to the dependency on the Subsequent Procedures and the Applicant Guidebook-related updates, ICANN org cannot estimate the completion date.

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