主题
网络资源证据
在主题维度下，网络资源证据主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
报道
APNIC数清了IDNIC的2,974笔分配，三项已完成NIR审查却没有公开分母
“审查已完成”可以是一项真实、审慎而且干净的结论。但如果这句话没有同时说明审查了多少记录、覆盖什么时期、依据哪一版规则、如何处理假阳性，它就只能证明流程走到了终点，不能让外部读者理解终点的边界。APNIC 已经证明自己能够公布精确分母；现在缺少的不是成员档案，而是一张不泄露成员信息的完成回执。
报道
AFRINIC 现行 RPKI CPS 把其管理区域写成了亚太
AFRINIC 当前资源认证页面仍把读者引向一份 2020 年 5 月发布的 3.0 版认证实践声明。文件第 V.8 节用 AFRINIC 的名称搭配了 APNIC 的服务区域。真正需要修复的不只是一处地名，而是这次修改能否留下版本、授权与回读证据。
互联网历史
名字服务差点成为谈判者：RFC 830 如何拆开域解析与能力选择
一个完整名字最先被处理的，不是最靠近用户的左端，而是最右边的顶级域。RFC 830 让源端服务器沿着层级逐段找到目的域，却在抵达域的服务端点后停了下来：真正要用哪种传输、哪种应用、哪个地址，还要再谈一次。后来成为 DNS 的设计保留了层级，却没有保留这位通用谈判者。
案例档案
每份证据都是真的，拼出的机器却可能不存在：RFC 9999 与远程证明的组合权
一台服务器可以提交 CPU、SmartNIC 与 GPU 三份格式正确、签名有效的证明，仍然没有回答最关键的问题：它们是否来自此刻请求权限的同一台机器。RFC 9999 让异构证明能够被统一封装和转交，但成员绑定、时效判断、可信评估与业务授权仍然各有权责。
案例档案
信封标明了证据，却没有绑定设备：RFC 9999 与证明集合中的权限边界
一台服务器可以把主处理器、SmartNIC 与 GPU 的三份签名报告装进同一个整齐的集合。类型都能识别、签名都能验证、解析器也没有报错，仍然不能证明三份报告属于眼前这台设备、同一次会话和同一条受保护的历史。RFC 9999 解决的是可携带性；它也清楚划出了可携带性不能替代的判断。
报道
AFRINIC 有 3,573 个地址对象指向 Geofeed，数据库却仍没有专用字段
AFRINIC 的 Geofeed 并非不存在，而是藏在备注里。这个兼容方案既合规又被大量采用；真正需要回答的是：当一项机器可读的网络数据依赖数千条“约定俗成的文字”时，谁负责定义格式、写入权限、冲突规则、RDAP 输出和迁移结果？
互联网历史
编号不会让文件变成标准：RFC 825 如何把意图写进记录
一条目录记录保留了“RFC 825”，状态栏却是空的。编号没有错，链接也能打开，但读者已经失去最重要的判断条件：这份文件是在制定规范、发起讨论、提供信息、报告阶段状态，还是记录一次会议？RFC 825 在 1982 年给出的答案很克制——不要让编号承担它没有获得的权力，要让文件先说明自己正在做什么。
报道
RIPE NCC 报告 IPv4 队首已等 467 天，公开队列还缺一张流量账
RIPE NCC 的等待名单同时运行着两只钟：公开表格每三小时刷新一次，8 月会员更新中的队首 LIR 却已经等待 467 天。高频快照能告诉人们队列此刻有多长，却不能解释一个月里有多少申请进入、多少 /24 发放、多少请求撤回。
互联网历史
层不是模块：RFC 817 如何横切协议栈
协议栈图把 IP 画在 TCP 下面，TCP 又画在 Telnet、FTP 和 SMTP 下面。图中的横线回答了协议之间如何提供服务，却没有回答一台正在运行的主机应当在哪里读报头、唤醒进程、维护计时器和移动数据。1982 年的 RFC 817 抓住了这个常被忽略的差别：网络层次是互操作合同，执行模块则是本地成本的分配方式，两者不必沿同一条线切开。
报道
394名支持者不是表决结果：RIPE NCC会员提案的议程门槛需要计算回执
一项会员决议进入表决之前，先要通过另一种计算。RIPE NCC 在 2026 年 5 月要求 394 名会员支持，才把会员提出的决议列入大会日程。这道门槛有清楚而合理的制度目的；目前公开记录欠缺的，是让 394 能够被重新算出的分母快照与支持事件链。
报道
LACNIC 公布了 98% 的外联满意度，却没有公布回复数
LACNIC 称，2025 年的会员见面活动覆盖了 5 个国家、7 座城市和 330 多家组织；在“收到的回复”中，98% 落在最高满意度区间。这个限定写得谨慎，但公开记录仍少了一个决定解释边界的数字：究竟收到多少份回复。
案例档案
两边的地址都没错，重连后却只能留一个：RFC 10019 与零配置组播的冲突裁决权
网络分区会制造两份各自诚实的历史：两边都看不到占用，都分配出可用的组播地址，也都让应用开始发送。链路恢复时，问题不是找出哪一本账造假，而是承认旧观察范围已经失效，并决定谁迁移、怎样迁移，以及用什么证据证明新旧流量没有被混淆。
互联网历史
报错只是建议，不是裁决：RFC 816 如何分层判断故障
邮件正文的每个字节都已被 TCP 确认，收件程序却可能在发出 SMTP 最终确认前崩溃。RFC 816 借这个早期事故说明：传输成功、网络报错、等待超时和业务完成各有边界，任何一层都不能替下一层宣布结果。
报道
ARIN 把 1.7 万个历史网络写进博客，却没有给出完整状态表
ARIN 公开了一组少见的具体数字：数据库中约有 1.7 万个历史网络，大约一半没有联系人或联系人无法核验，当前已验证的仅占 11%，另有 20% 的联系信息不完整。数字本身未被证明有错；真正欠缺的是一张带时间戳的汇总表，用来说明“网络、组织、POC 记录”三种统计单位如何连接。
互联网历史
丢失的报文段没有拦住后来者：RDP 如何把可靠与有序拆开
“已经收到”在网络里从来不只有一种含义。接收端可以确认某个报文段完好到达，却仍缺少它前面的报文段；它可以把这份到达事实告诉发送端，却不一定把数据交给应用；即使交给了应用，也不能据此断言操作已经完成。1984 年的 RDP 把这几层证据明明白白地分开了。
互联网历史
名称不是地址：RFC 814 如何把身份与路径分开
端口 23 曾经可以表示远程登录服务，却不等于“这个流量就是 Telnet”，更不等于“这个进程值得信任”。RFC 814 在 1982 年把这种差别放进一条更长的链：名称回答要找什么，地址回答它接在哪里，路由回答下一步怎么走，端口才在主机内部选择服务。
案例档案
请求签名没坏，证书却可以变：RFC 10002 如何拆开 CMC 的证明与修改权
证书申请系统最危险的误报，往往不是“签名失败”，而是把一串不同主体作出的决定压缩成“已验证”。RFC 10002 展示了另一种更诚实的结构：终端实体保护原始请求，RA 见证身份或密钥占有并在外层提出修改，CA 再依据自己的策略决定最终签发什么。完整性仍在，权力却可能已经换手。
案例档案
探针走了同一条路，却没排同一个队：RFC 10014 与 OAM 的证据边界
业务流遭遇拥塞时，探针完全可能穿过同一组节点和链路，却因为进入了更高优先级的队列而一路畅通。RFC 10014 的价值，是把过去常被“带内 OAM”混在一起的三个事实重新拆开：测量如何参与流量、是否走同一路径、是否受到同样的转发待遇。
互联网历史
确认止于链路：PPP 如何把可靠性限定在本地
1994 年，PPP 获得了一种可选的编号、确认与重传办法。RFC 1663 把这套相邻节点之间的恢复循环写得很精确，也把它的权力边界写得很窄：一份确认可以证明某条链路上的帧推进了，却不能替身份认证、路由连通或应用完成作证。
报道
ARIN把ROA与IRR对象连在一起，可见操作记录却只在ROA一侧
ARIN 的 IRR Auto-Manager 让一次操作可以同时留下两类记录：一份 ROA，以及与它关联的 IRR 路由对象。这项自动化确实减少了重复工作。问题出现在两者后来分开时：公开说明的变更历史能够解释 ROA 发生了什么，却还不能还原生成、关联、保留或删除 IRR 对象的完整操作。