摘要

  • RFC 3060 标准化了可复用的策略信息模型：组、规则、条件、动作和关联关系。它明确没有规定把这些属性转换为结果的统一算法。
  • PCIM 可以表达优先级，也能说明动作顺序是强制还是建议；但这并不构成一套所有设备共用的执行引擎。RFC 3460 后来增加了决策策略等模型要素，也不能证明不同设备会得出相同结果。

规则可以共享，解释却未必

两台设备收到字段名称相同的策略对象，最后可能采取不同动作。它们的本地能力、扩展项和评估逻辑可能各不相同。2001 年 2 月发布的 RFC 3060《Policy Core Information Model — Version 1》正好暴露了描述与执行之间的距离。

PCIM 描述的是信息如何组织：类表示策略元素，关联类表达实例之间的关系。PolicyRule 把条件与动作连在一起；PolicyGroup 可以归拢规则或其他组；优先级可以区分一般规则和例外。条件能写成“或的合取”或“与的析取”，单项还可以取反。它说明规则由什么构成，却不自动替网络设备完成决策。

RFC 用服务质量举例：工程组流量可以获得 Bronze 服务，而优先级更高的例外规则把某位工程师的流量改为 Gold。数据模型能承载两个条件和优先级。系统仍要评估条件、解决重叠，再把胜出的动作翻译成该设备实际支持的配置。

“声明式”不等于自动执行

RFC 称 PCIM 采用声明式风格，但马上说明了这个词的边界：模型定义实体与属性，不定义如何根据属性计算结果的算法，也不规定完整的处理步骤。它可以记录动作的预期顺序，以及顺序是强制还是建议；它没有因此统一各家的评估流程。

差异往往出现在边缘情形：条件缺失怎么办？遇到设备不认识的扩展怎么办？两条规则冲突时如何裁决？设备能力不同时如何处理？PCIM 留有供应商条件类和动作类等扩展机制，便于适配不同系统；同一份基础结构也因此可能容纳不同的本地语义。

作者写明了取舍：模型应当让人容易定义和诊断，同时又要让不同处理能力的设备可以自动处理。他们承认当时对网络策略管理的集体经验有限，并提醒不要为了完整而把规范做得过于复杂。他们主张先满足 VPN、QoS 等共同需求，待需求和经验增长后再扩展。

RFC 还把 PCIM 放在 IETF Policy Framework 工作与 DMTF Common Information Model 的交界处，并说后续文档会定义通往具体实现的映射，例如采用 LDAPv3 的目录。这句话划出了模型与落地之间的距离：信息模型可以作为实现路径的输入，却不证明某个目录、策略服务器或路由器已经采用它。

相邻标准解决的是不同层

RFC 2753 将决策位置称为 Policy Decision Point（PDP），将网络设备上实际落实决策的位置称为 Policy Enforcement Point（PEP）。RFC 2748 定义 COPS，用于在这些角色之间交换请求与决策。RFC 3084 规定了以 COPS 传送 Policy Information Bases 的方式。它们互有关联，但不可互相替代：PCIM 是信息模型，COPS 是通信协议，COPS-PR 处理策略配置数据的供给。

因此，每一步都要有自己的证据。目录里存在某条规则，不代表 PDP 已按预期计算；PDP 返回了决定，不代表 PEP 接受了它；配置被安装，也不等于流量实际获得了预期处理。只看到符合模型的对象，无法知道设备使用了哪个版本、如何处置扩展项或最终怎样转发数据包。

后续版本改变了表达方式

2003 年 1 月，RFC 3460 更新 PCIM：加入新元素，弃用并替换一部分定义，调整规则优先级的表示方式，并引入由管理员指定的决策策略。这说明信息模型确实继续演化，共同结构并非永远不变。

但新添的决策策略字段仍不是设备行为一致的证明。它说明某种选择可以被模型表达，不能证明两个评估器采取同样的算法、支持相同扩展，或安装出相同转发规则。RFC 3198 也指出，从业务目标转换为设备参数时，可能还需要网络和设备能力等外部信息。

历史结论应当保持克制：RFC 3060 试图让策略信息在异构管理环境中复用，同时明确没有提供通用评估算法。标准文档证明模型和后续修订存在，不证明有多少产品实现了它，更不证明生产网络里的决定已经互通。

要验证互通，必须追完整条链：用了哪些类和扩展？PDP 评估了哪个版本？规则冲突如何裁决？PEP 安装了什么？数据包实际经历了什么？共享的描述有助于协调概念，却不是共享结果的回执。

来源