主题
软件生命周期与供应商锁定
在主题维度下,软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径,涵盖相关报道、证据来源、市场参与者和基础设施影响,并给出足够背景,帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题,而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道,以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
案例档案
回包只证明这一枚探针抵达,不能替下一份数据报担保:RFC 9869
路径 MTU 不是写在远端主机名上的常数。RFC 9869 让发送端凭匹配令牌确认一件更窄、也更可靠的事:某个指定大小的 UDP Options 探针,在当时沿那条路径到达了接收端。
案例档案
这个位见过选项,却记不住它何时出现、出现几次:RFC 9870
一个位从 0 变成 1,看起来像把事实钉死了。RFC 9870 的确能让 IPFIX 记录某种 UDP 选项在一个 Flow 中至少出现过一次;它同时明确划出边界:包的先后、次数、选项值以及接收端是否处理,都没有装进这个位。

互联网历史
名字服务失灵,代理仍然可以回答:RFC 1419
管理站记得一台设备的名字,也保存着它昨天的地址。今天,名字服务无法再把二者对应起来;旧地址却可能仍能收到 SNMP 请求。它也可能已经属于另一台刚上线的设备。RFC 1419 的价值正在这条窄缝里:缓存可以让运行中的管理系统穿过发现故障,但旧路线不能因此升级成设备身份。

互联网历史
规范说零是 VAR,运行中的代码却把它读成 VALUE:RFC 1408
纠正文档很容易,纠正已经安装在别处的解释却不容易。RFC 1408 给 Telnet 环境变量划定了字节语法:零表示变量名,一区隔变量值。可是它本来要记录的 BSD 参考实现恰好反着使用这两个标记。同一个选项号、同一串字节,从此可以产生两棵不同的语法树。后来的修复没有假装新文字能改写旧程序,而是先为旧分歧设计识别办法,再给确定的未来分配一个新编号。
案例档案
前缀没有错,数据包却走错了出口:RFC 9872
一台设备同时接入两张 IPv6 网络时,“已经发现 PREF64”不是成功条件。RFC 9872 要修补的是前缀值与首跳路由器之间被 DNS 查询丢掉的关系:翻译器属于路径,而不属于一个孤立字符串。

互联网历史
报告数了 56 台路由器,也拒绝把压力案例说成常态:RFC 1266
56 和 49 不是同一事实的两种写法。RFC 1266 先记录七个自治系统里的 56 台 BGP 边界路由器,再把 T3 NSFNET 试验网的七台设备从运行互联网的口径中拿掉,得到六个自治系统、49 台。试验记录仍然有效,却没有借一次加法混进生产记录。
案例档案
响应点名了一个缓存组,但缓存群没有收到统一命令:RFC 9875
源站可以把多个 HTTP 响应标成同一组,并在状态变更后向途经的缓存发出失效信号。RFC 9875 解决的是单个缓存如何理解这层关系,不是如何让整条缓存链同时清除、重新填充并向用户呈现新结果。

全球区域 ISP 趋势
IPv6 重编址:生命周期、DNS 与回滚必须同属一份契约
IPv6 前缀在路由表中几分钟即可切换,但分支机构、递归解析器、应用缓存与既有会话可能仍按旧时钟运行。真正需要审批的,不是新前缀何时发布,而是何时已有足够证据可以放弃旧前缀。
案例档案
包里有两种形态,但还不能算同一把密钥:RFC 9935
一份 ML-KEM 私钥包可以同时装入 64 字节种子和完整解封装密钥。兼容性因此变好,证据义务也随之出现:接收方没有从种子重新展开并逐字节比对以前,只能证明读到了两个值,不能证明它们属于同一把密钥。

互联网历史
网络不必保持节拍,接收端把它重建出来:RFC 1257
一组语音样本可以忽早忽晚地抵达,却仍按原来的间隔播放。RFC 1257 在 1991 年抓住了这道缝隙:网络需要给出足够带宽和最大时延边界,但最终节拍由发送时间戳、接收缓存、共同时间基准和操作系统调度共同完成。
案例档案
哈希很快,真正的控制是碰撞恢复:RFC 9923
FNV 的价值在于用很少的计算把普通输入分散到表中。它没有承诺攻击者也会配合这种分散。RFC 9923 最值得管理层注意的,因而不是“非密码学”这个标签本身,而是当碰撞开始吞噬查询时间时,组织能否看见、换代、重建并证明恢复。
案例档案
图里有这个比特,登记表里却没有:RFC 9927 如何修复 C 标志位
RFC 8928 把 C 标志画在一个紧凑字段的第 3 位,却没有向 IANA 登记。后来,RFC 9685 按程序把同一位置分配给另一个字段。RFC 9927 在尚无已知部署形成兼容负担之前消除了冲突;但规范发布本身不会改写任何固件,也不能证明任何报文被怎样解释。

互联网历史
分析不能代替测试网络:RFC 1245、RFC 1246 与 OSPF 的证据边界
1991 年 7 月,OSPF Version 2 的论证没有被压进一份“已经可用”的说明书里。IETF 把分析与经验拆成两份报告,并另行发布协议规范。这个安排留下了一条重要的工程纪律:模型说明系统为何可能成立,独立实现、测试拓扑和运行网络则说明它在什么条件下真正经受了检验。

创造者
Jakub Kicinski:Linux 如何将网络功能转化为可持续基础设施
一款新网卡可能带着引人注目的功能和紧迫的商业时间表而来。但 Linux 必须提出一个更缓慢的问题:这种能力能否以其他设备也能理解、运营人员可以观测、测试能够复现,并且维护者多年后仍能支持的方式来表达?Jakub Kicinski 的职业经历正建立在这些边界之上。他从 Netronome 的可编程 NFP 硬件走向 Linux 网络的共同维护,展现了代码审查、API 设计和测试基础设施如何在聚光灯之外,决定这一广泛应用的开放操作系统能够负责任地作出什么承诺。

互联网历史
AppleTalk 的 MIB 重画了“谁能改什么”:RFC 1243 与 RFC 1742
管理界面上的一个值,可能是人写进去的,也可能是设备从网络中推断的,甚至可能只是启动时猜出来的。1991 年的 AppleTalk MIB 把这些来源写进模型;1995 年的继任版本又调整了哪些字段可写、哪些只能读取。这段变化说明:看见数值、拥有写入口和证明网络已经改变,是三件不同的事。
案例档案
缓存头说“仍然新鲜”,RFC 9919 要求以签名响应为准
客户端收到一份 OCSP 响应时,真正回答问题的未必是在线响应器。它可能来自本机缓存、代理节点,甚至随 TLS 一同送达。RFC 9919 正是要让这种大规模分发变得可行,但它同时划出一条不能越过的证据边界:HTTP 头可以安排缓存,不能替签名响应决定证书状态是否仍可采用。
案例档案
签名仍然正确,“良好”状态却已过期:RFC 9919
大规模 OCSP 的价值,不在于让每台客户端都实时询问一次,而在于让一份经过授权签名的状态答复可以预生成、缓存和随连接传递。RFC 9919 同时划出不可越过的边界:字节可以复用,状态权威不能越过签名中的 `nextUpdate`。

互联网历史
设备没有丢帧,但其他测试仍未通过:RFC 1242
“零丢帧”很像一句总评,实际上只回答了一条边界。RFC 1242 的重要之处,不是替设备选出一个最漂亮的数字,而是把吞吐、时延、丢帧曲线、连续突发、过载、重启与首帧分别关进各自的证据格子里。数字离开帧长、方向、负载和试验对象,就失去了原来的问题。
案例档案
CA 获得了信任,其他用途的证书也随之进入控制面:RFC 9918
设想一家机构把同一 CA 用于办公终端、监测系统和网络管理。三张证书都能通过链验证,但只有其中一张原本属于 NETCONF。RFC 9918 指出的风险正在这里:信任签发者的范围一旦大于管理用途的范围,密码学上的“有效”就可能把不该进入控制面的证书带进来。

互联网历史
隧道送走了数据包,错误却丢了原问题:RFC 1241
隧道最容易制造一种误会:外层路径通了,内层结果似乎也就有了答案。RFC 1241 在 1991 年已经写出相反的一幕。原始 IP 数据报可以完整地藏进封装空间;可一旦空间内部返回 ICMP 错误,引发错误的内层报头却可能一个字节都没有被带回来。
