APNIC · RIR 观察
报道
与该 RIR 相关的 BTW 报道及背景信息。如需逐项了解各项提案的历史、相关人物及其立场变化，请从“政策”栏目开始。
报道
最新报道
291报道数
报道
APNIC 的 WHOIS 小时档案为同一时段给出两个总数
最新完整小时写着 3,192,583 次 WHOIS 查询；把旁边七种查询类型相加，结果却是 3,183,463。相差 9,120 次并不可怕，可怕的是公开文件没有说明这两个数字各自在数什么。
报道
APNIC领导多样性咨询需要可衡量的参与漏斗
APNIC 已经说明谁参加了第一阶段社区领导多样性咨询，以及参与者提出了哪些障碍。下一步的考验，是在不识别个人贡献者的前提下，把触达、参与、应对措施与更广泛的领导人才管道连接起来。
报道
APNIC 的 NIR SIG 提了四个章程问题，却只公布了一组未注明归属的结果
APNIC 62 会前发布的 NIR SIG 章程审议演示稿，把四个不同问题交给七个国家互联网注册管理机构，却在旁边只放了一张支持率为 86% 的饼图，没有说明这组结果对应哪一问。拟议章程要让该论坛汇总意见并提交 APNIC 执行委员会；在承担这项角色之前，它首先应当让每一组答案都能追溯到原来的问题。
报道
APNIC定义页展示的是草案，官方文本仍为生效版
一份定义文件可以同时有生效版和修订草案，问题不在于“两份”，而在于读者能否在同一个入口看懂两者的关系。APNIC 的 APNIC-080 主页面展示 2026 年的 004 版草案，稳定文本地址仍提供 2023 年的 003 生效版；真正说明哪份文本优先的规则，又写在第三份文件里。
报道
APNIC 的 SIG 在线投票仍以现场签到为参会者门槛
APNIC 62 的 SIG 选举已经在线开票，但“在线”只说明选票如何送达，并不说明谁能取得选票。会员组织通过授权联系人行使一票；个人参会者则必须到孟买现场签到，并有此前八届指定会议之一的参会记录。两条入口是否形成了均衡而可解释的选民结构，应该在投票结束后用汇总数据回答。
报道
APNIC 的 ASPA 列出获授权提供商，并不证明当前上游关系
APNIC 的 ASPA 列出获授权提供商，并不证明当前上游关系 的情报摘要说明事态进展、可核验的公开证据、相关组织、区域背景、市场风险敞口，以及可能带来的基础设施影响。报道情报 语境将这一信号与网络运营、服务商策略、治理决策、资本流动、客户依赖、监管压力、合作关系动向、韧性规划、采购风险和服务连续性联系起来。
报道
APNIC设立了APNIC Foundation联络角色，公开记录却止步于协议之前
治理接口最怕两种误会：有一个角色，就被当成有一套完整规则；能参加沟通，就被当成拥有决策权。APNIC 的公开会议记录其实认真区分了这两件事。它先承认旧联络角色长期缺少清晰范围，随后设立新角色，再把观察员出席、保密和信息共享交给单独协议。这个设计可以很稳健。公开资料缺的不是机密内容，而是协议目前处在哪个状态的一张小回执。
报道
APNIC 同一则付款通知写了 9 月 23 日，也写了 8 月 17 日
维护通知的价值，在于让会员知道何时需要调整安排。APNIC 目前这则在线付款维护通知却给出了两套日期：标题与起止时间指向 2026 年 9 月 23 日，说明文字又写成 8 月 17 日。现有官方材料不足以判断哪一天才是原意，真正需要补上的，是一份能保留修订过程的维护记录。
报道
APNIC 的 NIR RDAP 重定向找到更具体的注册记录，而非网络运营者
APNIC 将查询重定向到国家互联网注册机构的 RDAP 主机，说明的是注册数据从哪里提供。它能找到更具体的记录，却不能证明当下是谁在路由、拥有或运营网络。
报道
APNIC 注册局 API 的批处理结果，没有注明对应哪一项请求
一个批次可以同时提交多项新增、修改和删除；返回结果却只给出 `status` 与 `message`。APNIC 的公开 OpenAPI 没有规定每条结果应如何对应原请求中的具体项目。这里没有已证实的故障，只有一处会把契约成本转嫁给自动化使用者的小缺口。
报道
APNIC Whois 的 mnt-irt 指向事件响应，而非网络控制
一个强制联系人指针，很容易被误读为“谁在运营这张网”。在 APNIC Whois 中，`mnt-irt` 的含义更窄也更实用：它把号码资源记录关联到负责安全事件与滥用报告的 Incident Response Team 对象。这个关联提高了问责可见性，却不能证明谁控制路由器、实际发起 BGP 宣告、承载流量或依法拥有资源。
报道
APNIC 的 API 故障通告并未提及注册管理 API
`api.APNIC.net` 与 `registry-api.APNIC.net` 之间只多了一个连字符和一个限定词。APNIC 在 8 月 5 日的故障通告中写的是前者，并列出五项受影响服务；它公开的注册管理 API 规范使用的却是后者。这个差别不能证明两个服务彼此独立，却足以说明：只写“API”，还没有说明事故触及了哪一种权限。
报道
APNIC 的 RDAP 曾因请求“不像浏览器”拦截约一成流量
一项面向程序的注册信息协议，不应要求程序先把自己打扮成浏览器。APNIC 公开记录的一次 18 小时事故恰好暴露了这条边界：安全防护本身有必要，但客户端长得像什么，不能代替它是谁、为何访问以及是否应获准访问的证据。
报道
APNIC Whois 的 mnt-lower 表示维护者层级，而非路由层级
“lower”这个词很容易让人联想到网络拓扑：上游、下游，以及两者之间传送的数据包。但在 APNIC Whois 中，`mnt-lower` 的含义更窄。它指向注册数据库更新授权结构中的维护者。这是有价值的问责证据，却不是 BGP 或转接关系图。
报道
APNIC上线公开查询账本，但会员视图并未上线
APNIC 上线公开查询账本，但会员视图并未上线 的情报摘要说明事态进展、可核验的公开证据、相关组织、区域背景、市场风险敞口，以及可能带来的基础设施影响。报道情报 语境将这一信号与网络运营、服务商策略、治理决策、资本流动、客户依赖、监管压力、合作关系动向、韧性规划、采购风险和服务连续性联系起来。
报道
APNIC 已建成 RPKI 吊销机制，但行使权限的制度依据仍在追赶
APNIC 表示，prop-166 的技术实施已经完成，但公开记录仍将该政策列为“实施中”，认证实践声明和 RPKI 条款与条件的更新尚未完成。这个差距并非文字细节：该提案拟允许 APNIC 在自托管 RPKI 认证机构持续失效超过 60 天后，吊销其资源证书。
报道
APNIC 统计了 96.9 亿次 DNS 查询，却仍无法确定重试发生在哪一层
APNIC Labs 只改变权威服务器给出的结果，抵达服务器的查询量便随之跨越了不同数量级：保持沉默时，记录接近 97 亿次。这个商数可以复算，但它没有携带重试者的身份证明。若把权威端的总量直接归咎于“递归解析器”，一项重要实验就会越过自身证据的边界。
报道
APNIC prop-175 把 IPv6 需求证明提前到首次申请
APNIC prop-175 拟允许符合资格的机构在首次申请时，就以已经明确的运营需求证明其需要大于 `/48` 的运营商无关 IPv6 地址。该提案目前仍只是在 Policy SIG 邮件列表发布。它试图减少重复程序，但真正的治理考验在于：部署尚未发生时，APNIC 能否像审查既有使用情况那样一致地审查规划证据。
报道
APNIC 的资源质量检查不是地址的固有属性
路由表里的一次干净观测，不会自动改掉远端网络的旧过滤器，也不会让信誉库和地理位置库同步更新。APNIC 早已把“保证”改成“检查”；真正需要随检查结果一起保存的，是时间、观测点和权力边界。
报道
本地提供 DNS 根区，也要支付刷新账单
把根区副本放在递归解析器旁边，会减少对外查询，却不会让网络流量消失。APNIC 最新介绍的一项测量揭示了新的成本位置：流量进入刷新循环，而循环如何运行，比它叫 DNS 还是 HTTPS 更重要。