Summary

  • Andy Clyde told a RIPE 93 panel that his Internet Society/Pulse team uses PeeringDB for analysis and needs data back to 2019 so it can rerun historical work.
  • PeeringDB’s September 2026 API v3 draft sets targets for current data but excludes historical traversals from that clock. It requires a published retention window for older served data without giving its length.

A new API can answer today’s query in a minute and still lose yesterday’s evidence. On the RIPE 93 PeeringDB panel, Andy Clyde approached the proposed v3 from an analyst’s chair. His team’s use is read-only; moving its client might take a couple of weeks, he estimated. The harder request was access to records back to 2019 and permission to reprocess them when an analysis needs another pass.

The official transcript records Clyde asking for more data in the IXP tracker too: traffic, network classifications and dataset types. He acknowledged that some of those fields might sit outside PeeringDB’s remit. He also disliked the maintenance cost of two APIs, for both clients and PeeringDB. That is a different complaint from a router operator’s immediate need for a fresh session record. An analyst cannot reconstruct a six-year comparison from a current snapshot.

PeeringDB’s v3 draft, dated 18 September, proposes a public read-only interface beside v2, incremental sync and daily snapshots. Its target of 99% of current changes visible within a minute explicitly leaves historical traversals out of the freshness measurement. The text says PeeringDB must publish a retention window for older data it serves. It does not name a duration. Existing dump URLs stay as they are under this work.

Clyde’s question is therefore precise: what older record can a researcher fetch, and for how long? A fast present-tense API is useful. A historical series is a separate promise, and the draft has yet to put a number on it.