Summary

  • APNIC's 22 October account counts 538 ASPA objects under its RPKI trust anchor and advises operators to start path validation while the published set is still manageable.
  • MyAPNIC checks proposed provider-list changes against observed BGP paths before publication; the holder must review the pending change and commit it.

The pile of signed provider declarations is growing faster than a cautious operator can justify saying, “we'll inspect it later.” APNIC's new ASPA FAQ puts 538 objects under its RPKI trust anchor. It also makes a pointed operational argument: as the published population rises, turning on path validation later means finding and correcting more misconfigured objects at once.

An ASPA is an ASN holder's signed account of its authorised upstream providers. Relying networks can use it to examine whether a BGP AS path fits the declared customer-provider relationships. APNIC describes both the object and the validator role on its ASPA service page. A published object is a declaration waiting to be checked; the routing decision remains with each receiving network.

The clock starts before publication. APNIC says MyAPNIC suggests possible providers from observed BGP data and tests an edit against paths currently visible, warning if a proposed change would make an existing route invalid. The holder then finds the edit in a Pending queue, reviews it and clicks Commit. That sequence gives the signer a chance to catch an error while the ink is still wet. It cannot turn every unseen backup arrangement into a path that has been tested.

The FAQ gives a concrete reason to take the list seriously. A missing or mistaken provider entry can cause routes involving the customer's ASN to be treated as invalid once a network uses ASPA validation. APNIC urges early validation because a small population is easier to audit; after validation is running, new errors can be traced back to the issuers who made the changes. The 538-object count marks the growing publication queue. Path checks and corrections are the next shift.

APNIC's RPKI explanation describes upstream and downstream ASPA checks separately, with Valid, Invalid and Unknown outcomes. That distinction matters when an operator decides how to handle a route. The count is on the registry side of the ledger. The safety gain appears only when an ASN holder maintains the right relationships, validators obtain the objects and receiving networks apply a deliberate routing policy. The backlog is the space between those acts.