Summary

  • RFC 3060 standardized a reusable information model for policy objects: groups, rules, conditions, actions and their associations. Its authors explicitly left the algorithm that converted those attributes into a result to implementations.
  • The model could represent priorities and whether action order was mandatory or recommended, but that was not a universal execution engine. RFC 3460 later updated the model and added decision-strategy vocabulary; neither document proves devices applied identical policies.

A rule can travel farther than its meaning

A policy file can look portable while behaving differently at the edge. One device may receive the same named condition and action as another, yet use different local capabilities, evaluation code or configuration to decide what happens next. That distinction sits at the center of RFC 3060, the February 2001 Policy Core Information Model (PCIM) Version 1.

PCIM described policy information as a structure. Its classes represented policy elements; association classes described how those elements related. A PolicyRule connected conditions with actions. PolicyGroups organized rules or other groups, and rules could carry priorities. Conditions could be expressed as OR-of-ANDs or AND-of-ORs, with individual statements negated. These constructs gave policy designers a way to encode what a rule referred to and when it was meant to apply.

But the schema was not the point where the network necessarily made its decision. The RFC distinguished an information model from the algorithm that interpreted one. Its own example made the problem concrete: a general rule could give engineering traffic a Bronze service while a higher-priority exception gave one engineer Gold. The model could identify the overlap and encode priority. A concrete implementation still had to evaluate the conditions, apply the ordering semantics and translate the selected action into device-specific behavior.

“Declarative” with a deliberate blank space

RFC 3060 describes its style as declarative, but immediately narrows what that label means. It says the model defines attributes and entities; it does not define the algorithm that produces a result from those attributes or a sequence of processing steps. Desired action order can be recorded, including whether it is mandatory or merely recommended, but the evaluation procedure remains outside the common information model.

That is a careful boundary, not proof of one common language runtime. A declaration such as “when condition C is true, apply action A” needs concrete definitions for C and A. It also needs rules for missing or unsupported attributes, conflicting policies, local exceptions, and what to do when device capabilities differ. PCIM offered extension points, including vendor-specific condition and action classes. Those extensions made the model adaptable; they also meant a shared base schema could coexist with locally different semantics.

The RFC's explanation is unusually direct. The authors wanted a representation that humans could define and diagnose, but that a wide range of devices could also process. They acknowledged limited collective experience with policy management and warned against trying to make the model complete. Instead, they favored a common core for needs such as VPN and QoS, with paths for the model to grow as requirements and experience changed.

The same document situated PCIM in work shared between the IETF Policy Framework Working Group and the DMTF's Common Information Model effort. It said later documents would map the information model to concrete implementations, giving an LDAPv3-backed directory as one example. That sentence matters: the model was an input to an implementation path, not evidence that one transport, directory, policy server or router had adopted it.

The surrounding architecture had different jobs

The earlier policy-admission framework in RFC 2753 separated a Policy Decision Point (PDP), where decisions were made, from a Policy Enforcement Point (PEP), where a decision affected a network element. RFC 2748 then defined COPS as a client/server protocol for exchanging requests and decisions between those roles. RFC 3084 specified a COPS usage for provisioning policy information bases. They addressed adjacent architectural layers, but none should be collapsed into PCIM: a transport protocol, a provisioned data model and an information schema answer different questions.

That division exposes a measurement problem. A directory may contain a rule; a PDP may evaluate it; a PEP may receive a decision; and a router may install configuration. Each is a different event. Seeing a PCIM-shaped object in a repository does not show which policy version a device consumed, whether the decision point understood an extension, whether the enforcement point accepted the decision or whether packets received the intended treatment.

The successor changed the model, not the evidence bar

RFC 3460, published in January 2003, updated PCIM. It added elements, deprecated and replaced others, changed how rule priorities were represented and introduced administrator-specified decision strategies. This was a genuine evolution of the information model. It also shows that the earlier vocabulary was not frozen: future policy work could revise the structures used to express rule sets and evaluation choices.

The successor does not, by itself, prove consistent execution. Specifying a decision-strategy field tells a model what choice can be represented; it does not prove that two implementations evaluate it identically, support the same extensions or install the same forwarding behavior. RFC 3198 later distinguished business-level policy abstractions from device-specific parameters and noted that translating between them can require external capability and configuration information. A shared representation can reduce ambiguity without erasing the translation work.

The historical claim must therefore remain narrow. RFC 3060 documented an attempt to make policy information reusable across a diverse management environment. Its authors also documented the limit: common objects did not amount to a universal algorithm. The standards record establishes the model and its subsequent revision, not which vendors implemented it, how many networks used it or whether their decisions interoperated in production.

The enduring lesson is to ask for the whole chain. Which schema and extensions were present? What policy version did the decision point evaluate? Which algorithm resolved overlap and ordering? What did the enforcement point install? What did the network actually do? An interoperable policy description can be valuable. It is not a receipt for interoperable outcomes.

Sources