Bank spends $800,000 to move from a .bank to the exact-match .com

A small Wisconsin bank has acquired the exact-match .com for its brand for $800,000.

Bank First currently uses a .bank domain, bankfirstwi.bank, but has decided to rebrand to bankfirst.com, CFO Kevin LeMahieu told DI today.

In what many domainers will consider an “upgrade”, the .com was purchased during the fourth quarter from another financial institution.

Its new domain currently redirects to the old .bank domain.

The exact-match .bank domain, bankfirst.bank, belongs to an unrelated Mississippi bank with a similar name. But that company doesn’t use it, preferring instead bankfirstfs.com.

.bank is a tightly restricted and secured gTLD launched in 2015 where domains cost about $1,000 a year. It currently has fewer than 5,000 domains under management.

1 Comment Tagged: .bank, bank first

Battle for .web “far from over”, says Afilias lawyer

Altanovo Domains’ fight with Verisign and ICANN for the .web gTLD is not over, despite an adverse ruling late last month, according to a top lawyer for the company.

Altanovo, the company previously known as Afilias Domains No 3, has not thrown in the towel and left the path clear for Verisign to launch .web, Arif Ali of the law firm Dechert told DI last night.

“Bottom line: this matter is far from over and no, Verisign doesn’t ‘get to run .web after all;’ certainly if the Board does its job objectively and fairly,” he said in an email.

He said this just hours before ICANN published its latest, but by no means final, board resolution on the .web case.

Ali represented Afilias in its Independent Review Process complaint against ICANN’s decision to award .web to Verisign following a 2016 auction, which was won by a company called Nu Dot Co, secretly backed by $135 million of Verisign’s money.

Afilias technically won its IRP, with the panel ruling last May that ICANN broke its bylaws by shirking its duty to address Afilias’ claim that NDC broke new gTLD program rules. Afilias said ICANN should have forced NDC to disclose itself a Verisign pawn before the auction went ahead.

ICANN got close to signing a registry agreement for .web with NDC, despite it being an open question as to whether the auction was legit, the panel ruled. It ordered ICANN to pay Afilias its $450,000 in legal fees and $479,458 of IRP costs.

What the IRP did not do was void the Verisign/NDC bid, nor give Afilias rights to .web.

Instead, it instructed ICANN to stay the .web contract-signing until its board has formally “considered and pronounced upon the question of whether the [Verisign-NDC Domain Acquisition Agreement] complied with the New gTLD Program Rules”.

The board had held a secret, undocumented discussion about the case in November 2016 and decided to keep its mouth shut and just let the IRP play out, according to the IRP ruling, which essentially told the board to stop avoiding difficult questions and to actually make a call on the legitimacy of the Verisign play.

Before the board could do so, Afilias/Altanovo filed an unprecedented appeal with the IRP panel. Technically an “application for an additional decision and interpretation”, Afilias asked the IRP panel to definitively answer the question of whether Verisign broke the rules rather than merely passing the hot potato back to ICANN’s board.

But in a December 21 decision (pdf), the IRP panel denied Afilias’ request as “frivolous” in its entirely, writing:

The Panel has dismissed the [Afilias] Application in its entirety. In the opinion of the Panel, under the guise of seeking an additional decision, the Application is seeking reconsideration of core elements of the Final Decision. Likewise, under the guise of seeking interpretation, the Application is requesting additional declarations and advisory opinions on a number of questions, some of which had not been discussed in the proceedings leading to the Final Decision.

In such circumstances, the Panel cannot escape the conclusion that the Application is “frivolous” in the sense of it “having no sound basis (as in fact or law)”. This finding suffices to entitle the Respondent [ICANN] to the cost shifting decision it is seeking and obviates the necessity of determining whether the Application is also “abusive”.

The panel told Afilias to pay ICANN’s $236,884 legal fees and the panel’s costs of $140,335, leaving Afilias out of pocket and back to square one in terms of getting clarity on whether Verisign’s actions were kosher.

Afilias had basically accused the panel of shirking its duties and punting its decision on Verisign’s auction bid in much the same way as the panel decided that ICANN had shirked its duties and punted its decision on Verisign’s auction bid.

Nobody seems to want to make a call on whether the successful Verisign-NDC ploy to win the .web auction with a secretly bankrolled bid was legit.

On Sunday, the full ICANN board met to discuss the outcome of the IRP and — surprise surprise — it punted again, instructing a subcommittee to look more closely at the matter:

the Board asks the Board Accountability Mechanisms Committee (BAMC) to review, consider, and evaluate the IRP Panel’s Final Declaration and recommendation, and to provide the Board with its findings to consider and act upon before the organization takes any further action toward the processing of the .WEB application(s).

There’s not yet a publicly announced date for the next BAMC meeting. It tends to meet as and when needed, so we might not have too long to wait.

Once the committee has made a decision, it would be referred back to the full board for a final rubber stamp, and it seems that only after that would Afilias make its next move.

Ali, in an email sent to DI just a few hours before ICANN published its Sunday board resolution last night, said:

The [IRP] Panel also made it clear that the Board can’t just punt on the matter as it did previously, but must decide it, and that its decision is subject to review by a future IRP panel.

There’s nothing preventing Afilias filing another IRP to challenge the board’s ultimate decision, should it favor Verisign. Likewise, if it favors Afilias, Verisign could use IRP to appeal.

Verisign has been pursuing a counter-claim against Afilias, albeit so far only in the court of public opinion, accusing the company of breaking ICANN’s rules by trying to secretly “rig” the .web auction during a communications blackout period.

Ali calls this a “red herring”, among other things.

In my view, whichever way ICANN’s board goes, it’s going to wind up back in an IRP.

With IRP proceedings typically measured in years, and no indication that Afilias or Verisign are ready to back down, it seems the .web saga may still have some considerable time left on the clock.

If you’re desperate to register a .web domain, don’t hold your breath.

Note: most of Afilias was acquired by Donuts a year ago, but the .web application was not part of the deal. The IRP proceedings have continued to refer to “Afilias” interchangeably with “Altanovo”, and I’m doing the same in my coverage.

1 Comment Tagged: .web, accountability, afilias, altanovo, auction, ICANN, irp, new gTLDs, verisign

BMW porn site leads to registrar getting suspended

A Hong Kong registrar has had its ICANN contract suspended after failing to transfer a cybersquatted domain to car maker BMW.

ThreadAgent.com, which has about 32,000 .com and .net domains under management, attracted the attention of ICANN compliance after a customer lost a UDRP case concerning the domain bmwgroup-identity.net.

The domain led to a site filled with porn and gambling content, and the UDRP was a slam-dunk win for BMW.

But ThreadAgent failed to transfer the domain to BMW within the 10 days required by ICANN policy, leading to Compliance reviewing the registrar for other areas of non-compliance.

A December 22 breach notice led to the registrar transferring the domain to BMW last week, but it had failed to resolve the other issues ICANN had identified, leading to a suspension notice the very next day.

ICANN wants ThreadAgent to explain why the UDRP was not processed according to the policy, and how it will be compliant in futre. It also says the company is not operating a web Whois service as required.

ICANN has told the company it will not be able to sell gTLD domains or accept inbound transfers between January 28 and April 28, and must display a notice to that effect prominently on its web site.

That second requirement may prove complicated, as ThreadAgent appears to be one of about 20 registrar accreditations belonging to XZ.com, a Chinese group based in Xiamen. It has not used the domain threadagent.com in several years, and its other accreditations, which use the same storefront, are all still unsuspended.

Comment Tagged: bmw, compliance, dotmedia, ICANN, suspension, threadagent, udrp, xz.com

CentralNic grows revenue 70% in 2021

CentralNic saw its revenue grow by about 70% last year, a bit more than half of which was organic growth, the company said this morning.

The acquisitive company expects to report revenue of about $410 million and adjusted EBITDA of about $45 million when it reports its final numbers on February 28.

That represents year-on-year organic revenue growth of 37% and a 47% growth in EBITDA, the company said.

Acquisitions closed during the year include Safebrands, Wando and NameAction. Most of its recent growth has come from its newish domain monetization business.

Comment Tagged: centralnic, financials, revenue

Nightmare downtime weekend for some eNom and Google customers

Some eNom customers have experienced almost two days of downtime after a planned data center migration went titsup, leading to DNS failures hitting what users suspect must have been thousands of domains.

Social media has been filled with posts from customers complaining that their DNS was offline, meaning their web sites and email have been down. Some have complained of losing money to the downtime.

Affected domains include some registered directly with eNom, as well as some registered via resellers including Google Workspace.

The issue appears to have been caused by a scheduled data center migration, which was due to begin 1400 UTC on Saturday and last for 12 hours.

The Tucows-owned registrar said that during that time both reseller hub enom.com and retail site enomcentral.com would be unavailable. While this meant users would be unable to manage their domains, DNS was expected to resolve normally.

But before long, customers started reporting resolution problems, leading eNom to post:

We are receiving some reports of domains using our nameservers which are failing to resolve. Owing to the migration we are unable to research and fully address the issue until the migration is complete. This is not an expected outcome from the migration, and we are working to address it as a priority.

The maintenance window was then extended several times, by three to six hours each time, as eNom engineers struggled to fix problems caused by the migration. eNom posted several times on its status page:

The unexpected extension to the maintenance window was due to data migration delays. We also discovered resolution problems that impact a few hundred domains

eNom continued to post updates until it finally declared the crisis over at 0800 UTC this morning, meaning the total period of downtime was closer to 42 hours than the originally planned 12.

A great many posts on social media expressed frustration and anger with the outage, with some saying they were losing money and reputation and others promising to take their business elsewhere.

Help, it's Monday morning in the UK, I have a team who need to work. I have customers who want to place orders. I have a new partnership in progress which will be ruined at this rate. Please please let us know what is happening. #enom #enomdown @enomsupport

— Karen Burns (@cooper_karen) January 17, 2022

@enom @enomsupport What on the world is going on? Every 3 hours we get another boilerplate message saying “another 3 hours” This is completely unacceptable. How are you going to fix this and how are you going to make people whose work sites have been down all weekend whole?

— Andrew Pershing (@Sci_Officer) January 16, 2022

I almost have begrudging respect for how badly @enom has fucked the pooch with their migration. Blowing up your service so badly that your customers can’t even take their business elsewhere is some galaxy brain shit.

— Keith (@FilthySpecs) January 16, 2022

Same. I'm in a group with 6 other bloggers who also have the same DNS issue. Our sites have been down since yesterday. We're losing ad income & have readers who can't access the information they need.

— Elaina Newton (@TheRisingSpoon) January 16, 2022

Some said that they continued to experience problems after eNom had declared the maintenance over.

@enom your service status website states incorrect status for Google services? My email is still down!!! Also, getting error when logging in to enom domain management console!

— Tomislav Pavosevic (@tompavosevic) January 17, 2022

eNom primarily sells through its large reseller channel, so some customers were left having to explain the downtime in turn to their own clients. Google Workspace is one such reseller that acknowledged the problems on its Twitter feed.

Some customers questioned whether the problem really was just limited to just a few hundred domains, and eNom seemed to acknowledge that the actual number may have been higher.

Looks like one of the most severe internet outages I've seen in years is underway and has not hit MSM yet! @enom, "largest wholesaler of Internet domains" has screwed up a migration and taken possibly up to 2M domains offline.
Certainly my measly 100+ are dead.
See @enomsupport

— 😷Andy Stringer (@AndyStringer) January 17, 2022

At this point, we have been able to track a few hundred. If you have domains that are affected we encourage you to reach out to help@enom.com with the domain(s) in question.

— enomsupport (@enomsupport) January 16, 2022

I’m in contact with Tucows, eNom’s owner, and will provide an update when any additional information becomes available.

1 Comment Tagged: downtime, enom, google, google workspace, migration, tucows

XYZ bosses agree to pay $1.5 million to settle Fed’s loan scam claims

Some of XYZ’s top executives have agreed to pay $1.5 million to settle a US Federal Trade Commission lawsuit alleging they “deceptively” harvested vast amounts of personal data on millions of people and sold it “indiscriminately” to third parties including potential scammers and identity thieves.

The FTC says that the execs, through a network of interlinked companies, deceptively collected loan applications through at least 200 web sites, promising to connect the applicant with verified lenders, but instead sold the personal data willy-nilly to the highest bidder through a lead-generation marketplace.

The data was bought by companies that in the vast majority of cases were not in the business of providing loans, the FTC said. The buyers were not checked out by the XYZ execs and exposed consumers to identity theft and fraud, it added.

The allegations cover activities starting in 2012 and carrying on until recently, the FTC said.

“[They] tricked millions of people into giving up sensitive financial information and then sold it to companies that were not making loans,” Samuel Levine, director of the FTC’s Bureau of Consumer Protection said in a press release. “The company’s extraction and misuse of this data broke the law in several ways.”

“The FTC’s allegations were wholly without merit,” the defendants’ lawyer, Derek Newman, told DI in an email. “But litigation against the FTC is expensive and resource draining. For that reason, my clients chose to settle the case and move on with their business.”

“In fact, the FTC did not require any changes to my clients’ business practices that they had not already implemented before the case was filed,” he added.

The suit (pdf) named as defendants XYZ.com CEO Daniel Negari, COO Michael Abrose, business development manager Jason Ramin, and general counsel Grant Carpenter. Two other named defendants, Anisha Hancock and Sione Kaufusi, do not appear at first glance to be connected to the domains business.

The settlement (pdf) sees the defendants pay $1.5 million and agree to certain restrictions on their collection and use of data, but they did not admit or deny any liability.

The lead generation business was carried out via at least 17 named companies, including XYZ LLC (which appears to be a different company to the .xyz registry, XYZ.com LLC), Team.xyz LLC and Dev.xyz LLC. The FTC complaint groups them together under the name ITMedia.

Some of the companies are successors to Cyber2Media, the FTC said, a company that in 2011 had to settle a massive typosquatting lawsuit filed by Facebook.

Despite the personnel crossover, nothing in the complaint relates directly to the .xyz domains business, and the only domains listed in the complaint are some pretty nice .coms, including badcreditloans.com, personalloans.com, badcredit.com, fastmoney.com and cashadvance.com.

The complaint alleged deceptive representations and unfair distribution of sensitive information as well as violations of the Fair Credit Reporting Act. It reads:

In numerous instances, Defendants, through ITMedia’s actions, have shared and sold sensitive personal and financial information from consumers’ loan forms — including consumers’ full names, addresses, email addresses, phone numbers, birthdates, Social Security numbers, bank routing and account numbers, driver’s license and state identification numbers, income, status and place of employment, military status, homeownership status, and approximate credit scores—without consumers’ knowledge or consent and without regard for whether the recipients are lenders or otherwise had a legitimate need for the information.

Essentially, the complaint alleged that the defendants bullshitted consumers into handing over personal info thinking they were applying for a legitimate loan, when in fact the info was just being harvested for resale to sometimes dodgy buyers.

The complaint reads:

ITMedia’s practice of broadly disseminating consumer information, including to entities that share information with others whose identities and use of the information are unknown to ITMedia, exposes consumers to the risk of substantial harm from identity theft, imposter scams, unauthorized billing, phantom debt collection, and other misuse of the consumers’ information. Some consumers have complained that, shortly after submitting loan applications to ITMedia, they have received communications using the names of ITMedia websites to present sham loan offers or demands for repayment of counterfeit debt.

The $1.5 million settlement will be paid by “Individual Defendants and Corporate Defendants, jointly and severally”, according to court documents.

UPDATE: This article was updated shortly after publication with a statement from XYZ’s lawyer.

Comment Tagged: .xyz, ftc, identity theft, lawsuit, lead generation, new gTLDs, xyz.com

New gTLD pioneer MMX to wind up

MMX, the new gTLD registry also known as Minds + Machines, has decided to close down and de-list.

The company said today that it plans to return its remaining cash to investors through a tender offer and then cancel its remaining shares, which are listed on London’s Alternative Investment Market.

The cancellation plan is subject to shareholder approval at a February 7 general meeting, but the tender does not require approval.

MMX will buy back shares to the tune of £19 million ($26 million) at 10.4 pence per share, a premium of 26.1% on yesterday’s closing price and 24.8% on the last month’s average price.

It follows an $80 million tender offer completed in October.

MMX sold off its major assets — 22 new gTLD registry contracts — to GoDaddy last year in a $120 million deal, and has wound down its legacy registrar businesses.

Now, all that remains is a transition services agreement with GoDaddy, which will soon end.

There had been talk of using the AIM listing as a reverse-takeover vehicle for an operating business seeking quick access to the public markets, but it appears that’s no longer on the table.

If everything goes according to plan, MMX will cease to exist as a public company on February 22. Shareholders have until January 28 to accept the tender offer.

It seems the remaining shareholders will be losing out — if the tender offer is fully subscribed, they’ll only get to sell one share for every 1.485 shares they currently own.

Comment Tagged: acquisition, godaddy, mmx, new gTLDs

ICANN trying to strangle SSAD in the crib?

ICANN is trying to kill off or severely cripple Whois reform because it thinks the project stands to be too expensive, too time-consuming, and not fit for purpose.

That’s what many long-time community members are inferring from recent discussions with ICANN management about the Standardized System for Access and Disclosure (SSAD), a proposed method of normalizing how people request access to private, redacted Whois data.

The community has been left trying to read the tea leaves following a December 20 briefing in which ICANN staff admitted they have failed to even approximately estimate how well-used SSAD, which has been criticized by potential users as pointless, might be.

During the briefing, staff gave a broad range of implementation times and cost estimates, saying SSAD could take up to four years and $27 million to build and over $100 million a year to operate, depending on adoption.

The SSAD idea was thrown together in, by ICANN standards, super-fast time with a super-tenuous degree of eventual consensus by a cross-community Expedited Policy Development Process working group.

One of the EPDP’s three former chairs, Kurt Pritz, a former senior ICANN staffer who’s been heavily involved in community work since his departure from the Org in 2012, provided his read of the December webinar on a GNSO Council discussion this week.

“I’ve sat through a number of cost justification or cost benefit analyses in my life and got a lot of reports, and I’ve never sat through one that more clearly said ‘Don’t do this’,” Pritz said.

GNSO liaison to the Governmental Advisory Committee Jeff Neuman concurred moments later: “It seemed that we could imply from the presentation that that staff was saying ‘Don’t do it’… we should require them to put that in writing.”

“It was pretty clear from the meeting that ICANN Org does not want to build the SSAD. Many people in the community think its estimates are absurdly inflated in order to justify that conclusion,” Milton Mueller of the Internet Governance Project recently wrote of the same webinar.

These assessments seem fair, to the extent that ICANN appears seriously averse to implementing SSAD as the recommendations are currently written.

ICANN repeated the December 20 cost-benefit analysis in a meeting with the GAC this week, during which CEO Göran Marby described the limitations of SSAD, and how it cannot override privacy laws such as the GDPR:

It’s not a bug, it’s a feature of GDPR to limit access to data…

The SSAD is a recommended system to streamline the process of requesting data access. It cannot itself increase access to the data, as this is actually determined by the law. And so, in practice, the SSAD is expected to have little to no impact on the contracted parties’ ultimate disclosure or nondisclosure response to requests… it’s a ticketing system with added functionality.

While Marby stressed he was not criticizing the EPDP working group, that’s still a pretty damning assessment of its output.

Marby went on to reiterate that even if SSAD came into existence, people wanting private Whois data could still request it directly from registries and registrars, entirely bypassing SSAD and its potentially expensive (estimated at up to $45) per-query fees.

It seems pretty clear that ICANN staff is not enthused about SSAD in its current form and there’s a strong possibility the board of directors will concur.

So what does the policy-making community do?

There seems to be an emerging general acceptance among members of the GNSO Council that the SSAD proposals are going to have to be modified in some way in order for them to be approved by the board.

The question is whether these modifications are made preemptively, or whether the GNSO waits for more concrete feedback from Org and board before breaking out the blue pen.

Today, all the GNSO has seen is a few PowerPoint pages outlining the top-line findings of ICANN’s Operational Design Assessment, which is not due to be published in full until the board sees it next month.

Some Council members believe they should at least wait until the full report is out, and for the board to put something on the record detailing its reservations about SSAD, before any changes are made.

The next update on SSAD is an open community session, likely to cover much of the same ground as the GAC and GNSO meetings, scheduled for 1500 UTC on January 18. Details here.

The GNSO Council is then scheduled to meet January 20 for its regular monthly meeting, during which next steps will be discussed. It will also meet with the ICANN board later in the month to discuss its concerns.

1 Comment Tagged: epdp, gac, gdpr, gnso, ICANN, privacy, ssad, whois

ICANN trying to water down its transparency obligations

ICANN? Trying to be less transparent? Surely not!

The Org has been accused by some of its community members of trying to shirk its transparency obligations with proposed changes to its Documentary Information Disclosure Policy.

The changes would give ICANN “superpowers” to deny DIDP requests, and to deny them without explanation, according to inputs to a recently closed public comment period.

The DIDP is ICANN’s equivalent of a Freedom of Information Act, allowing community members to request documentation that would not be published during the normal course of business.

It’s often used, though certainly not exclusively so, by lawyers as a form of discovery before they escalate their beefs to ICANN accountability mechanisms or litigation.

It already contains broad carve-outs that enable ICANN to refuse disclosure if it considers the requested info too sensitive for the public’s eyes. These are the Defined Conditions for Nondisclosure, and they are used frequently enough that most DIDPs don’t reveal any new information.

The proposed new DIDP broadens these nondisclosure conditions further, to the extent that some commentators believe it would allow ICANN to deny basically any request for information. New text allows ICANN to refuse a request for:

Materials, including but not limited to, trade secrets, commercial and financial information, confidential business information, and internal policies and procedures, the disclosure of which could materially harm ICANN’s financial or business interests or the commercial interests of its stakeholders who have those interests.

The Registries Stakeholder Group noted that this is “broader” than the current DIDP, while the At-Large Advisory Committee said (pdf) it “essentially grants ICANN the right to refuse any and all requests”.

ALAC wrote that “rejecting a request because it includes commercial or financial information or documents an internal policy makes a mockery of this DIDP policy”.

Jeff Reberry of drop-catch registrar TurnCommerce concurred (pdf), accusing ICANN of trying to grant itself “superpowers” and stating:

Extremely generic terms such as “confidential business information” and “commercial information” were added. Frankly, this could mean anything and everything! Thus, ICANN has now inserted a catch-all provision allowing it to disclose nothing.

Other comments noted that the proposed changes dilute ICANN’s responsibility to explain itself when it refuses to release information.

Text requiring ICANN to “provide a written statement to the requestor identifying the reasons for the denial” has been deleted from the proposed new policy.

A collection of six lawyers, all prolific DIDP users, put their names to a comment (pdf) stating that “the change results in less transparency than the current DIDP”.

The lawyers point out that requests that are denied without explanation would likely lead to confusion and consequently increased use of ICANN’s accountability mechanisms, such as Requests for Reconsideration. They wrote:

Simply stated, the Revised Policy allows ICANN to obscure its decision-making and will ultimately cause disputes between ICANN and the Internet community — the complete opposite of the “accountable and transparent” and “open and transparent processes” required by ICANN’s Bylaws.

One change that didn’t get much attention in the public comments, but which certainly leapt out to me, concerns the turnaround time for DIDP responses.

Currently, the DIDP states that ICANN “will provide a response to the DIDP request within 30 calendar days from receipt of the request.”

In practice, ICANN treats this obligation like one might treat a tax return or a college essay — it almost provides its response exactly 30 days after it receives a request, at the last possible moment.

The revised DIDP gives ICANN the new ability to extend this deadline for another 30 days, and I don’t think it’s unreasonable to assume, given past behavior, that ICANN will try to exploit this power whenever it’s advantageous to do so:

In the event that ICANN org cannot complete its response within that 30-calendar-day time frame, ICANN org will inform the requestor by email as to when a response will be provided, which shall not be longer than an additional 30 calendar days, and explain the reasons necessary for the extension of time to respond.

The predictably Orwellian irony of all of the above proposed changes is that they come in response to a community review called the Cross-Community Working Group on Enhancing ICANN Accountability Work Stream 2 (WS2), which produced recommendations designed to enhance accountability and transparency.

Whether they are adopted as-is or further revised to address community concerns is up to the ICANN board of directors, which is of course advised by the staff lawyers who drafted the proposed revisions.

ICANN staff’s summary of the seven comments submitted during the public comment period is due next week.

Comment Tagged: accountability, alac, didp, ICANN, rysg, transparency, turncommerce, ws2

A decade after the last new gTLD round, Marby starts the clock on the next one

The next new gTLD application is moving a step closer this month, with ICANN chief Göran Marby promising the launch of its Operational Design Phase.

But it’s still unclear whether the ODP has officially started, and many community members are angry and frustrated that the process is taking too long, some 10 years after the last application window opened.

Marby published a blog post December 20 stating “the org has advised the Board that it is beginning the ODP”, but he linked to a December 17 letter (pdf) that told the board “the org is now transitioning to launch the ODP formally as of January”.

We’re well into January now, so does that mean the ODP has officially started? It’s not clear from what ICANN has published.

It seems either ICANN doesn’t yet want to pin down an exact date for the ODP being initiated, which starts the clock on its deadline for completion, or it’s just really bad at communications.

In September, the board gave Marby $9 million and 10 months for the ODP to come up with its final output, an Operational Design Assessment.

The project is being funded from the remaining application fees from the 2012 application round, rather than ICANN’s regular operations budget.

The text of the resolution gives the deadline as “within ten months from the date of initiation, provided that there are no unforeseen matters that could affect the timeline”.

Assuming the “date of initiation” is some point this month, the ODA would be therefore due to be delivered before the end of November this year, barring “unforeseen matters”.

The document would then be considered by the ICANN board, a process likely to be measured in a handful of months, rather than weeks or days, pushing a final decision on the next round out into the first quarter of 2023.

For avoidance of doubt, that’s the decision about whether or not to even have another new gTLD round.

As a reminder, the 2012 round Applicant Guidebook envisaged a second application round beginning about a year after the first.

Naturally, many would-be applicants are incredibly frustrated that this stuff is taking so long, none more so than the Brand Registry Group, which represents companies that want to apply for dot-brand gTLDs and the consultants that want to help them do so.

Overlapping with ICANN’s December 17 letter to the board, BRG president Karen Day wrote to ICANN (pdf) to complain about the lack of progress and the constant extensions of the runway, saying:

The constant delay and lack of commitment to commencing the next round of new gTLDs is unreasonable and disrespectful to the community that has worked diligently… these delays and lack of commitments to deliver the community’s work is an increasing pattern which risks disincentivizing the volunteer community and threatens the multistakeholder model

Day asked the board to provide more clarity about the ODP’s internal milestones and possible delaying factors, and called for future work to begin in parallel with the ODP in order to shorten the overall roadmap.

It’s worth noting that the ODP may wind up raising more questions than it answers, delaying the next round still further.

It’s only the second ODP ICANN has conducted. The first, related to Whois privacy reform, ended in December (after delays) with a report that essentially shat all over the community’s policy work, predicting that it would take several years and cost tens of millions of dollars to implement for potentially very little benefit.

The board is expected to receive that first ODP’s report in February and there’s no telling what conclusions it will reach.

While Marby has publicly indicated that he’s working on the assumption that there will be another new gTLD round, the ODP gives ICANN a deal of power to frustrate and delay that eventuality, if Org is so inclined.

Comment Tagged: brg, ICANN, new gTLDs, oda, odp, subpro