摘要

  • Aftab Siddiqui曾提出APNIC的ROA来源ASN限制方案；担任Routing Security SIG主席期间，他也参与发布了关于服务需求的调查结果。
  • 政策提案有版本、共识、指南和实施状态等公开记录；调查则记录了对ROA通知和API的偏好。调查没有指挥产品发布，也没有证明互联网路由因此更安全。

两条路径，留下不同凭据

区域互联网注册机构可以通过多种方式听取运营者的实际问题。政策提案进入既定程序后，会经过版本修订、公开讨论，并留下社区作出决定的节点。服务调查则主要记录受访者偏好，可供产品团队评估，但并不替产品负责人作出决定。

Aftab Siddiqui的APNIC履历同时出现在这两条路径上。2021年，他提出限制在路由起源授权（ROA）中使用某些自治系统号码（ASN）作为起源ASN。另一个场景中，他以路由安全特别兴趣组（Routing Security SIG）主席身份，参与撰写了有关ROA通知和管理API调查的文章。这些议题都与网络运行有关，但它们经过的制度流程并不相同。

这种区分很重要，因为名录记录和路由状态属于不同环节。API可以让获授权的用户更方便地修改记录；ROA则声明某个自治系统是否获准宣告某个前缀。接下来还需要注册机构发布数据、验证器获取数据，以及各网络根据自己的路由策略处理验证结果。关于管理工具的调查，不能证明这些后续环节已经发生。

章程赋予讨论职责，而不是发布决定权

APNIC 49在2020年的会议报告记载，当时对已有的Routing Security/RPKI SIG进行了主席选举，并讨论名称和章程。社区认可更名后，该组采用Routing Security SIG这一名称并通过章程，Siddiqui当选主席。章程将它界定为讨论运营问题和最佳实践的平台，也包括收集运营者对APNIC服务的反馈，例如RPKI、IRRd和RRDP，并就路由安全政策提案的技术部分提供咨询。

这项职责能搭起一座实用的桥梁：运营者说明服务如何影响日常工作，APNIC团队再评估可行的改进。但它并不授权SIG决定APNIC的产品优先级，也不能承诺何时发布某项功能。Siddiqui在2022年的主席候选人陈述中，也把该组描述为讨论运营问题、增值功能及APNIC可提供支持的渠道。他同时表示，疫情让讨论失去了部分动力。这是他当时的判断，并非对参与度或业绩的独立测量。

2022年一篇APNIC文章进一步说明了下一步由谁负责：服务团队原计划在APNIC 54介绍相关功能的成本与收益。讨论组可以把问题提上议程，是否开发仍须由服务团队评估。

调查数字说明什么，又缺少什么

Siddiqui与Di Ma、Afifa Abbas合著的文章称，调查在2021年10月的公开会议之后进行。对于创建ROA时是否应发送邮件通知，52.4%回答“应该”，33.3%偏好“可选择开启”，9.5%担心通知过多，4.8%认为还需讨论。在支持通知的人中，47.6%偏好webhook，28.6%认为电子邮件足够，23.8%尚不确定。对于通过MyAPNIC或Krill等自托管RPKI软件管理ROA的API，公布的答案为：66.7%赞成、19%反对、14.3%表示可能。

这些比例记录了受访者表达的偏好，但公布文章没有提供分母、答题方式或网络类型分布。因而无法判断有多少人作答，也不能据此推断他们代表APNIC会员、全体运营者或整个地区。这也不是一场路由政策投票：问题针对可能提供的服务功能，且有些回答明确要求继续讨论。

不过，问题本身揭示了不同的操作摩擦。邮件提醒能告知技术联系人某个ROA刚刚创建；webhook可以把事件送入运营者自己的系统；API则可能让重复操作自动化。每种方式改变的是工作流程的一部分。它们都不能单独判断ROA是否正确，也不能决定路由器会如何处置无效路由。

后来的API并不能证明调查促成发布

APNIC在2024年10月宣布Registry API开放使用。它支持查询地址分配信息，也可管理Whois、反向DNS、ROA和路由对象；APNIC表示，API回应了会员的需求，并可将一些原本需要在MyAPNIC手动完成的变更自动化。APNIC 2022年度报告此前已记录原型进入公开测试，生产开发原定于2023年开始。

调查和产品确实有交集：两者都涉及通过API管理注册信息，包括ROA。但这里引用的公开材料没有说2021年的调查启动了API项目，也没有证明调查答题者就是提出产品需求的会员，更没有说SIG决定了产品设计。API后来开放，并不证明答题者已采用它，也不等于路由泄漏或劫持事件减少。

“路由安全”容易把数个不同层级揉成一个词。注册机构提供操作入口，资源持有人修改自己的记录，注册机构发布签名数据，验证器读取这些数据，网络运营者再决定如何使用验证结果。某一层的材料，不应被当成后一层已经发生的证明。

政策提案留下了另一种轨迹

Siddiqui提出的prop-138提供了对照。提案指出，APNIC的ROA管理系统允许使用私有、保留或尚未分配的ASN作为起源，并建议限制此类ROA；第二版还把类似限制扩展到route和route6对象。APNIC公开追踪页记录：提案在2021年8月和9月分别发布版本，在9月16日APNIC 52开放政策会议上形成共识，以指南形式推进，12月发布指南，当前状态为“Implemented”。

与服务调查相比，这是一条更正式的决策记录：规则内容、版本、共识日期以及实施状态均可追踪。但它仍不能说明避免了多少错误对象，或路由风险发生了多大变化。“已实施”说明流程状态，并不是效果评估。

这不是说调查不重要，而是两类产出承担不同功能。政策流程记录提案是否到达社区的正式决策节点；服务调查则帮助服务负责人理解偏好和待解问题。要判断各自的效果，需要寻找对应凭据：规则状态、产品规格和发布记录，以及下游运营数据。

公开记录能说明Siddiqui什么

APNIC 2012年的候选人资料称，Siddiqui当时在巴基斯坦从事网络运营管理，参与IPv6部署、基础设施安全、巴基斯坦IPv6任务组和区域运营者活动。APNIC 2022年的页面则保留了他对SIG主席角色的自述，以及将运营问题与APNIC支持连接起来的意愿。这些有日期的材料说明，他曾处于运营、政策讨论和服务反馈的交界处；它们并不能证明他独自决定该组方向或掌握APNIC系统的发布权。

更稳妥的结论应与证据范围一致。Siddiqui提出了一项可从政策档案中追踪状态的提案，也参与领导一个记录服务偏好并转交服务团队的讨论平台。前者留下共识和实施轨迹；后者提供产品评估所需的信号。之后API开放让议题更具体，但并未补上调查与产品之间缺失的因果链，也没有证明路由安全结果。

来源