主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
IETF
CAPWAP 状态不等于服务证明：RFC 5415
RFC 5415 为 WLAN 建立了结构化控制面：Access Controller 管理 Wireless Termination Point，建立受保护会话，变更配置并承载客户数据。但状态机完成、DTLS 建立或数据通道出现报文，只能证明协议路径，不足以证明策略已经应用、端点获得授权或客户服务健康。
领导者
根区请求量增长后，Kim Davies 重建了 RZMS
到 2022 年，顶级域名管理组合扩大、DNSSEC 密钥变更增多，旧版根区管理系统（RZMS）的工作假设已显局促。Kim Davies 介绍了 ICANN 团队如何重建平台：按请求配置审批门槛、支持并行申请，并让技术检查独立演进。
IETF
WiCoP 是历史控制记录，不是部署基线：RFC 5414
RFC 5414 描述 WiCoP，用集中方式管理和配置大型无线局域网。RFC Editor 将其列为 Historic，并以 RFC 5415 作为后续 CAPWAP 参考。因此，控制器可达、接入点出现在清单中，或收到配置确认，都不能证明当前实现、授权已经生效或客户端正在获得服务。
IETF
SLAPP 安全是历史边界，不是部署证明
RFC 5413 记录了提交到 CAPWAP 工作中的 Secure Light Access Point Protocol。它描述发现、认证与受保护传输，对理解历史路径有价值，但 RFC Editor 说明该文档仅为历史记录发布，不应作为部署依据。RFC 5415 才是标准轨道上的 CAPWAP 方案，并替代了 RFC 5413 的机制。
IETF
LWAPP 是历史记录，不是部署基线
RFC 5412 记录了 CAPWAP 工作期间提交的 Lightweight Access Point Protocol。它能帮助我们理解接入控制器与轻量接入点的架构，但 RFC Editor 将其标为 Historic，并明确不应把它作为任何部署的基础。RFC 5415 才是标准轨道上的 CAPWAP 方案，并替代了 RFC 5412 的机制。
IETF
SIP 指南是地图，不是部署证书
RFC 5411 把庞大的 SIP 文档族按主题、状态和关系整理出来，帮助读者找到下一份规范。它是发布时点的 Informational 快照，不是运营商当前运行什么的清单。被列出的扩展可能仍在草案阶段、已经放弃，或从未进入某个产品。
IETF
扩展承载了密钥消息，但没有证明密钥已安装
RFC 5410 为 OMA BCAST 1.0 定义 MIKEY General Extension。它可承载 STKM、LTKM、LTKM 报告和家长控制消息。Type 5 证明消息使用了该容器，不证明终端已接收、写入密钥、安装上下文或允许播放。
IETF
CMS 封装了密钥，但接收者身份仍必须匹配
RFC 5409 规定如何在 CMS 中用 BF 或 BB1 加密内容加密密钥，并定义接收者身份的编码和算法 OID。它把封装格式说清楚，却没有把“能解开”变成业务授权。
IETF
身份可以算出公钥，但它仍不是授权
基于身份的加密把“先发证书再加密”的等待压缩成一条计算路径：发送方用身份和公开参数得到公钥，私钥生成方（PKG）在需要时交付对应私钥。RFC 5408 规范了这套架构，却没有把身份自动变成业务许可。真正需要管理的是私钥发放、身份命名空间和应用决定之间的边界。
创造者
一个说法先进入听证记录：Cory Doctorow 与互操作政策的边界
加拿大国会委员会审议一项有关数字锁和软件设备的法案时，证人 Alissa Centivany 提到了 Cory Doctorow 的“对抗性互操作”概念。这个观点进入了正式记录，但 Doctorow 没有出席作证，也没有因此成为委员会或所有平台用户的代表，更不是后来成法的作者。
IETF
通道已经绑定，但操作仍是另一项决定。
An SIP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5407 draws a harder line: SIP Version 2 can bind a SIP message to lower-channel information, but the binding does not become local…
IETF
通道已经绑定，但操作仍是另一项决定。
An IPsec gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5406 draws a harder line: IPsec Version 2 can bind a IPsec message to lower-channel information, but the binding does not become…
IETF
通道已经绑定，但操作仍是另一项决定。
An RTP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5404 draws a harder line: G.719 RTP Version 2 can bind a G.719 frame block to lower-channel information, but the binding does not…
IETF
通道已经绑定，但操作仍是另一项决定。
An RPC gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5403 draws a harder line: RPCSEC_GSS Version 2 can bind a GSS context to lower-channel information, but the binding does not…
IETF
一个绿色“已处理”，掩盖了四种尚未完成的状态
贸易网关收到消息、验证签名、匹配 MIC，控制台便亮起“已处理”。然而压缩可能还没成功反转，附件可能尚未提取，业务规则也可能拒绝交易。RFC 5402 的价值不只是节省带宽，而是迫使系统说明：这个绿色状态究竟属于哪一层。
IETF
页面看起来已经定稿，文件却还没有：RFC 5385
一个文档在屏幕上与最终版逐行一致，最多证明某次渲染符合预期。它没有说明哪份源文件获批、转换程序改了什么、谁赋予发布身份，也没有保证未来还能复现。RFC 5385 以 Word 模板和 ASCII 后处理留下了一个清楚的分层案例：可见页面、生成文件、权威记录和归档历史不是同一件事。
IETF
RFC 5401 的取舍：更少反馈，也意味着更长等待
一个大规模组播系统把 NACK 随机退避窗口调长后，反馈洪峰明显下降，发送端终于安静下来。但接收端恢复时间也随之拉长，缓存占用上升，边缘成员仍在等待。这个安静区间不是免费获得的可靠性，而是用延迟换来的反馈压缩。
IETF
最小地址赢了，但它没有因此获得授权：RFC 5384
同一棵组播树收到两个下游邻接发来的冲突属性，上游路由器必须给出一个确定答案。RFC 5384 的通用规则并不判断哪项请求更符合业务意图，而是选择 IP 地址数值更小的邻接。控制平面因此可以收敛，权力来源却仍然悬而未决。
创造者
Susan Kare与图标背后的文件
MoMA 收藏着 Susan Kare 于 1982 年绘制的 Macintosh 图标手稿；多年后，一份由参与收购工作的保护人员撰写的记录，又提到其档案材料中有三百多张软盘。纸页与软盘并不是同一作品的两种等价副本。它们共同说明：要研究一件数字设计，既要看它如何被制作，也要看多年后人们凭什么重新解释它。
IETF
凭据已经通过，日历主页仍然无处可寻
配置向导拿到了用户名、主机名和密码，认证也返回成功。可是它仍不知道该去哪里寻找用户的日历或通讯录。RFC 5397 填补的正是这段路：让服务器指出当前认证用户的一项主体资源，再由客户端继续查询。它交付的是身份发现的下一跳，不是对后续资源的授权，更不是“账户已经可用”的最终结论。