YANG 计划有效，不代表动作仍获授权

Summary

RFC 9922 为日期、时段、循环、校验与状态定义了可复用的 YANG 类型和分组，但明确不规定被触发动作的性质，也不负责解决计划冲突。一个计划可以显示“已启用”和“当前版本”，却没有共同字段说明谁仍有权让动作发生。
Daniel Kade 建议在每次触发时生成“发生次授权凭据”，把计划版本、动作与目标、机构责任主体、现行策略、执行主体、时间依据和结果连接起来。这是运营治理建议，不是 RFC 9922 的规范要求，也不指控任何已知部署事故。

时间规则没有保存组织变化

计划系统的价值，正在于把决定和执行拆开。资源可以提前预留，维护可以等到低峰窗口，测量可以按固定频率反复运行，不必每次都等某个人上线确认。

然而，计划和机构拥有两条不同的时间轴。计划记录开始、结束、循环、版本和下一次发生时间；机构则经历人员更替、职责转移、权限收紧、目标升级和政策修订。后一条时间轴发生变化时，前一条时间轴未必出现语法错误。

于是，屏幕上可能同时出现几个绿色判断：循环表达式有效，下一次发生仍在允许区间，服务器时钟可信，资源没有冲突。它们共同证明调度器理解并遵循了储存的规则，却没有共同证明机构今天仍然愿意承受该动作的后果。

这并不要求恶意行为。最普通的组织迁移就够了。老服务账户在过渡期内继续可用，计划按原定义执行，接手团队以为前任已经清理。真正缺失的不是时间字段，而是一个可核查的回答：这一次发生究竟代表谁的现行决定？

RFC 9922 中“有效”的准确边界

RFC 9922 于 2026 年 3 月作为 IETF Standards Track RFC 发布，是经过公开评审和 IESG 批准的 IETF 共识文件。它定义 ietf-schedule 模块，提供用于按日期和时间安排事件、政策、服务或资源的共同类型和分组，既支持一次性时段，也支持简单或接近 iCalendar 的复杂循环。

文件主动限制了自身范围。它不假定计划会触发什么动作；计划之间的冲突检测与解决也在范围之外。这个共同模块本身没有暴露可写数据节点、只读状态节点或 RPC，实际模块需要引用、细化或扩展这些分组。

这种模块化不是缺陷。告警、OAM 测试、资源预约和破坏性配置动作不应被一个循环库强制套用同一套授权制度。责任落在将时间规则接到具体动作上的消费模块和运营制度。

generic-schedule-params 中的 validity 有严格的时间含义：超过该时点后，计划不能再启动，之后的发生次不执行。最早或最晚开始、最晚结束和丢弃动作进一步限制计划请求。

这些字段回答“什么时候还能运行”。它们不记录谁批准了动作、创建者是否仍代表现有服务主体、执行时应采用哪一版权限策略，也不说明目标性质改变后是否需要再次决定。时间有效性可以与机构授权同时成立，却不能替代它。

NACM 保护请求，但未来触发必须指明主体

RFC 8341 定义 NETCONF 与 RESTCONF 的网络配置访问控制模型 NACM。传输层验证用户，服务器把会话与用户名和组联系起来，并在开始处理消息时采用当时生效的访问规则。NACM 能保护计划的创建、修改和删除，也能保护消费模块暴露的动作或数据。

因此，不能把本文的差距说成“YANG 没有访问控制”。真正的问题是时间错位：几个月后由服务器或控制器触发的动作，以谁的身份执行？

RFC 8341 主要描述用户会话发起的请求，并指出某些服务器主动访问不按用户会话请求执行同样的检查。这并不决定所有调度实现的行为。消费模块可以把发生次建模为新的受控动作，可以使用服务主体，也可以保存一个有边界的机构授权。

每种选择都可能合理。备份计划不应因为最初管理员调岗就停止；涉及密钥、路由、稀缺资源或高风险配置的动作，在目标或政策变化后可能必须重新决定。危险不在于选择了某种延续规则，而在于规则完全隐形。

还要区分四个角色：输入计划的人、对服务负责的机构、真正执行的技术主体，以及批准后果的权力主体。把四者压成一个旧用户名，既不利于连续运营，也不利于精准撤权。

可信时钟只能证明时间

RFC 9922 把准确时间视为安全依赖。时间错误可能让动作在错误间隔触发；高频循环可能掩盖异常，或让系统持续忙于调度；若缺少每次触发时间和动作结果的详细日志，事故就难以追溯。

RFC 3339 规定互联网时间戳格式。RFC 7317 允许 YANG 管理的系统配置时区与 NTP。RFC 8915 的 Network Time Security 则为时间同步提供对端身份、报文认证、防重放和请求—响应一致性。

这些机制可以强化“凌晨两点确实是凌晨两点，时间报文来自已认证来源”。它们不能推出“凌晨两点执行的动作仍有机构授权”。可信时钟可以极其准时地触发一个过时决定；合法决定也可能被错误时钟提前执行。

所以，发生记录必须保留两条独立证据：一条说明时间源、计划时间、实际时间和不确定性；另一条说明批准依据、现行政策、执行主体和允许或拒绝的结果。把两者并入一个“有效”状态，只会让事后调查无法定位失败边界。

未来资源预约展示了延迟动作的后果

RFC 8413 讨论按时间预约流量工程资源。未来 LSP 可以现在计算路径并预留容量，到计划窗口开始时才真正建立。它要求把未来 LSP 与资源预约联系起来，以说明为何占用资源、如何处理抢占，以及取消后如何释放；运营商政策仍控制可预约比例和重优化方式。

RFC 8934 把这种架构落实到 PCEP：有状态 PCE 保存计划 LSP，PCC 在开始时建立路径，并在到期时根据属性启动删除。请求、计算、同步、激活与删除发生在不同时间。

这些 RFC 没有报告授权事故。它们只是让延迟控制面变得清晰。路径约束可能仍满足，资源可能仍可用，计划数据库也可能已同步；与此同时，客户请求可能在别处取消，负责机构可能已经改变，新的运营政策可能不再允许原先的优先级。

资源可用性、协议正确性与决定权限是三个独立连接点。可靠自动化需要分别说明，不能让任何一个替另外两个作证。

为每个发生次建立授权凭据

合理做法不是重写共同调度模块，而是在消费模块把计划接到重要动作时，生成一份紧凑凭据。低风险且完全同质的循环可以由一份加密限定的凭据覆盖多个发生次，但边界必须明确。

凭据应连接：

稳定计划标识、当前版本和精确定义哈希；
本次循环实例、计划时间和观测触发时间；
动作类别与目标类别，并对敏感值使用受保护承诺；
创建者与当前机构责任主体，区分个人和长期服务角色；
创建时授权依据，以及执行时现行政策或委托版本；
执行主体与当前允许或拒绝结果；
时间源及相关不确定性；
冲突、优先级、抢占或本地政策处置；
目标状态承诺、实际应用状态与动作结果；
失败、取消或主动不执行的原因；
替代、撤回与更正链接。

这不是要求每分钟人工点击。经过签名的授权可以覆盖某类动作、一组目标、风险上限和一段发生范围。一旦计划版本、责任主体、目标、策略、冲突条件或预期后果改变，这个授权缓存就应缩小或失效。

公开表面也不必泄露用户名、拓扑与配置。它可以显示机构角色类别、政策标识、哈希、证据保管人和处置结果；敏感细节留在受保护记录中。

核心目标很简单：让“为何在这一次运行”拥有与“何时运行”相同的可核查精度。

反对意见帮助确定尺度

第一项反对是连续性。机构计划必须跨越休假、人员离职与账户轮换。正确。凭据应支持把计划明确转交给长期机构角色，而不是继续依赖离职者账户，也不是每次人员变化都停止服务。

第二项反对是成本。高频循环若每次完整计算复杂政策，可能造成新负担。可以使用有期限的授权租约，覆盖明确的动作类别、目标和风险范围，同时列出立即失效条件。

第三项反对是重复建设。NACM、编排器和审计平台也许已经各自保有数据。凭据不应复制完整数据库，而应提供可验证连接。判断标准是：有权审计的人能否在不依赖口头解释的情况下，把计划版本、现行权限、发生次和结果连起来。

第四项反对是标准的通用性。RFC 9922 本来就不该理解每种动作。这恰好说明授权凭据属于消费模块或运营保障层。本文尊重标准边界，并不把模块化误说成疏忽。

证据边界

本文依据的是标准文件，不是生产部署调查。它不能证明某个厂商、运营商或开源实现正在执行授权过时的计划，也不证明存在攻击、故障、损失、违规或普遍缺陷。它不能推断现有系统都没有所有者、服务主体、重新授权或充分日志。

“发生次授权凭据”也不是 IETF 要求。RFC 9922 是有明确范围的共识 Standards Track 文件，并正确要求引用其分组的模块说明各自安全问题。

能够成立的结论更窄：一个计划可以在 RFC 9922 的时间与运营语义中保持有效，而其绑定动作的机构授权仍是另一个未说明的事实。机构必须选择这项授权是长期存在、正式转交、每次重审还是已经撤回。若选择没有留下记录，“已启用”就会承载超出数据本身的承诺。

YANG 计划仍然有效，不等于其动作仍获授权

为何重要

Summary

时间规则没有保存组织变化

RFC 9922 中“有效”的准确边界

最新版本仍可能没有现行责任主体

NACM 保护请求，但未来触发必须指明主体

可信时钟只能证明时间

未来资源预约展示了延迟动作的后果

为每个发生次建立授权凭据

反对意见帮助确定尺度

证据边界

Sources

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报