Latest news of the domain name industry

Recent Posts

“It’s not our fault!” — ICANN blames community for widespread delays

Kevin Murphy, February 14, 2022, Domain Policy

ICANN may be years behind schedule when it comes to getting things done on multiple fronts, but it’s the community’s fault for making up rubbish policies, bickering endlessly, and attempting to hack the policy-making process.

That’s me paraphrasing a letter sent last week by chair Maarten Botterman to the Registries Stakeholder Group, in which he complained about the community providing “ambiguous, incomplete, or unclear policy recommendations”.

RySG chair Samantha Demetriou had written to Botterman (pdf) in December to lament the Org and board’s lack of timely progress on many initiatives, some of which have been in limbo for many years.

Policies and projects related to Whois, new gTLDs and the Independent Review Process have been held up for a long time, in the latter case since 2013, she wrote, leading to community volunteers feeling “disempowered or discouraged”.

As I recently reported, ICANN has not implemented a GNSO policy since 2016.

The lack of board action on community work also risks ICANN’s legitimacy and credibility, Demetriou wrote.

But Botterman’s response (pdf), sent Thursday, deflects blame back at the community, denying that the delays are “simply because of failure at the level of the organization and Board.”

He wrote:

we need to continue to find our way forward together to address the challenges that affect the efficiency of our current decision-making processes, including, for example, ambiguous, incomplete, or unclear policy recommendations, the relitigation of policy issues during implementation, and the use of the review process to create recommendations that should properly be addressed by policy development

In other words, the community is providing badly thought-out policy recommendations, continuing to argue about policy after the implementation stage is underway, and using community reviews, rather than the Policy Development Process, to create policy.

The RySG, along with their registrar counterparts, put their concerns to the board at ICANN 72 in October, warning of “volunteer burnout” and a “chilling effect” on community morale due to board and Org inaction.

At that meeting, director Avri Doria presented staff-compiled stats showing that across five recent bylaws-mandated community reviews (not PDPs), the board had received 241 recommendations.

She said that 69% had been approved, 7% had been rejected, 18% were placed in a pending status, and 6% were “still being worked on”.

CEO Göran Marby provided a laundry list of excuses for the delays, including: reconciling differing community viewpoints, the large number of recommendations being considered, the potential for some recommendations to break ICANN bylaws, sensitivity to the bottom-up nature of the multi-stakeholder process, lack of staff, and the extra time it takes to be transparent about decision-making.

Just this week, ICANN has posted eight job listings, mostly in policy support.

In his letter last week, Botterman pointed to a “Prioritization Framework”, which is currently being piloted, along with further community conversations at ICANN 73 next month and a “thought paper” on “evolving consensus policies”.

Because why fix something when you can instead create another layer of bureaucracy and indulge in more navel-gazing?

Surprising nobody, Verisign to raise .com prices again

Kevin Murphy, February 11, 2022, Domain Registries

Verisign has announced its second consecutive annual price increase for .com domain names.

The wholesale registry fee for .com names will rise from $8.39 to $8.97 on September 1 this year, an extra $0.58 for every new or renewing domain, of which there are currently over 160 million.

Verisign announced the move, which was expected, as it announced a 2021 profit of $785 million and a 65.3% operating margin.

CEO Jim Bidzos, speaking to analysts, played down the impact of the increases on .com registrants, pointing out that .com prices were frozen under the Obama administration and have only gone up once before, last year, since 2012.

“This is the second wholesale price increase for COM since January of 2012,” he said. “So, if you look back over the last 10 years, that translates into a cost increase of only 1.3% CAGR over the last ten and a half years actually.”

The current .com contract, signed off by the Trump administration and ICANN, allows for two more 7% annual price increases, excluding the just-announced one, but Bidzos would not say whether Verisign plans to exercise those options.

If it does (and it almost certainly will) it would raise the price to $10.26, where it would stay until at least October 2026, he said.

“We believe .com continues to be positioned competitively,” he said.

It’s still basically free money for Verisign, which saw strong fourth-quarter and full-year 2021 results.

The company yesterday reported revenue of $1.33 billion for 2021, up 4.9%, with net income of $785 million, down from $815 million. The operating margin was 65.3%, compared to 65.2%.

For the fourth quarter, revenue was up 6.3% to $340 million, with net income of $330 million compared to $157 million. Operating margin was 65.3%, compared to 63.9%.

For 2022, the company is guiding for revenue of between $1.42 billion and $1.44 billion, based on the price increases and predicted unit growth of between 2.5% and 4.5%. The operating margin is expected to be between 64.5% and 65.5%.

Bidzos also addressed the controversial .web gTLD, which it won at auction but has been unable to launch due to legal action pursued by rival bidder Afilias/Altanovo.

An Independent Review Process panel recently threw a decision about .web back at ICANN, which is now considering Afilias’ allegations of wrongdoing at the board level.

“ICANN looks to be moving forward with making the decision on the delegation of .web, and we will be monitoring their process,” Bidzos said. He said that Verisign has not budgeted for any revenue or costs from .web in 2022.

That’s probably wise. Afilias recently told us that it has not stopped fighting against Verisign’s .web win.

Is the .sucks mass-cybersquatting experiment over?

Kevin Murphy, February 4, 2022, Domain Registries

The Everything.sucks experiment is mass-cybersquatting .sucks domains may be over and done with.

Thousands of .sucks domains have been deleted in a huge junk drop, newly created domains at Everything.sucks’ registrar of choice have dried up, and there have been no new UDRP cases filed in months.

Everything.sucks, you may recall, is a wiki-style web site where thousands of famous brands and public figures have pages populated by content scraped from third-party sites discussing, on the rare occasion when the scraping works, how terrible they are.

When the site emerged in 2020, it was a redirect destination for around 2,000 .sucks domains that exactly matched those brands. You typed jackdaniels.sucks into your browser, you wound up at the Jack Daniels page at Everything.sucks.

Various attempts were made at monetizing these names by persuading the brand owners to purchase or transfer them for fees measured in the hundreds, or more usually thousands, of dollars.

The domains were registered to a Turks & Caicos company called Honey Salt and a likely fictitious individual named Pat Honeysalt or Pat Collins. The registrant has fought 21 UDRP cases, most of which it lost, since July 2020.

There hasn’t been a UDRP complaint filed against a .sucks domain since November 2021, and this may be because most of Honey Salt’s domains were only registered for one year and have since expired and dropped.

Registry transaction reports filed with ICANN by .sucks registry Vox Populi show the registrar Rebel.com — Vox’s sister company and Honey Salt’s registrar of choice — deleted 2,179 .sucks domains in September 2021.

That’s very close to the 2,184 one-year adds Rebel recorded in June 2020.

The most likely interpretation of this data, in my view, is that it’s Honey Salt’s first junk drop — the company let the domains go on expiry having failed to sell them to the brand owners and failed to convince UDRP panels that it wasn’t cybersquatting.

At least couple thousand more .sucks domains were registered via Rebel over the year to June 2021, most likely to Honey Salt, but since then the registrar has been selling no more than two or three new .sucks domains per month.

It looks like Honey Salt stopped buying .sucks domains in bulk several months ago.

And zone files show that the total number of active .sucks domains has continued to decline by the thousands since Vox’s last transaction report, from an August 2021 peak of over 13,000, to fewer than 9,000 today.

If these trends continue, it looks like the experiment in mass cybersquatting might be over by the third quarter, when Honey Salt’s last remaining .sucks domains drop.

UDRP panelists and yours truly have speculated that Vox/Rebel and Honey Salt are probably affiliated, because the registry/registrar are the only parties that stood to benefit from Everything.sucks’ monetization techniques, but Vox has denied a connection.

At ICANN, you can have any registrar you want, as long as it begins with A

Kevin Murphy, February 3, 2022, Domain Registrars

Want to find a registrar based in your home country, or in a friendlier foreign jurisdiction? Don’t rely on ICANN to help.

A recent outcome of the Org’s information transparency car crash is a registrar search engine that only returns filtered results where the registrar’s name begins with the letter A.

The search engine allows users to search for registrars by name, IANA number or the country/territory where the registrar is based. Results can also be filtered alphabetically.

But it’s broken.

If you’re looking for a local registrar, or an overseas registrar, perhaps because you’re concerned about the legal jurisdiction of the company before you register a domain, you might expect the handy drop-down countries menu to bear fruit.

Say you’re looking for an Irish registrar. You select “Ireland” from the drop-down:

ICANN screencap

And the results come back:

ICANN screencap

Oh. According to these results, there are no ICANN-accredited registrars based in Ireland.

But I notice the letter A is highlighted. Perhaps it’s only showing me the registrars beginning with A.

Are there any Irish registrars beginning with B? I’m sure I’ve heard of one, but the name escapes me. I click B:

ICANN screencap

Oh. It’s showing me registrars beginning with B, but they’re not all Irish. The search engine has cleared my original filter.

With B still selected, I filter again by country, and now I’m looking at an empty result set again. There are no Irish registrars beginning with A, ICANN is telling me again.

ICANN screencap

There also doesn’t appear to be a way to filter for registrars that begin with numerals or special symbols, so the likes of 123reg and 101domain appear to be fresh out of luck.

This search engine appears to have been live for about a year, replacing the old flat list, which appears to have been deleted, because that’s how ICANN rolls nowadays.

I don’t know whether it’s been broken the whole time it’s been live, nor whether ICANN knows it’s broken.

Perhaps nobody uses it. It does appear to be the only way to find accredited registrars by country on the ICANN or IANA web sites.

UPDATE Feb 4, 2022: within approximately seven hours, one of the major bugs reported in this post had been fixed. That’s what I call tech support!

Turkish registrar on the naughty step over abuse

Kevin Murphy, February 3, 2022, Domain Registrars

ICANN has issued a public contract breach notice to a Turkish registrar over claims it’s not adequately responding to abuse reports.

Atak Teknoloji showed a “failure to take reasonable and prompt steps to investigate and respond appropriately to reports of abuse” and did not provide ICANN with evidence it responds to abuse reports, ICANN said.

These are violations of the Registrar Accreditation Agreement, the breach notice says.

The registrar is also not offering a port 43 Whois service as required by the RAA, ICANN claims.

Atak isn’t small. It has about 175,000 domains under management in gTLDs, according to registry reports.

It has until February 18 to come into compliance or risk suspension, and has already supplied ICANN with documentation that is now under review.

ICANN hasn’t implemented a policy since 2016

Kevin Murphy, January 31, 2022, Domain Policy

It’s been over five years since ICANN last implemented a policy, and many of its ongoing projects are in limbo.

Beggars belief, doesn’t it?

The ongoing delays to new gTLD program policy and the push-back from ICANN on Whois policy recently got me thinking: when was the last time ICANN actually did anything in the policy arena apart from contemplate its own navel?

The Org’s raison d’être, or at least one of them, is to help the internet community build consensus policies about domain names and then implement them, but it turns out the last time it actually did that was in December 2016.

And the implementation projects that have come about since then are almost all frozen in states of uncertainty.

ICANN policies covering gTLD domains are usually initiated by the Generic Names Supporting Organizations. Sometimes, the ICANN board of directors asks the GNSO Council for a policy, but generally it’s a bottom-up, grass-roots process.

The GNSO Council kicks it off by starting a Policy Development Process, managed by working group stocked with volunteers from different and often divergent special interest groups.

After a few years of meetings and mailing list conversations, the working group produces a Final Report, which is submitted to the Council, and then the ICANN board, for approval. There may be one or more public comment periods along the way.

After the board gives the nod, the work is handed over to an Implementation Review Team, made up of ICANN staff and working group volunteers, which converts the policy into implementation, such as enforceable contract language.

The last time an IRT actually led to a GNSO policy coming into force, was on December 1, 2016. Two GNSO consensus policies became active that day, their IRTs having concluded earlier that year.

One was the Thick WHOIS Transition Policy, which was to force the .com, .net and .jobs registries to transition to a “thick” Whois model by February 2019.

This policy was never actually enforced, and may never be. The General Data Protection Regulation emerged, raising complex privacy questions, and the transition to thick Whois never happened. Verisign requested and obtain multiple deferrals and the board formally put the policy on hold in November 2019.

The other IRT to conclude that day was the Inter-Registrar Transfer Policy Part D, which tweaked the longstanding Transfer Dispute Resolution Policy and IRTP to streamline domain transfers.

That was the last time ICANN actually did anything in terms of enforceable, community-driven gTLD policy.

You may be thinking “So what? If the domain industry is ticking over nicely, who cares whether ICANN is making new policies or not?”, which would be a fair point.

But the ICANN community hasn’t stopped trying to make policy, its work just never seems to make the transition from recommendation to reality.

According to reports compiled by ICANN staff, there are 12 currently active PDP projects. Three are in the working group stage, five are awaiting board attention, one has just this month been approved by the board, and three are in the IRT phase.

Of the five PDPs awaiting board action, the average time these projects have been underway, counted since the start of the GNSO working group, is over 1,640 days (median: 2,191 days). That’s about four and a half years.

Counting since final policy approval by the GNSO Council, these five projects have been waiting an average of 825 days (median: 494 days) for final board action.

Of the five, two are considered “on hold”, meaning no board action is in sight. Two others are on a “revised schedule”. The one project considered “on schedule” was submitted to the board barely a month ago.

The three active projects that have made it past the board, as far as the IRT phase, have been there for an average of 1,770 days (median: 2,001 days), or almost five years, counted from the date of ICANN board approval.

So why the delays?

Five of the nine GNSO-completed PDPs, including all three at the IRT stage, relate to Whois policy, which was thrown into confusion by the introduction of the European Union’s introduction of the GDPR legislation in May 2018.

Two of them pre-date the introduction of GDPR in May 2018, and have been frozen by ICANN staff as a result of it, while three others came out of the Whois EPDP that was specifically designed to bring ICANN policy into line with GDPR.

All five appear to be intertwined and dependent on the outcome of the ICANN board’s consideration of the EPDP recommendations and the subsequent Operational Design Assessment.

As we’ve been reporting, these recommendations could take until 2028 to implement, by which time they’ll likely be obsolete, if indeed they get approved at all.

Unrelated to Whois, two PDPs relate to the protection of the names and acronyms of international governmental and non-governmental organizations (IGOs/INGOs).

Despite being almost 10 years old, these projects are on-hold because they ran into resistance from the Governmental Advisory Committee and ICANN board. A separate PDP has been created to try to untangle the problem that hopes to provide its final report to the board in June.

Finally, there’s the New gTLD Subsequent Procedures PDP, which is in its Operational Design Phase and is expected to come before the board early next year, some 2,500 days (almost seven years) after the PDP was initiated.

I’m not sure what conclusions to draw from all this, other than that ICANN has turned into a convoluted mess of bureaucracy and I thoroughly understand why some community volunteers believe their patience is being tested.

“GDPR is not my fault!” — ICANN fears reputational damage from Whois reform

Kevin Murphy, January 28, 2022, Domain Policy

Damned if we do, damned if we don’t.

That seems to an uncomfortable message emerging from ICANN’s ongoing discussions about SSAD, the proposed Standardized System for Access and Disclosure, which promises to bring some costly and potentially useless reform to the global Whois system.

ICANN’s board of directors and the GNSO Council met via Zoom last night to share their initial reactions to the ICANN staff’s SSAD Operational Design Assessment, which had been published just 48 hours earlier.

I think it’s fair to say that while there’s still some community enthusiasm for getting SSAD done in one form or another, there’s much more skepticism, accompanied by a fear that the whole sorry mess is going to make ICANN and its vaunted multistakeholder model look bad/worse.

Some say that implementing SSAD, which could take six more years and cost tens of millions of dollars, would harm ICANN’s reputation if, as seems quite possible, hardly anyone ends up using it. Others say the risk comes from pissing away years of building community consensus on a set of policy recommendations that ultimately don’t get implemented.

GNSO councillor Thomas Rickert said during yesterday’s conference call:

One risk at this stage that I think we need to discuss is the risk to the credibility of the functionality of the multi-stakeholder model. Because if we give up on the SSAD too soon, if we don’t come up with a way forward on how to operationalize it, then we will be seen as an organization that takes a few years to come up with policy recommendations that never get operationalized and that will certainly play into the hands of those who applaud the European Commission for coming up with ideas in NIS2, because obviously they see that the legislative process at the European and then at the national state level is still faster than ICANN coming up with policies.

NIS2 is a formative EU Directive that is likely to shake up the privacy-related legal landscape yet again, almost certainly before ICANN’s contractors even type the first line of SSAD code.

While agreeing with Rickert’s concerns, director Becky Burr put forward the opposing view:

The flip side of that is that we build it, we don’t have the volume to support it at a reasonable cost basis and it does not change the outcome of a request for access to the Whois data… We build it, with all its complexity and glory, no one uses it, no one’s happy with it and that puts pressure on the multi-stakeholder model. I’m not saying where I come out on this, but I feel very torn about both of those problems.

The ODA estimates the cost of building SSAD at up to $27 million, with the system not going live until 2027 or 2028. Ongoing annual operating costs, funded by fees collected from the people requesting private Whois data, could range from $14 million to $107 million, depending on how many people use it and how frequently.

These calculations are based on an estimated user base of 25,000 and three million, with annual queries of 100,000 and 12 million. The less use the system gets, the higher the per-query cost.

But some think the low end of these assumptions may still be too high, and that ultimately usage would be low enough to make the query fees so high that users will abandon the system.

Councillor Kurt Pritz said:

I think there’s a material risk that the costs are going to be substantially greater than what’s forecast and the payback and uptake is going to be substantially lower… I think there’s reputational risk to ICANN. We could build this very expensive tool and have little or no uptake, or we could build a tool that becomes obsolete before it becomes operational.

The low-end estimates of 25,000 users asking for 100,000 records may be “overly optimistic”, Pritz said, given that only 1,500 people are currently asking registrars for unredacted Whois records. Similarly, there are only 25,000 requests per year right now, some way off the 100,000 low-end ODA assumption, he said.

If SSAD doesn’t even hit its low-end usage targets, the fee for a single Whois query could be even larger than the $40 high-end ODA prediction, creating a vicious cycle in which usage drops further, further increasing fees.

SSAD doesn’t guarantee people requesting Whois data actually get it, and bypassing SSAD entirely and requesting private data directly from a registrar would still be an option.

There seems to be a consensus now that GDPR always requires registries and registrars to ultimately make the decision as to whether to release private data, and there’s nothing ICANN can do about it, whether with SSAD or anything else.

CEO Göran Marby jokingly said he’s thinking about getting a T-shirt printed that says “GDPR was not my fault”.

“The consequences of GDPR on the whole system is not something that ICANN can fix, that’s something for the legislative, European Commission and other ones to fix,” he said. “We can’t fix the law.”

One idea to rescue SSAD, which has been floated before and was raised again last night, is to cut away the accreditation component of the system, which Marby reckons accounts for about two thirds of the costs, and basically turn SSAD into a simplified, centralized “ticketing system” (ironically, that’s the term already used derisively to describe it) for handling data requests.

But the opposing view — that the accreditation component is actually the most important part of bringing Whois into GDPR compliance — was also put forward.

Last night’s Zoom call barely moved the conversation forward, perhaps not surprisingly given the limited amount of time both sides had to digest the ODA, but it seems there may be future conversations along the same lines.

ICANN’s board, which was in “listening mode” and therefore pretty quiet last night, is due to consider the SSAD recommendations, in light of the ODA, at some point in February.

I would be absolutely flabberghasted if they were approved in full. I think it’s far more likely that the policy will be thrown back to the GNSO for additional work to make it more palatable.

No SSAD before 2028? ICANN publishes its brutal review of Whois policy

Kevin Murphy, January 25, 2022, Domain Policy

Emergency measures introduced by ICANN to reform Whois in light of new privacy laws could wind up taking a full decade, or even longer, to bear dead-on-the-vine fruit.

That’s arguably the humiliating key takeaway from ICANN’s review of community-created policy recommendations to create a Standardized System for Access and Disclosure (SSAD), published this evening.

The Org has released its Operational Design Assessment (pdf) of SSAD, the first-ever ODA, almost nine months after the Operational Design Phase was launched last April.

It’s a 122-page document, about half of which is appendices, that goes into some detail about how SSAD and its myriad components would be built and by whom, how long it would take and how much it would cost.

It’s going to take a while for the community (and me) to digest, and while it generally veers away from editorializing it does gift opponents of SSAD (which may include ICANN itself) with plenty of ammunition, in the form of enumerated risk factors and generally impenetrable descriptions of complex systems, to strangle the project in the crib.

Today I’m just going to look at the timing.

Regular DI readers will find little to surprise them among the headline cost and timeline predictions — they’ve been heavily teased by ICANN in webinars for over a month — but the ODA goes into a much more detailed breakdown.

SSAD, ICANN predicts, could cost as much as $27 million to build and over $100 million a year to operate, depending on adoption, the ODA says. We knew this already.

But the ODA contains a more detailed breakdown of the timeline to launch, and it reveals that SSAD, at the most-optimistic projections, would be unlikely to see the light of day until 2028.

That’s a decade after the European Union introduced the GDPR privacy law in May 2018.

Simply stated, the GDPR told registries and registrars that the days of unfettered access to Whois records was over — the records contain personal information that should be treated with respect. Abusers could be fined big.

ICANN had been taken off-guard by the law. GDPR wasn’t really designed for Whois and ICANN had not been consulted during its drafting. The Org started to plan for its impact on Whois barely a year before it became effective.

It used the unprecedented top-down emergency measure of the Temporary Specification to force contracted parties to start to redact Whois data, and the GNSO Council approved an equally unprecedented Expedited Policy Development Process, so the community could create some bottom-up policy.

The EPDP was essentially tasked with creating a way for the people who found Old Whois made their jobs easier, such as intellectual property lawyers and the police, to request access to the now-private personal data.

It came up with SSAD, which would be a system where approved, accredited users could funnel their data requests through a centralized gateway and have some measure of assurance that they would at least be looked at in a standardized way.

But, considering the fact that they would not be guaranteed to have their requests approved, the system would be wildly complex, potentially very expensive, and easily circumvented, the ODP found.

It’s so complex that ICANN reckons it will take between 31.5 and 42 months for an outsourced vendor to build, and that’s after the Org has spent two years on its Implementation Review Team activities.

SSAD timeline

That’s up to almost six years from the moment ICANN’s board of directors approves the GNSO’s SSAD recommendations. That could come as early as next month (but as I reported earlier today, that seems increasingly unlikely).

The ODA points out that this timetable could be extended due to factors such as new legislation being introduced around the world that would affect the underlying privacy assumptions with which SSAD was conceived.

And this is an “expedited” process, remember?

Ten years ago, under different management and a different set of bylaws, ICANN published some research into the average duration of a Policy Development Process.

The average PDP took 620 days back then, from the GNSO Council kicking off the process to the ICANN board voting to approve or reject the policy. I compared it to an elephant pregnancy, the longest gestation period of all the mammals, to emphasize how slow ICANN had become.

Slow-forward to today, when the “expedited” PDP leading to SSAD has so far lasted 1,059 days, if we’re counting from when Phase 2 began in March 2019. It’s taken 1,287 days if we’re being less generous and counting from the original EPDP kicking off.

Nelly could have squeezed out two ankle-nibblers in that time. Two little elephants, one of which would most assuredly be white.

ICANN board not happy with $100 million Whois reform proposals

Kevin Murphy, January 25, 2022, Domain Policy

ICANN’s board of directors has given its clearest indication yet that it’s likely to shoot down community proposals for a new system for handling requests for private Whois data.

Referring to the proposed System for Standardized Access and Disclosure, ICANN chair Maarten Botterman said “the Board has indicated it may not be able to support the SSAD recommendations as a whole”.

In a letter (pdf) to the GNSO Council last night, Botterman wrote:

the complexity and resources required to implement all or some of the recommendations may outweigh the benefits of an SSAD, and thus may not be in the best interests of ICANN nor the ICANN community.

The SSAD would be a centralized way for accredited users such as trademark lawyers, security researchers and law enforcement officers to request access to Whois data that is currently redacted due to privacy laws such as GDRP.

The system was the key recommendation of a GNSO Expedited Policy Development Process working group, but an ICANN staff analysis last year, the Operational Design Phase, concluded that it could be incredibly expensive to build and operate while not providing the functionality the trademark lawyers et al require of it.

ICANN was unable to predict with any accuracy how many people would likely use SSAD. It will this week present its final ODP findings, estimating running costs of between $14 million and $107 million per year and a user base of 25,000 to three million.

At the same time, ICANN has pointed out that its own policies cannot overrule GDPR. Registries and registrars still would bear the legal responsibility to decide whether to supply private data to requestors, and requestors could go to them directly to bypass the cost of SSAD altogether. Botterman wrote:

This significant investment in time and resources would not fundamentally change what many in the community see as the underlying problem with the current process for requesting non-public gTLD registration data: There is no guarantee that SSAD users would receive the registration data they request via this system.

ICANN management and board seem to be teasing the GNSO towards revising and scaling back its recommendations to make SSAD simpler and less costly, perhaps by eliminating some of its more expensive elements.

This moves ICANN into the perennially tricky territory of opening itself up to allegations of top-down policy-making.

Botterman wrote:

Previously, the Board highlighted its perspective on the importance of a single, unified model to ensure a common framework for requesting non-public gTLD registration data. However, in light of what we’ve learned to date from the ODP, the Board has indicated it may not be able to support the SSAD recommendations as a whole as envisioned by the EPDP. The Board is eager to discuss next steps with the Council, as well as possible alternatives to design a system that meets the benefits envisioned by the EPDP

The board wants to know whether the GNSO Council shares its concerns. The two parties will meet via teleconference on Thursday to discuss the matter. The ODP’s final report may be published before then.

ICANN splits $9 million new gTLD ODP into nine tracks

Kevin Murphy, January 20, 2022, Domain Policy

ICANN has added a little more detail to its plans for the Operational Design Phase for the next round of the new gTLD program.

VP and ODP manager Karen Lentz last night blogged that the project is being split into nine work tracks, each addressing a different aspect of the work.

She also clarified that the ODP officially kicked off January 3, meaning the deadline for completion, barring unforeseen issues, is November 3. The specific dates hadn’t been clear in previous communications.

The nine work tracks are “Project Governance”, “Policy Development and Implementation Materials”, “Operational Readiness”, “Systems and Tools”, “Vendors”, “Communications and Outreach”, “Resources, Staffing, and Logistics”, “Finance”, and “Overarching”.

Thankfully, ICANN has not created nine new acronyms to keep track of. Yet.

Pro-new-gTLD community members observing how ICANN’s first ODP, which addressed Whois reform, seemed to result in ICANN attempting to kill off community recommendations may be worried by how Lenzt described the new ODP:

The purpose of this ODP, which began on 3 January, is to inform the ICANN Board’s determination on whether the recommendations are in the best interests of ICANN and the community.

I’d be hesitant to read too much into this, but it’s one of the clearest public indications yet that subsequent application rounds are not necessarily a fait accompli — the ICANN board could still decide force the community to go back to the drawing board if it decides the current recommendations are harmful or too expensive.

I don’t think that’s a likely outcome, but the thought that it was a possibility hadn’t seriously crossed my mind until quite recently.

Lentz also refers to “the work required to prepare for the next round and subsequent rounds”, which implies ICANN is still working on the assumption that the new gTLD program will go ahead.

The ICANN board has give Org 10 months and a $9 million budget, paid out of 2012-round application fee leftovers, to complete the ODP. The output will be an Operational Design Assessment, likely to be an enormous document, that the board will consider, probably in the first half of next year, before implementation begins.