档案
Research
Research档案页面汇集了人物、公司、机构等实体的情报，帮助读者对比BTW.MEDIA报道中的相关主体。通过该页面，读者可以对比公开档案、相关事件、证据材料、角色变动、运营足迹、治理风险、组织联系以及市场关联性，同时将机构与人物记录同普通新闻时间线区分开。读者能理解新闻标题背后的主体、支撑档案的证据，以及使该档案具有重要影响的基础设施或市场关系。也可以看到档案所代表的主体是谁或是什么、依据哪些公开来源、它如何与公司、市场、治理机构或事件连接，以及随着主体演进，哪些变化值得持续关注。
领导者
Tina Dam 与那个无法批准域名的根区测试
在国际化顶级域名进入根区之前，ICANN 把问题限定得很窄：编码后的标签会不会影响传递 DNS 查询的服务器和解析器？实验室测试只在自己的模拟环境内回答了这个问题。它不能决定哪个群体的名称应获接纳，也没有说明普通用户能否顺利使用该名称。
IETF
Syslog 可以报告时钟质量，但边界仍须由运维配置：RFC 5424
把多台设备的日志排成一条时间线，并不等于已经证明它们的钟彼此可靠。RFC 5424 为 Syslog 来源端提供了一组可选字段，用来说明它对时区和同步状态的判断；这些字段能随事件传递，但不能替代时钟监测本身。
IETF
进入 EAP-FAST 隧道后，类型 6 另有含义：RFC 5421
RFC 5421 把一个熟悉的 EAP 类型码放进了新的封装里：Type 6 在全局登记中仍指向 Generic Token Card，但进入 EAP-FAST 隧道后，它选择的是另一种格式的内部交换。规范用明确的内外边界限定这两种用法，IESG 说明也提醒，这种复用会给方法协商和分派带来兼容性代价。
学者
Lorrie Cranor 的隐私标签，应能追溯到代码与 SDK
围绕 Google Play 的 Data safety 声明，关键问题很实际：开发者能否把商店里的每项披露，追溯到代码和 SDK 的行为？Lorrie Cranor 关于可用隐私的研究，把这道“从软件行为翻译成公开声明”的工序放回了开发流程。
IETF
配置成功仍不等于获准入网：RFC 5422
RFC 5422 区分凭据配置完成与网络授权；服务器未认证模式的会话只用于配置。
互联网历史
公开漏洞不等于公布蠕虫源码：RFC 1135 记录的披露争论
1988 年的 Internet 蠕虫事件留下的问题，常被压缩成“公开还是保密”。同期材料呈现的是更细的选择：说明漏洞、解释程序方法、发放修补方案，或公开可直接改造的反编译代码。RFC 1135 并列保存了多种立场，却没有把它们写成全网通用的规则。
领导者
Rebecca MacKinnon 重返 GNI，让两套数字权利问责方法重回视野
2026 年 8 月，Rebecca MacKinnon 重返 Global Network Initiative（GNI）。她也创办了 Ranking Digital Rights（RDR），因此这次回归把两种问责方法带到同一视野：RDR 曾以企业公开披露为依据评分；GNI 后来的评估还会查阅内部制度和选定个案。两者能回答的问题不同，不能互相代替。
IETF
AAA 能识别订户，归属代理仍需要一套密钥衔接机制：RFC 5419
RFC 5419 回顾了部分 Mobile IPv6 运营方为何希望沿用既有 AAA 关系来验证订户。更关键的问题发生在验证之后：归属 AAA 可以认出订户，但被选中的归属代理仍须获得一份可用、范围明确的 MN–HA 安全关联。
互联网历史
“常规”并非免审：RFC 6709 的协议扩展判据
判断一个协议扩展时，最容易误读的词也许是“常规”：它听起来像是在说改动小、风险低、无需多看。RFC 6709 给出的含义更窄，也更严格：基础协议和已经部署的实现能否把扩展当作不透明数据安全地忽略？即使答案是肯定的，专家审查仍可能有价值。
IETF
CAPWAP 链路通过认证，不等于设备获准入网：RFC 5418
RFC 5418 将 WTP–AC 链路认证、设备在特定部署中的登记、角色授权和客户端数据路径分开。会话建立只是其中一项运行证据。
互联网历史
互联网由多网协作：RFC 1462 的电话运营商类比
1993 年的 FYI 借电话运营商作比喻，让新用户理解互联网的分段结构：用户面对一项服务，各组成网络却分别运行并修复自己的部分。
互联网历史
NAT 是一项逻辑功能，不是一块接口：RFC 4008 的管理模型为何重做
RFC 4008 的配置示例从创建接口索引行开始，之后才把地址映射挂到该接口。十年后，NATV2-MIB 将转换功能从接口上抽离，改用逻辑实例、地址域、订户和资源池来描述。两版规范之间，IETF 自己记录了旧模型为何难以贴合许多实现。
领导者
Anriette Esterhuysen 的 IGF 框架，把能力放在制度的长期延续中衡量
IGF 的 2021 年进展报告列出了资助、参会支持和线上研讨会。Anriette Esterhuysen 更早提出的问题是：活动结束后，个人及其所在机构能否继续制定并实现自己的互联网政策目标？
互联网历史
帧穿过了伪线，服务角色却没有随行：RFC 7152 与 E-Tree
2014 年，IETF 的一份需求备忘录指出了二层 VPN 中一个不易察觉却影响转发的缺口：边缘路由器可以从伪线收到以太网帧，却不知道帧是从远端的根接入电路还是叶接入电路进入网络。RFC 7152 把这种上下文缺失写成了跨多点网络承载以太网树服务的需求。
IETF
CAPWAP 发现开始前，DHCP 已排好无线终端的控制器候选顺序：RFC 5417
DHCPv4 或 DHCPv6 选项可以把一个接入控制器排在另一个之前，影响无线终端启动时的搜索路径。RFC 5417 把这个顺序定义为服务器配置的偏好；后续发现过程与 DTLS 才决定哪个对端能够建立控制会话。
案例档案
根区 DNS 查询翻倍，线索来自递归解析器更新
约一周内，抵达 DNS 根区的查询量从每秒约 160 万升至 320 万。请求格式正常，来自递归解析网络；根服务没有出现可测量的性能或可用性影响。这个事件说明，上游一次软件更新可以改变共享基础设施看到的流量，而具体改动尚未公开时，跨网络协作仍能提供关键线索。
IETF
RFC 5416：802.11 绑定有明确的时代边界
RFC 5416 不是对所有现代 Wi‑Fi 能力的承诺。它把 CAPWAP 与 IEEE 802.11-2007 基线绑定起来，规定接入点与控制器怎样交换站点、射频、QoS、BSSID 与 WLAN 信息。管理者真正需要判断的是：一个绑定消息究竟证明了什么，又没有证明什么。
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 参考。因此，控制器可达、接入点出现在清单中，或收到配置确认，都不能证明当前实现、授权已经生效或客户端正在获得服务。