March 29, 2019
Brian Winterfeldt
Advisory
Advisory
Advisory

ICANN 64 Key Takeaways from Kobe, Japan

External Article

This article is hosted away from the Winterfeldt website at

The sixty-fourth public meeting of the Internet Corporation for Assigned Names and Numbers (ICANN), took place in Kobe, Japan from March 9 through March 14, 2019.Several crucial issues were hotly debated over the course of the week, with notable impacts on brand owners, business stakeholders, consumers, and future applicants for “.Brand” Top-Level Domains (gTLDs) over the course of the coming years.  After a close examination of the proceedings,here are our key takeaways, including our analysis of how each topic played a prominent role at ICANN 64, why each topic matters to the brand and business community, and what may happen in the near future.

  1. The   Expedited Policy Development Process (EPDP) on gTLD Registration Data  Phase 1 Concerning Data Processing Purposes, Collection, and Retention,  Begins Transition to Phase 2 Concerning Access

In the wake of the effective date of the European Union General Data Protection Regulation (GDPR), ICANN adopted a Temporary Specification for gTLD Registration Data,which resulted in heavy redaction to public WHOIS data in efforts to ensure that the treatment of WHOIS data complies with the GDPR.  Shortly after, an Expedited Policy Development Process (EPDP) was initiated to review the Temporary Specification and develop a permanent consensus policy on domain name registration data.  The EPDP was divided into two phases: Phase 1, which was recently completed, focused on defining the purposes of processing domain name registration data, parameters around collection and retention of such data, and the data elements that must continue to be published in a freely-accessible online database, and, importantly, additional parameters around individual disclosure requests for non-public data; and Phase 2, which just got underway during ICANN 64, will focus on a few remaining publication issues left over from Phase 1 and on developing a standardized system for accessing non-public data that goes beyond individual ad hoc disclosures.  

The Phase 1 Final Report, approved by the GNSO Council just prior to ICANN 64, contained twenty-nine policy recommendations and the ICANN Board is expected to formally adopt the report and recommendations following a public comment period closing on April 17, 2019. While the Phase 1 Final Report represents compromise on many key issues, a handful of important matters from Phase 1 were deferred to Phase 2,including: additional discussion regarding whether Purpose 2 for processing registration data (relating to processing to maintaining the security,stability, and resiliency of the DNS through enabling lawful access to registration data) is sufficient to enable disclosure in the course of intellectual property infringement and DNS abuse cases; whether or not to continue redaction of the registrant city field in the public database; and whether or not registrars must distinguish between data of natural versus legal persons (since GDPR only applies to personal data of natural persons).  With Phase 1 now behind us, in terms of community policy work, discussions about next steps for actually implementing the Phase 1 recommendations were a focus of ICANN 64.  An implementation plan will be developed by a separate implementation review team following Board adoption of the Phase 1 report in April.

In addition, and perhaps more importantly from a brand owner perspective, the planning for Phase 2 commenced in earnest during ICANN 64.  As an initial matter, the GNSO Council must select a new EPDP Chair for Phase 2, after the original Chair resigned at the end of Phase 1. The period for expressions of interest closes on March 22, and the goal is to confirm a new Chair during the April 18 GNSO Council meeting.  It is important that the Council select a new Chair that is both well-informed on the Phase 2 issues but who can also remain a neutral facilitator of the EPDP’s work rather than inserting her or himself as an advocate for a particular outcome.  Furthermore, we were greatly encouraged by cross-community statements calling for measures to ensure that Phase 2 institutes concrete milestones, progress reports and an expeditious timeline similar to Phase 1, is resourced accordingly, and works in parallel tracks for technical and legal guidance to maximize efficiency as much as possible.  This is critical because development of a standardized access system for non-public data is the most important component of an overall domain name registration data consensus policy to facilitate anti-counterfeiting, trademark enforcement, and other efforts to combat infringement, phishing, fraud, and other online abuse in light of global WHOIS data redaction following GDPR, the Temporary Specification, and Phase 1 recommendations.      

The next immediate action items for the EPDP team following ICANN 64 are to review the “mind map” developed by ICANN staff,which outlines proposed work plan items for Phase 2 and to provide input by March 28, 2019, and to identify specific questions to refer to EPDP legal counsel concerning development of a standardized system of access to non-public data.  Once a Chair is confirmed, the group can then finalize its overall Phase 2 work plan and begin substantive discussion on the issues within the scope of Phase 2.

  1. Rights  Protection Mechanism (RPM) Review Forges Ahead in Discussions on Sunrise and Trademark Claims

As a result of the New gTLD Program, several new trademark rights protection mechanisms (RPMs) were developed to mitigate additional potential risks and costs to trademark rights holders that could arise in the expansion of the gTLD namespace: the Uniform Rapid Suspension System (URS); the Trademark Clearinghouse (TMCH) and associated Sunrise and Trademark Claims RPMs; and the Post-Delegation Dispute Resolution Procedure (PDDRP).  Having implemented these mechanisms in 2013, the ICANN community agreed it would be useful to review them, as well as the long-standing Uniform Domain Name Dispute Resolution Policy (UDRP), before moving forward with any additional rounds of new gTLDs.  Accordingly, a formal ICANN policy development process (PDP) was launched in 2016 to review all ICANN RPMs,and this PDP has been working since that time to conduct an in-depth review of all of these mechanisms.  For additional background on the RPMs, you can read one of our prior publications on the subject here. Currently, the RPM Review PDP is debating the Sunrise and Trademark Claims mechanisms, which were the areas of focus during ICANN 64.    

Sunrise

The RPM Review PDP was tasked with answering a specific set of questions, per the PDP Charter, including thirteen questions (some with various sub-parts)concerning the Sunrise mechanism. Sunrise is important from a brand owner perspective, including in connection with anti-counterfeiting efforts, because it affords brand owners priority access to defensive registrations in new gTLDs, which prevents such domains from falling into the hands of potential counterfeiters, cyber squatters, and other infringers and bad actors.

During ICANN 64, members of a dedicated Sunrise sub-team reached preliminary agree mention responses to Sunrise questions 1 and 7.

Question 1: (a) Should the availability of Sunrise registrations only for identical matches be reviewed? (b) If the matching process is expanded, how can Registrant free expression and fair use rights be protected and balanced against trademark rights?  

The group generally agreed that matching rules for Sunrise should remain the same.However, the question of “truncated” versions of marks where the full mark incorporates the TLD itself may need to be further considered as part of this question (e.g. TRADE.MARK).  While many brand owners would prefer to have expanded matching for Sunrise (i.e. the ability to obtain priority access to domain name registrations in new gTLDs for names including their mark but not necessarily limited to just the mark by itself, such as “mark+keyword”), on balance it was recognized that this may inappropriately provide greater rights to brand owners than they should be afforded in the Domain Name System, provide additional avenues for “gaming” the system, and may have too great a negative impact on legitimate third-party registrations where a mark may incidentally be included in a domain.

Question 7: (a) Can SMD files be used for Sunrise Period registrations after they have been canceled or revoked? (b)How prevalent is this as a problem?

Signed Mark Data (SMD) files are technical files used by the TMCH and registry operators and registrars to confirm that a mark entered into the TMCH is eligible for Sunrise registration.  The group agreed that generally, SMD files are timely revoked once they become invalid for any number of reasons, including where the underlying trademark registration that was the basis for the SMD file is invalidated.  The use of an SMD file that is invalid to obtain a Sunrise registration was not identified as a prevalent problem.  Accordingly, the group responded to this question in the negative and will not propose any recommendations to change practices concerning SMD file revocation.  This is a positive development, because there had previously been some concern raised by domain name investors and free speech advocates that brand owners and parties attempting to use non-bonafide trademark registrations to gain access to priority Sunrise registrations could somehow keep using SMD files to participate in Sunrise even if the SMD file had become invalid.

The sub-team also began discussing Sunrise charter Question 2, but was not able to reach an initial conclusion.

Question 2: (Threshold question: Is Registry pricing within the scope of the RPM WG or ICANN's review?) (a) Does Registry Sunrise or Premium Name pricing practices unfairly limit the ability of trademark owners to participate during Sunrise? (b) If so, how extensive is this problem?

Clearly,the sentiment among brand owners is that registry pricing practices should not be permitted that have the effect of inhibiting access to Sunrise participation.  That said, many in the community are reticent to address pricing issues, which many perceive as beyond the remit of the RPM Review PDP and potentially problematic to regulate due to antitrust and competition concerns. Ultimately, after initial debate on the matter during ICANN 64, further discussion on this question and the remaining Sunrise charter questions will continue in future Sunrise sub-team meetings.

Trademark Claims

The RPM Review PDP was also tasked with answering five questions (some with various sub-parts)concerning the Trademark Claims mechanism. Trademark Claims includes two components: pre-registration notice to prospective domain name registrants if a domain they are attempting to register matches a trademark recorded in the TMCH, and notice of such registration to the TMCH-recorded mark owner if the registration is actually completed.  This service runs for the first 90 days of a new gTLD launch following the Sunrise period (and can be extended at the option of the registry operator), and the TMCH provides ongoing notices of registered names even after the 90 day minimum Claims period. Trademark Claims is important from a brand owner perspective,including in connection with anti-counterfeiting efforts, because the pre-registration notice can help deter third-party registrations that might be used for counterfeiting, cyber-squatting, and other infringing or abusive activity, and the post-registration notice allows brand owners to identify such registrations and determine whether further enforcement action is appropriate.

During ICANN 64, members of a separate sub-team dedicated to Trademark Claims discussed Trademark Claims charter Questions 1 and 3(b).

Question 1: Is the Trademark Claims service having its intended effect? Consider the following questions specifically in the context both of a Claims Notice as well as a Notice of Registered Name: (a) Is the Trademark Claims service having its intended effect of deterring bad-faith registrations and providing Claims Notice to domain name applicants? (b) Is the Trademark Claims service having any unintended consequences, such as deterring good-faith domain name applications?

In general, participants seemed to agree that Claims notices likely deterred some registrations, both bad and good faith, but that the proportionality of this effect was within a reasonable degree such that the Claims service need not undergo major overhaul to correct disparate unintended consequences.  One participant, however, suggested that because certain dictionary words also appeared as trademarks in the TMCH (e.g.CLOUD or HOTEL) that this presented an impermissible chilling effect on good faith registration to such a degree that changes to Claims service were needed.  Of course, this suggestion ignores the facts that entries into the TMCH should be challenged at the TMCH-level through existing challenge mechanisms, or by bringing challenges to the underlying trademark registrations themselves in the appropriate national or regional trademark offices on the basis that they are merely pre-textual and should not provide grounds for entry into the TMCH for purposes of taking advantage of Trademark Claims (or potentially also the Sunrise service).

Question 3(b): Should Claims Notifications only be sent to registrants who complete domain name registrations, as opposed to those who are attempting to register domain names that are matches to entries in the TMCH?

The vast majority of participants agreed that notice should be presented prior to completion of a registration, although one minority view suggested that the notice should be presented after a registration is completed in order to preserve the registrant’s ownership while also giving it additional time to consider the consequences of the Claims Notice (implying some potential for a post-registration cancellation period). However, this approach seems to generally undermine the intended purpose of the Claims Notice of deterring bad faith registrations.  Others also raised timing questions, mainly matters of implementation, where pre-registration marketing techniques are involved and how that practice might impact the timing of a Claims Notice where potentially months can intervene before the registration is ultimately made and whether this impacts the purpose or efficacy of the Notice.  Ultimately, the general agreement that notices should continue to be presented prior to completion of a registration is the position supported by the brand owner community, so we consider this to be a positive development despite the minority view.  These questions and the remaining Sunrise and Claims charter questions, will be further discussed in future sub-team meetings, slated to resume the week of March 25, 2019.

  1. Policy Discussions in Preparation for Future Rounds of New gTLDs Begin to Conclude on Several Important Topics      

The New Generic Top-Level Domain (gTLD)Subsequent Procedures Policy Development Process (Sub Pro), was chartered to evaluate what changes may need to be made to existing new gTLD policy for future new gTLD expansions, including application requirements, evaluation and objection procedures, registry agreement terms, and delegation and post-delegation matters. The Sub Pro issued its Initial Report in July 2018, as well as a Supplemental Initial Report in October 2018.

During ICANN 64 the Sub Pro discussed several topics it had identified as potentially warranting closure, based on public comments received on its Initial Report and Supplemental Initial Report. First, there was general support for there commendation that while the Applicant Guidebook (AGB) should continue to be used, it should be made more user friendly and provide more practical user processes and search ability, as well as more specific guidance with respect to different application types (e.g. .Brand TLDs). In addition, there was general support for the recommendation that applicant-facing systems should be integrated, preferably single sign-on, and allow bulk management of different applications by the same user and all aspects of the processing of applications by the same user.

In addition, there was general support for a minimum of four (4) months from AGB finalization until the start of application acceptance, adequate time for global stakeholder engagement and applicant support, and a communications period of at least six months regarding clear service level agreements and escalation paths for applicant communications, with real-time applicant support from ICANN Org. There was also agreement that there should continue to be support for Internationalized Domain Names (IDNs), but applicants should be made aware of Universal Acceptance issues. One possibility is for the Universal Acceptance Steering Group, which is developing solutions to problems with Universal Acceptance caused by new gTLD applications, to play a role in such informational efforts. This is important because it impacts .Brand operators whose TLDs may not be recognized by all Internet applications (e.g. email services who deny services using a .Brand TLD in an email address), as well as.Brand TLDs using non-Latin character scripts (e.g. in jurisdictions where non-Latin scripts are prevalent, such as Russia, China, Japan, and Middle Eastern nations).  

Finally,there was general support for a minimum of a three (3) month period for an applicant to submit an application, assuming subsequent new gTLD application procedures takes the form of rounds with specific submission deadlines. Some believe a longer period makes sense, but most agree that a fixed application period is the appropriate format. Importantly, if this is the case, evaluation and delegation of applications may overlap with the opening of new windows, the implications of which must be taken into account.

Overall,these represent sensible improvements and approaches that we believe the brand owner community, and in particular potential future .Brand applicants, can support.  While the brand community generally prefers to minimize the number of new gTLDs as new spaces for online counterfeiting, infringement, and other abuse, it remains important to set sensible rules for future application rounds that ensure fair and efficient processing, including appropriate evaluation and objection mechanisms(including legal rights objections and string confusion objections to avoid new gTLDs that are confusingly similar to third-party trademarks and .Brand TLD strings), as well as less onerous rules and requirements for future .Brand TLD operators to ensure greater participation by the brand community in the gTLD expansion, which also facilitates anti-counterfeiting and brand protection by providing dedicated online spaces for legitimate products and services by brand owners.The Sub Pro will continue to discuss these issues, as well as a number of more thorny issues were initial agreement was less clear, in the months ahead.

  1. Geographic Names Battles Resurface

The ICANN community continues to debate possible changes to the rules and requirements concerning the use of terms with geographical significance as future new gTLDs.  The brand owner community continues to fear governmental overreach with respect to the use of such terms, and so it remains important to engage in this work to avoid an outcome dictated by such governments that would contravene international legal norms such as respect for private intellectual property rights. While in general it is more favorable to have fewer new gTLDs than more to reduce new spaces for counterfeiting, cyber-squatting, and other infringement and DNS abuse, it is equally as important to have rules in place that permit more.Brand TLDs versus open TLDs because .Brand TLDs are “walled gardens” with very limited opportunities for such abuses to occur. Thus, it is critical to get the balance right with respect to rules governing the use of terms with geographic significance, particularly where such terms are also legally protected trademarks.

Work Track 5 is a sub-team of the Sub Pro focused specifically on the use of geographic names as future new gTLDs. During ICANN 64, Work Track 5 spent the majority of its time reviewing,analyzing, and debating public comments received on its Initial Report, which presented numerous preliminary recommendations and questions concerning possible changes to current ICANN policy on the use of geographic names as gTLDs.  Current policy decisions regarding these terms are encapsulated in the 2012 New gTLD Applicant Guidebook (AGB). In short, if an applied-for new gTLD string met the definition of a “geographic name” as set out in the AGB, an applicant was required to submit documentation of support for or non-objection to its application from the relevant governments or public authorities, or the names were outright prohibited in certain cases:

Prohibited Strings

Government Support/Non-Objection  Required

Two-letter  strings

Capital  city names in any language

Three-letter  country codes

City  names, where the applicant declares that it intends to use the gTLD for  purposes associated with the city name

Long  and short form country and territory names in all languages

Sub-national  place names, such as a province, state, or county

Separable  components of country and territory names in any language

UNESCO  region names, continental region names, geographical sub-region names

Permutations  or transpositions of any such names

Common  names of countries and territories as recognized by intergovernmental or  treaty organizations

The brand owner community generally supported the 2012 implementation, recognizing that it struck a careful compromise between the interests of governments and private applicants.  That said, in prior public comments and in discussions during ICANN 64, the brand owner community opposed the continued moratorium against use of three-letter names as gTLD seven where they may match three-letter country codes, opposed any further extension of preventative measures concerning applications identified as reflecting a term with geographic meaning beyond what currently exists in the AGB, and supported further use of curative objection measures rather than preventative measures to address concerns around applications reflecting a geographic term.

On the issue of three-letter names, the following examples illustrate why the current moratorium is overly restrictive: AGO (Angola), AND (Andorra), ARE(United Arab Emirates), ARM (Armenia), BRA (Brazil), BRB (Barbados), CAN(Canada), CUB (Cuba), FIN (Finland), GAB (Gabon), GIN (Guinea), GUM (Guam), GUY(Guyana), IOT (British Indian Ocean Territory) [IOT is an abbreviation for“Internet of Things”], JAM (Jamaica), LIE (Liechtenstein), and TON (Tonga).This does not even get into the impact of the prohibition on three-letter brands.

A good deal of discussion also took place regarding the issue of translations of terms corresponding to country and territory names and capital city names.Many, including members of the brand owner community, feel that the current rule extending AGB rules to translations “in any language” is vastly over broad,and could prevent applications for .Brand TLDs and other strings that may coincidentally overlap with a translation of one of these types of terms in an obscure local language somewhere in the world. Accordingly, brand owners supported minimizing the list of names that are prohibited and instead provide a streamlined ICANN objection mechanism to allow parties who might be aggrieved by a proposed application on the basis that it reflects a translation of their country, territory, or capital city name, to challenge the application.

Debates on these issues and numerous remaining issues raised by the Initial Report and public comments will continue over the next few months.

For more information about these topics, or other ICANN or Internet and trademark related matters, please contact any of the following team members:
Brian J. Winterfeldt - brian@winterfeldt.law
Griffin M. Barnett - griffin@winterfeldt.law
Jennifer P. Gore - jennifer@wnterfeldt.law

download this document as a PDF
VIEW PDF TO DOWNLOAD

Subscribe

* indicates required
www.xyz@abc.com
/( mm / dd )