主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
前缀写着发送者，服务器仍要核对来路：RFC 1459
“消息写着谁发来”与“服务器知道它从哪条连接来”是两件事。1993 年的 RFC 1459 没有让消息开头的名字自证真实：接收服务器还要在自己的数据库中找到该来源，并确认它确实登记在入站连接背后。前缀是一项声明，来路关系才使声明可被接受。
案例档案
解码器报出了 Profile，Level 与 Band 才把工作量说完整：RFC 9924
“支持 APV”只能说明有人贴上了一个类别标签。RFC 9924 要求把 Profile、Level 和 Band 组合起来，分别约束编码特征、图像与分块负荷以及码率；缺少后两项，能力声明仍然没有边界。
互联网历史
标签穿过了网络，它的含义却还没有抵达：RFC 1457
一串比特可以毫发无损地到达终点，一条规则却可能死在解释途中。接收端看见与发送端完全相同的标签，并不等于它知道谁定义了标签、怎样把它换成本地语义、哪个进程获准接收数据。1993 年的 RFC 1457 把这种“形式抵达、含义未到”的落差变成了安全标签设计的核心问题。
案例档案
“符合 CMC”写在产品上，责任角色却没写：RFC 10004
一套系统昨天只服务终端实体，今天被放到注册机构与认证机构之间，同一份合规结论就可能失效。变化的不是标签，而是它承担的角色和条件义务。
互联网历史
六个控制码成了字母，标签必须说明如何解读：RFC 1456
256 个位置像一排已经住满的抽屉。ASCII 字母和标点占据了最容易使用的一半，控制码守着早期终端与通信程序的机关；越南语却还需要容纳 134 种字母与附加符号的组合。RFC 1456 记录的不是一次简单扩容，而是一场兼容性预算：保住哪些旧含义，又把哪些位置改作文字。
案例档案
控制器建好了恢复图，下一个数据包仍要等待本地决定：RFC 9912
无线网络里的“已就绪”至少有三个时钟：控制器准备选项、PLR 根据眼前状况选路、转发面执行数据包。RFC 9912 的价值，正是拒绝把这三个时刻压成同一个绿色状态。
案例档案
恢复图列出了所有可行路径，却没有记录这个包走过哪一条：RFC 9912
RFC 9912 为不稳定链路划出了可控的恢复空间，也留下了一条不能跨越的证据边界：图描述“可能怎样走”，分布式转发才决定“实际怎样走”。
亚太地区数据中心趋势
Baya Systems 携手 AdoreSys 拓展亚太 ASIC 设计业务
AdoreSys 将把 Baya 的互连 IP 与 ASIC 设计和实施服务结合起来，面向中国及更广泛亚太市场的半导体客户提供支持。
互联网历史
数据包请求最安全的路径，网络却没有承诺保密：RFC 1455
1993 年，一个 IPv4 数据包可以在头部带上四个全为一的比特。它们不是锁，也不是通行证，而是一张写给路由器的便条：如果条件允许，请选择最不容易被网外人员偷看的物理路径。RFC 1455 的价值，恰恰在于它把这句话写进协议时，没有把“请求”伪装成“保证”。
欧洲与中东国家电信趋势
Tottenham Hotspur 以 Wi-Fi 7 升级体育场网络
HPE 将在 Tottenham Hotspur Stadium 增加室外 Wi-Fi 7，并通过 Aruba Central 统一管理数据中心、园区和边缘网络。
案例档案
参数是 NULL，不等于参数不存在：RFC 9909 的 SLH-DSA 证书边界
RFC 9909 为 SLH-DSA 进入 X.509 规定了精确的标识与字节格式。系统认得算法名称只是第一步；Pure 与 Hash 模式、参数缺席、密钥用途、证书路径和依赖方策略必须分别留下证据。
案例档案
分类器给流起了名字，却没有证明它受到怎样的处理：RFC 9892
RFC 9892 让 DLEP 调制解调器向路由器描述报文类别，但一个本地 TID/FID 只能说明分类规则。扩展是否启用、哪条规则胜出、队列是否生效以及业务结果，仍需分别取证。
互联网历史
代理声称实现了对象组，对象仍得亲自回答：RFC 1444
设备清单说“支持”，仪表读数却未必出现。1993 年的 RFC 1444 没有把这两件事混成一个事实。它分别规定对象如何成组、符合性声明最低要求什么、某个产品版本声称实现什么；然后把最难的一步留给运行现场：对象必须给出可信的回答。
案例档案
客户端估算了时延，服务器仍掌握验证窗口：RFC 9891
RFC 9891 允许 ACME 客户端说明延迟容忍网络中的预计往返时间，但这项说明只是输入，不是命令：实际等待多久、接受哪些路径证据以及何时作出结论，仍由服务器负责。
互联网历史
网络明明有带宽，应用却仍在挨饿：RFC 1453
一条高速链路可以满载着光亮的数据抵达主机，屏幕上的人脸却依旧冻结。问题不一定出在“网速”上。1993 年的 RFC 1453 把视线移到机箱内部：从传输层到操作系统，再到应用的缓冲区，任何一道边界都可能让充足的网络容量变成用户拿不到的服务。
案例档案
在 Kubernetes，标为 implementable 的 KEP 既不等于进入发布，也不等于集群支持承诺
当一项 Kubernetes 变更被称作“已经获批”，最容易被删掉的往往不是技术细节，而是责任链。受影响 SIG 的 approver 可以决定一份 KEP 已可实施；Release Team 可以把它纳入某个周期的跟踪；独立的生产就绪审查可以评估其运营条件；某个版本可以列出 feature gate；最后，运行集群的人仍要独立决定是否启用、如何回滚、是否承诺支持。它们相连，但不是同一个事实。
案例档案
CVE 记录是协调引用，不是补丁或修复完成的收据
漏洞管理里最容易被误用的不是一项技术事实，而是一串看似顺畅的状态词：有了编号、记录已公开、供应商已回应、列入优先目录，于是好像问题已经被修复。CVE 的真实价值恰恰更克制：它让发现者、CNA、供应商、发行版和运营者能够确定自己说的是同一个漏洞。这个共同坐标极有价值，却不能把不同主体的记录、选择和责任压缩成一个“已处理”的判断。
IETF
一次签名不等于证明另一把密钥：RFC 9883 与私钥持有声明
第二份证书请求可以由一把已经取得证书的签名密钥有效签名，但该签名只是一个断言，而不是技术证明：它不能证明请求者控制着请求中的另一把私钥，也就是拟用于密钥建立证书的私钥。RFC 9883 规定了如何处理这种断言。
互联网历史
必须作答的数据包：TCP 挑战 ACK 如何修补盲目复位
TCP 曾把“序列号落在接收窗口内”同时当作数据可接受性和连接销毁权的证明。RFC 5961 没有给 TCP 加密，而是插入了一次可逆的询问：可疑报文先回答挑战，精确证据才触发复位。
互联网历史
无法说明哪个数据包到达的 ACK：Karn 的重传歧义规则
ACK 可以证明字节已经到达，却未必能说明是哪一次发送触发了它。Karn 规则因此把交付证据和延迟证据分开：确认状态可以前进，但这次事件不能作为普通 RTT 样本。