行业情报
最新文章
关于基础设施运营商、政策决策、市场动向与数字权力转移的最新情报。
IETF
所有单元格都写着停止：RFC 9906 完成 ECC-GOST 的 DNSSEC 退役
每一个受影响的 ECC-GOST 注册表单元格现在都写着 **MUST NOT**：与 RFC 9905 为 SHA-1 保留兼容性过渡通道不同，RFC 9906 同时关闭生产和验证两条路径，并把执行要求推进到注册表接纳环节。
领导者
Seyed Pouria Mousavizadeh Tehrani 与 IPv6 首次回复前隐藏的状态
稳定的连通性并不能说明首次 IPv6 交互所需的网络状态已经准备就绪。
AFNOG
AfNOG 的 200 个词摘要上限未说明必要信息
AfNOG 2007 年征集页把摘要限制在 200 个词，却没有说明摘要必须证明什么。
互联网历史
当 IPv4 标识不再标识每个数据报
*一个字段仍然存在于每个报头中，并不意味着它对每个数据包都具有相同的语义。*
IETF
停止签名，继续验证：RFC 9905 让 SHA-1 退役呈现非对称路径
RFC 9905 的关键机制很直接：受影响的 DNSSEC 算法行同时禁止新建 SHA-1 材料，却保留验证实现义务。运营者要停止用 RSASHA1 和 RSASHA1-NSEC3-SHA1 生成 DNSKEY、RRSIG 与 DS，同时让递归验证器继续能够验证仍处于安装基础迁移期的旧数据。
互联网历史
附件声明了类型，本机决定了命令：RFC 1524
一封邮件可以把正文标成图像，却没有资格替收件人的电脑指定查看程序。RFC 1524 用一层本地 `mailcap` 规则把这两件事隔开：网络负责传递可互认的名称，本机负责决定这个名称是否、以及如何变成可执行动作。
IETF
四个单元格，一条信任链：RFC 9904 将 DNSSEC 算法政策移入注册表
RFC 9904 并没有改变 DNSSEC 算法编号本身。它改变的是围绕这些编号组织建议、引用权威信息和处理后续更新的方式。一个 DNSSEC 算法编号对应四个分别管理的建议单元格：验证器实现、签名器实现、验证使用和签名使用。理解这四个维度，而不是把它们压缩成一个笼统的“算法状态”，是读懂 RFC 9904 的起点。
互联网历史
消息完整抵达，阅读顺序却仍有三个责任方：RFC 1556
同一封希伯来语与英语混排的邮件，可以在每一跳都保持字节不变，却在两个收件人的屏幕上变成两种句子。RFC 1556 追问的不是字符有没有到，而是到达之后究竟由谁决定它们被人怎样读。
互联网历史
TCP 为什么同时需要结束标记和无操作
TCP 的可变选项区必须让接收方知道哪里停止解析，也必须允许发送方调整后续选项的位置。EOL 与 NOP 分别承担这两个任务。
案例档案
网址找到了令牌机构，却没有赋予发行者信任
ACME 客户端可以沿着一个地址取得 Authority Token，但服务器不能因此就相信令牌的签发者。JWTClaimConstraints 配置文件第 05 版把这条边界写得更清楚：发现位置、配置发行者信任、核对原始字节、绑定账户与证书角色，必须各自留下凭证。
案例档案
共享字典省下了字节，也进入了秘密边界
压缩字典常被归入性能资产，RFC 9841 却揭示了它更深的权力：它的精确字节参与重建内容，也可能通过压缩长度与秘密相互泄露。省带宽之前，系统必须先保存它的身份、来源与使用边界。
报道
LACNIC 的 PAI 客户端文档仍写 Java 8，最新 JAR 却要求 Java 17
README 是写给集成人员看的：Java 8 或更高版本。JAR 里的 class header 是写给 JVM 看的：major version 61，也就是 Java 17。两句话都很明确，问题恰恰在于它们已不再指向同一条运行时下限。
互联网历史
中继器先回复，后重置：RFC 1516
“收到”必须先走出设备，“完成”却要等破坏性动作之后才有资格出现。RFC 1516 没有把这两个时刻揉成一个成功状态：SNMP 回复、硬件重置、健康更新与业务恢复，各自需要自己的见证。
案例档案
解析器接受了字符串，协议仍必须拒绝它
JSON 解析成功，只能说明外层语法可读，不能说明字段里的每一个码点都能成为可互操作文本。RFC 9839 把这两道常被混淆的门重新分开：先解析封装，再决定内容是否准入。
互联网历史
选定下一代协议之前，互联网先问谁要与它共处：RFC 1550
电表和无线链路，比任何候选协议的包头更早出现在 RFC 1550 里。1993 年的这份征集没有急着问谁会赢，而是先让未来承担迁移、运营与安全后果的人说明：新协议必须经受什么。
案例档案
两个实例都是八分，背后的尺子却不是同一把
算力感知流量调度喜欢把 CPU、队列和链路压成一个整数。数字越短，控制器越容易比较；但如果各节点使用不同公式，同一个“八分”只是长得一样。IETF CATS 指标草案第 11 版新增的运行规范，终于把这把隐藏的尺子摆上了台面。
案例档案
成员已经移除，密码学排除仍要完成两次换钥
名册里删除一个成员只需一次写入。RFC 9838 揭示的难点在分布式状态：第一条消息仍由旧钥保护，后续流量密钥必须在新钥之下交付，而组播重换钥不会从每个成员那里带回确认。
报道
APNIC 的 API 故障通告并未提及注册管理 API
`api.APNIC.net` 与 `registry-api.APNIC.net` 之间只多了一个连字符和一个限定词。APNIC 在 8 月 5 日的故障通告中写的是前者，并列出五项受影响服务；它公开的注册管理 API 规范使用的却是后者。这个差别不能证明两个服务彼此独立，却足以说明：只写“API”，还没有说明事故触及了哪一种权限。
互联网历史
告警必须等五秒，计数器不必：RFC 1515
同一个以太网介质连接单元可以在五秒内两次进入异常状态。管理端也许只收到一次告警，下一次轮询又已经看见正常；但进入异常状态的累计数仍可能增加两次。1993 年的 RFC 1515 把这三种记录并排保留下来，因为“需要注意”“现在怎样”与“发生过几次”本来就不是同一项事实。
案例档案
证书把用户收窄了，旧服务器却照旧相信请求头
同一张客户端证书，落到两台 RPC 服务器上，可能产生两套权限含义。新草案把一个用户身份写进证书；新节点会拿它覆盖请求头，旧节点却可能忽略这项限制。真正需要审计的不是“证书里有没有”，而是“哪台服务器执行了”。