摘要

  • draft-ietf-ivy-entitlement-inventory-05 把组织持有的权益、资产关联、已安装记录、支撑许可证、allowed、in-use 与限制值拆成不同数据；任何一个字段都不能单独证明下一层事实。
  • 该 YANG 模块全部只读。真正改变或执行许可证状态的外部系统、同步规则和到期告警不在模型内，因此绿色状态首先是一份报告，而不是可执行权力。
  • 可靠自动化必须保存生产者、观察时间、组合规则和每次交接的回执，一直追到设备运行状态与可观察的网络结果。

续期日的两套时间

设想一个不指向任何真实厂商的续期场景。凌晨零点，中央清单把一项吞吐能力的许可证从 active 改为 expired。采购系统的记录没有错误：合同日期已经结束。可设备仍在转发，因为本地令牌还有宽限期，或它尚未收到中央变化。上午，控制器又从缓存里读到 allowed=true。

也可能完全相反。中央系统刚完成续费，权益已经关联到设备，仪表盘显示“有效”；设备却尚未获得令牌，或者支撑该能力的另一个附加许可已经失效。组织拥有权利，不等于设备此刻接受了权利。

这两个分支不需要假设谁在撒谎。它们只说明不同系统生活在不同时间和观察边界里。真正危险的做法，是把中央记录、设备状态和服务结果压成一个绿色圆点。

2026 年 9 月 29 日的 draft-ietf-ivy-entitlement-inventory-05 试图为这种差异提供共同的数据结构。它拟走 Standards Track，预计于 2027 年 4 月 2 日到期，目前仍是 IETF Network Inventory YANG 工作组的 Internet-Draft。它不是 RFC，不代表 IANA 已完成注册，也不是任何产品已经支持或部署的证据。

它最值得重视的地方，不是承诺“一个字段解决许可证管理”，而是允许我们把权利链拆开。

从拥有到结果，共有九站

第一站是组织级权益：标识符、供应方、产品信息、状态、生效与到期日期、限制。第二站是关联：这项权益面向哪个组织、用户、网络元素或组件。第三站是资产公开的 installed-entitlements 引用。第四站是设备报告自己具备的技术能力。第五站是能力所依赖的一项或多项支撑权益。第六站是 allowed，即权益规则是否允许使用。第七站是 in-use，即报告方是否认为权益或能力正在使用。第八站是全局或能力级的最大值与当前值。第九站才是配置是否成功、数据面是否生效、业务服务是否达到预期。

这些站点可以相互指向，却不能相互替代。组织可以买下尚未分配的许可证；分配可以停留在资产库里；设备可以激活许可证但没有启用功能；功能可以允许但未使用；使用状态可以为真但没有客户流量；服务可以失败于路由、光层、安全策略或应用，与许可证无关。

如果把所有站点都叫“已授权”，故障时就再也无法判断责任停在哪一步。

“已安装”是谁眼中的已安装

草案本身留下了一处必须公开处理的术语张力。范围章节说，installed entitlement 指分配给特定资产的权益；所谓安装既可能是直接写入设备，也可能只是中央系统里的逻辑分配。定义章节则把它描述为已经在网络元素上本地激活、可供能力使用。后文又称这些引用“当前有效并赋权于资产”。

未来版本可能会统一这些表达。在当前版本下，消费者不能默默挑选最乐观的解释。

资产管理平台能直接看到“许可证被分配给序列号 X”。许可证服务器能看到“10:04 发出了一次租约”。设备能看到“本地令牌加载成功”。控制器只能看到“上次轮询返回一个 installed 引用”。四份记录可能使用相同 ID，却不具有同一含义，也不处于同一时刻。

所以最小证据不应是一个孤立的 installed=true，而应包含：谁产生、该生产者能观察什么、何时观察、经过哪条验证路径、缓存多久。共同的 YANG 路径让系统能交换记录，并没有让它们拥有同一个现实。

缺失、空值与否定不能合并

模型使用 presence container 表示报告能力。系统若公开 installed-entitlements 容器，就在声称自己知道这一类信息；容器存在但列表为空，可以表示没有安装项。容器根本不存在，则可能表示该系统不会报告，而不是设备没有许可证。

同样，in-use 叶子缺失可以表示生产者无法表达使用状态，并非使用为假。supporting-entitlements 容器存在且为空，可以表示能力不需要特殊许可证；容器缺失，则可能只是依赖关系未知。

许多数据管道为了方便，把缺失统一转成 false 或空数组。格式更整齐，证据却被破坏：未知变成否定，或未知变成“没有限制”。自动化至少要保留四种状态——报告为真、报告为假、明确为空、未报告——并带上来源与时间。

五级实现不能只看一个勾

草案允许逐步实现。Level 1 只有中央权益目录；Level 2 增加资产上的已安装权益；Level 3 增加能力；Level 4 增加能力与权益的依赖，以及 allowed、in-use；Level 5 再加入全局与能力限制。

实现者应说明支持哪一级以及偏离之处。这比“支持权益清单”的产品勾选框更重要。Level 1 无法回答某台设备当前是否允许使用；Level 3 可以列出硬件能力，却不知道其许可证依赖；Level 4 可以给出许可判断，却未必知道一个共享池还剩多少可原子预留的额度。

采购和架构评估应该问：每个字段由谁产生？多久刷新？网络分区时保持什么语义？冲突时谁优先？不知道这些，所谓支持只是一项名义能力。

allowed 是计算结果

一个能力可以依赖多项权益。草案要求 allowed 反映所有必要权益的合并效果；若必需项缺失、到期或撤销，它应为假。这意味着 allowed 不是硬件固有属性，而是策略计算的输出。

要相信这个输出，消费者必须知道完整依赖集合、每项权益的新鲜状态、组合规则和决策者。目录若遗漏一个附加许可，结果可能过度宽松；控制器若不知道宽限期，结果也可能过度严格。两个系统给出不同布尔值，可能只是使用了不同但各自合理的视图。

即使 allowed=true 完全正确，它也只说明权益政策允许组织使用。它不授予某个操作者配置权限。RFC 8341 的 NACM 管理 NETCONF/RESTCONF 用户对操作和数据的访问；权益模型管理组织是否有权激活能力。许可证不能提升用户角色，管理员权限也不能凭空创造许可证。

此外，允许不等于可运行。软件版本、内存、板卡、拓扑、配置依赖和业务策略仍可阻止功能生效。

in-use 也需要说明观察方法

模型可在许可证和能力两个层面报告 in-use，并要求两者存在时保持一致：若任何受支持能力正在使用，权益也应标记为使用中。这能发现明显矛盾，但并未规定“使用”如何被观察。

设备可能把“配置存在”算作使用，也可能要求进程启动；许可证服务器可能计算席位已借出；控制器可能重复上一轮状态；运营团队更关心邻接、路由、转发表和实际流量。这些都不是同一个命题。

因此 in-use=true 后面仍要接运行回执：配置接受、进程状态、资源占用、数据面计数和服务探测。权益清单应链接这些证据，而不是吞掉它们。

共享池里的余量会被同时消费

限制可以是组织级安装数量，也可以是能力级吞吐、连接或隧道上限。模型提供资源名、单位、最大值和当前值。

“当前 80，上限 100”并不自动批准下一次申请 20。当前值可能已经过时；两个控制器可能同时看到同一余量；一个值可能表示已配置容量，而执行系统计算的是活跃使用；父许可证与附加项可能消耗不同池。

层级权益还有图结构风险。YANG 能阻止直接自指，却不能单独发现所有深层环路。管理系统必须在提交前识别 A→B→A。通过 schema 校验的文档仍可能包含不可执行的依赖图；正确的依赖图仍可能遭遇并发预留竞争。

所以限制回执至少要包含池范围、单位、采样窗口、来源、时间、重置规则和预留状态。否则 current value 只是遥测，不是并发控制。

只读模型依赖外部写入现实

模块的所有节点都是 config false。它负责报告，不负责改变底层权益。真正写入状态的是许可证服务器、资产平台等外部系统，它们与设备之间的通信又不在本文范围内。

NETCONF 或 RESTCONF 连接可以被双向认证和加密，仍可能读到过时或伪造的状态。安全章节明确提醒：若外部通道被破坏，攻击者可能注入错误权益，使能力看似被允许或被限制。只读能限制这条接口的写操作，不能自动证明读到的事实真实、及时。

草案因此建议实现检测中央记录、本地安装与实际使用之间的不一致，但没有规定通用的新鲜度、优先级或冲突裁决。到期也相同：模型给日期，不负责临期通知。缓存又是大规模系统的现实需求，所以每个绿色状态都应带缓存身份和最近一次成功刷新时间。

把可执行权利写成回执链

一项可审计决策至少需要九份回执：

  1. 授予回执：谁授予什么权利，给谁，何时到期，有何限制；
  2. 分配回执：谁把它关联到哪项资产或组件；
  3. 激活回执：哪台设备或许可证服务接受了它；
  4. 依赖回执：完整支撑项与已验证无环的层级；
  5. 许可回执：allowed 的规则、生产者、时刻和例外；
  6. 访问回执：操作者或自动化主体的 NACM 决策；
  7. 使用回执：实现如何定义并观察 in-use；
  8. 限制回执：共享池、预留、执行结果和剩余余量；
  9. 结果回执：配置、运行状态、流量和最终服务。

这九份回执不必装进同一数据库。重要的是交接不能丢失。共同清单越诚实地标明权力到哪里结束，就越能成为可信的协调工具。

资料来源