摘要

  • RIPE NCC 的 RIPEstat 2026 年第三季度计划称，AS 名称已经加入产品，未来的贡献功能将收集更合用的网络名称；同一计划还提到市场需要知道哪些 ASN 构成一个“逻辑实体”。
  • 网络常用名是面向单个 ASN 的显示判断；逻辑实体分组则是面向一组 ASN 的分析判断。后者可能改变网络数量、规模和集中度的计算，却不因此证明共同所有权或共同控制。
  • 最小而可靠的做法，是把 WHOIS 所示持有人、贡献的常用名、贡献的 ASN 分组三者分栏保存，并为每项判断附上类型、定义、证据、来源身份、有效时间、争议、修订和下游投影记录。

从一行产品计划看三种身份

RIPEstat 的季度计划没有用危言耸听的语言。它说 AS 名称已经添加，BGP Community 的说明将会加入，还计划提供贡献功能，以便收集更好的网络名称。理由很朴素：一个网络的法定名称，可能不同于日常使用的名称。紧接着，计划又写到，人们希望获得关于“哪些 ASN 组成一个逻辑实体”的数据，并准备把这些数据用于 RIPEstat，同时改善公开的 asn.txt 文件。

这两项需求都有现实价值。值班工程师不想在故障时把一家人人都叫作“甲网”的运营网络，反复对应到一个陌生而冗长的公司登记名。研究者也不想因为同一运营网络使用多个 ASN，就在某些统计里把它重复计算数次。社区比正式登记更早知道品牌变更、并购后的常用称呼或实际运营分工，也并不奇怪。

问题不在于应不应该听取社区，而在于贡献进来的是什么。常用名回答“人们怎样称呼这个网络”。分组回答“在某个目的下，哪些 ASN 应被当作一个单位”。一个改变界面上的识别标签，另一个改变分析中的分母。把两者都简称为“名称数据”，就会把方便检索的判断，悄悄升级成关于网络边界的判断。

这种升级不会在数据库里发出警报。它往往发生在最流畅的使用体验中：用户键入品牌，系统返回 ASN；下载者取得一列名称，再按名称合并记录；风险模型把合并后的组当作共同控制；研究报告据此比较规模。每一步单看都很自然，但它们依赖的“同一”可能完全不同。

现有 holder 字段已经给出一条边界

RIPEstat 的 AS Overview 文档把 holder 解释为依据 WHOIS 得到的资源持有人名称。这是一条重要边界，因为它没有承诺显示品牌、最终受益所有人、路由操作团队或所有关联公司。它只说明这个值来自哪一类登记证据。

RIPEstat 的资料来源说明也承认，产品会组合 RIPE NCC 内部来源与外部来源。换言之，RIPEstat 本来就是一个把多种证据呈现在同一工具中的服务，并不需要假装所有字段拥有相同权威。未来的社区常用名或 ASN 分组完全可以进入产品，只要它们没有披上 holder 字段的外衣。

冻结的 AS3333 样本可以说明当前传播路径，但不能被写成故障案例。在抓取时，asn.txt 中的对应行是 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL；AS Overview 的 API 响应给出相同核心持有人名称，不含末尾国家代码，并记录该 ASN 正在宣告。这个例子只证明一项登记名称可以被压缩成文件行和 API 字段，不证明名称错误，也不证明 AS3333 应与别的 ASN 合并。

这份 asn.txt 快照有 6,195,825 字节、122,241 行，而且没有表头。它之所以好用，正是因为简单：下载、搜索、连接都很容易。但简单文件没有足够空间在每一行解释“此名称是 WHOIS 持有人、社区常用名，还是某个分组的显示名”。如果今后输出规则改变，严谨的机器用户必须能在另一个稳定入口查到选择规则和来源。

RIPEstat Data API 的文档还说明，API 是公开数据接口，也是 RIPEstat 自身界面和组件的唯一数据来源。这意味着来源设计不会只停留在后台。一个未标明类型的值进入 API 后，会同时获得产品界面与第三方调用的放大。来源并非脚注，而应当是数据类型的一部分。

常用名的价值，恰恰来自它不必冒充法律事实

假设 WHOIS 持有人是“示例基础设施控股有限公司”，而运营人员几十年来都使用“ExampleNet”。把常用名显示在醒目位置，可以让搜索更快，让故障沟通更准确，也能减少把相似公司误认成同一网络的机会。此时社区贡献是一种低成本、高收益的知识补充。

这项贡献不必背负多余含义。记录可以明确写成：对于 AS X，贡献者建议在运营场景中显示名称 Y，依据是若干公开材料，复核日期为某日。它没有说 Y 是资源持有人，没有说 Y 控制每一条由该 ASN 发出的路由，也没有说 Y 掌握 RPKI 权限或代表法律主体。WHOIS 所示持有人仍然可以并列显示。

一个网络还可能同时拥有多个合理名称：法定名称、商业品牌、历史名称、本地语言名称、面向批发客户的网络名称。产品为了检索可以选取一个首选显示名，却不应抹去其他名称。把常用名视为“可审查的主张”，而不是“唯一正确的替代值”，争议就变得可处理：持有人可以确认或反驳，贡献者可以提供更好证据，新名称可以继承旧名称，而不是把历史从文件中擦掉。

这也是名称贡献最适合社区参与的部分。它可逆、易纠错，对资源权利没有直接影响。如果贡献者类别、证据和时间与名称同行，下游用户可以自行决定信任程度。

“逻辑实体”首先要回答：为了什么逻辑

分组比命名困难，因为已核查的计划没有定义“逻辑实体”。它可能指共同品牌，也可能指共同运营团队、共同母公司、共同路由策略，或者只是在某个 RIPEstat 视图中需要合并观察的网络集合。这些关系经常交叉，却并不相等。

两个 ASN 可以共享品牌但属于不同法人；可以属于同一集团却由不同团队独立操作；可以在迁移期间共享路由策略，迁移结束后再次分离；也可能一个 ASN 承载多个品牌。一家公司收购另一家公司，并不意味着双方 ASN 在当天就成为一个运营网络。反过来，技术上紧密协作也不自动构成共同所有权。

如果研究问题是“一个运营网络用了多少个 ASN”，适当分组可以消除重复计算。如果研究问题是“互联网上存在多少独立路由策略”，相同分组却可能掩盖真实差异。竞争研究者可能把分组理解为经济控制，安全团队可能理解为共同管理，制裁筛查可能理解为同一法律主体。这些更强的结论，都不能从“逻辑实体”四个字自动推出。

因此，分组必须附带用途与范围。例如，“截至 D 日，在某个 RIPEstat 运营视图中，把这些 ASN 视为一组”，与“这些 ASN 具有同一最终受益所有人”是两项不同主张。数据模型应允许前者存在，同时明确阻止界面看起来像是在证明后者。

时间也是分组的一部分。公司会拆分，品牌会出售，网络会迁移，ASN 的用途会改变。若只有当前组、没有生效时间和继承链，后来者就无法还原旧研究当时使用的边界。把今天的分类覆盖到昨天，不是更新，而是无声重写。

三个字段比一个“正确名称”更诚实

最小方案不需要建立庞大的身份数据库，只要先拒绝把三种主张塞进同一个字段。

第一栏是官方持有人：WHOIS 或 RIR 记录在观察时点如何标识资源持有人。它应保留登记来源，但不声称解释所有品牌、运营关系或最终控制。

第二栏是首选网络名：什么名称最便于人们发现和讨论该网络。它需要说明谁提出、依据什么、何时复核、持有人是否回应。它可以比法定名称更实用，却不能静默替换持有人。

第三栏是逻辑分组：在明示定义和用途下，哪些 ASN 构成一个集合。它必须列出成员、定义、证据、有效时间、争议与修订。它不能仅凭共同名称就变成所有权、路由控制、RPKI 授权、RIPE NCC 会员关系、投票权或制裁身份的证明。

界面仍然可以简洁。RIPEstat 可以把常用名放在标题位置，把 holder 放在其下，再提供明确标注的分组视图。复杂性无需强迫每一位普通用户阅读，但必须保存在机器可查的记录里。否则复杂性不会消失，只会被转嫁给每个下载者，由他们各自发明解释。

让贡献记录先写清 claim_type

一条可用的贡献记录，第一项就应说明 claim_type：是 preferred_network_name，还是 logical_asn_group。名称主张的对象是一个 ASN；分组主张的对象是一组明确列出的 ASN。之后才是拟议名称或稳定组标识、贡献者身份与权限类别、引用证据、声明依据、适用范围、有效起点或观察日期、复核状态。

贡献者类别不能被省略。资源持有人自行维护的说明、网络运营人员的贡献、外部研究者的分类、自动模型的推断，都可能有价值，但不能以同一种语气出现。一个“已验证”徽章也必须说清验证了什么：验证账号、验证证据存在、验证持有人确认，还是验证登记事实。模糊徽章很容易让用户误以为社区判断已经成为注册局事实。

冲突不应被清理成唯一答案。两位可信贡献者可能提出不同运营名称；持有人可能反对根据公开路由资料形成的分组；并购期间可能同时存在两个合理视图。系统应保留竞争主张、回应和特定投影采用的选择规则。允许分歧存在，往往比制造一个官方外观的统一身份更可靠。

修订也应是链接，而不是覆盖。新记录取代旧记录时，要说明这是纠正错误、反映后来事件，还是采用另一种分组定义。旧版本必须可重建。否则同一个下载地址在不同时点会表达不同意义，而研究者无法解释自己当时究竟使用了哪种边界。

最后，记录要列出下游去向。只在搜索建议中显示一个常用名，与通过 Data API 输出一个 ASN 组，后果不同；写入 asn.txt 又会影响大量简单脚本。投影范围本身就是治理字段，因为传播越广，含义不清带来的代价越大。

保留 asn.txt 的简单，也保留简单背后的证据

不必为了来源完整性，把每一行 asn.txt 变成庞大的 JSON。平面文本可下载、可 grep、可快速连接的优点值得保留。RIPE NCC 可以增加一个版本化的伴随清单或 API：解释本行选择了哪一类名称、来源是谁、观察时间是什么、哪个记录被继承或修订。

如果文本文件继续只显示每个 ASN 的一个名称，文档应公布投影规则：优先使用 WHOIS holder，还是经过复核的常用名；常用名缺失时如何回退；发生争议时如何处理。若另行发布分组数据，成员关系需要明确时间和定义，不能让用户通过名称相同自行猜测。

这种设计兼顾兼容性。旧脚本仍得到熟悉的简明查找表；需要严谨性的用户则能追溯来源。RIPEstat 界面可以给出干净答案，同时允许读者打开“为什么这样显示”。修订可以改变当前投影，却不会假装以前的值从未存在。

相反，若把登记持有人、社区常用名和分组身份压缩成一个“规范名称”，初期开发看起来省事，后续却很难回答：两个 ASN 为什么被合并？某品牌为何替换了持有人？一篇旧论文使用的是哪个版本？缺失的来源历史，无法靠将来补一个说明页面完整复原。

目前能说的，和不能说的

已核查的公开材料没有说明谁可以贡献、需要什么证据、逻辑实体如何定义、持有人能否确认或挑战、冲突怎样显示、主张多久失效、置信度是否公开、纠错如何传播。也没有展示已上线的贡献界面、数据结构、分组数据集或实施结果。

这些空白不是失职证据。季度计划本来就比成品数据契约短。文章的主张是时序性的：在贡献数据被广泛采用之前，应先公布类型与来源边界；否则用户会从字段位置和 RIPEstat 的产品信誉中自行推断权威。

现有证据同样不能证明当前 RIPEstat 名称错误，不能证明 AS3333 存在争议，也不能证明尚未推出的分组已经误导任何分析。这里提出的是预防性控制：让社区知识顺利进入产品，同时不让便利性抹去登记事实、社区描述与分析分类之间的界线。

来源