There are many ICANN policies that dotBrands need to follow as part of applying for and operating their dotBrand registry. We have set out some key ones in the gTLD Registry Agreement that you should be aware of as a dotBrand operator.

1. Specification 13 – provides qualified dotBrand registries certain modifications to their new gTLD Registry Agreement with ICANN.

The ICANN gTLD Registry Agreement contains terms that are irrelevant or inappropriate to .brand registries. DotBrand registries do not intend to sell names at the second level. Specification 13 is a revision to make the contract more fit for purpose and to avoid the need for ICANN to conduct hundreds of separate negotiations. The BRG negotiated Specification 13 with ICANN on behalf of its members.

Specification 13 defines a dotBrand and a trademark licensee. To remain as a qualifying dotBrand TLD, and therefore to retain the benefit of Specification 13, domain names may only be allocated to the registry, its affiliates and trademark licensees.

Specification 13 also:

• Provides an exemption from Specification 9, a code of conduct towards registrars dealing with matters such as equal treatment of registrars and restrictions on data sharing. The code of conduct is essentially for the protection of a registrant but no names are being sold.

• Provides an exemption from the need for a Sunrise period (for selling names to trademark owners). The registry must still comply with other provisions of the Trade Mark Clearing House, including claims service.

• Allows the dotBrand registry to limit itself to working with up to three ICANN accredited registrars. For dotBrands the registrar role is about security and trust, not selling names.

• Delays any re-delegation of the top-level-domain to a successor, without the consent of the registry, for a period of two years, unless necessary to protect the public interest. This recognises the brand equity inherent in the dotBrand and the consumer confusion which could result from re- delegation.

• Requires the dotBrand to affirm annually it continues to meets the definition of a .brand.

• Requires the doBbrand to notify ICANN of any reason why it no longer meets the definition of a .brand.

 

2. Specification 5, Section 2 – Schedule of Reserved Names / Two-character labels

Specification 5, Section 2 of the gTLD Registry Agreement requires registry operators to reserve two-character ASCII labels within the TLD at the second level. The reserved two-character labels “may be released to the extent that Registry Operator reaches agreement with the related government and country-code manager of the string as specified in the ISO 3166-1 alpha-2 standard. The Registry Operator may also propose the release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes, subject to approval by ICANN.

Following a lengthy consultation, ICANN developed a process for granting approval of 2-letter second level domains where governments had previously objected to their release on the basis of confusion with the country code. By implementing a set of confusion avoidance measures, registries can proceed to register two-letter domains.

There are three confusion avoidance measures:

• The first of these, an exclusive registration period for governments and ccTLD operators, does not apply to dotBrands.

The other two measures are compulsory:

• DotBrands must include in their registration policies a requirement that registrants will avoid falsely implying a connection with the government or country code manager.

• DotBrands must also commit to taking reasonable steps to investigate and respond to any reports of confusion.

 

3. Specification 4, Section 2 – Zone File Access / CZDS

Zone data contain mappings between domain names and IP addresses and other resources. This data is required to be available publicly for queries by any Internet user for the TLD to function properly.

Zone files contain a daily snapshot of zone data in text file format and CZDS provides a centralised access point to access and download zone files. Requests for access can be approved or denied by registry operators per the terms Specification 4, Section 2 of the gTLD Registry Agreement (https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm).

A concern raised by BRG members and other dotBrand registries relates to the provision for access to CZDS. The primary use of the CZDS is for law enforcement, brand monitoring service providers and researchers to access domain registrations across TLDs. This is helpful when considering commercial TLDs where third parties are constantly registering domains. However, for dotBrands, the registrant is always related to the registry operator, so this information becomes less relevant.

 

4. Specification 6 – Name Collision Occurrence Management

A name collision occurs when an attempt to resolve a name used in a private name space (e.g. under a non-delegated Top-Level Domain, or a short, unqualified name) results in a query to the public Domain Name System (DNS). When the administrative boundaries of private and public namespaces overlap, name resolution may yield unintended or harmful results.

Name collisions are not new. The introduction of any new domain name into the DNS, whether a generic TLD, country code TLD or second-level domain name, creates the potential for name collision. However, queries for un-delegated TLDs at the root level of the DNS have received renewed attention because certain applied-for new TLD strings could be identical to name labels used in private networks. A secure, stable and resilient Internet is ICANN’s key priority and these measures are a commitment to the Internet community to mitigate and manage name collision occurrence.

The Name Collision Occurrence Management Framework was created to mitigate the impact of name collisions in the domain name system (DNS). It calls for Registry Operators to implement a controlled interruption for a period of 90 days to alert system administrators that there may be an issue in their network, and to have an emergency response capability in place. The detailed document can be found here – Name Collision Occurrence Management Framework.