Summary

  • RFC 3084 made each COPS-PR Decision message an all-or-nothing transaction. A PEP returned a solicited success or failure report and rolled a failed transaction back to the last good state.
  • That receipt did not settle every later fact. During disconnection the device could keep cached policy, local state could change, and reconnection required an explicit synchronization procedure—or an assumption that both sides still agreed.

A pushed rule entered another machine’s reality

Imagine a policy server sending one Decision message that removes an old classifier and installs its replacement. TCP delivers the bytes. The network device replies Success. For that transaction, COPS-PR has produced a useful receipt.

Now break the connection. The device continues using its active Request-State. A board is replaced, local capability changes, or cached state reaches its lifetime. When the connection returns, which fact is authoritative: the server’s intended Policy Information Base, the last successful report, or the configuration that still exists inside the device?

Published in March 2001, RFC 3084 defined the COPS usage for policy provisioning, or COPS-PR. A Policy Decision Point supplied modeled policy to a Policy Enforcement Point. Policy Information Bases named provisioning classes and instances; PRIDs identified the individual instances. The document did not define one universal policy model. It defined the transaction and synchronization machinery that carried models for areas such as QoS or security.

That distinction keeps this history separate from RFC 3060. PCIM described reusable policy information while leaving evaluation algorithms to implementations. COPS-PR addressed another boundary: how a server and a device installed, acknowledged, cached, removed and reconciled provisioned state.

One message was a transaction, not an outcome

A DEC could contain several decisions. Removes came before installs, explicitly to resolve precedence rather than timing. The complete DEC had to succeed or fail as one transaction. On solicited failure, the PEP returned a Failure report and rolled back as though the transaction had not occurred. This let the server remove old policy only if replacement policy could be installed.

Every DEC required a solicited Report State message. Success reported that the PEP had taken the requested action; Failure reported rejection and restored the last successful transaction. That was stronger evidence than a sent command. It still stopped at the enforcement point. It was not a packet trace, a queue measurement, or proof that an application received the intended service.

RFC 3084 exposed a harder limit when a previously installed configuration failed later. Such an unsolicited failure did not belong to the neat request-response transaction. The document warned that rollback could be impossible because, under asynchronous conditions, the correct state was ambiguous. A known-good checkpoint existed for an immediate failed DEC; time and local change could erase that certainty.

Compatibility had asymmetric failure rules

PIBs were designed to evolve. If a newer PDP sent a provisioning class an older PEP did not understand, the PEP had to report an error and return to its previous good state. If the PEP knew a newer class but the PDP did not, the class simply arrived empty. Deprecated classes followed still another rule.

These rules limited damage, but they did not make versions equivalent. A successful transaction proved agreement on the objects exchanged. It did not prove that both sides possessed the same unused classes, interpreted device capabilities identically, or would build the same local forwarding mechanisms.

The architecture concentrated authority deliberately. For each policy area identified by a Client-Type, a single connection meant a single server updated the configuration. RFC 3084 said the configuration was effectively locked even against local console changes while the PEP remained connected. That reduced competing writers. It also made the connection, server identity and state database part of the control boundary.

Disconnection turned policy into cached authority

When communication failed, the PEP tried its last PDP, then a configured secondary. Meanwhile the active Request-State continued to govern policy. On reconnection, a LastPDPAddr object could tell the server whose decisions remained cached. The server could issue a Synchronize State Request, causing the PEP to reissue requests for all known Request-States; the PDP then sent deletes for individual PRIDs or prefixes where needed to establish a consistent known state.

If the server did not request synchronization, the client could assume the server recognized it and that current PEP state was correct. That was an operational shortcut, not an independent proof. Changes made while disconnected still had to be reported. After an administrative timeout, both sides deleted stale Request-States, each according to its own connection-loss timer.

The later record adds perspective without rewriting the protocol. SPPI supplied a language for PIBs, and later RFCs built QoS, framework and usage-feedback models around COPS-PR. In 2016 the IETF moved RFC 3084 and related documents to Historic, citing limited deployment and the shift of configuration-management work toward NETCONF and YANG. “Limited” does not mean nonexistent; Historic status does not identify what any surviving device ran.

RFC 3084’s durable lesson is the shape of a receipt chain. Intent at the PDP, atomic acceptance at the PEP, a solicited RPT, cached Request-State, resynchronization, installed local mechanisms and traffic outcome are related facts, not one fact. Reliable delivery can move a policy transaction. Only reconciliation and observation can show what policy the network kept.

Sources

  1. https://www.rfc-editor.org/info/rfc3084
  2. https://www.rfc-editor.org/rfc/rfc3084.html
  3. https://datatracker.ietf.org/doc/rfc3084/
  4. https://www.rfc-editor.org/errata/rfc3084
  5. https://www.rfc-editor.org/rfc/rfc2748.html
  6. https://www.rfc-editor.org/rfc/rfc2753.html
  7. https://www.rfc-editor.org/rfc/rfc3159.html
  8. https://www.rfc-editor.org/rfc/rfc3198.html
  9. https://www.rfc-editor.org/rfc/rfc3317.html
  10. https://www.rfc-editor.org/rfc/rfc3318.html
  11. https://www.rfc-editor.org/rfc/rfc3483.html
  12. https://datatracker.ietf.org/doc/status-change-copspr-sppi-to-historic/
  13. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  14. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/