Summary

  • ICANN's 28 August notice says IPIP INC.'s Registrar Accreditation Agreement is terminated under section 5.5.4, with the termination becoming effective on 13 September 2026.
  • The stated basis is failure to cure four named breaches by 26 August: RDAP service, registrar-data-escrow deposits, accreditation fees and a homepage link explaining the non-public-registration-data disclosure process.
  • The notice then introduces another set as “additional concerns” and later identifies transition steps, logo revocation and obligations that survive termination. Those categories should not be collapsed into one enlarged breach count.
  • A public issue-disposition table could preserve the authority, evidence, cure request, deadline, response and status of each item without exposing private correspondence or personal data.

A decision on 28 August, an effect on 13 September

The first line of a termination story is often written in the past tense. This one needs two dates.

On 28 August 2026, ICANN sent IPIP INC., IANA registrar number 3774, a notice terminating its 2013 Registrar Accreditation Agreement under section 5.5.4. The same paragraph says the termination “shall become effective” on 13 September, 16 calendar days after the notice, under section 5.6.

The decision exists. Its stated effective date has not arrived. As of this article's 30 August cutoff, that distinction rules out several tempting but unsupported sentences. The public record does not yet identify a gaining registrar, a bulk-transfer date, the number of registrations involved or a completed handoff. It does not show that registrants have lost names. It does not say an arbitration, stay or later cure has occurred.

ICANN's public notices page joins the 5 August breach notice to the 28 August termination. It is an enforcement status record, not proof that every downstream operational step is complete.

The first list names four remaining breaches

The termination notice says IPIP failed to cure the breaches identified on 5 August by the 26 August deadline. It then names four that remained.

First, ICANN says IPIP failed to operate an RDAP Directory Service that returns required registration data for all active gTLD names it sponsors and uses the current implementation guide and response profile. The earlier breach notice says IPIP had registered a base RDAP URL, but ICANN's tested domain queries failed to return registration data.

Second, ICANN says the registrar failed to submit data-escrow deposits on time and in the required schedule, terms and format. Third, it says accreditation fees remained past due. Fourth, it says IPIP did not place a direct link on its homepage to the mechanism and process for requesting disclosure of non-public registration data.

Each item points to a different control surface. RDAP is a public registration-data service. Escrow is a continuity deposit to an approved custodian. Accreditation fees are a contractual payment. The disclosure link is a public intake route required by Registration Data Policy section 10.1. Calling them all “compliance” is accurate at a high level but erases what failed, who relies on it and what cure would demonstrate.

The underlying rules are public. ICANN says the February 2024 gTLD RDAP Profile has been mandatory since 21 August 2025. Its registrar-data-escrow page says the 2025 specification became effective the same day. The Registration Data Policy says the disclosure page must identify the request format, the response method and the anticipated response timeline.

The event-specific findings still belong to ICANN. This article does not independently reproduce IPIP's full sponsored-name set, inspect its escrow account or audit its invoices. The precise formulation is that ICANN found and recorded four remaining breaches.

The second list uses a different noun

After the four-item breach list, the notice changes grammar: “In addition,” it says, IPIP failed to address and resolve “additional concerns.”

The listed matters concern a public abuse-report route, the process for handling and tracking abuse reports, officer names and positions, a correspondence address, deletion and auto-renewal policies, restore fees, renewal-notification methods, and promised remediation measures with implementation dates.

These are not trivial subjects. Several correspond to express RAA information or operational duties. Nor does the label “additional concern” immunise an item from future contractual consequence. But the notice itself does not put them into the preceding sentence that names the four remaining breaches supporting this termination.

That is the reporting boundary. It would be wrong to say the additional matters have no legal relevance. It would also be wrong to retell the document as though ICANN expressly adjudicated every bullet under one enlarged list of termination grounds. The public text made a distinction; a responsible account should preserve it.

The notice also does not rank the four breaches. Section 5.5.4 allows termination when a registrar fails to cure any breach within 21 days after notice. The public document says all four remained, not which one carried the decision or whether ICANN regarded one as independently sufficient. A headline should not manufacture a hierarchy the decision-maker did not publish.

The chronology is evidence of process, not motive

The notices record a long contact trail. In three case chronologies, ICANN describes escalated or successive notices beginning in March and June, rejected email, absent responses, telephone calls and one response it deemed insufficient. On 5 August it issued the formal breach notice and set 26 August as the cure deadline. Courier delivery was confirmed on 7 August. Reminder emails followed on 19 August. On 28 August, ICANN said the required cure had not occurred.

That record supports a bounded claim: ICANN documented notice attempts, a cure period and its assessment of the response state. It does not establish why messages were rejected or unanswered. It does not prove abandonment, insolvency, fraud, a cyber incident or intentional evasion.

The strongest defence of the notice is contractual economy. ICANN does not need to write an essay about every informal exchange in order to exercise a power the registrar agreement expressly supplies. A public enforcement notice also must not expose protected contact details, customer data or internal legal advice.

Economy is not the same as category collapse. The public should still be able to tell an observed issue from a requested answer, a formal breach, an additional concern, a termination consequence and a duty that survives the contract's end.

A third group begins after the decision

The notice next turns from grounds to effects. ICANN says it will follow the De-Accredited Registrar Transition Procedure to move the names managed by IPIP to a qualified accredited registrar. It revokes the ICANN logo licence effective 13 September. It identifies RAA provisions that survive termination, including registration-data retention, fees, dispute resolution and monetary-remedy limits. It also says past-due and specified remaining fees are still payable.

Those statements matter, but they are not extra breaches to add to a total. They answer different questions: what happens to the service portfolio, what branding authority ends, and which contractual obligations outlive accreditation.

BTW already has separate reporting on how ICANN selects a gaining registrar and on why an escrow file is not a functioning customer service operation. Repeating that machinery here would obscure the live news. The present issue is earlier and narrower: whether the public enforcement record lets every sentence keep its legal and operational class.

Publish an issue-disposition table

ICANN's notices page provides a useful case-level status. A compact item-level table would make the record considerably harder to misquote.

Each row should carry an issue identifier; its class; the exact agreement, specification or policy provision; a public evidence source and observation date; the cure or information requested; deadline and extension; response state; disposition at each notice; whether it is a stated ground for the current act; and any public correction, challenge, arbitration or stay.

After termination, the row could name the actor responsible for the next step and its next review date. A formal breach might close, survive as a debt, move into dispute resolution or become irrelevant to the transfer. An additional concern might be answered, formalised later or remain a historical note. The table would show the transition without asking readers to infer it from prose.

Sensitive case evidence can remain protected. The table needs classifications and attributable outcomes, not private mailboxes, personal names, raw logs or legal advice.

The doctrine in Heng Lu's work is useful here only as a discipline: consequential institutional power should be bounded by identifiable authority, evidence, responsibility and review. The contract, not the essay, supplies ICANN's power. The essay explains why the public record should not let that power expand or blur through careless retelling.

The immediate conclusion is therefore modest. ICANN has issued a termination notice to IPIP. Four remaining breaches are named. Other concerns are recorded separately. The effective date is ahead. Accuracy begins by refusing to turn those four sentences into one undifferentiated accusation.

Sources

  1. ICANN — Notice of termination to IPIP INC., 28 August 2026
  2. ICANN — Notice of breach to IPIP INC., 5 August 2026
  3. ICANN — Notices of breach, suspension, termination and non-renewal
  4. ICANN — Registrar Accreditation Agreement and related materials
  5. ICANN — Registration Data Policy
  6. ICANN — gTLD RDAP Profile
  7. ICANN — Registrar Data Escrow Program
  8. ICANN — Contractual Compliance approach and processes
  9. ICANN — Terminating an Accreditation
  10. ICANN — De-Accredited Registrar Transition Procedure
  11. Heng Lu — On When Registry Power Detaches from Liability