主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
IETF
解析器披露了例外，但没有为答案作保
一种新的 DNS 信号可以告诉客户端：解析器曾对某个名称暂停验证。这份坦白很有价值，却不是答案真实性的印章，也不能替运营方的决定辩护，更不能证明应用最终抵达了安全服务。
IETF
父区承认这里有边界，却没有替私网承诺一条路
一条拟议中的 DNS 约定，让公共父区可以声明某个子区存在于另一套命名空间，同时不虚构任何可从公网抵达的权威服务器。空目标最重要的价值，不是“指向哪里”，而是把父区知道什么、又不知道什么说清楚。
案例档案
签名能证明谁说了什么，却不能替资源服务器决定现在该做什么：RFC 9701
一份 JWT 内省响应可以把授权服务器、接收方和签发时刻牢牢绑定在同一组字节上。它仍只是决策输入：令牌是否适用于本次操作、证明是否抗重放、数据能否披露、请求是否执行成功，都有各自的权力边界。只有逐层保存收据，系统才能说明一次“允许”究竟来自谁，又在哪一层真正生效。
IETF
DNS 响应省掉了梯子，验证责任没有省掉
SigTag 让解析器声明自己已经知道某条带签名的 Merkle Tree Ladder，权威服务器因而可以只返回精简签名。它减少的是重复传输，不是验证环节。缓存是否真实存在、是否绑定正确签名者、失败后怎样取回完整证明，仍需各自留下证据。
案例档案
注册表给格式命名，执行器才决定身体收到什么：RFC 9695
一份触觉文件可以拥有完全正确的媒体类型，也可以被正确交给触觉子系统，却仍在抵达身体之前变成另一种效果。注册表只负责公共名称，解析器、适配器、限幅器和执行器分别拥有后续决定。真正需要治理的，不是斜线左侧的名字，而是从名字到能量输出之间每一次没有被记录的翻译。
IETF
固件清单能签名，目标设备未必认识其中的可选指令
SUIT 更新管理草案的最新修订把一个容易被忽略的问题留给具体部署：向某批设备投递之前，谁能证明它们实现了清单所依赖的可选扩展？签名有效与设备具备相应能力，是两项不同的判断。
案例档案
后继密钥等满了三十天，验证器却没有共用一只时钟：RFC 9691
运营看板上的第 30 天已经到了，验证器群体里却可能同时存在第 30 天、第 12 天、刚刚开始和从未计时四种状态。RFC 9691 给 RPKI 信任锚换钥提供了严谨路径，但它没有把分散运行的依赖方变成一台同步机器。
案例档案
证书里有密钥，不等于接收方已经点头：RFC 9690
证书可以证明“这是一把怎样的 RSA 公钥”，却未必回答“接收方今天是否愿意用这把钥匙接收 RSA-KEM”。RFC 9690 把这条常被自动化系统抹平的边界写得很清楚：密钥标识、能力声明、具体算法组合和实际解封装，必须分别留证。
IETF
LAKE 的 AuthKEM 新稿删去“四条消息换取身份暴露”的捷径
设备握手少走一步，代价可能是把谁在发起连接提前告诉旁观者。IETF LAKE 工作组 9 月 28 日的 AuthKEM 修订稿不再保留这种四消息变体，而是把五条消息列为必经流程；但这仍是草案，不是已经落地的安全承诺。
案例档案
一条 LSP 穿过两套控制平面：RFC 9689 的迁移代理边界
凌晨割接结束后，Node3 同时背着两本账：向左，它仍要解释 LDP 或 RSVP-TE 的信令状态；向右，它又要承接 PCECC 下发的逐节点标签指令。数据包看到的也许是一条连续路径，运维团队面对的却不是一笔连续交易。
IETF
服务器把文件标为不可缓存，客户端仍须真正照做
NFSv4.2 即将获得一种标准信号：服务器可以告诉客户端，某个文件不适合把数据长期留在本地缓存。这个信号的价值恰在于边界清楚——它记录要求，却不冒充执行结果。
案例档案
算法名称没变，证据却被“规范化”掉了：RFC 9688 的参数存在性边界
一次归档迁移可以在不改动 OID、不改动密钥、也不改动界面标签的情况下，改变一份 CMS 对象的协议含义。关键不在 SHA3 这个名字，而在解码器最容易抹平的细节：参数字段究竟应当缺席、应当出现 `NULL`，还是必须携带一段精确的 customization 字节。
案例档案
路由仍在，不代表那名监听者还在：RFC 9685 的最长有效期边界
RFC 9685 允许多个低功耗节点订阅同一个组播或任播地址，路由器则把逐来源状态合并成一条上游通告。共享路由可以因为最长的有效期继续存在；它并不能替某个已经过期、掉电或丢失状态的监听者证明可达，更不能证明应用收到数据包。
案例档案
Quote 验签通过，机框里却还有一颗没被问到的 TPM
RFC 9684 让验证方通过 YANG RPC 向网络设备发出新鲜 nonce，选择 PCR，并取回 TPM Quote 与测量日志。它解决的是证据如何被请求和表达，不会自动说明哪颗 TPM 对应哪块组件、基线是否当前、谁有权作出隔离决定，以及决定是否真正改变了网络。
案例档案
文件下载成功，RRDP 会话却必须因跨源而作废
RFC 9674 把 RRDP 通知文件的权限边界落在一个可计算的三元组上：scheme、host、port。即便主机名看起来没变，只要端口改变，Snapshot、Delta 或重定向目标就可能越过 origin。这个检查决定“能否从那里取”，却不回答“取到的 RPKI 对象是否有效、路由器是否收到、流量是否改变”。
案例档案
带选项的探测包到了终点，却没有证明沿途任何一台路由器处理过它
RFC 9673 允许路由器在不伤害整体转发能力的前提下，按本地配置选择性处理 IPv6 Hop-by-Hop 选项。A/B 探测成功只能说明一组字节在某个时刻穿过了一条路径；它不能替沿途每个节点签署“已经执行选项”的收据。
案例档案
维护权已经移交，现场 Wi-Fi 却没有因此多出一条升级记录
RFC 9672 把 OWE 的后续维护与发展交给 IEEE 802.11 工作组。这解决了“今后由谁修改规范”的制度问题，却没有回答任何一台接入点正在运行哪份文本、哪版固件、哪组测试和哪项配置。
IETF
一个网络功能，四种安全职责：RFC 9509 留给运营商的证书组合选择
5G 核心网里的证书不是一张笼统的“可信证”。同一个网络功能可能要建立 TLS、签署客户端断言、处理 SEPP 间的加密 JSON，还要依赖 OAuth 访问令牌。RFC 9509 为后三项补上了用途名称，却没有替运营商决定它们是否共用证书。
案例档案
state 已经前进，接收者仍然不能执行那项操作
RFC 9670 为 JMAP 共享建立了统一的数据模型，却没有把所有数据类型压成同一种权限。`shareWith` 写入成功、state 更新和 `myRights` 返回，都只能证明各自那一层；真正的访问结果仍要用接收者的实际操作来闭环。
IETF
字节相同，超时却不同：RFC 9510
CCNx 报文里的一字节，在旧转发器眼中可能不足四分之一秒，在新转发器眼中却可能长达数年。RFC 9510 压缩了时间，却也把软件版本变成了解释证据的一部分。