主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
同一个应用跨过两个版本，代理却改写了操作：RFC 1452
应用发出的是批量读取，旧版代理收到的却只是“取下一个”。中间的双语管理器先查本地数据库，再把两个重复参数清零并改掉 PDU 类型。RFC 1452 希望这层转换对应用透明；它同时留下了另一条更重要的记录：接口连续，不等于两端执行了同一项操作。
创造者
Stefan Savage 与作为系统测量的网络犯罪
Stefan Savage 的研究不断以对流量、供应链、激励和故障路径的测量，取代孤立的攻击故事。从 DDoS、网络蠕虫和垃圾邮件，到支付网络、云基础设施与联网汽车，其方法始终是识别支撑滥用的机制，构建能够观察其中一部分的工具，并在决策时明确工具边界。
案例档案
切片标识到了传输边缘，保障仍需落地：RFC 9889
RFC 9889 把“网络切片”拆成一条可问责的实现链：5G 控制面可以给切片命名，但传输网仍要识别流量、配置资源、安装路径并用测量证明结果。
创造者
Stefan Savage：把网络犯罪作为系统来测量
Stefan Savage 的研究不断以流量、供应链、激励机制和故障路径测量取代关于攻击的简单叙事。从拒绝服务、蠕虫和垃圾邮件，到支付网络、云基础设施与联网车辆，他反复识别支撑滥用的机制，构建能够观察其中一部分的工具，并在决策者采取行动时保留工具的证据边界。
报道
APNIC 自动化课的下一位老师，也要会搭实验室
孟买工作坊不仅教工程师操作，还准备教他们组织下一堂课。年底部分科目退出 APNIC 讲师授课课程之前，真正需要交接的，是能够重新搭建、排错和恢复的教学环境。
领导者
Abdiel Marin：眼科临床工作流背后的软件架构
Abdiel Marin 创建 EyeMD EMR 时抓住了一个朴素却苛刻的前提：服务眼科的系统应当贴合诊所的实际工作，而不是要求医护人员迁就通用电子病历的分类方式。他把专科影像、互操作标准、边缘计算和患者流程连在一起；在他退出日常管理后，这套逻辑是否仍能延续，成为观察 Optivate 的关键。
互联网历史
版本号留了下来，安全框架却没有：RFC 1441
抓包工具若显示 SNMP 的 `version = 1`，它未必在说“第一版”。在基于共同体字符串的 SNMPv2 消息中，这个整数恰好表示第二版。数字本身没有矛盾：它只是枚举值。真正危险的是，人们常把这个解析线索扩写成一整套安全结论。RFC 1441 的兴衰提醒我们，版本、消息处理、安全、访问控制和实际执行从来不是同一份证据。
互联网历史
告警还在，通往另一台管理站的通知路径却已过期：RFC 1451
监测没有停止，阈值也没有被删除，事件计数仍可能继续增长；消失的是把事件送往另一台管理站的那一行配置。RFC 1451 给这行配置加上了倒计时：如果接收方不再续期，通知关系就会自行销毁。它把一个经常被合并为“告警正常”的状态，拆成了探测、判断、事件、投递关系与接收五个事实。
互联网历史
用户名像一个人，命名空间却只承诺一个槽位：RFC 1439
早期电子邮件把“猜得到地址”当成一种便利：知道一条命名规则，就能由姓名推测账户。可当两个人生成同一字符串时，协议即使毫无差错，也可能把信交给错误的人。1993 年的 RFC 1439 讨论的正是这道常被界面掩盖的边界。
案例档案
安全通道失败，客户端不得退回旧路：RFC 9887
RFC 9887 把安全传输升级变成一条权限规则：受保护的 TACACS+ 路径一旦失败，旧路径仍然可达，也不等于客户端获得了使用它的许可。
互联网历史
文件已经到达，收件人却还没有接收它：RFC 1440
1993 年的一项实验协议把文件放进了一个容易被界面抹掉的中间状态：网络传输已经结束，接收主机也保管了数据，但收件人尚未作出决定。SIFT/UFT 追求的是发送方便；它也因此清楚暴露出，抵达、托管、接收和使用从来不是同一个事实。
全球机构
Batfish 与在网络变更前完成验证的承诺
Batfish 将多厂商配置转换为统一的路由与转发模型，让运营方在部署前检查可达性、策略变化和故障韧性。结论的实际价值仍取决于快照完整性、解析器覆盖、明确的网络意图及部署后的实时验证。
互联网历史
WAN 会话已经连上，两端终端却仍各有一条链路：RFC 1434
一台终端收到的确认，可能只来自同一机房里的交换节点；远端终端此时甚至还没有接通。RFC 1434 没有掩饰这段落差，而是把局域链路、交换电路与广域传输拆成可分别失败的状态，由 Data Link Switching 在三者之间承担接力。
全球云服务趋势
Netskope 改按年收款，增长的钱由谁先垫
收入预期上调，全年自由现金流率目标却收窄至约 2%。变化不只在财报数字里，也在客户与供应商之间重新分配的垫资时间里。
全球机构
Batfish 与网络变更前测试的承诺
Batfish 将多供应商配置转换为路由与转发模型，使运营人员能够在触及生产环境前，检验拟议变更下的可达性、策略和故障行为。其分析可在模型范围内实现广泛覆盖，但实际价值仍取决于解析器覆盖、快照完整性、明确意图和部署后的实时验证。
互联网历史
路由写出了下一跳，链路却仍要点头：RFC 1433 的 Directed ARP 实验
三台设备接入同一项数据链路服务，并不意味着三者可以两两通信。RFC 1433 把这条容易被网络图掩盖的事实写进协议：路由可以指明下一跳，地址解析可以给出链路地址，实际路径仍可能被过滤、只通单向，或者根本不存在。
IETF
CATS OAM 可以核验流量引导策略，不能自行选择补救措施
CATS 的 OAM 工作稿面对的是一个很具体的运行事实：网络地址仍可达，并不等于该地址后的服务仍可用。实例可能仍能响应连通性检查，但应用已经阻塞、资源耗尽或性能严重下降。工作稿因此把观察拆成链路、路径、实例和服务四层，并要求将实际转发与 CATS 路径选择器先前作出的选择相对照。
案例档案
能力已经通告，协议却不得据此行动：RFC 9885
一个零长度的能力信号可以出现在所有路由器上，却依然不足以批准一项配置变更。RFC 9885 把这条边界写得很清楚：Type 30 只提供管理信息；真正决定 MP-TLV 能否启用的，是每台接收设备对具体码点的运行事实。
互联网历史
临时方案买到了时间，也可能透支未来：RFC 1380
1992 年的 Internet 同时面对几只速度不同的钟：路由表和 B 类网络号已经逼近设备与人员的承受力，更大的地址空间却需要漫长的架构选择。RFC 1380 没有把它们压成一个项目。它要求眼前缓解、短期工程、中期替代与长期研究一同启动，还提醒读者：用于“争取时间”的工作，本身会消耗未来方案所需的人力、迁移窗口与选择空间。
互联网历史
网络找到了书，却无法同步书架：RFC 1432 的时间边界
RFC 1432 的书目表里有作者、页数、价格、读者和类型，却没有单独一列叫“这条记录在什么时候仍然有效”。1993 年的这份文献并非忘记了时间；恰恰相反，它用问号、待出版状态和变动警告，把时间写进了每一种事实的边界。