时间范围
Immediate to Medium
在时间范围维度下，Immediate to Medium时间跨度情报按信号预计产生影响的时间段组织文章。该页面帮助读者区分即时运营变化与可能需要数季度或数年才会逐步显现的长期治理、投资、标准和基础设施变化。它将时间预期与公开证据、相关方、市场背景、客户影响、政策压力和基础设施规划联系起来，以便读者判断某项动态是紧迫、具有战略意义，还是仍在等待证实证据。页面还解释了时间跨度如何改变信号的含义、哪些组织可能面临风险，以及哪些基础设施决策需要短期行动或长期监测。
ICANN
ICANN董事会自评将“Delegation of Authority”留给BGC继续审议
ICANN 的 Board Governance Committee 将董事会自评议题与 Board Efficiency Work Team 的工作对照，决定让“Delegation of Authority”继续由委员会跟进；其他重叠事项则无需重复审议。
IETF
WebAuthn 2026 重启周期：从重新加入到专利承诺交接的制度化证明链
2026 年 9 月 11 日，W3C 宣布 Web Authentication Working Group 新章程获批并生效。真正需要被管理的，并不是一次简单的技术路线更新，而是一场参与资格、工作范围与知识产权承诺之间的制度交接。新章程开启了新的工作周期，也要求既有参与方重新确认其在扩展范围下的参与和 Patent Policy 承诺。未来两年的治理质量，将取决于能否清楚区分章程生效、宽限期参与、正式重新加入以及专利承诺更新这四种不同状态，并建立一套隐私安全的重新加入与承诺收据机制。
IETF
Web4 政策草案把“发布”与“行为证明”分开
一份政策可以拥有有效签名、明确版本和“当前生效”的状态，却无法凭这些条件证明运营者真的兑现了申诉、删除或撤销承诺。一份新提交的个人 IETF 草案把这种差距写进设计：机器可以核验声明，但不能把声明自动升级为行为证据。
IETF
SAV 基准草案要求说明每个“合法”数据包为何合法
实验室可以把转发与拦截计数到个位，却未必能同样精确地说明一个源地址为什么应当被接受。IETF 一份 SAV 基准草案的新修订把这个先于测量发生的判断写进报告义务：合法与伪造不再只是测试流量的预设标签，而是需要交代理由的事实主张。
IETF
Agentproto 章程修订把外部输入与 IETF 决策分开
同一个协议依赖，从外部进入时是证据，经过 IETF 程序后才可能成为决定。Agentproto 拟议章程 00-01 新增了与外部标准组织和开源项目协调的要求，却把“决定如何处理协议变更”留给相关 IETF 工作组。这不是文字上的客气，而是一条防止参与被包装成授权、也防止标准机构越界指挥外部项目的治理边界。
IETF
CMS 草案把未来发布日期定为新旧用途的分界线
规则写得明确，并不等于受规则影响的对象已经清楚。LAMPS 工作组 9 月 14 日发布的新修订禁止 CMS SignedData 的“新用途”继续使用 `id-data`，却以未来正式文件的发布日期定义“新”，同时又用已部署实现解释不追溯原则。规范时间与部署时间不能混成一条线。
IETF
RPKI 草案把阈值设定权交给注册局政策
一项 RPKI 委托 CA 运维草案在第 02 版里改动了几组大写词，也重新分配了权力。99.5% 可用性、十秒响应和单一撤销时限不再全部是全球硬指标；草案保留共同技术底线，却要求各注册局选择、公布并解释真正触发执法的数字。
IETF
AIPREF 里“允许搜索”可以压过“禁止训练”
AIPREF 词汇草案第 08 版把一组容易误读的选择写成了明确的优先规则：发布者可以拒绝一般性的 AI 训练，同时允许搜索服务为检索目的训练或使用内部模型。这个例外只存在于严格限定的搜索活动中，既不是开放训练许可，也还不是 IETF 共识。
IETF
RDAP 扩展为注册申请固定了参照文本
可靠性评估扩展的最新修订没有改动线上数据格式，而是为名称注册请求提供了一份独立、冻结的规范。文本稳定性有助于互操作，却不能替代 REGEXT 的采纳决定，更不能替运营者决定如何使用评估结果。
IETF
一条有效的 OAuth 链无法证明自己从何处开始
一串签名可以证明眼前的经纪节点没有被换位或篡改，却不能替最前面的节点补出此前的历史。OAuth 授权请求委托链草案第 01 版把这条边界写得很清楚：链首是否可信，最终仍是本地治理决定。
IETF
一个比特位能扩展 IKEv2 载荷头，却不会承诺对端内存
协议里的“支持”常被误读成资源许可。IPSECME 正在跟踪的一份候选草案建议用一个 Large 位扩展 IKEv2 载荷长度；它能让接收方知道该怎样解析报文，却没有告诉发送方可以占用多少内存、计算时间和并发槽位。真正的接纳边界仍由实现和运营策略掌握。
IETF
电源状态清单不会自行让线卡休眠
一张线卡可以在清单中标明休眠能力、额定功耗差和最坏唤醒时间，但清单不会判断它此刻能否退出服务。9 月 10 日更新的一份 YANG 个人草案，把设备“能做什么”描述得更清楚；至于谁有权下令、设备是否接受、节电是否发生以及业务是否受损，仍需另外留下运行证据。
IETF
security.txt 新草案分开了收件箱，却没有划清产品边界
研究人员拿到的是一台设备、一个固件版本和一条漏洞路径；厂商网站给出的却只是一个联系入口。邮件成功送达，不等于收件团队已经承认这件产品归自己负责。9 月 10 日出现的一份个人 Internet-Draft，试图把产品漏洞报告与网站基础设施报告分流，但真正的产品责任边界仍留在下一步。
IETF
SMTPUTF8 草案把“看不见的字符”纳入邮箱地址准入
客服截图里是同一个邮箱地址，数据库却说它们不是同一串字节。只要其中一串夹着一个在当前字体里不占可见位置的 Unicode 码位，两种说法就可以同时成立。IETF 一份草案的第 05 版，正把这种差异前移到地址能否被接受的判断中。
IETF
MPLS-IOAM 把未知负载均衡变成一项 19 位约束
“不知道设备怎么做散列”不是一句无害的运维注脚。若 MPLS 节点把标签栈内容纳入负载均衡，原本用来观察报文的递增序号也可能反过来影响报文走哪条路。IETF 一份草案的第 14 版为这种未知状态补上了明确边界：同一流中有 19 位不能变。
IETF
一场命名空间冲突让两项 PCEP 错误在 IETF 电话会议前消失
错误编号只有和所属协议、消息类型及登记表放在一起，才有确定含义。IETF 柔性光栅 PCEP 草案的第 17 版删掉了两项拟议错误：评审发现，它们借用了 RSVP-TE 的说法，却要落进 PCEP 中已经分配给另一类故障的 24 号位置。
IETF
DKIM2 的“未对齐”标志可让豁免被记成“通过”
安全系统最容易误导人的时刻，往往不是它显示失败，而是两个性质不同的决定被涂成同一种绿色。`draft-chuang-dkim2-sender-policy-01` 为 DKIM2 的 `unaligned` 标志补上了前置证据，却仍让“确实完成对齐”和“获准不检查对齐”共同落入 `pass`。这不是一个措辞小节，而是一条决定日后能否被审计的治理边界。
IETF
有效签名不能证明审批人看见了什么
当一笔高风险操作进入争议阶段，“签名验证成功”往往会被当成终点。可签名只回答密钥签过哪些字节，屏幕呈现、人的感知以及组织授权分别属于另外三层。最新一版个人互联网草案主动收窄了自己的结论，也把真正的治理责任重新显露出来。
IETF
草案内的知识产权说明，不等于 IETF 披露记录
一份仍处于个人草案阶段的 OAuth 提案，在第 05 版中加入了具体的专利与许可说明。信息本身值得实施者关注，但它同时暴露出一个治理断点：草案称 Datatracker 的正式披露才具有权威性，而在本次截点查询中，草案与正式披露记录之间尚未出现可见关联。
IETF
签名访问意图，不能证明机器人之后如何使用内容
一份新的个人互联网草案试图把网站与自动化客户端之间的约定变成可验证的交互：机器人先申明来意，按需提交用户授权或支付凭证，网站交付内容后再签发收据。密码学可以固定这次交互，却无法替未来行为作证。这条界线，正是 `terms.txt` 提案最值得关注的治理信息。