Summary

  • prop-167-v002 contained two outputs: hourly public WHOIS/RDAP usage statistics and a MyAPNIC view showing resource holders queries against their own resources.
  • Resolution 2025-32 endorsed the public statistics. It said cost, resourcing and potential privacy concerns outweighed the immediate benefit of the MyAPNIC function, which the EC did not consider feasible at that time.
  • The public branch is demonstrably implemented. APNIC’s FTP archive begins on 30 June 2026 and its current JSON serves separate RDAP and WHOIS data.
  • The proposal page nevertheless gives the whole proposal one Implemented state. An output-level projection would preserve the EC decision without questioning its authority or treating the second output as a broken promise.

The implementation is not hypothetical. Open APNIC’s public whois-rdap-stats directory and there is a current JSON file, a checksum and a year archive. Open the June archive and the first listed day is 30 June 2026. Hourly compressed files run from 03:00 through 23:00. The current object separates RDAP from WHOIS, defines a one-hour range and reports totals, query types, ASNs and distinct source-IP counts.

That is what successful public infrastructure evidence looks like. A policy output became a running data surface that another operator can retrieve and parse. APNIC’s canonical proposal page records the same date as Implementation Complete and labels the current status Implemented.

Read only that line and the story appears finished. Read the proposal text and the Executive Council minutes, however, and the underlying object has two rows.

Output in prop-167-v002 EC decision on 4 December 2025 Evidence checked in August 2026
Hourly machine-readable public statistics about WHOIS and RDAP usage Endorsed through Resolution 2025-32 Live current JSON and archived hourly files from 30 June 2026
A MyAPNIC feature showing resource holders queries against their allocated resources Not considered feasible at that time, for stated cost, resourcing and potential privacy reasons No checked public source establishes a later decision or implementation

The first row is not weakened by the second. The feed exists. The second row is not a failure inferred from silence. It has an express, time-bounded decision. The documentary problem begins when those different outcomes are projected back into one proposal-level word.

The community text named two products

prop-167-v002 was posted on 21 August 2025. Its problem statement said APNIC had answered approximately 5.5 billion directory queries between 1 April and 30 June 2025, and that RDAP received queries from more than 365,000 unique IP addresses in some hours. Those figures come from APNIC internal data as described by the proposal. They are not a public reconstruction, and they do not identify misuse by any network.

The text sought visibility rather than a verdict. Its public output would report WHOIS and RDAP query counts, source ASNs for at least the top 1,000, source-IP counts per ASN, service and query metadata. Updates would be hourly and machine-readable as JSON or CSV.

Version 2 added a different kind of visibility. A resource holder would enter MyAPNIC and see how often its own IP addresses or ASNs had been queried, broken down by query type and, if possible, source ASN. This was not merely another column in the public file. It implied authenticated presentation, a resource-to-account relationship and handling of data whose privacy consequences could differ from aggregate publication.

APNIC’s impact assessment reflected that difference. It described a method for extracting and publishing public data, on a best-effort basis without an SLA. For the amendment, it said the required logging work in underlying WHOIS systems would be large if feasible. The proposal itself separately named both the publication mechanism and the MyAPNIC extension as implementation work.

The community therefore debated one proposal with two operational products. It reached consensus at APNIC 60 on 11 September 2025. The final comment period ended on 14 October, after which the proposal went to the EC.

Endorsement was a scope decision

APNIC’s Policy Development Process matters here. Maintained consensus does not jump directly into production. The SIG chair asks the EC to endorse the proposal; after endorsement, the Secretariat implements it. The EC’s place in this chain is explicit.

Resolution 2025-32 should therefore not be read as an unauthorised edit that outside observers can reverse by appealing to community intent. It is the public record of how the endorsement stage treated the text.

The resolution endorsed prop-167-v002 with respect to publishing real-time or near-real-time directory-service statistics. It then quoted the MyAPNIC feature and recorded a separate conclusion. Cost, resourcing and potential privacy concerns outweighed the immediate benefit, the EC said, and it did not consider that functionality feasible at that time. The resolution passed unanimously.

Three boundaries follow. First, “with respect to” identifies the scope that advanced. Second, the reasons belong to the EC’s decision and should not be replaced with speculation about budgets or motives. Third, “at this time” dates the conclusion. It does not promise reconsideration, but neither does it establish permanent abandonment.

This is careful governance language. It allows the institution to accept one output without pretending that a technically and institutionally different output carries the same feasibility. A public status system should preserve that care.

A live feed closes the endorsed branch

The APNIC 61 implementation update described prop-167 as in implementation and expected by the end of Q2. Its description focused on machine-readable statistics for interested parties. APNIC’s product-roadmap data later framed the work as implementing the endorsed requirements.

The FTP surface supplies stronger evidence than either plan. Its archive is an observable product. The current JSON carries both protocol families, time ranges and query distributions. It can be downloaded without accepting a narrative about what engineers intended.

The checked files do not establish perfection. They do not prove every hour was continuously available, that every requested interpretation of query method is satisfied or that the best-effort feed has an SLA. Nor does one current sample validate the proposal’s historical 2025 volume figures. Those are separate tests.

But the central implementation claim is no longer open. Public directory-use statistics are being published in structured hourly form. A fair account should say so plainly before asking anything of the landing page.

One page can carry more than one state

The canonical page links v002, reproduces an impact assessment that mentions the MyAPNIC requirement, and says the EC endorsed the proposal on 4 December. It then assigns one current status and one completion event to prop-167 as a whole.

Nothing on that page’s status or history rows tells a reader that the EC resolution separated the outputs. To reconstruct the scope, the reader must find the December minutes, identify Resolution 2025-32, interpret its delimiter and then locate the FTP artifact. The facts are public. The join among them is not.

That distinction is narrower than alleging a false status. If Implemented means “the scope endorsed by the EC has been implemented”, the live feed supports it. If a later reader assumes it means “every output in the consensus text entered production”, the page alone does not correct the assumption.

Proposal state and output state have different cardinality. A page may have one proposal identifier, while the text contains several independently decidable outputs. A single status can summarise those rows, but it should be derived from them rather than erase them.

The second row also needs a neutral vocabulary. Failed would overstate the evidence. Rejected forever would contradict the time boundary. A source-faithful state could say not endorsed at 2025-12-04 or not considered feasible at that time, followed by later reconsideration not stated until another public decision appears.

Preserve the decision, not private query records

The repair does not require APNIC to implement the MyAPNIC feature. It does not require publication of individual queries, source addresses or a resource holder’s authenticated view. Those would raise the very privacy and operational questions the EC identified.

What needs to be public is the decision relationship. A compact implementation-scope projection can sit beneath the proposal history. For each output, it would bind the exact proposal version to community state, EC resolution and disposition. Where endorsed, it would point to the implementation artifact, schema and completion evidence. Where not endorsed, it would preserve the dated reason class and state whether any reconsideration path has later been defined.

Projection field Institutional function
Proposal version and fingerprint Identifies the exact text that reached each stage
Output identifier and source passage Prevents a whole proposal from becoming the smallest decision unit by default
Consensus and final-comment dates Preserves the community state without treating it as implementation authority
EC resolution and output disposition Shows what advanced, what did not and who decided
Artifact, schema and first verified production time Connects an endorsed clause to an observable result
Unendorsed-output state and later trigger Keeps a dated feasibility judgment from becoming an unexplained permanent assumption
Correction or supersession relation Allows later change without rewriting the earlier decision
Derived proposal status Explains what Implemented summarises

This is not a second policy process. It is a projection of the one APNIC already ran. Detailed impact analysis can remain in assessments. Engineering tests can remain protected. The status page only needs enough structure to make the public conclusion reproducible.

What remains unknown

The checked record does not show whether APNIC later analysed a safer or cheaper MyAPNIC design. It does not show a roadmap item, release note or later EC resolution implementing the resource-specific view. It also does not prove that no such private work exists.

There is no evidence here of a resource holder harmed by the absence of the feature, of query data leaked by the public feed or of an APNIC service obligation breached. The proposal’s statements about possible mining and anomalous use are reasons for visibility, not findings against a user or ASN.

The record also does not define how APNIC ordinarily assigns a whole-proposal status after a scoped endorsement. Implemented may be an established convention for the EC-endorsed portion. The recommendation is compatible with that convention: retain the summary, but expose the rows from which it follows.

The completed feed deserves an accurate public ending. So does the output that stopped earlier. One was implemented. One was not considered feasible at that time. The history of prop-167 becomes clearer, not more adversarial, when APNIC lets both statements remain true on the same page.

Sources