Summary

  • APNIC prop-173 version 1 would publish separate terms for ordinary directory queries, present them through WHOIS, RDAP and web interfaces, and maintain a policy version, effective date, revision history and archive. It remains a mailing-list proposal, not adopted policy.
  • The proposed response notices identify the policy and its current URL but do not carry the version, effective date or digest that governed a particular result. A compact terms receipt would preserve that temporal join without turning the response into a legal document.

The draft fixes a real ambiguity

The strongest argument for prop-173 is not copyright maximalism. It is legibility. APNIC already publishes an agreement for bulk Whois access, but a person making one ordinary query is not applying for a mirror or a significant extract. The proposal says the bulk instrument does not clearly tell such a user what may be stored, combined, republished or built into another service. A distinct ordinary-query policy is a cleaner way to draw that line.

APNIC's proposal record says version 1 was posted to the Policy SIG mailing list on 17 August 2026. Its current status is “Published to Mailing List.” The checked record has no Secretariat impact assessment, consensus finding, adoption decision or implementation notice. Every operational sentence therefore has to remain conditional: the draft would create the regime; it does not yet establish that APNIC has done so.

The version-one text is unusually specific about scope. It would cover people and systems that access APNIC-authoritative data through WHOIS, RDAP, web search and equivalent registration-data APIs. Mirrored or referred data would remain subject to the authoritative registry's terms. High-volume access, significant extracts and substitute databases would stay in the separate bulk route.

That separation is sensible. It makes ordinary operational and technical research use expressly possible while reserving a different contract for industrial collection. The draft would permit work such as routing-policy evaluation, troubleshooting, abuse response and technical research. It would prohibit uses including marketing lists, systematic harvesting, rate-limit evasion and certain forms of resale or republication. It would also require a review route for a user who believes access was restricted in error.

Those are the questions existing coverage of prop-173 has rightly examined: what the bargain permits, where caching becomes compilation, and how automated enforcement can remain reviewable. A different control appears when the bargain changes over time.

The policy has a version; the response does not

Section 8 of the draft would carry notice into each interface. A WHOIS response would say that APNIC directory data is subject to the acceptable-use policy and that querying or using the service means agreeing to the terms. An RDAP response would include a notice identifying the policy, a link whose relation is terms-of-service, an intellectual-property notice and the current policy URL. A web form would display a link and state that submitting a query and using the result is subject to the policy.

The draft then adds a good operational control: the notice must use a stable, maintained HTTPS URL without redirection. Elsewhere, it says the central policy will have a version number, effective date, revision history and archive of previous versions. APNIC would provide reasonable advance public notice of amendments, and material weakening of protection would return to community consultation.

That is much better than a mutable page with no history. The proposal gives a reader a place to find the current rule and a way, in principle, to inspect older ones. It keeps response payloads short. APNIC can correct or clarify one central document instead of changing text embedded across several protocols. Anyone designing the mechanism should preserve those advantages.

But two things that are separately versioned are not necessarily joined. The response requirements say “the current policy URL.” They do not say that the WHOIS text or RDAP JSON must carry the applicable policy identifier, version, effective date or content digest. If a result is saved on Monday and the policy changes on Friday, the saved result still points to a URL whose current content may now describe Friday's bargain.

An archive can help reconstruct the past if the investigator has an independently trustworthy query time and if version boundaries are exact. A client log may provide that time; a packet capture may; a preserved HTTP header may. But the response itself does not name the document against which its use was conditioned. The gap is a missing join key, not a claim that the archive is useless.

A live response shows the distinction

The captured APNIC RDAP result for 1.1.1.1 is useful as a canary, not as evidence that the proposal has been implemented. It contains a “Terms and Conditions” notice and a link with the terms-of-service relation. It also carries other notices and a self link. What it does not contain is a policy version, a policy effective date or a digest for the terms document.

That single result cannot describe every APNIC endpoint. WHOIS, RDAP, web and other APIs may differ, and their deployment records are not visible in this packet. Nor does the presence of a terms link tell us that the link reflects prop-173. It demonstrates only the response shape at the captured time: a consumer can find a terms destination, but cannot learn from the JSON which revision of that destination governed the response.

The distinction fits the underlying standard. RFC 9083 defines top-level RDAP notices as information about the service or the whole response. A notice must have descriptive text and may contain links. That is enough structure to point to terms and enough flexibility to add a compact receipt. The RFC does not prescribe an APNIC policy-version field, so the governance choice remains with the implementer rather than appearing automatically from protocol compliance.

Bulk restrictions are not the answer to the join

APNIC's bulk Whois agreement restricts reproduction, storage, transmission and onward bulk transfer outside approved purposes. It is relevant because it shows that data-use conditions can have consequences long after retrieval. It is not the document prop-173 wants an ordinary lookup to inherit by accident.

This is why the response-version problem should not be confused with the larger argument over who owns each field. A rights ledger might distinguish registry-authored expression, member-supplied material, mirrored values and facts. A terms receipt answers a narrower question: which policy text did the service invoke for this transaction? It does not prove that every clause is enforceable or every asserted right exists.

The APNIC Privacy Statement adds another reason to be precise. Directory services can expose contact and resource-registration information through Whois and RDAP. A response-linked receipt would not justify a use of that information. It would simply prevent the applicable service rule from drifting away from the record to which it was attached.

Proposal is not policy, and absence is not failure

APNIC's Policy Development Process depends on open discussion and consensus. Version 1 is therefore an invitation to test implementation details, not a finished instruction to operators. The version-receipt issue can be repaired in later text without rejecting the draft's purpose.

The evidence boundary is equally important. No reviewed source identifies a person who relied on one version and was judged under another. There is no enforcement dispute, lost route, failed query, hidden amendment or court finding here. The proposal may be implemented with excellent internal release records. APNIC may be able to reconstruct every applicable version from server logs. The public gap is narrower: the draft does not require the returned record to carry that proof.

Sources

The analysis uses APNIC's prop-173 status page, version-one proposal, bulk Whois agreement, captured RDAP response, Privacy Statement and Policy Development Process, together with RFC 9083. They establish the proposed fields and the observed response shape, not an implemented prop-173 dispute.