摘要

  • IETF《采集数据清单》草案第 15 版不再把 current-period 视为没有特殊敏感性的普通只读字段。它表示周期性更新的实际间隔，可能让持有清单的人推测采集节奏以及间隔中的空档。
  • 新版还区分了 NETCONF／RESTCONF 读取权限与数据进入下游时序数据库之后的权限。9 月 24 日的安全审查认为草案文字已充分回应相关问题；这并不等于 IESG 批准或生产系统已安全部署。

运营人员需要知道设备究竟按什么节奏上报。订阅时要求十秒，并不意味着设备负载升高后仍能十秒更新；如果实际周期变长，不说明这一变化，就可能把正常降频误判成链路丢包或软件故障。current-period 解决的是解释数据的难题。它也是一项有关观测能力的情报：知晓更新间隔的人，可能据此寻找较难被采样覆盖的时段。

这里的新闻并非 IETF 新发明了这个字段。第 14 版已经定义实际周期，并说明它与请求周期可能不同。真正变化的是安全定性。旧版甚至写道，这个模块没有特别敏感的可读节点；第 15 版则明确指出，实际周期可能暴露采集时间表，攻击者若得知何时没有采集，可能把恶意活动安排在间隙里，以降低被发现的概率。草案说的是一种有条件的风险，不是对任何已发生入侵的通报。

还必须把推断的边界说清。一个周期数值本身既不提供所有采样点的精确时刻，也不证明网络在两次更新之间完全没有其他监控。能否据此找到可利用的空档，要看采集方式、其他时间线索和清单的可见范围。因此，合理的治理问题不是“禁止报告周期”，而是逐项判断谁需要这个周期、在什么系统里需要、保留多久。

修订过程提供了直接证据。9 月 1 日，安全领域审查第 14 版时提出三项关切：采集周期的披露风险、某些系统是否真的能实施细粒度过滤，以及不应一股脑上报敏感元数据。第 15 版将这些关切落在安全章节；9 月 24 日的后续审查给出“Ready”，认为平台细节和采集时间信息的保护问题已在草案中得到充分处理。这是审查意见，不是标准获批。IETF 最新记录仍显示它是拟定为 Proposed Standard 的有效 Internet-Draft，IESG 状态为等待负责领域主管推进。

新的文字同时承认权限边界不会自动随数据复制。通过 NETCONF 或 RESTCONF 读取 YANG 节点，可以在安全传输、双向身份验证及 NACM 模型下限制访问；可是清单和样本往往还会进入时序数据库。数据库的权限粒度可能粗糙，甚至缺乏适用控制。草案建议尽可能保护留存数据，并在特定部署里不报告会暴露敏感信息的元数据。完整性签名或来源证明也无法代替保密：被允许读取的人仍会看见周期。

这与此前关于“从未到达的数据点”的分析不是同一问题。那篇讨论清单与遥测数据共同失效时，完整性证据的缺口；这篇讨论清单成功到达之后，解释能力本身可能产生的披露成本。两者都不能靠一个勾选了“已记录”的状态来解决，但决策位置并不相同。

来源