档案
Research
Research档案页面汇集了人物、公司、机构等实体的情报，帮助读者对比BTW.MEDIA报道中的相关主体。通过该页面，读者可以对比公开档案、相关事件、证据材料、角色变动、运营足迹、治理风险、组织联系以及市场关联性，同时将机构与人物记录同普通新闻时间线区分开。读者能理解新闻标题背后的主体、支撑档案的证据，以及使该档案具有重要影响的基础设施或市场关系。也可以看到档案所代表的主体是谁或是什么、依据哪些公开来源、它如何与公司、市场、治理机构或事件连接，以及随着主体演进，哪些变化值得持续关注。
互联网历史
那扇关上却没有结束连接的窗口：TCP 持续状态
接收窗口降到零，意味着发送方必须停下，却不意味着连接已经死亡。真正棘手的是：如果“窗口重新打开”这条消息丢了，双方怎样走出等待。
IETF
一个响应头可以使整个站点分区失效：RFC 9875 与 HTTP 缓存组
响应可以在同一个缓存、同一个 URI 源站范围内声明一个或多个不透明组标识符；随后，针对不安全请求的响应可以用这些标识符提出可能的失效操作。它解决的是局部关联，不是多个缓存、CDN 或源站之间的同步。
IETF
DNS 目录区域把成员清单变成全服务器群的配置权
空文件通常意味着没有内容，但空的 DNS 目录区域可能是一道指令。若生成器误发了一个语法正确却没有成员的目录，原先由该目录配置的辅助服务器可能开始移除成员区域及其关联状态。真正需要治理的不是区域数据量，而是谁有权改动这张清单。
互联网历史
让不在通信路径上的攻击者更难预测的数字：TCP 初始序列号
TCP 连接以交换数字开始。历史上的关键改动不是隐藏这次交换，而是让一次可见的数字不再泄露下一条连接的起点。
ICANN
区域文件提供的是受控访问，不是重新发布命名空间的权力
上午九点，一名获准研究人员通过 ICANN 的 CZDS 下载某个通用顶级域的区域文件，校验和完全一致。这能证明一组特定字节已经交付，却不能证明每个域名由谁实际控制、为何存在，也不能自动赋予重新发布整份文件的权力。真正的治理边界就在“能够访问”与“有权使用”之间。
IETF
一条删除命令可能破坏他人的域名：RFC 9874 与 EPP 依赖控制
一次具有破坏性的 EPP 状态转换，影响范围可能超出发起请求的客户。如果某个从属主机仍与其他客户赞助的域名建立关联，删除该主机就可能改变这些域名的 DNS 依赖，造成解析失败、客户端与服务器状态不一致，或破坏关系完整性。RFC 9874 的权威来源是 RFC Editor；它提出最佳实践，并未定义新的 EPP 命令，也没有改变注册局所有权或管理权。
IETF
第二个地址成为主地址：RFC 9873 如何改变 EPP 联系人数据
一次 EPP 联系人更新现在可以形成更明确的状态转换：联系人对象可保存一个额外电子邮件地址， 可选的 `primary` 属性说明哪个地址应被视为主要地址。协议记录的是这种关系，并不验证邮箱归属、保证邮件送达，也不保证所有下游流程都会采用这一选择。
IETF
默认拒绝让缺失的 EBGP 策略从隐性授权变成显性故障
一条外部 BGP 会话可以已经建立，但接收或通告路由的权限仍未定义。RFC 8212 改变了这个边界的默认值：没有导入策略就不接收路由，没有导出策略就不通告路由。领导者要问的不是会话是否在线，而是谁授权了两个方向，以及这种授权在升级后是否仍然有效。
互联网历史
让公钥变得可信的链条：PEM 证书管理
公钥只是一段密码学材料，并不会自行说明持有者是谁。RFC 1422 为隐私增强邮件设计了证书、认证机构、验证路径与吊销信息，使收件人能够检查“姓名与密钥之间的绑定”由谁作出、又凭什么值得信任。
IETF
增强型 uRPF 让运营者接纳可行源路径，而不是信任所有路由
多宿主客户发出的合法数据包，可能从接收路由器不会用于返程的链路抵达。严格检查可能误丢它，宽松检查却可能放行任何已有路由的源地址。RFC 8704 给出更窄的中间边界：为每个接口建立可行源路径集合，并把这个集合的授权依据与运行成本说清楚。
IETF
前缀先于查询到达：RFC 9872 如何改变 NAT64 发现
仅有 IPv6 接入的终端若要访问 IPv4 服务，必须知道网络用于合成地址的 IPv6 前缀。RFC 9872 把这项信息放回接入网络：先从路由器通告学习 PREF64，无法取得时再使用 DNS 发现。
互联网历史
从未真正带外的指针：TCP 紧急数据
TCP 紧急数据是一个很小、却有漫长历史的控制面。URG 标志使 16 位紧急指针生效，但 RFC 793 对它标记的边界给出了两种彼此矛盾的描述。这一歧义从规范进入了实现和应用 API。
IETF
ZONEMD 让辅助服务器在传输结束后验证整个区域
区域传输完成，只能证明交付流程结束，不能单独证明接收方拼出的区域正是发布方有意发布的完整版本。ZONEMD 为整个区域增加摘要，把“收到”与“验证一致”分成两道控制。
IETF
位图只说明 UDP 选项出现过，不说明它做了什么：RFC 9870
RFC 9870 为 IPFIX 导出器提供了一种紧凑方式，用来报告一个流中观察到哪些 UDP 选项类型。它的价值恰恰来自结论范围有限：记录的是出现事实，而不是逐包历史、接收端处理决定或应用结果。
IETF
负信任锚让递归解析器无需修改区域即可暂停 DNSSEC
签名区域配置出错时，验证型递归解析器可以继续拒绝解析，也可以为一个明确分支开启本地例外。负信任锚能够在区域尚未修复时恢复可达性，但代价是把暂停 DNSSEC 保证的临时权力交给解析器运营方。
IETF
Mukul Srivastava 与“数到了 RIB、却没看见路由”的 BMP Gauge
数字可以准确，却仍然只回答一个很小的问题。RFC 9972 让 BMP 能在清楚标出的 RIB 视图中报告“此刻有多少条路由”。这不是某条路由的档案，不是策略为何接受或拒绝它的说明，也不是数据包已经抵达的凭据。Mukul Srivastava 参与编辑的价值，正在于把这个边界写进了可互操作的遥测语言。
IETF
BGP 角色把对等关系变成路由泄漏边界
在交换第一条路由之前，两张网络就可以说明自己如何理解双方关系。RFC 9234 把这项双边声明变成控制：角色不相容时，eBGP 会话可以被拒绝；Only to Customer 属性则能阻止已标记路由继续越过错误的商业边界。协议让意图可核验，却不能证明意图背后的合同是真的。
领导者
Abdiel Marin：眼科临床工作流背后的软件架构
Abdiel Marin 创建 EyeMD EMR 时抓住了一个朴素却苛刻的前提：服务眼科的系统应当贴合诊所的实际工作，而不是要求医护人员迁就通用电子病历的分类方式。他把专科影像、互操作标准、边缘计算和患者流程连在一起；在他退出日常管理后，这套逻辑是否仍能延续，成为观察 Optivate 的关键。
IETF
Cédric Fournet 与一张不能证明日志完整的回执
一张签名回执可以严谨地说明某条记录与某个树状态的关系，却不能因为术语叫作“透明”就替所有未观察到的事件、根和治理决定作证。
领导者
Aaron Moreck 与 NaaS、SD-WAN 背后的网络服务决策
Aaron Moreck 的公开记录把他置于 IntegraONE 网络服务、客户连接、托管防火墙和 SD-WAN 的交汇处。证据显示的是技术决策界面，而不是个人拥有所有客户结果。