主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
案例档案
网址找到了令牌机构，却没有赋予发行者信任
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 揭示的难点在分布式状态：第一条消息仍由旧钥保护，后续流量密钥必须在新钥之下交付，而组播重换钥不会从每个成员那里带回确认。
互联网历史
告警必须等五秒，计数器不必：RFC 1515
同一个以太网介质连接单元可以在五秒内两次进入异常状态。管理端也许只收到一次告警，下一次轮询又已经看见正常；但进入异常状态的累计数仍可能增加两次。1993 年的 RFC 1515 把这三种记录并排保留下来，因为“需要注意”“现在怎样”与“发生过几次”本来就不是同一项事实。
案例档案
证书把用户收窄了，旧服务器却照旧相信请求头
同一张客户端证书，落到两台 RPC 服务器上，可能产生两套权限含义。新草案把一个用户身份写进证书；新节点会拿它覆盖请求头，旧节点却可能忽略这项限制。真正需要审计的不是“证书里有没有”，而是“哪台服务器执行了”。
互联网历史
功能关掉，标准也得照常工作：RFC 1547
在按流量收费的线路上，一枚只为确认“对端还活着”的报文也会进入账单。RFC 1547 从这类不起眼的冲突出发，提出了一条很硬的规则：一端需要某项功能，另一端选择关闭它，双方仍必须留在同一个协议里。
案例档案
VPN 编号到了，准入边界却仍然敞开
RFC 9837 让 IPv6 报文携带一个 32 位 VPN 服务值，用来选择出口 PE 上的 FIB 条目。这个值能说明“往哪里转”，却不能说明“谁有权这样选”。服务选择与 VPN 准入必须各自留下证据。
IETF
CATS给度量清单加了版本，运行时分数却不说明自己依据哪一版
CATS 度量草案第 11 版选择了一条很实际的路：不同厂商先在系统初始化阶段谈妥归一化方法、参数与聚合权重，把结果写进受版本控制的配置清单，运行时不再逐条协商算法。问题不在这项取舍本身，而在取舍成立所需的前提——所有组件当前拿到的必须是同一份清单。新版要求选择器相信这个前提，却没有让度量分数携带或绑定清单身份。
互联网历史
同一块盘，为什么容量表里不是同一个数字：RFC 1514
机房里只有一套存储硬件，监控端却收到几种不同的“容量”：设备有设备的总量，文件系统有自己的边界，应用真正能申请到的空间又少了一截。RFC 1514 没有把这种差异当作需要抹平的噪声，而是把它写成 Host Resources MIB 的结构：先说明数字属于哪一层，再谈数字有多大。
案例档案
电路已经下单，网络里却还没有它
RFC 9833–9836 没有把客户订单、运营商网络对象和实际通流压成一个“已开通”状态。它们用一串明确引用保留了每一层的责任边界：下单成功只是第一张回执，不是网络已经建成的证明。
互联网历史
地址没变，接手的服务器却可以变：RFC 1546
运维记录里，一串多年不变的 IP 地址很容易被写成“那台服务器”。但在 RFC 1546 设想的世界里，这种写法从第一天起就不成立：地址负责把一次请求交给某个能提供服务的成员，却没有承诺下一次仍由它接手。
互联网历史
探针多记了一次资源告急，却不知道漏了多少帧：RFC 1513
计数器从 41 跳到 42，数字干净得像一项确定事实。可若追问“刚才究竟漏掉多少帧”，RFC 1513 的答案是：这个计数器没有回答那道题。它只说明远程监测探针又一次察觉自己资源不足。
互联网历史
TCP 序列号为什么会回到零
TCP 的序列字段长度有限，但字节流仍能保持连续，因为协议把序列空间看作一个环，而不是一条无限延伸的整数线。
IETF
一种意图，两套链路状态语言：RFC 9903 与 OSPF SR-MPLS 控制边界
同一个 SR 意图可以通过共同的 YANG 管理面来管理，但它不会因此拥有相同的线缆表达：OSPFv2 使用 Opaque LSA，OSPFv3 使用 Extended LSA 及其不同的 TLV。RFC 9903 的价值正在于把管理契约统一起来，同时保留两条必须分别核验的协议证据路径。
互联网历史
让 TCP 流量控制运转起来的那个数字
TCP 的 Window 字段把接收许可变成了序列号空间中的移动边界。