档案
Research
Research档案页面汇集了人物、公司、机构等实体的情报，帮助读者对比BTW.MEDIA报道中的相关主体。通过该页面，读者可以对比公开档案、相关事件、证据材料、角色变动、运营足迹、治理风险、组织联系以及市场关联性，同时将机构与人物记录同普通新闻时间线区分开。读者能理解新闻标题背后的主体、支撑档案的证据，以及使该档案具有重要影响的基础设施或市场关系。也可以看到档案所代表的主体是谁或是什么、依据哪些公开来源、它如何与公司、市场、治理机构或事件连接，以及随着主体演进，哪些变化值得持续关注。
案例档案
四千是前缀声明，不是放宽限流的命令：RFC 9977 的证据边界
一份前缀文件可以让地址分组更精细；它不能把发布者对端站数量的陈述变成服务方必须接受的例外。
ICANN
ICANN Ombuds 工作计划已经公开，董事会评估对照表却没有
ICANN 已经公开说明 Ombuds Office 在 2027 财年要做什么，也列出了六类绩效指标。董事会随后又批准了一组用于评价 Ombuds 的“具体目标”。公开记录里真正缺失的，并不是计划或数据，而是把这两套对象逐项连接起来的对照表。
报道
RIPE NCC 正在修订 RIS 对等策略：归档也应留下选择凭据
一份路由档案的边界，往往在下载它的人看来最不显眼。页面上的曲线、可检索的更新报文和一张对等列表，容易让人把“已收集”误读成“已看见”。RIPE NCC 在 RIS 2026 年第三季度计划中反而给出了一个更诚实的起点：正在更新和澄清对等策略；这项工作曾因资源限制延后；目标是在可持续的数据增长之内，维护一份相关且多样的长期档案。
案例档案
证书验证了对端，外部 PSK 仍需要保管人：RFC 9973 与 TLS 权责
设备接入记录上可能同时出现三行漂亮的结果：证书链通过、外部 PSK 被选中、TLS Finished 成功。把它们读成“这台设备已被完全信任”，往往是事故的起点。证书回答的是谁能够完成签名验证；PSK 参与的是哪些秘密进入会话密钥；而制造、交付、备份和运维环节中到底还有谁保有那份 PSK，则是另一条尚未回答的控制链。
报道
LACNIC董事会有九名成员，其公开简介仍写七名
机构网页里最危险的往往不是长篇章程，而是一句很短、很容易被复制的话。LACNIC 当前的英文董事会内容记录恰好留下了这种错位：描述字段仍称荣誉董事会有七名董事；同一记录的正文却写明董事会由九名成员组成，并以“截至 2026 年”列出九名有投票权的董事。执行董事另列，明确为无投票权参与者。这不是对董事会构成或程序有效性的指控，而是一项更窄的观察：同一公开记录让读者得到两种不相容的摘要。
案例档案
标志说明多个路由器意在公告该前缀，却没有指出哪一台正在工作：RFC 9983 与 Anycast 证据
一个前缀由多个节点公告，可能是精心设计的 anycast，也可能只是拓扑、迁移或配置留下的表象。RFC 9983 给 OSPFv2 增加的并非“服务正常”判定，而是一个更克制、也更有用的共同事实：该前缀意在由多个节点公告。
案例档案
Cookie 随请求而来，却没有替任何人作出决定：RFC 10025 与环境式权限
一笔高风险操作可以同时具备看似无可挑剔的条件：浏览器走了 HTTPS，请求带着正确的 Cookie，服务器查到了一个仍存在的会话，并返回成功。这个组合仍不能回答：是谁促成了此刻的请求，服务端是否仍接受这段会话，该操作是否获得当前授权，以及最终效果是否真的发生。RFC 10025 规范的是浏览器状态的存取边界，不是把这些问题压缩成一行请求头。
案例档案
一套理事名单，两块董事会：Internet Society 的每项决定都应标明行为身份
Internet Society 与 Internet Society Foundation 由同一批理事监督，这让两家机构能够共享全局视野，却不等于两块董事会在法律上合二为一。2026 年两份前后相接的议程还揭示出第三条权力路径：Internet Society 以基金会唯一会员的身份行事。
案例档案
密文抵达了密钥，却没有指认发送者：RFC 9180 与 HPKE Base 模式缺失的授权
接收端用正确私钥打开一段 HPKE 密文，只能说明一项受限的密码学事实；它不能自行说明是谁发出、为何当时有效、外层请求代表什么，或系统是否应当据此行动。RFC 9180 把这些责任留给采用 HPKE 的应用，而不是假装由一次解密替代。
案例档案
MPLS 包里写着“执行动作”，并不等于网络已经同意执行：RFC 9994
一台设备在 MPLS 标签栈里看见了 Network Action Sub-Stack：有动作指示符、有 opcode、有附属数据。它可以解析这段结构，却仍可能不具备处理该动作的能力、不在该动作的适用范围内、无法在所需标签深度读取它，或因本地规则而跳过甚至丢弃该包。RFC 9994 解决的是动作怎样被放进标签栈，而不是谁因此失去本地判断权。
互联网历史
每转发一次就多长一个连字符：RFC 934 与递归转义的代价
一封被转发的旧邮件若要仍可被处理为旧邮件，就必须既处于新信的正文里，又不能被新信的分隔规则误判。1985 年的 RFC 934 为此给出一个很小、也很诚实的动作：遇到可能被外层当作边界的行，在前面加上 `- `；解包时只撤销这个外层添加。它保住了内容的可恢复性，却没有让中间形态免费。每多一层封装，保护用的前缀就再长一层。后来 MIME 改变的，正是这种成本由谁承担。
报道
ARIN让五项服务继续可用，却暂停发布更新：其服务水平报告没有新鲜度一栏
“可用”这个词在运维页面上很有力量，但它常被读成一个并未作出的承诺：既然查询成功，眼前的记录一定已经反映了最新的权威状态。ARIN 在一次计划维护中恰好把两件事拆开了——五项面向读取的服务继续运行，更新却不再发布。真正需要公开的不是更响的告警，而是两只不同的钟。
案例档案
发送方标了优先级，接收设备仍须决定是否执行：RFC 9993 与触觉渲染权限
RTP 载荷里的 Layer 可以告诉接收方：发送端认为这一触觉单元对体验更重要。它不能告诉接收方：这位用户现在适合感受它、这个致动器仍在安全范围内，或本地的急停是否已经切断输出。优先级是媒体排序，不是越过本地安全边界的权力。
案例档案
收到一条 KV TIE，不等于接受一个网络事实：RFC 9992 与 RIFT 的权限边界
一台设备收到格式正确的 RIFT Key/Value TIE，可以转发它、解码它，甚至在本地保存它。每一步都可能成功，但仍没有哪一步自动回答：这条值是否可以影响路由计算、控制器、FIB 或真实的数据包。RFC 9992 的价值，正是把这个常被自动化抹平的间隔写进标准边界。
案例档案
私钥没有离开，调用权却越过了边界：RFC 9987 与 SSH Agent Forwarding 的传递信任
“私钥从未离开终端。”这句话可以完全正确，也可以遗漏事故中最重要的事实。若远端进程能够通过转发的 SSH agent 请求一次新签名，它不必复制私钥，也能借用私钥完成一次身份认证。
案例档案
发现失败，不等于获准发送原文：RFC 9991 与 DMARC 取证披露边界
邮件系统可以准确发现一封信的 DMARC 对齐失败，却没有因此自动获得把信件正文、收件人和转发路径交给域名所有者的权力。RFC 9991 建立了细粒度失败报告的共同格式，也把最重要的一步留在接收方：先决定哪些证据可以离开自己的边界。
案例档案
SC100 草案把 DNSSEC 边界落在主网络视角，回执必须点名它
一条记录写着“DNSSEC 验证成功”，看似已经回答了安全问题，其实可能漏掉最关键的主语：是谁、从哪个网络视角完成了验证？SC100 草案把既有义务集中到一个更清楚的边界——必须执行 DNSSEC 的是主网络视角；远程网络视角可以执行，但它们在 MPIC 中首先承担的是独立佐证。结果若脱离角色，就不能证明应当履责的角色真的做了那次查询。
报道
APNIC执行理事会启用议题“Shepherd”，公开记录却没有角色章程
一项复杂议题要在两次理事会会议之间继续推进，总得有人记得上次谈到哪里、哪些材料还欠缺、下次该把什么带回集体讨论。APNIC 执行理事会在 2026 年 5 月给出了一个务实答案：为重点议题设置“Shepherd”。但一名成员“带领讨论”究竟能做什么、不能替理事会做什么，冻结的公开治理页面尚未给出共同定义。
案例档案
SC101 堵住域名控制缺口，过渡期却允许两套规则并存
到了 2026 年 9 月，一家证书颁发机构说自己“遵守现行 TLS Baseline Requirements”，这句话仍然不能告诉审计者它用了哪套域名控制算法。现行 v2.2.9 已经写入更严格的顺序，但同一份文件又明确允许 CA 在 11 月 15 日前继续采用 v2.2.7 的对应条款。过渡安排本身合理；若签发记录把版本选择藏在一句“符合现行要求”里，日后便无法还原授权边界。
案例档案
标签通过了，含义仍未获授权：RFC 9996 与 Protobuf schema 的控制边界
一条消息可以拥有完全正确的 `Content-Type`，也可以被解析器毫无报错地读出，却仍被系统理解成另一件事。RFC 9996 解决的是 Protobuf 序列化形式的公共命名问题；它没有替应用选择 `.proto`、证明 descriptor 的来源，更没有替运行中的服务决定这份对象能否改变现实状态。