Summary

  • ICANN's 25 September 2026 notice calls unpaid accreditation fees Netpia.com, Inc.'s fundamental and material breach; it separately deems the registrar noncompliant on RDAP service and a homepage link to its disclosure-request process.
  • The first access door is a public, query-based service for required registration data. The second tells a requester how to seek data that are not public; a visible link does not itself authorize disclosure.
  • ICANN set a 16 October cure deadline and said it may begin termination proceedings if the notice is not satisfied. It has not announced termination in this notice.

Imagine a registrar pays its overdue bill tomorrow. Would a user then be able to retrieve a current registration record? Would an authorized requester know where to submit a case for nonpublic data, what to include and when to expect an answer? A payment receipt cannot answer either question. That is the useful separation in ICANN's 25 September notice to Netpia.com, Inc., the accredited registrar identified as IANA number 130.

The document's legal labels matter. ICANN identifies failure to pay accreditation fees under section 3.9 of the Registrar Accreditation Agreement as the fundamental and material breach. It then says Netpia has been deemed noncompliant in two other areas: the RDAP Directory Service and the direct homepage link to a disclosure-request mechanism. Seven further website and agreement disclosures sit under a heading called “Additional Concerns.” They may need attention, but the notice does not make them interchangeable with its named payment breach.

This article is about whether two different access paths can be made observable, not a new ranking of those enforcement categories.

For the public path, ICANN says Netpia registered rdap.ibi.net as its RDAP base URL but that its Service Level Agreement Monitoring system found intermittent, consistently down results during affected periods. The notice says sponsored-domain queries fail while the service is down. That is ICANN's monitoring finding, not our own uptime measurement; it provides no outage duration or count of affected names. The requested cure is correspondingly specific: show free public query access to up-to-date information for all active sponsored gTLD names, show implementation of the February-2024 RDAP technical and response profiles, and supply a sponsored name for ICANN's monitoring. The profile has been required since August 2025. A single successful lookup would be encouraging but would not by itself demonstrate the required breadth, freshness, profile conformity or service level.

The other path begins before any data are released. Section 10.1 of ICANN's Registration Data Policy requires a direct homepage link to a page explaining how to request disclosure of nonpublic registration data. That page must specify the request's format and content, how a response will be delivered, and the anticipated timeline. ICANN says that information was absent from Netpia's homepage at the notice's observation point. A published link would make the entry route findable; it would not establish that every request merits release.

The policy requires properly formed requests to be considered on their merits and answered, including with reasons for a denial. Public RDAP and private-data requests therefore have different audiences, evidence and privacy boundaries.

The notice gives Netpia until 16 October 2026 to pay, demonstrate RDAP operation and publish the direct disclosure link, alongside other requested information and corrective measures. It says ICANN may commence termination if Netpia does not cure and respond in time. “May” and “if” do real work here: there is no termination in the 25 September document. The chronology records repeated ICANN contacts and some registrar replies that ICANN judged insufficient; it is not accurate to describe the registrar as never having responded.

A defensible cure record would keep three receipts apart: settlement of the contractual debt; timestamped RDAP checks across a specified observation period and sponsored-name sample, with profile version and exceptions; and the public homepage route plus its current request instructions and response channel. That is an editorial way to make the obligations reviewable, not a form ICANN has prescribed. The public version need not expose requesters, private registration records or monitoring credentials. Until the separate evidence exists, economic cure should not be reported as proof that either reader-facing access path has recovered.

Sources