档案
Research
Research档案页面汇集了人物、公司、机构等实体的情报，帮助读者对比BTW.MEDIA报道中的相关主体。通过该页面，读者可以对比公开档案、相关事件、证据材料、角色变动、运营足迹、治理风险、组织联系以及市场关联性，同时将机构与人物记录同普通新闻时间线区分开。读者能理解新闻标题背后的主体、支撑档案的证据，以及使该档案具有重要影响的基础设施或市场关系。也可以看到档案所代表的主体是谁或是什么、依据哪些公开来源、它如何与公司、市场、治理机构或事件连接，以及随着主体演进，哪些变化值得持续关注。
IETF
RFC 9998：年龄核验失败，不等于同意接受更具侵入性的核验
年龄核验常被画成一道门：达到年龄门槛就放行，否则拒绝。真正困难的治理问题却发生在第一种方法无法得出可靠结论之后。系统可能转而索要证件、面部影像、电话号码或更长的行为记录。RFC 9998 说明了为什么单一方法并不充分，也记录了每种方法的误差。它没有把这种不足变成默示授权。方法之间的升级本身必须能够被解释、审计和纠正。
领导者
Nick McKeown 与那条从未见过数据包的 Barrier Reply
控制器收到 Barrier Reply 的那一刻，最容易发生的错误不是协议错误，而是语言错误：系统把“此前消息已经按序处理”写成“网络变更已经成功”。前一句有严格边界，后一句却偷偷跨过了流表、端口、链路和接收端。
IETF
RFC 9876：CoAP 注册表编号不等于互操作性结论
在受限协议里，一个很小的整数很容易背上过大的制度承诺。CoAP Content-Format 编号让设备不必在报文中重复媒体类型、参数和可能存在的内容编码。RFC 9876 让这个编号更难被错误分配，却没有证明两套已部署产品会以同样方式解释同一组字节。治理上需要保留两张相连但不混同的收据：编号为何获批，以及真实实现之间究竟发生了什么。
IETF
RFC 9874：一个客户的 EPP 删除可能让另一个客户的 DNS 失效
最危险的删除不一定报错。它可能对发起命令的客户显示成功，却改变了其他客户名下域名所依赖的名称服务器。RFC 9874 揭示的正是这条权力与后果不重合的边界：谁有权删除，并不等于谁承担 DNS 中断、通知延迟和恢复失败的代价。
领导者
Remco van Mook 与没有 IPv4 邻居的 IPv4 网关
路由表里写着一个 IPv4 默认网关，链路上却不应存在与它对应的 IPv4 邻居。Remco van Mook 正在 IETF 推进的方案把这个矛盾变成一条简洁指令：看见 `192.0.0.11`，不要发 ARP；去 IPv6 邻居缓存里取下一跳的链路层地址。
IETF
网络认定根节点失效，却未证明它物理崩溃：RFC 9866
低功耗网络必须在因果调查结束前就决定还能不能继续路由。RFC 9866 给了 RPL 一套快速关闭当前 DODAG 版本的办法；它产生的是可执行的安全结论，不是对边界路由器物理状态的鉴定书。
领导者
John Ousterhout：一次快速写入如何变成清理债务
Sprite 的日志结构文件系统把零散小写入合并成顺序长写，让前台路径显得异常轻快。它真正留下的不是“顺序写必胜”的口号，而是一套完整核算：旧版本占掉的空间、清理器搬动的数据、为性能预留的容量，以及故障后的恢复工作，都必须有人支付。
互联网历史
RFC 2350 写清了服务入口，却没有替任何事件出具结案证明
公开邮箱、工作时间、权限范围与服务清单，能够回答“应该向谁报告、可以期待什么”。它们不能回答“这一次报告是否已被接收、核实、归因、根除并恢复”。
互联网历史
三张命名空间地图已经展开，邮箱之门却未必存在：RFC 2342
一条完整的 NAMESPACE 响应能告诉 IMAP 客户端个人、其他用户与共享邮箱应如何命名。前缀和层级分隔符解决了“名字怎样拼”的问题，却没有替任何具体邮箱证明存在、可见、可访问、已同步，更没有证明邮件被人读到。
互联网历史
同一条路径，四种算法，以及一个会传染的“未知”：RFC 2215
路径上每台设备都可以交出一个数，但这些数并不服从同一种合并规则。RFC 2215 把这种差异写进协议语义：断点取逻辑或，已知节点逐个计数，可用带宽和 MTU 取最小值，最低时延则累加。更关键的是，一旦某个环节只能回答“未知”，后面的精确值也无权把证据缺口抹掉。
IETF
备用权威服务器回答了，缓存的密钥却对不上：RFC 8901
第一家权威 DNS 提供商失效后，第二家仍能回答，并不代表验证解析器一定能接受答案。RFC 8901 揭示了 DNSSEC 冗余的真正对象：它是签名者之间的同步合同，而不是 NS 数量。
互联网历史
包里同时有画面和声音，也不等于节目已经播出：RFC 2343
RFC 2343 把 MPEG-2 视频 slice 与音频 frame 装进同一条 RTP 负载流，让一套节目能以统一的边界和时间关系传送。但一只格式正确的包只能说明发送端怎样组织字节，不能替网络、解码器、渲染器、扬声器、屏幕或观众证明后续结果。
互联网历史
编号只是合同的索引：RFC 2216 如何拆开“服务”与结果
一项网络服务有了名称和编号，最容易产生的错觉是：它已经成为一项可以端到端兑现的能力。RFC 2216 的贡献恰恰是拆掉这种错觉。它要求规范作者逐项说明调用参数、流量边界、异常处置、请求合并和可验证行为，让每一层只为自己真正控制的结果负责。
互联网历史
RFC 2345 的一条公司名检索结果，为什么不是身份与归属证明
输入公司名称，收到一个名称和一个网址，浏览器随即打开页面——RFC 2345 刻意把 1998 年的公司信息定位压缩到这样一个轻量动作。它解决的是“去哪里找”，而不是“这是谁”“域名归谁”或“服务是否可靠”。那条看似完整的结果没有展示匹配规则、来源、排名、遗漏项、域名控制链与实际服务结果。简化响应缩短了下一步，却没有替用户完成核验。
互联网历史
公式没有承诺奇迹：RFC 2212 如何用 C/R 与 D 算出时延上界
一条时延上界如果只剩下最后的毫秒数，就已经失去了一半含义。RFC 2212 的价值不只是给出公式，而是把流量形状、预留速率、逐节点误差和路径条件留在公式里：网络可以承诺一个可计算的最坏排队时延，却不能借此宣布零抖动、身份可信或应用已经成功。
互联网历史
找到地址，不等于道路已经打通：RFC 2333 为 NHRP 划定的证据边界
一条 NHRP 缓存记录可以同时给出协议地址、NBMA 地址、权威性和剩余有效期，看上去像一张完整的“下一跳可达证明”。RFC 2333 却把它放回更长的执行链：路由先选择方向，NHRP 再解析地址，ATM 等面向连接的底层还要建链，数据包必须真正通过，远端服务必须响应，应用任务才可能完成。地址映射很重要，但它不是道路本身。
IETF
根查询少了，流量账单未必更轻
LocalRoot 把大量普通根查询留在递归解析器本机，减少对 Root Server System 实时路径的依赖，也缩小一部分外部观察面。但它同时新增一条控制链：找到发布源、检查根区是否变化、取得完整或增量数据、验证 ZONEMD 与 DNSSEC、激活候选副本，并在过期前安全回退。2026 年一项短期测量显示，这条链路的字节数可能高于被省掉的查询流量。
互联网历史
一个位如何让整条路径摘要失效：RFC 2210 的 ADSPEC 证据边界
路径上有多少个支持综合服务的节点、带宽和最小时延如何、能够覆盖多大的报文——RFC 2210 允许这些信息随着 RSVP 的 PATH 消息向接收端汇总。但真正决定这些数字能否被当作端到端事实的，并不是另一个更精确的数值，而是一个 break bit。只要路径中有一处不支持 RSVP/Integrated Services，其余 ADSPEC 参数就不再具有完整路径摘要的可信度。它记录的不是“网络一定失败”，而是“这份汇总已无权代表整条路径”。
案例档案
一个递归解析器地址，未必代表一个解析器
APNIC Labs 给实验区增加第二台双栈权威名称服务器后，每次测试观测到的平均查询数从 3.43 降到 2.57。实验没有查明原因，却暴露了一个更值得运维团队正视的问题：公网解析器 IP 是路由入口，不一定是执行身份。
互联网历史
当“成功”只在一端成立：RFC 2188 与远程操作的证据边界
一次远程操作究竟有没有“成功”，看似应该有一个简单答案。RFC 2188 展示的却是另一种更接近分布式系统现实的图景：invoker、performer、协议 provider 和应用，各自只能根据自己实际观察到的事件形成判断。报文可能已经抵达，操作可能已经执行，结果甚至可能已经被 invoker 接受，而另一端仍可能因为确认报文丢失而报告 FAILURE。真正值得从这份 1997 年协议文本中保留下来的，不只是 ESRO 如何节省无线链路上的消息开销，而是一个更持久的工程原则——协议事件是端点相对的证据，不是自动同步的全局历史。