Summary

  • APNIC’s 2019 Secretariat report says Resource Quality Assurance was renamed Resource Quality Check to avoid false expectations and legal liability. The newer name accurately limits what observation can prove.
  • APNIC can inspect a global routing-table view, monitor undelegated resources and diagnose selected failure modes. It cannot guarantee how every autonomous network, reputation list or geolocation provider will treat an address block.
  • A useful quality result should travel with its time, vantage point, data source, tested condition and recheck trigger. Without that context, a past observation can be mistaken for a durable property of the address.

The word APNIC deliberately removed

In September 2019, an APNIC Secretariat report gave a short project update with an unusually revealing editorial decision. “Resource Quality Assurance” had become “Resource Quality Check”. The report said the project was renamed to avoid false expectations and legal liability. It also said a disclaimer had been drafted. This was not merely a shorter label. It was an attempt to keep a useful technical service from sounding like a promise it could not control. APNIC Secretariat report

The surrounding description explains the choice. RQC was intended to identify operational issues associated with particular address blocks: route filtering, email and other blacklisting, routing history and geolocation errors. These are real problems. They can make an otherwise valid delegation expensive to use. They also belong to different systems, maintained by different actors, with different update cycles. A route can be visible while mail is rejected. A geolocation database can be wrong while the routing system behaves normally. A block can pass one observer today and encounter an old filter tomorrow.

APNIC repeated the newer name in its activity report at APNIC 49. That report called RQC “Previously RQA”, listed routing status and history, route filtering, blacklists and geolocation errors, and said the functions were included in NetOX. The two reports are publications of the same institution, not independent corroboration, but together they show that the change was deliberate and carried into a public operational account. APNIC 49 activity report

The restraint deserves credit. “Check” describes an act. It invites the next questions: checked when, from where, against which source, and for which failure mode? “Assurance” can be heard as a condition that travels with the resource. The Internet does not offer APNIC the authority needed to make that condition universal.

Three public descriptions, one boundary

APNIC’s current public material presents the boundary at different levels of precision. Its resource-registration overview still says that “APNIC Resource Quality Assurance (RQA)” works to evaluate all address space allocated to APNIC before it is distributed to Members. The navigation on the same page calls the service Resource Quality Check. The coexistence is observable in the captured page; it does not reveal when either sentence was written or who maintained it. Resource registration services

The dedicated RQC page is narrower. It begins with what Members reasonably want: delegated resources that are routable. It immediately adds that APNIC policy does not guarantee that number-resource delegations will be globally routable, though APNIC acts to minimize problems. It then separates historical work from ongoing activity. APNIC says it assessed the usability of IPv4 /8 blocks allocated by IANA before 2011. For ongoing work, it names two acts: monitoring use of undelegated APNIC resources, and checking the global routing table from the APNIC router when making delegations. APNIC says it will not delegate resources that are still being routed. Resource Quality Check

That check answers a consequential question. If the APNIC router still sees a route for a resource that the registry is preparing to delegate, proceeding would expose the future holder to an obvious conflict. Stopping is prudent. But the observation is not the same as an Internet-wide certificate. It says what a named APNIC observation found at a relevant time. It does not say what every route collector, peer, customer, firewall, mail operator or application will do.

The FAQ makes the division explicit. RIRs do not control how network operators administer, route or filter addresses, it says, and no single organization can guarantee routability throughout the Internet. When a holder encounters reachability trouble, APNIC advises diagnosis: ask whether email or particular web services fail, examine announcement practice and upstream relationships, test forward and reverse paths, and use services such as RIS or a looking glass. If a filter is found, the holder must contact the network applying it. The block cannot simply be returned to APNIC because a reachability problem was identified. Resource quality FAQ

These statements are not contradictory. They describe layers. The overview states an institutional aim. The RQC page names a registry-side check. The FAQ locates the remaining control in autonomous networks. The risk appears when the layers are compressed into one context-free label—“quality”—and that label is treated as if it belonged to the address itself.

A pilot prefix carries a date

APNIC’s reachability-testing archive shows why time and method belong beside a conclusion. It describes a procedure used with RIPE NCC: announce pilot prefixes from new blocks, compare their route distribution with ordinary production prefixes, publish daily visibility reports, provide pingable targets and test reachability from the pilot prefixes. Differences could identify ISPs that were still filtering the new block.

The page lists tests from 2010 and 2011 for parts of 1/8, 14/8, 27/8 and other blocks. Some entries name a date range, collaborators and a report. That is good evidence design. A reader can see that a finding arose from a particular experiment rather than from the numerical identity of the prefix. Those historical tests should not be silently represented as the procedure used for every delegation today; APNIC’s current RQC page describes its ongoing work separately. Resource Reachability Testing

The current “Currently Assessing” page preserves another useful distinction. It lists fifteen debogon prefixes and, separately, a set of assessment and report links. It does not publish one universal quality score. Nor does its captured text say that presence or absence on the list guarantees global reachability. A list item is a work object. A dated report is evidence. Neither becomes an eternal attribute merely because the prefix notation stays the same. Currently Assessing

RFC 6441 explains one reason the result can decay. The IETF Best Current Practice advised operators to remove packet and BGP prefix filters based on previously unallocated IPv4 /8s. An operator that instead continued filtering unallocated RIR-managed space would need much more granular filters and daily updates to avoid blocking legitimate traffic. Registry state can change at one institution. The copied filter changes only when its operator updates it. RFC 6441

This is the operational version of a simple governance limit. APNIC can change its ledger, announce a pilot, inspect a route table and contact an organization using undelegated space. It cannot reach into every autonomous system and delete an old access list. It cannot compel a mail reputation service to forget a former user’s behavior on the same address block. It cannot ensure that a geolocation vendor ingests a correction before a customer makes a decision. The registry’s authority is important precisely because it is bounded.

Quality is a bundle of questions

Treating “resource quality” as one property obscures the difference between at least five questions.

First, is the block in the correct registry state, available to be delegated or transferred? That is close to APNIC’s core ledger authority. Second, is an unexpected route visible from the observations used at the decision time? APNIC can make and document that check. Third, do remote networks accept and propagate the intended route? That depends on their policies, sessions and filters. Fourth, do application-layer reputation systems accept traffic or mail from the addresses? Their inputs and appeal paths differ. Fifth, do geolocation providers describe the addresses accurately enough for the holder’s use? That can vary by vendor and date.

A single pass/fail mark cannot say which of these was tested. Worse, it may encourage the wrong operator to act. A route conflict visible before delegation is a reason for APNIC to stop. A stale firewall at a remote ISP is a reason for that ISP to correct its filter. A DNSBL problem belongs with the list maintainer and the affected resource holder. A geolocation error requires evidence suitable for the relevant provider. Escalating every failure to the registry would enlarge its role without giving it the necessary control.

There is also a serious counterargument to demanding elaborate publication. APNIC already disclaims the global guarantee. It publishes test history and practical diagnostic advice. Some operational checks may involve data or topology that should not be exposed. A large certificate could become stale faster than a concise result, and a public score could be gamed or misread. The answer is not to turn RQC into a new approval gate for Internet use.

The modest improvement is to make the scope portable. A quality result can name the resource, the observation interval, the data source and vantage class, the exact condition tested, the supported conclusion, known exclusions, the actor able to remedy a failure and the event that should trigger a recheck. It need not reveal private peers or customer traffic. It need not rank the holder. It merely prevents an observation from losing the information that makes it interpretable.

For example, “no route seen from APNIC’s router at delegation check time” is a strong, bounded statement. It is more useful than “clean”, because it tells a future operator what was actually established. “No listed problem in the checked email-reputation sources at 12:00 UTC” is likewise different from “not blacklisted”. A later failure does not prove the earlier check was false; it may show that the world changed or that another observer had a different view.

Preserve the check, not the promise

The public record examined here establishes no failed APNIC delegation, unreachable Member resource, stale filter, blacklist entry, geolocation error, damaged transfer or product outage. No NetOX session was tested. The evidence does not show which additional internal checks APNIC may perform. The reference to legal liability in the 2019 report is not a legal conclusion for this article. The historical pilot-prefix method cannot be projected onto every current allocation.

What the record does establish is more useful than an accusation. APNIC recognized a category mistake and changed the service’s name. Its dedicated page and FAQ describe a defensible allocation of responsibility: the registry checks what it can observe and acts within its ledger and delegation role; operators control their filters; holders diagnose and pursue the remaining blockers.

The old word survives in broader public copy, where it can still suggest a comprehensive property. Aligning that copy with APNIC’s more careful operational language would not weaken the service. It would preserve the achievement of the 2019 rename. A check is credible when its boundary is visible. Assurance without control is fragile; evidence with a date and an observer can be tested again.

Sources

  1. APNIC: Resource registration services
  2. APNIC: Resource Quality Check
  3. APNIC: Resource quality assurance FAQ
  4. APNIC: Resource Reachability Testing
  5. APNIC: Currently Assessing
  6. APNIC EC minutes and Secretariat report, 9 September 2019
  7. APNIC activity report presented at APNIC 49
  8. RFC 6441 / BCP 171