主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
IETF
握手内容解开了，群组记忆却还没有到场
MLS 的外部接收者可以拿到与群成员完全相同的提案或提交，却仍无法证明发送者是谁。欠缺的不是另一层加密，而是把当前纪元、发送者叶节点、凭证与接收者名单连在一起的 GroupContext。
IETF
协议接受了这个数，32 位程序却装不下它
一条 EDHOC 消息可以通过 CBOR 解析、落入拟议的私用范围并完成认证，随后却在应用把整数塞进有符号 32 位字段时改变含义。线上格式正确与软件内部保持原值，是两项完全不同的证明。
互联网历史
有效签名仍然需要一份策略：RFC 3125
RFC 3125 试图把电子签名周围的规则变成可引用、可校验、必要时可由机器处理的对象。密码学计算正确，只打开了第一道门；真正的“有效”还取决于哪一版策略、哪种承诺、哪些信任条件，以及外部制度是否承认它们。
互联网历史
一次发送许可还不是一个数据包队列：RFC 3124
拥塞管理器试图在一台主机内协调多个应用何时发送，却有意不接管它们的数据。RFC 3124 最值得记住的边界，是把请求、短时许可、本机实际发送与接收端反馈拆成不同事实。
IETF
现用密钥签下了继任者，风险正从这里开始
验签只能说明：按昨天的规则被接受的那把密钥，确实批准了这次变更。它不能回答更难的问题：这把密钥是否有权独自决定明天由谁控制同一个标识符？
互联网历史
前缀列表还不是访问策略：RFC 3123
DNS 可以准确发布一串网络前缀。RFC 3123 更重要的克制，是没有把这串数据伪装成命令：记录负责表示，应用负责解释，运营者负责决定，执行点才负责动作。
互联网历史
延迟数字也在陈述时钟：RFC 3116
ATM 实验室里，接收时间减去发送时间似乎就是答案。RFC 3116 把被减法遮住的条件重新摆上台面：先证明两个时间戳属于同一时间轴，再谈交换机用了多久。
IETF
两张地图都通过了验签，缺失的却是它们各自的边界
值班人员把两个邻居的拓扑视图并排放在屏幕上：来源节点相同，完整性保护都有效，可左边只看到一组 IPv6 会聚层实例，右边却收到另一份凭据和几乎不重叠的邻居集合。问题未必是谁撒谎。SAND 第 04 版允许节点按底层网络、终结点与目的地投射不同事实；真正危险的是，平台删掉投影条件之后，还把差异叫作冲突。
互联网历史
共享同一套系统，不等于合并批准权：RFC 3113
2001 年，第三代移动系统必须接入互联网，IETF 也必须听见无线网络的约束。RFC 3113 没有为两者发明一个共同上级，而是把协作设计成一条不夺权的接口。
IETF
源文件一个字没变，允许清单却改了它的意义
一份可读的 CDN 文件通过了昨天的生产门禁。今天，文件哈希完全相同，解释器却拒绝同一个前缀。差别不是语法，也不是注册表里有没有这个名字，而是运营方修改了允许调用的扩展集合。文本表达了请求；本地配置仍然决定这段请求能否变成一个值。
互联网历史
RFC 写的是 37，运行中的网络却认 38：RFC 3115
2001 年，Mobile IP 的同一种扩展在标准正文与 IANA 注册表里有两个编号。RFC 3115 没有让机器服从纸面，而是依据实现已经采用的编号，废止了两个月前发布的 RFC。
IETF
控制台读懂了每个字段，却仍不知道谁有权改这片区域
DUJ 把含糊的 DNS 操作说明变成机器可检查的动作清单。解析器因此能准确知道要增加或删除什么；真正承担后果的 DNS 运营者仍必须独立回答：提交者是否有权、这项变更是否符合本地策略、提交是否完整生效、公共 DNS 是否已经呈现新状态。
IETF
AS2 名称完全匹配，签名者的授权仍是本地决定
一条异步 MDN 可以从另一条 HTTPS 连接返回，名称对调正确、签名验证成功、MIC 也与原文一致。它证明了一条很强的证据链，却仍不能替代那条没有出现在报文里的记录：谁批准这把新密钥代表这一交易伙伴？
IETF
每秒一个包，也不是“空闲”
PowerBench 第 03 版把一条极小的流量轨迹变成了采购网络设备时必须面对的大问题：只有当有效转发、设备状态、配置、仪表与时间窗口被写进同一份结果，瓦特数才有资格参与比较。
案例档案
编号已经变绿，注册表却仍是一片空白
迁移看板最容易制造的一种错觉，是把“测试向量已经换成正式编号”显示成“算法身份已经稳定”。2026 年 10 月 1 日，OpenPGP 工作组草案第 05 版已经把八种 NIST/Brainpool 复合算法写成 37 至 44；同一时点的 IANA 公共注册表仍把 37 至 99 标成未分配。这不是谁对谁错的判决，而是一个控制边界：编号、注册权威和实际执行还不能被合并成同一事实。
IETF
调试头写下了每一步，却证明不了任何一步发生过
一份新的 DKIM2 草案给互操作测试留下了统一的取证线索。它可以精确地告诉人该去哪里查，却被有意设计成不能为机器提供任何权威结论。
互联网历史
策略服务器推送了规则，重连仍须核对设备留下了什么：RFC 3084
RFC 3084 试图把策略下发变成一套可追踪的分布式事务：服务器给出决定，设备整体安装或整体回滚，再用回执报告结果。真正棘手的部分发生在连接断开之后——两端都保存着状态，却未必保存着同一个事实。
互联网历史
有线链路加密了流量，管理面仍能关闭隐私：RFC 3083
RFC 3083 把 DOCSIS Baseline Privacy 变成可由 SNMP 观察、调节与重置的系统。可见性帮助诊断，也划出第二条安全边界：查看密钥状态的接口，同样能重启授权、改变时钟并决定多播范围。
案例档案
SID 选中了资源通道，却没有证明容量真的在那里
数据包携带正确的标识、每一跳也能查到对应的资源分区，并不等于带宽、缓存与队列已经在全路径兑现。资源感知 Segment Routing 真正暴露的，是“选中”与“交付”之间那段容易被控制器状态遮住的距离。
互联网历史
一条连接，不只一场对话：RFC 3080
在 BEEP 里，底层连接畅通，只能说明两端之间有一条路。RFC 3080 把通道零留给会话管理：宣布能力、协商新通道、关闭通道。真正的应用含义，要等某个明确的 profile 被对端接受之后才出现。连接、能力、通道、消息与结果，从来不是同一张回执。