摘要

  • RFC 3159 要求 PIB-INDEX 只包含一个 InstanceId，并明确规定这个数值除了标识 PRC 实例之外没有其他语义。行号可以精确定位记录，却不能自动说明策略意图。
  • 一行策略的含义分散在 PIB 模块、PRC 与文本约定、主体类别、访问方式、唯一性和引用约束、合规声明，以及基础行、完整增补与稀疏扩展的生命周期中。
  • 是否产生实际效果还需要后续证据：COPS-PR 交换、事务结果、PEP 安装状态、真实执行路径与应用结果。后来被列为 Historic、部署有限，并不抹去“命名不是执行证明”这条边界。

两个不同的号码，未必是两项不同的策略

先看最容易被界面掩盖的情况。系统列出 PRI 104 与 PRI 208。两者的所有业务属性都相同。若控制台只强调主键，操作员会自然地把它们当成两项不同对象；若清理程序只比较内容，又可能把其中一项直接合并。

这两种决定都缺少上下文。模块也许允许内容相同的多个实例；UNIQUENESS 也许禁止它们并存；其中一行也许是另一个基础行的稀疏扩展；两个实例也许属于不同虚拟信息库。设备还可能在模式检查通过以后拒绝安装。

RFC 3159 把标识职责限定得很窄。基础行的 PIB-INDEX 指向一个类型为 InstanceId 的属性。这个无符号 32 位值“除了标识 PRC 实例之外”不承担别的含义。把它追加到 PRC 行定义的 OID 后，可以形成该实例的地址。地址准确，不等于解释完整。

如果工程师偷偷把租户、优先级或队列编码进行号，标识符就会变成没有写进模式的第二套政策语言。后来换号、迁移或恢复数据时，那些暗含义很容易丢失。RFC 3159 的克制反而保护了可审计性：坐标就是坐标，业务含义必须公开写在别处。

SPPI 借用了 SMI，却重新划定了对象边界

2001 年发布的 SPPI 以 SNMP 的 SMI 为基础，沿用了 ASN.1 形式、工具经验与模块化思路。但 COPS 协议本身已经使用 object 一词，继续照搬“managed object”会让传输对象与被建模数据混在一起。

于是 SPPI 把表和行定义称为 Provisioning Class（PRC），把一行的实例称为 Provisioning Instance（PRI），把列称为属性。它没有提供与 SMI 标量对象对应的机制；PIB 操作围绕表状 PRC 展开。

名称变化说明了职责变化。MODULE-IDENTITY 描述整个 PIB 模块的语义，OBJECT-TYPE 描述 PRC 与属性，文本约定给相同底层类型增加可复用的特定含义，对象组与模块合规声明给出最低实现范围。

这套形式很严谨，却不能被误当成运行结果。一个 PRI 可以语法正确、类型正确、必填字段齐全、OID 可解析；这些只证明它符合某个数据模型。它没有证明 PDP 为什么选择它、PEP 是否接受它，更没有证明某一类分组真的被它改变。

PIB-INDEX 与普通 INDEX 不是一回事

基础行必须使用 PIB-INDEX，除非行通过 AUGMENTS 或 EXTENDS 继承身份。PIB-INDEX 只包含一个描述符，通常来自本 PRC，但规范并未把“通常”写成“必须”。它指向的属性必须使用 InstanceId。

SPPI 也允许在特定条件下出现普通 INDEX，但它服务于 PIB 到 MIB 的算法转换。若把两种索引混为一谈，就会把“协议怎样找到一个策略实例”与“转换后的管理表示怎样建立索引”压成同一问题。

完整的证据不能只保存最终 PRID。至少还要保存 PIB 模块与修订、PRC 行定义、文本约定和适用上下文。否则，一个看似精确的 OID 只是没有词典的地址。

即使词典齐全，它也只给出允许的解释范围。是否安装、是否启用、是否命中流量，仍属于后面的层次。

策略含义被有意分布在多个契约里

SPPI 没有设计一个万能字段来承载全部意义。PRC 定义列出属性及其说明；文本约定把普通整数或字节串变成具有特定语义的数据类型；SUBJECT-CATEGORIES 把模块关联到指定 COPS Client Type，或声明适用于全部类别。同一 PIB 模块还可能出现在多个虚拟存储中。

PIB-ACCESS 决定一类数据如何在 PDP 与 PEP 之间出现。install 表示 PDP 可把实例作为配置安装；notify 表示 PEP 必须把该 PRC 的全部实例和值通知 PDP；install-notify 兼具二者；report-only 则既不是普通安装，也不是普通通知，但可进入同步或异步报告。

一个 PRID 不会告诉读者它属于哪种模式。可安装的策略行与只用于报告的状态行都可能拥有漂亮、稳定的标识符。只有查回模块定义，才能知道谁能产生它、谁需要接收它以及它承担什么作用。

合规声明也只是其中一层。它可以说明实现至少支持哪些属性和 PRC，却不能证明某个具体 PRI 在某一时刻已经生效。

唯一性不是行号的别名

UNIQUENESS 把最容易偷懒的推理拆开了。它列出一组有意义的属性，要求同一 PRC 的两个实例不能在这些属性上拥有完全相同的组合。PIB-INDEX 所指的标识属性反而不得出现在其中。

因此，协议身份与内容身份可以同时存在。前者让系统引用一行，后者说明哪些业务值足以区分实例。空的 UNIQUENESS 更直白：两个实例可以在除行号之外的所有属性上完全相同。

“ID 不同”只能证明编号不同，不能证明政策内容不同。反过来，内容相同也不自动授权删除其中一行，因为它们的引用、生命周期或存储上下文可能不同。

规范建议在有用时写出唯一性，却没有强迫所有 PRC 都提供自然键。未声明就是未声明。系统不能自行挑几个字段，随后把猜测包装成标准约束。

引用值必须带着目标类型

策略实例常常引用其他实例。RFC 3159 要求使用 ReferenceId 的属性同时写出 PIB-REFERENCES，明确它指向哪个 PRC。使用 TagReferenceId 时则必须给出 PIB-TAG，说明目标 PRC 中哪一个属性构成标签集合。

一个机制指向声明类型中的单个实例，另一个机制选择具有相同标签值的一组实例。裸整数本身无法区分二者，也无法说明目标。

队列 PRC 的实例 12 与阈值 PRC 的实例 12 没有天然关系。标签 7 也不会跨所有模块成为全球统一分组。若日志只保留数字，不保留引用属性、目标 PRC 与模块上下文，引用外观还在，关系事实却已经消失。

可恢复的记录要保留引用两端：来源属性及其文本约定、声明的目标类型、目标的身份规则和当时使用的模块修订。

基础行、增补行与稀疏扩展有三种生命

每个 SPPI 行定义只能三选一：拥有自己的 PIB-INDEX，通过 AUGMENTS 与基础行一一对应，或通过 EXTENDS 建立零或一的稀疏关系。

AUGMENTS 继承基础行的标识，也共享其存在语义。基础实例安装时，所有增补实例一起安装；基础实例移除时，它们一起移除。这不是两行恰好编号相同，而是一项生命周期契约。

EXTENDS 更松。稀疏扩展不能脱离对应基础实例存在，但基础存在时扩展可以不存在。扩展必须显式安装，可以先于基础显式移除，也会在基础移除时被隐式清理。若基础与扩展一起安装，两者必须进入同一条 COPS 消息。

同一个实例值可能出现在这三种完全不同的关系里。只看行号无法知道某行能否独立存在，也无法判断删除应该传播到哪里。数据恢复若失去关系定义，会制造“可寻址但不合法”的孤儿实例。

身份帮助关联记录；生命周期才决定这些关联在时间上是否合法。一个静态快照不如一条说明基础何时存在、扩展如何安装、删除如何传播的历史。

模式有效仍然可能安装失败

INSTALL-ERRORS 允许 PRC 列出安装或移除被拒绝的专用原因，并为每种原因分配 COPS 错误子码。更重要的是，RFC 3159 明说：即使没有这个子句，安装或移除依然可能失败，只是无法报告 PRC 专用错误。

这条规定阻断了一串常见误报。PRI 通过模式检查，不等于 PEP 接受；消息被接受，不等于事务完成；事务完成，不等于设备实际配置已经核验；配置存在，不等于分组命中；分组路径符合预期，也不等于应用目标已经实现。

COPS-PR 提供传输与事务机制，包括决策、错误、完成状态、缓存状态和重连处理。SPPI 提供被传输数据的描述语言。两层相连，却不能互相冒充。

若控制台只有一个绿色“成功”，它必须说明成功的是哪一步。否则，最早的语法成功会吞掉后面所有未验证状态。

合规能力不是一次执行回执

SPPI 要求每个属性至少进入一个对象组，并用 MODULE-COMPLIANCE 表达强制组、语法细化与最低访问要求。实现若宣称符合该声明，就应支持相应属性和 PRC。

这对互操作规划与采购有用，但它描述的是能力边界。支持一个 PRC，不代表设备里存在任何实例；保存一个实例，不代表相应行为已启用；行为已启用，也可能从未遇到匹配流量。

能力、配置、执行结果是三种证据。把它们统一命名为“合规”，会抹掉标准原本提供的精确区分。

同样，RFC 3159 的安全章节只说这种描述语言本身对互联网没有安全影响。它没有替 COPS 会话、PDP 身份、操作授权、策略内容或 PEP 实现作安全担保。句子的适用层必须被保留。

被列为 Historic，并不让边界失去价值

后来的标准记录改变了这条技术路线的地位。RFC 6632 记载，COPS-PR 没有广泛部署；运营者认为二进制管理编码不利于用常见文本脚本完成简单配置；IETF 没有把任何 PIB 模块批准为 Proposed Standard，并且不建议继续使用 COPS-PR。RFC 3159 现已是 Historic。

这些事实不能省略。把 SPPI 写成今日主流配置技术，会制造历史幻觉。但“没有广泛部署”不等于“从未有实现”，Historic 也不是删除架构证据的命令。

恰恰因为这条路线后来退场，它留下的边界更容易被看见：地址不是内容，内容不是访问权限，权限不是生命周期，生命周期不是事务，事务不是执行结果。换成资源 URI、声明式对象或现代 API 后，系统仍可能犯同样的错误——把稳定 ID 或 200 响应当成运行证据。

历史价值不由市场份额单独决定。失败或退场的机制，也能留下比流行产品更清楚的责任分层。

真正可审计的产物是一条证据链

一份可复核的策略记录应从准确的 PIB 模块、修订和主体类别开始，保存 PRC 与文本约定、基础/增补/稀疏关系、InstanceId 与完整 PRID、唯一性字段、引用和标签目标、虚拟存储、访问模式与合规配置。

随后进入运行层：保存 COPS-PR 请求和决策、事务标识、安装或移除结果、通用与 PRC 专用错误、缓存或重连上下文，以及 PEP 事务前后的状态。再到执行层观察真实分组或其他执行对象，最后由应用层记录目标是否实现。

每一层只证明自己的范围。模块解释字段，PRID 指出实例，协议记录说明交换了什么，设备状态说明安装了什么，流量证据说明执行了什么，应用回执说明结果是否有用。

RFC 3159 的索引之所以可靠，正因为它拒绝冒充整条链。号码给策略行命名，却不解释、授权、安装或证明那一行。审计能力从这种克制开始。

来源