摘要

  • RFC 5277 允许服务器在请求起点早于现存日志时，从仍可取得的最早通知开始回放。因此，replayComplete 可以为真，而请求窗口的开头依然永久缺失。
  • “完整”只覆盖该会话实际可见的交集：日志留存、通知流成员、过滤条件和访问控制。订阅获准、消息送达、时钟可信、客户端落盘与业务状态都要另立凭证。

先写出那个没有被回放的区间

RFC 5277 没有要求服务器制造已经老化出日志的通知。若客户端要求的 startTime 早于日志能够支持的时间，服务器从现存最早的通知开始。它发送所有适用于这次订阅的历史通知，然后发出不能被过滤掉的 replayComplete。

这套行为不是异常，而是标准明确容许的结果。错误发生在报告层：操作平台只保存“回放完成”，没有保存“请求从何时开始、实际从何时开始”。一个本来边界清楚的协议断言，被抬升为对整段历史的断言。

管理者首先要问的不是绿灯是否可信，而是绿灯关闭了哪个集合。最少要把请求起点、有效起点、结束点和缺失区间放进同一条收据。缺口不是脚注，也不是失败后才补写的解释；它本身就是调查结果。

RFC 8639 后来更新了订阅通知框架，RFC 8641 则把 RFC 5277 的通知管理模式转换为 YANG。这里讨论的是 RFC 5277 的回放边界，并不把 2008 年的模型描述成今天唯一的通知架构。

日志年龄不是日志生日

回放是可选能力，依赖服务器保留通知。RFC 5277 把保存多少、保存多久交给实现。服务器可以公布 replayLogCreationTime 与 replayLogAgedTime，但这两个时间不能被随意解释。

尤其容易误读的是 replayLogCreationTime。标准指出，日志创建时间可能早于当前仍可取得的最早通知。日志容器可以一直存在，内容却持续滚动老化。因此，“这个日志三个月前创建”不能推出“三个月历史仍在”。

更可靠的证据模型会保存日志代次或重置标识、创建时间、老化边界、实际第一条事件以及留存策略版本。只要实际起点晚于请求起点，系统就应把差值显示为未覆盖，而不是用一次成功状态把它归零。

通知流本来就是现实的投影

RFC 5277 把事件流定义为满足转发条件的一组通知。默认 NETCONF 流包含服务器支持的 NETCONF XML 事件通知；它不是设备内部发生过的一切。非默认来源怎样配置、内部变化怎样变成通知，都不由该标准包办。

这意味着“流中没有这条通知”与“系统中没有发生这件事”是两种不同判断。只有另一个可审计契约能证明某类状态变化必定生成通知、必定进入指定流，前者才有资格支撑后者。

在长期调查中，流定义还会变化。一次软件升级、功能开关或厂商策略调整，可能改变哪些事件属于流，而流名保持不变。收据若只有流名，没有定义版本，就把两个不同的观察面伪装成同一个来源。

过滤与权限塑造每个会话自己的过去

客户端创建订阅时可以提交过滤器。通知元素生成后，服务器还会依据会话的访问权限决定是否交付；无权查看的通知会被丢弃。因此，同一时间段、同一设备上的两个合法会话，可能得到两份不同且都合规的回放。

replayComplete 只结束该会话可见的那一份过去。它不能证明过滤器排除的事件不存在，也不能证明权限策略隐藏的事件不存在。审计材料应保留过滤器原文、认证身份、授权策略代次，以及条件允许时过滤前、过滤后、授权后的计数。

如果调查期间权限改变，再次回放可能出现新事件或少事件。这不一定是日志篡改；它可能只是观察者的权限面改变。没有策略版本，两个合法结果会被错误解释为源系统自相矛盾。

接受订阅不等于收到每条通知

服务器以肯定 RPC 回复接受 create-subscription，只说明请求被建立。之后的通知是单向消息，RFC 5277 没有为每条通知定义确认响应。能力声明也只证明机制受支持，不证明某个业务事件生成了通知，更不证明它穿过网络并被客户端持久保存。

会话中断、缓冲区溢出、解析失败、队列拒绝和落盘失败都位于接受之后。服务器可以正确发送回放及标记，而接收端仍丢失中间一段。因此，端到端结论需要客户端检查点、事件标识或序列证据，以及持久化结果。

标准还区分 replayComplete 与 notificationComplete。前者标记历史回放部分结束；后者在指定 stopTime 的订阅到点终止时出现。把两个标记都翻译成笼统的“完成”，会失去它们各自关闭的边界。

从回放切到实时是一处需要核对的接缝

没有停止时间的回放订阅会先结束历史部分，再交付自订阅建立以来产生的通知，随后进入自然实时流。replayComplete 帮助客户端定位这次切换，却不自动证明接缝处无丢失、无重复、无重排。

需要连续性的系统，应保存生产者代次、可用的序列或事件标识、服务器发送时间、客户端接收时间和持久化时间。eventTime 只是事件源生成事件的时间；它不是网络到达时间，也不证明源时钟同步。按它排出的漂亮时间线，仍可能建立在漂移时钟之上。

一张不会夸大结论的回放收据

对高后果调查，收据至少应包含：

  • 服务器、NETCONF 会话与认证身份；
  • 能力声明、流发现响应、流名及定义版本；
  • 请求的开始和停止时间；
  • 日志创建时间、老化边界、代次或重置标识；
  • 实际观察到的第一条与最后一条历史通知；
  • 过滤器原文和授权策略代次；
  • 订阅 RPC 结果、服务器侧订阅标识；
  • replayComplete、notificationComplete 及客户端接收时间；
  • 回放到实时的接缝、已知重复和缺口；
  • 源 eventTime、发送、接收、解析与落盘结果；
  • 用来核验通知结论的权威状态或最终业务结果。

准确的结论应写成：“在 B 到 C 之间，对该流、过滤条件和授权会话可见且仍被保留的通知已经回放完毕。”删掉这些限定，不是让语言更简洁，而是改变了证据所能承受的含义。

Sources