摘要

  • draft-ietf-opsawg-collected-data-manifest-14 为遥测数据保存平台、订阅与实际采集周期等上下文，解决“已收到的数字应如何解释”的问题。它仍是处于审议中的 Internet-Draft，不是 RFC 或部署证明。
  • 草案明确承认一个边界：Data Manifest 本身也是数据，它的采集可靠性与遥测采集相同。因此，存活的清单可以解释存活的数据点，却不能证明预期的数据点或中间清单版本都曾抵达。
  • 对容量、故障、安全或自动化决策，运营者应在这条共同采集路径之外保存精简的采集连续性回执，连接订阅意图、实际周期、序列或到达节奏、清单版本、会话边界、重建来源、缺口处置与责任人，而不复制原始遥测。

空白最容易被误写成一个值。折线从 42 降到没有点，图表库可能把线断开，也可能补零，也可能延续上一个值。三种画法会给人三种因果感受，但数据库里真正存在的事实只有一句：在预期窗口内，没有可用数据点。

如果分析者随后找到空白前后的 Data Manifest，他能回答不少问题：数据来自哪个平台，平台运行什么版本，订阅使用什么过滤条件，实际采集周期是否与配置值不同。仍然回答不了的是：空白期间应该有几个点、它们是在设备端没有生成，还是在传输、收集或存储环节消失，以及解释这些点的清单更新是否也一同丢失。

这正是治理边界。上下文让证据更可读；连续性回执让“没有证据”不被悄悄改写成“证据为零”。

先肯定清单解决的问题

网络遥测常把计数器与来源环境拆开。几个月后，分析者还能看到接口字节数，却不知道设备型号、操作系统、软件变体、YANG 模型或订阅选择是否已经改变。同一个数，在十秒采样和六十秒采样中代表的观察能力不同；在不同软件版本中也可能受已知行为或缺陷影响。

第 14 版草案把 Data Manifest 分为两部分。规范性的 Platform Manifest 描述产生遥测的平台。Data Collection Manifest 描述数据怎样、何时被度量；由于设计时的 YANG Schema Mount 能力尚不具备，它被放在附录中作为非规范性示例。两者合起来，目标不是暴露新的业务数据，而是让已经采集的数据保持可解释。

草案还为 YANG-Push 增加只读的 current-period。平台可能因负载提高而自动拉长采集周期，不一定直接拒绝原请求。若系统只保存配置周期，分析者会误以为缺点来自丢包或错误；若能看到平台当时报告的实际周期，至少可以排除一种混淆。

清单需要随数据一起传输、一起进入数据库，并在路由器升级、新建订阅或订阅参数变化时更新。草案把清单本身视作时间序列。这一点很重要：今天的设备清单不能自然覆盖昨天的测量。

current-period 说明当前状态，不自动生成完整历史

假设订阅配置为每十秒一次，平台在 12:00 因过载将实际周期调整为六十秒。如果 current-period 更新先于稀疏数据抵达，空白有了清晰解释。如果更新在 12:03 才被收集，分析者只能知道 12:03 时的状态，不能倒推出调整究竟从哪一秒开始。如果更新与遥测一起丢失，后来看到六十秒也不能证明中间没有出现过别的周期。

只读并不等于自动归档。字段的历史取决于它的变化能否被采集、传送和保存。Data Manifest 可以作为时间序列，但展示两个存活版本并不能证明序列中没有第三个版本。

草案在这一点上非常坦率：清单采集的可靠性与数据采集相同，因为清单也只是数据。复用同一套遥测系统降低了实现成本，也让上下文紧贴数据；代价是二者共享故障域。解释渠道失效时，用来解释渠道的记录也可能失效。

因此要把两个问题分开。Data Manifest 回答“收到的点是什么意思”。运营治理还要回答“为什么当时预期有点、缺点由什么证据发现、原因最终如何判定”。

三个坐标能找到最近版本，却不能证明版本链无缺口

草案用三个坐标把数据点关联到清单：设备发送时间、源平台标识与订阅标识。查询时，系统找到时间戳之前最新的 Platform Manifest，再找到同一平台和订阅下最新的 Data Collection Manifest。

这个规则务实而清楚，但它只在数据库已知记录上运算。若 M1 在 12:00 入库、M3 在 12:10 入库，那么 12:07 的数据会关联到 M1。若 M2 在 12:05 改过过滤条件，却在途中丢失，“最新已知版本”仍会给出形式正确、实质不完整的答案。

平台标识也有边界。草案指出，当前用 hostname 标识的往往是角色，不一定是一块特定硬件。另一处更能说明“验证通过”与“信息充分”的距离：实现被要求至少支持 yang-catalog 或 ietf-system 中的一项功能，但 YANG 模式无法表达或检查“至少一项”。两项都不开启的模块仍可能通过模式验证，却只提供一个平台标识。

模式有效、上下文有用、历史完整，是三个不同判定。把它们合并，就会让工具的成功承担它没有接受的责任。

会话终止是边界证据，但前提是它被收到

Platform Manifest 在一次流式会话内通常较稳定。设备重启时，subscription-terminated 可以标记订阅终止；重新建立订阅后，收集器必须获取可能变化的平台清单。若终止通知、重连与新清单都保留下来，一个新采集时期的边界就很清楚。

若只剩重连，故事仍有多个版本。终止通知可能发出后丢失，传输可能在通知抵达前中断，收集器自己也可能重启。恢复后的第一个点证明恢复后的状态，不证明此前的完整过程。

RFC 8641 为 on-change 更新提供了一个有用线索：当 patch-id 被用作递增计数器时，跳号或乱序能帮助识别丢失记录；重新同步或计数回绕时需要归零。“当它被用作计数器”是必要限定。这个机制不是所有实现与所有流的完整性保证；发现断点也不等于已经知道断点发生在哪一层。

签名保护存在的对象，不能替不存在的邻居签字

Data Manifest 草案把完整性与来源问题交给 YANG provenance 草案。后者以 COSE 对 YANG 数据签名，并可通过会签记录多个主体对同一对象的保管。这能帮助分析者确认一份清单由谁签署、内容是否改变。

签名的结论必须停在对象边界内。M1 的有效签名支持 M1 的来源与完整性，不证明 M2 从未存在。一个数据点的签名能保护这个点，不证明预期的相邻点全部抵达。对不完整集合签名，得到的是“这份集合未被改动”，不是“世界上没有遗漏”。

当设备尚不支持清单模块时，第 14 版允许收集器从标准或厂商特定的多个 YANG 模块中组装清单。这是合理的过渡办法。回执需要诚实标记它是平台直接产生还是收集器组装，并保存组装时间、使用的观察、未知字段与责任人。两种来源是 provenance 状态，不应被偷换成好坏判断。

为负空间保存一张采集连续性回执

回执不应成为第二套原始遥测库。它只保存对重要结论不可缺少的连接关系：

  • 申请了什么订阅、过滤条件和周期，以及平台接受、调整或拒绝的证据；
  • 平台报告的 current-period，以及该报告实际被观察到的时间窗；
  • 序列号、预期到达窗口或其他节奏证据，并注明检测能力边界；
  • 实际收到的清单版本标识或哈希，及平台生成、收集器组装或混合来源；
  • 订阅终止、设备重启、重新同步与重建订阅等时期边界；
  • 设备发送、传输接收、收集器入站与数据库落盘的不同时间；
  • 每个缺口仍然成立的解释、调查进度、最终处置与置信度；
  • 决策责任人、申诉路径、纠正记录，以及因证据不足而撤回的自动化动作。

回执必须允许结论为“尚无法区分”。on-change 流没有点，可能只是没有状态变化；周期流变稀，可能来自已报告的周期调整；订阅明确终止后，本来就不应继续期待数据。控制的目的不是把每个空白都升级为事故，而是先记录什么期待在何时有效。

这张回执应处在不同故障域，却不能脱离安全约束。平台版本和能力信息可能帮助攻击者，草案因此要求访问控制。回执可以使用假名化标识、哈希与时间窗，避免复制接口内容或完整平台明细；运营访问与审计访问也可以分离。

不要把窄范围误解为标准遗漏

草案明确把采集后的数据 lineage 排除在范围外。这个界线合理。若一份标准同时承担平台目录、采集配置、传输完整性、存储保管、每次分析变换、模型训练和最终授权，它会失去可实施性。

第 14 版已经做了多项克制而重要的工作：实际周期而非只有配置周期；可随时间变化的清单；以时间、平台和订阅完成回溯关联；会话重建后的刷新；敏感信息访问控制；以及签名来源路径。最关键的是，它没有掩饰共同可靠性边界。

采集连续性回执因而是运营者在标准旁边承担的本地控制，不是本文替 IETF 写入的新规范。它只应用于空白会影响容量、安全、客户或自动化决定的场景。

截至研究截止时间，第 14 版仍是目标为 Proposed Standard 的活跃 Internet-Draft，当前页面显示 AD Evaluation 的后续处理，未安排 telechat。评审历史是仍在推进的过程，不代表拒绝、批准或已有命名部署。

清单让到达的数据点可以被正确解释。回执让未到达的数据点不能被随意解释。

来源