摘要

  • RFC 9922 为基于日期和时间的排程提供可复用的 YANG 类型与分组。enabled、last-occurrence 和 upcoming-occurrence 说明的是排程表面，不是某次动作的回执。
  • 该 RFC 不假定被排程触发的动作性质，也不处理冲突检测或裁决。授权、调用、执行、回滚和结果须由本地系统分别作出并留下证据。

晨会上最容易出现一种省事的结论：“这个维护任务已经开着，下次窗口也算出来了，所以自动化会把事情办完。” 屏幕上的信息没有错；把它拼成这个结论，才越过了信息本身的边界。

屏幕记录的是排程。它可能准确地给出规则版本、时区、上一次和下一次发生时间，甚至还保留失败次数。它没有告诉读者哪个消费该模型的模块把这个排程关联到了何种动作；没有说明届时谁有权发起该动作；没有给出目标、请求 ID、响应、补偿或独立的效果观测。缺少的不是格式化报表，而是另一串事实。

RFC 9922 的价值，恰在于它没有把这些不同事实假装成同一件事。它定义的是用于事件、策略、服务和资源排程的共同 YANG 语言：周期、重复、UTC、时区、周期列表与来自 iCalendar 的规则形式均可被共享。共同语言使不同系统对“什么时候”形成可互操作的理解；它不产生一个执行引擎，也不替任何本地制度作决定。

读状态字段，而不是替字段补写故事

schedule-status 可包含状态、版本、排程类型、主机本地时间、最后更新、重复计数、上一次发生、下一次发生、上一次失败发生与失败计数。它们适合观测和排障，但每一个词都应按自身含义使用。

对于重复排程，只有状态为启用时才可提供 upcoming-occurrence。这表示承载该模型的系统已按当前规则算出下一次发生，并不表示届时执行器存在、资源仍可用、请求会获得权限、目标会接受操作，或动作会成功。last-occurrence 则指向一次此前的排程发生；RFC 专门把它与 last-failed-occurrence 区分开来。二者都不是动作标识，也不携带目标响应或结果测量。

结构上的界线更清楚。ietf-schedule 模块本身只定义身份、类型和分组；单独使用时没有可写数据节点、只读状态节点或 RPC。它不是会改路由、备份配置、分配带宽、轮换密钥或关闭工单的执行器。引用该共同词汇的模块必须自行定义上下文，并为其自身的安全影响负责。

RFC 9922 明确表示，它不预设排程所触发动作的性质；冲突的发现和解决也不在范围内。这不是欠缺的工作流功能。两个时间窗口冲突时谁让步、紧急例外如何被许可、哪项服务优先，以及窗口打开后具体要做什么，都是承受后果的本地参与者必须作出的选择。

从时间计算到可证实结果，中间隔着四层记录

可审计的受控变更至少需要分开保存四类材料。第一类是时间定义：规则、版本、时区、例外、时间源和计算出的发生时间。第二类是本地授权：主体、范围、适用的策略和决定。第三类是执行回执：不可变动作 ID、目标、开始与结束、响应或错误、回滚或补偿状态。第四类是效果证据：从排程器和执行记录之外独立观察服务或资源是否真的达到承诺状态。

四类信息可以各自真实却互不推出。时钟漂移会让发生时间计算得不对；排程仍为启用时，负责调用的工作进程可能已经停止；请求按时到达却被策略拒绝；目标可能确认请求，而随后的验证又拒绝了预期状态。RFC 9922 特别提醒不准确的时间同步会在错误间隔触发事件，过于频繁的重复会掩盖异常活动，缺少触发和动作结果的详细日志会令事后追溯困难。

RFC 8413 提供了相邻但不同的例子：对未来资源状态的计算能帮助计划 LSP，但实际请求时可用性仍只是尽力而为，运营者策略可能拒绝计算请求，之后的实例化和信令又是另一阶段。它并非 RFC 9922 的实现，而是说明“算出的未来”不能替代政策决定和已实现资源状态。

安全管理会话同样不是动作结果。RFC 9922 要求 YANG 管理使用安全传输与相互认证；RFC 8341 的 NACM 则分别控制操作、数据、动作和通知的访问。能够读取排程的认证会话没有自动取得执行动作的权力；一项获准的协议操作也没有自动证明其物理或服务效果。

卢恒关于运行代码优先的判断在这里可以转成一个简单的检验：模型、页面和状态字段属于表示层；真正的控制是那条会校验时钟、在调用时查询本地策略、携带动作 ID 抵达目标、记录响应并验证效果的可运行路径。薄而确定的共同层很有价值，前提是它不被仪表盘夸大为已经发生的现实。

来源