主题
网络资源证据
在主题维度下，网络资源证据主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
DHCP 之前，四个字节先选定语法：RFC 1048 与 BOOTP 的 64 字节边界
无盘工作站开机时，往往连自己的 IP 地址、启动服务器和文件名都不知道。它必须先从网络取得配置，才能真正使用网络。BOOTP 为这个最早的回答留出 64 个字节；RFC 1048 又用开头四个字节告诉机器后面应当怎样读。它解决了表示法，却从未声称能证明回答者可信。
互联网历史
名称就是地址，但它不是路由：RFC 1088 的 IP-over-NetBIOS 映射
1989 年的 RFC 1088 做了一件非常克制的事：把某台 IP-over-NetBIOS 主机的 IP 地址写成固定的 16 字节 NetBIOS 名称 `IP.XX.XX.XX.XX`。每个 `XX` 是地址中一个字节的 ASCII 十六进制表示。这样，发送 NetBIOS 数据报时不必为了得到该名称而查询物理地址。它节省的是一次特定的解析；它没有交付一条路由，没有认证主机，也没有证明任何应用已经收到或接受了数据。
互联网历史
四个字节让 TCP 有了报文边界，却没有重建 OSI 网络：RFC 1006 的 TPKT 边界
发送方可以一次写入一条完整指令，接收方却不应把一次 `read` 当成那条指令。TCP 保证的是连续有序的字节流。RFC 1006 面对 ISO 传输协议需要离散 TPDU 的问题，没有改写 TCP 的承诺，只在流上放置了一个可计数的边界。
案例档案
遗留代码点抵达了客户端，却没有重新授权服务器：RFC 9963
迁移评审中看到 IANA 新增一个代码点，很容易把它读成“旧算法又被允许了”。RFC 9963 的设计恰恰更窄。它为三种遗留 RSASSA-PKCS1-v1_5 签名分配 TLS 1.3 数值，但这些数值只能在服务器通过 `CertificateRequest` 明确提出后，由客户端用于自己的 `CertificateVerify`。它们不能用于服务器签名，默认应关闭，在注册表中也标为不推荐。这是一座只通向客户端的窄桥，不是对遗留 RSA 的全面放行。
案例档案
反向连接已抵达，设备身份仍待验证：RFC 10011
控制器等到了一个反向连接，往往会让人产生一种过早的确定感：设备应当回连，监听器也正为它打开，于是抵达者似乎自然就是那台设备。RFC 10011 和 RFC 8071 的组合恰好说明了为什么不能这样推论。前者让 RESTCONF 客户端、服务器和 Call Home 的配置关系可以用 YANG 表达；后者规定设备可以先发起 TCP。二者都没有说，一次成功抵达的套接字已经证明设备身份、RESTCONF 会话或变更权限。
互联网历史
令牌找到了连接，却没有准入子流：MPTCP 的 MP_JOIN 边界
一个新的 TCP SYN 可以携带一段更早建立的关系：它并非要新建应用会话，而是请求把自己的五元组并入已有的 MPTCP 连接。这个请求若被简化成“连接换了路径”，就会丢掉最要紧的几次判断：查找哪个状态、如何证明仍是原来的对端、谁有权接纳新子流，以及接纳后由什么字段处理数据包。
案例档案
抗量子密钥已经加入，传统收件人仍能打开邮件：RFC 9980
RFC 9980 为 OpenPGP 增加了后量子算法，并定义了把 ML-KEM 与 X25519 或 X448 组合在一起的复合加密密钥。这使迁移有了可互操作的技术基础，却不等于任何带有新密钥的邮件都自动具备抗量子保密性。为不中断通信，发送方可以同时为 PQ/T 密钥和传统密钥加密同一封邮件。RFC 9980 给出的边界非常明确：只有这封邮件所用的每一把收件人密钥都支持 PQ(/T) 加密，才可以说该邮件具有后量子保密性。
IETF
Weiqiang Cheng 与仍需一条路由的 SRv6 定位符租约
T1、T2、首选有效期和有效有效期可以把一份 DHCPv6 租约描述得非常准确，却不能回答路由表里有没有下一跳。RFC 10038 的价值，正是让这两个事实可以连接核验，又不被误写成同一个事实。
报道
LACNIC与超越RIR的转型经济学
真正需要移交的不是一个机构名称，而是四本不能断裂的账：资源、权利、规则与连续性。
互联网历史
横幅圈出了屏幕，却没有制定政策：RFC 933 与 Telnet 输出标记的边界
把安全标记重复塞进每一屏应用输出，既浪费带宽，也迫使服务器猜测远端终端有多大。RFC 933 的选择是让服务器只送一次横幅，由用户端 Telnet 维护版面；这项分工解决了显示问题，却没有把分类、授权和访问控制写进那串 ASCII 字符。
案例档案
模型可以解释网络，却不能授权变更：NEMOPS 与可见性、控制权之间的边界
控制器完成了一次提交，并不等于服务完成了一次安全变更。前者说明某个接口接受了请求；后者要面对客户结果、依赖关系、观测盲区、授权范围和可逆性。RFC 9968 对网络管理提出的要求越成熟，这个差别越不能被一张漂亮的仪表盘掩盖。
案例档案
快速报文维持了会话 Up，却没有授权变更：RFC 9985
RFC 9985 面对的是一个很实际的取舍：BFD 要靠高频控制报文及时发现受监测路径的问题，而每个报文采用同一种高成本认证，可能反过来压缩可承载的会话规模。它把会改变状态的报文与保持既有 `Up` 状态的报文分开处理。前者使用对实现成本更高的 MCI，后者可以使用成本较低的 LCI。这是一套会话保护安排，不是一张允许改路、切流或宣布服务正常的授权书。
互联网历史
NAK 拒绝的是端口，不是数据包：RFC 938 如何划清接收与分派的边界
1985 年的一项实验性协议曾允许接收方同时作出两种并不相同的陈述：它已把一个数据包计入连续接收状态，但该包所指向的本地端口无人认领。RFC 938 将这一响应命名为 `PORT NAK`。它的价值不在于替任何应用宣布失败，而在于拒绝让传输层的收据冒充本地分派决定。
案例档案
OAM 要求写下来了，却不等于诊断已经成立：RFC 9974 与 BIER 证据边界
能力要求可以把工程缺口说清楚；它既不能证明某网络已经具备该能力，也不能替一次测量或生产变更背书。
报道
RIPE 的 RPKI 密钥计划尚不能充当 ROA 范围凭证
RIPE NCC 计划把 RPKI API 密钥转向 OpenID Connect，说明的是未来的访问机制。它尚未构成一份可公开重建的凭证，用以证明某一次 ROA 变更究竟获得了哪一组资源权限，以及执行了哪一种具体操作。
案例档案
签名时间省下了一次传输，却没有证明那个时刻：RPKI、RFC 9589 与切换边界
RRDP 失效时，RPKI relying party 可以转向 rsync，并避免重取已经拥有的对象；但它不能把 CMS 中被签名的时间字段误当作可靠的时间事实。RFC 9589 恰恰为这种克制的切换设计。
互联网历史
UUID 跨过连接，决定权留在原处：RFC 927 的免重复登录交易
用户少输一次密码，不等于目标主机少做一次判断。1984 年的 RFC 927 允许已完成认证的一端送出四个八位组的用户编号，却把是否相信这次认证的权力明确留给接收服务的那一端。
报道
AFRINIC 的 DBWG 有 46 项 Open：计数不是状态路径
把“46 项 Open”放在机构名称后面，很容易让人抢先写出结论。仿佛这个数字天然证明了某种效率、优先级或责任。AFRINIC 在 2026 年 8 月 31 日公开的 Database Working Group（DBWG）概览并不支持这种读法：页面给出的是 83 个工作项、46 项 Open、37 项 Resolved 的有日期快照。它值得认真看，但首先应被当作库存，而不是判决书。
案例档案
四千是前缀声明，不是放宽限流的命令：RFC 9977 的证据边界
一份前缀文件可以让地址分组更精细；它不能把发布者对端站数量的陈述变成服务方必须接受的例外。
报道
LACNIC 的 Bogon 指南有三种数据时钟
同一条 BGP 过滤规则可以产生“未放行”的结果，但这个结果并不自动说明发生了同一种问题。若来源、取数时间和本地处置被压缩成一个数字，读者就失去了判断其含义所必需的时间坐标。