摘要

  • Andy Clyde 在 RIPE 93 说，Internet Society/Pulse 团队用 PeeringDB 做交换点分析，需要取回 2019 年以来的数据，必要时重新计算。
  • PeeringDB 2026 年 9 月的 v3 草案为最新数据规定时效，却把历史遍历排除在该指标之外；旧数据保留期须公布，具体年限尚未写入。

新 API 的演示通常从“更快”开始。Andy Clyde 在 RIPE 93 的 PeeringDB 圆桌把讨论拉回 2019 年。他的团队做分析，调用是只读的；迁移到草案接口，他估计需要几周。真正难以迁移的是历史：研究者要能取回旧记录，换一种方法再跑一次。

官方逐字稿还记录了 Clyde 对交换点追踪器的数据诉求，包括流量、网络分类和数据集类型。他承认部分内容可能不属于 PeeringDB 的职责。两套 API 并行会增加双方维护成本，但接口成本至少还能估算。缺了一段历史，研究问题本身就没法重复验证。

PeeringDB 9 月 18 日的 v3 草案提出与 v2 并行的公开只读接口、增量同步和每日快照，目标是让 99% 的最新变更在一分钟内可见。这个时效指标明确不计算历史遍历。草案要求公布所提供旧数据的保留窗口，却没有给出期限；现有数据转储地址在这项改动中维持原样。每日快照解决不了“2019 年还能取到什么”的合同问题。

Clyde 要的不是一句长期保存承诺，而是一个能测试的日期边界：研究者最远能回到哪天，明年还能否用同一批记录重跑分析。