Summary

  • APNIC marks Prop-167 implemented on 30 June 2026, but its v002 text contains two different visibility products: public service statistics and a per-resource view inside MyAPNIC.
  • The Executive Council endorsed the publication component while saying the member-level view was not feasible at that time. The later status page gives one completion label without a component-by-component receipt.

One status, two ways to see the directory

A resource holder looking at a WHOIS record can see the registration data that APNIC publishes. Prop-167 asked a different question: how often is that record being queried, through which service, and from where? Its version 2 did not propose only a public traffic chart. It paired public usage statistics with a MyAPNIC feature that would let a holder inspect queries against its own allocated addresses or AS numbers.

That distinction matters because the two views expose different things to different readers. Aggregate service statistics could help members and other observers understand the load on WHOIS and RDAP. A resource-level view would answer a narrower operational question for the holder: what attention are my resources receiving? The proposal text included query type and source ASN where possible. These are related outputs, but they are not interchangeable.

APNIC’s impact assessment described a fairly specific public dataset: query counts for WHOIS and RDAP, source ASN for at least the top 1,000 ASNs, a count of source IP addresses per ASN, and metadata such as query type and method. It called for hourly updates in machine-readable JSON or CSV. The assessment also said availability would be best-effort, with no service-level agreement. After the proposal’s second version added the MyAPNIC feature, the assessment said implementation could take more than 12 months if the required work proved possible.

At APNIC 60 in September 2025, Prop-167 reached consensus. Consensus was not the last step. In December, the Executive Council considered the implementation consequences and passed Resolution 2025-32. It endorsed the proposal with respect to publishing real-time or near-real-time directory-service statistics. The same resolution identified the separate MyAPNIC requirement—showing holders how often their resources had been queried, broken down by query type and source ASN if possible—and said cost, resourcing and potential privacy concerns outweighed its immediate benefit.

The Council did not consider that functionality feasible “at this time.”

The public proposal page now lists the current status as “Implemented” and gives 30 June 2026 as the completion date. It does not display separate status lines for the public dataset and the resource-level portal view. That omission is a limit in the public record, not proof that the portal feature is still absent. The Council’s finding was explicitly time-bound; a later implementation could have changed the position. But a single status word does not tell a reader which output was delivered, when it became usable, or what changed after the Council’s decision.

Completion needs a traceable receipt

An implementation record can answer those questions without publishing sensitive query details. For the public stream, a useful receipt would identify the endpoint or downloadable files, the fields and aggregation rules, the last refresh time, and the treatment of source data that could expose individuals or networks. It would also clarify what “best effort” means in practice, since the proposal’s assessment did not promise an availability level.

The member-level function needs its own receipt. If it was later delivered, the record could identify the MyAPNIC feature and explain its access boundary, the resource types covered, the query dimensions shown, and any privacy safeguards. If APNIC decided not to proceed, a dated decision could state whether the function was deferred, withdrawn from the implementation scope, or left for a future policy decision. Those are materially different outcomes. The public materials reviewed here do not resolve which applies.

This is a governance question as much as a product question. A proposal can reach consensus, receive an Executive Council decision, enter a roadmap, and later acquire an “implemented” status. Each step records a different act. A reader should not have to infer from one milestone that every sentence in a multi-part proposal produced a working feature. Nor should an earlier feasibility concern be mistaken for proof that no later work occurred.

The practical test is simple: can a member or outside observer follow each promised output from the policy text to a current, inspectable result—or to a clearly documented decision about its scope? Until that chain is visible, the completion label is informative but incomplete evidence of what resource holders can actually see.

Sources