ICANN77 brought the community to Washington DC for a four-day policy-focused meeting. While the remote participation services continue to be robust and accessible, in-person participation has a certain special something, and I was grateful for the ability to attend in my physical form. Let’s take a look at some of the policy updates coming out of this meeting and what Tucows customers can expect.
DNS Abuse
One of the most exciting things happening at ICANN77 was the response to the draft amendments to the 2013 Registrar Accreditation Agreement and Base Registry Agreement (find all the docs here). We discussed this in our ICANN76 recap; the work has remained on track since then, and the Public Comment period is now open until mid-July.
These amendments are an important step forward, demonstrating that Contracted Parties (registrars and registries) are committed to fighting DNS Abuse and to having their responsibilities as related to this important issue formalized.
The contract changes oblige registrars to mitigate DNS Abuse when actionable evidence has been provided, aligning with Tucows’ current processes. We believe that this will improve the health of the Internet overall. The changes also allow the use of web forms for report submission (as an option in addition to the email address currently required) and confirmation of receipt of report. All of these are positive steps toward a cleaner Internet, and Tucows is already in compliance.
We’re pleased that the draft changes have received support from other areas of the ICANN Community and look forward to submitting our own supportive public comment, voting in favour of these amendments, and encouraging our registrar colleagues to do the same. If you are an ICANN registrar and you’re unsure how to vote, please reach out to us to discuss.
Registration Data Policy
When our previous ICANN meeting recap went live, we were eagerly anticipating the final language for the Registration Data Policy. Those updates were posted at the end of April, and they raised two new issues, which were discussed at ICANN77, but the Implementation Review Team (IRT) did not come to a conclusion on either. Here are the two open issues still being discussed:
The first issue is that the response period for disclosure requests marked as “Urgent” was changed from “two business days” to “24 hours.” Although this may seem like a good change—if the request is urgent, surely it needs a prompt response—this is actually an unnecessary and inappropriate late-stage change to agreed Policy decisions.
The Policy requires that responses happen “without undue delay,” and the specific timeframe is a maximum rather than a minimum. Urgent requests will certainly be prioritized and reviewed as soon as possible; setting a shorter response time is not necessary to achieve the goal of prompt action. There are also important reasons to keep the requirement at two business days. For one thing, a 24-hour response timeframe unfairly disadvantages smaller registrars who don’t have an in-house legal team and need to send out requests for consideration. Secondly, rushing requests will lead to bad responses—incorrect denials and incorrect disclosures are both incorrect outcomes.
Ultimately, the reasons for or against this change don’t matter; the job of the Implementation Review Team is to implement the Policy Development Working Group’s Recommendations as written, and the Recommendation here said, “A separate timeline of [less than X business days] will be considered.” Moving from business days to hours simply does not match up. “Two business days” was the settled language for quite some time, and it is inappropriate for the IRT to make changes to Policy at this point. We continue to advocate for returning to the agreed Policy language.
The second open issue is how much time registrars, registries, resellers, and others in the industry will have to come into compliance. The plan for several years now has been to have an 18-month buffer period beginning when the new Policy is published. During this time, affected parties can follow either the old requirements or the new requirements, but they must fully comply with the new Policy by the end of that period. This would give everyone enough time to make changes and allow for cascading updates: first, registries can modify what they require, then registrars can update to match, and finally, resellers can modify their own platforms once they have the full scope of required updates.
When they published the final updated Policy language, ICANN surprised us all by proposing instead a two-year waiting period followed by a one-month implementation window, meaning everyone across the industry would be expected to complete the required changes in August 2025. This proposal was met with a flurry of emails and discussion about the inevitable chaos this would cause (I’d run out of blog space if I tried to capture it all, but you can read my email to the IRT mailing list here). As a result of the pushback, ICANN is now considering instead a several-month waiting period followed by the expected 18-month implementation window.
We’re paying close attention to this issue because of the potential adverse effects the proposed one-month implementation period would have on both our systems and those of our customers—especially the possibility of rushed code changes without enough time to fix the inevitable resultant bugs. While we anticipate that we’ll reach an agreement to follow the initial 18-month plan, we are considering next steps in case the outcome is different.
In any case, reseller-facing changes will be fairly minimal, like updates to required contact sets (goodbye forever, Admin contact!) or mandatory data elements becoming optional. We’re committed to minimizing the work required of our reseller partners and to sharing resources that outline any changes you will have to make.
New gTLDs
We’ve been eagerly anticipating the work coming out of the New gTLD Subsequent Procedures (“SubPro”) team relating to the accreditation of new generic top-level domains (gTLDs), and at ICANN77, we had an in-depth look at some specific topics still in progress.
Draft Framework for Closed Generics
Closed Generics are a specific type of gTLD where the “string” (the letters that make up the TLD) is a word that could refer to both a general object (like an apple) or to a specific trademarked term (like Apple) and where access to register domains in that TLD is restricted to a specific entity. The default standard for gTLDs is open access: anyone can purchase a domain name under the extension (sometimes anyone who fits certain criteria, such as .law, but anyone who fits those criteria can register).
Closed Generics are different: since the term is broadly applicable but is being artificially limited by the supporting organization, they unfairly restrict people and businesses that could benefit from registering a domain in the TLD. The frequently-used example is .book: these domains could have been registered to authors, publishers, libraries, book clubs, and readers, but instead, the TLD belongs to Amazon and isn’t currently available for anyone to use, hindering proper competition.
A team of ICANN community members has developed this Draft Framework, which is currently open for public comments. One of the key aspects of the Framework is the understanding that a Closed Generic TLD must serve the public interest in some way; it requires a TLD applicant to show that they either represent the relevant industry or group or will contractually commit to “non anti-competitive behaviour.” This representativeness requirement has already proven difficult in the most recent round, and it’s not clear how this will change in subsequent procedures. It’s also not clear what “non anti-competitive behaviour” means when the Closed Generic TLD is implicitly a monopoly and, while a closed generic TLD can serve a broader public interest, that’s certainly not the automatic default, so this Framework to set guidelines around how that should work is a step in the right direction.
As we heard from Jason Merritt, our Canadian representative on ICANN’s Governmental Advisory Committee, identifying the public interest before delegating a TLD is of the utmost importance. There needs to be a connection between the TLD, how it’s used, who’s applying to operate it, and the public interest. We agree with Jason on this one and look forward to spending some time with the Framework and submitting comments on it within the next few weeks.
Applicant Support
The New gTLD Subsequent Procedures (SubPro) Final Report talks about an Applicant Support Program, with details to be worked out by the Implementation Review Team. Applicant Support is just what it sounds like: help for entities that want to apply to operate a new gTLD but may not have the resources to do so.
The ability to apply for a gTLD depends on having information (knowing that new gTLDs are coming, that there is a process to apply for one, and even that ICANN exists to delegate gTLDs) and the technical and legal ability to submit a complex and detailed application. This means that parties which might be the most relevant or appropriate owner of a new gTLD may not be able to compete fairly for the delegation without support of some kind.
Tucows is committed to supporting the Free and Open Internet, so we’re watching the discussion closely and promoting our services as a backend registry operator and consultant for new gTLDs.
Transfer Policy
The Transfer Policy Review PDP Working Group met at ICANN77 to share some of the current work in progress: considerations around the Transfer Emergency Action Contact and Transfer Dispute Resolution Process. The group is almost finished reviewing these two processes and will soon move on to looking at “ICANN-approved transfers,” which happen when a Registrar is acquired by another Registrar or when a Registrar is deaccredited and its domains are automatically redelegated to another Registrar. We continue to participate in this Working Group and look forward to collaborating to determine how to best govern these ICANN-approved transfers.
That’s all for this ICANN Policy update. We are so glad to be able to participate in this important community-driven multistakeholder process and look forward to ICANN78, which is also the 25th ICANN Annual General Meeting, to be held in Hamburg this October.