RFC 5224: A Policy Result Is Not Proof of Enforcement

Summary

RFC 5224 registers Command Code 314, an OMA vendor-space Policy-Data AVP and Application Identifier 16777243 for a Diameter policy-processing exchange. These identifiers classify the message; they do not prove the provenance or authority of every assertion it carries.
OMA's own architecture permits evaluation-only processing. A decision may be returned to a requesting resource, which then controls how to handle it, while a separate enforcement component performs the action. A successful answer is therefore not inherently an enforcement receipt.
Accountable automation needs a joined chain from request and policy version through decision, enforcement-point receipt, installation, activation, later-state reconciliation and observed effect. Compressing that chain into policy applied destroys the evidence needed to locate failure.

The answer arrived before the action

Imagine a constructed control-room sequence, not a reported deployment. At 09:00:00 a service sends a Diameter Policy-Data-Request. At 09:00:01 a Policy-Data-Answer comes back with the expected Application-Id, matching hop-by-hop and end-to-end identifiers, and a success-class result. The policy dashboard immediately paints the resource green: applied.

At 09:00:02 the enforcement process is still disconnected. At 09:00:03 a local override rejects one of the returned obligations. At 09:00:04 the subject moves to another session. At 09:00:05 the original decision is superseded. The only durable record is the answer received at 09:00:01.

Nothing about that answer is fake. It is simply earlier than the claim made for it.

RFC 5224 describes a vendor-specific Diameter application for invoking policy processing. It is an Informational RFC whose core registration work is deliberately small: Command Code 314 for PDR/PDA, Policy-Data AVP code 1 in the OMA vendor namespace, and Application Identifier 16777243. Its text says that policy inputs travel in a new AVP and results travel through that AVP together with the Experimental-Result AVP. It also sends the reader elsewhere for the detailed contract: section 5.4.1 of OMA's PEM-1 technical specification.

That delegation matters. The RFC records how the Diameter namespace is used. It is not a complete theory of who selected the policy, which context was supplied, what the result means to a particular resource, who executed it or whether the intended operational outcome occurred.

A registry number coordinates parsers, not principals

The assignments are real and useful. IANA's AAA Parameters registry still lists the application and command code. The OMA Diameter binding uses Vendor-Id 30079, and its capability exchange advertises support for the vendor-specific application. Those facts let independent nodes agree that they are speaking the same protocol extension.

They do not answer the principal question: who is entitled to decide this policy for this subject, resource and moment?

An Application-Id names an application. A Vendor-Id names an assignment space. A command code tells a parser which request/answer grammar applies. Capability advertisement says a peer claims support. None of them is a corporate power of attorney, a current delegation record or a proof that the destination reached by realm routing is the intended policy authority for a specific decision.

Diameter peer security is another necessary but bounded layer. RFC 5224 inherits the security considerations of RFC 3588. Its successor, RFC 6733, requires protected peer communications and defines how Diameter messages, applications and results are carried. A protected connection can authenticate a peer and preserve message integrity. It cannot prove that the request included every required fact, that an external data source was current, or that the authenticated peer had business authority over the target resource.

The right audit record therefore separates at least three things often merged under “trusted”: the cryptographic peer, the authorized application relationship and the policy principal. One may imply another in a tightly controlled deployment, but implication is a local configuration claim that must be evidenced, not a property of code point 314.

Policy-Data is intentionally open-ended

The PEM-1 technical specification explains why the interface uses a generic data container. Policies vary. They need different inputs and produce different outputs. PEM-1 therefore carries collections of parameters in BLOBs interpreted through standard or custom templates.

Extensibility solves an interoperability problem and creates an evidence obligation. A template identifier and version can tell the receiver how to parse fields. They do not demonstrate that the sender populated every field honestly, that a value came from its claimed source, that time-sensitive context remained fresh, or that two organizations assign the same operational meaning to a custom extension.

The specification is unusually candid about that edge. It says mechanisms for storing, publishing or advertising supported PEM-1 options are outside its scope. It also says it does not define how a PEEM implementation processes input parameters or how the requesting resource processes output parameters.

Those are not defects to be filled with confidence. They are interfaces at which local responsibility begins.

A useful request receipt should bind the raw Policy-Data bytes to the template ID and version, request identifier, subject, resource, policy reference or version, source and observation time for each external fact, and the peer that supplied them. If a policy depends on account balance, location, subscription state or risk score, “field present” is not the same as “fact current.” If a policy delegates to another resource, the subordinate request and result need their own correlation.

“Policy processing” has more than one execution path

PEM-1 defines policy processing as policy evaluation, or policy evaluation and enforcement. The shared phrase therefore cannot tell an observer which one occurred.

The OMA architecture makes the branching explicit. A callable request can end with the PEEM enabler returning a decision to the requesting resource. The resource then controls how to handle that decision. Alternatively, PEEM can perform enforcement itself, possibly without returning a value. The architecture even draws an evaluation-only path in which no action or enforcement is performed by PEEM.

Its component model is equally clear. The evaluation component identifies policy, evaluates it using supplied context and returns a result. The enforcement component performs an action as a consequence of that result and may delegate further. A combined implementation may house both components. Co-location does not erase the logical boundary; it merely makes the handoff local.

This is consistent with the IETF vocabulary. RFC 2753 places policy decisions at the Policy Decision Point and actual enforcement at the Policy Enforcement Point. RFC 3198 defines policy enforcement as execution of a policy decision. A correctly operating PEP is expected to enforce the PDP's decision. That normative expectation is not transaction evidence that this PEP received, installed and applied this decision.

Compliance frequently loses this distinction. A requirement says the PEP must enforce; a test report therefore records that the decision was enforced. The verb tense changed without a witness.

Three results can coexist in one answer

The word “result” is treacherously compact.

First, Diameter has protocol-level result semantics. A Result-Code or Experimental-Result reports the success or failure class defined by the relevant application or vendor. “Experimental” is a registry term for a grouped vendor result, not a claim that someone observed an experiment in the network.

Second, PEM-1 defines an Output Status template. Its mandatory status code represents a final status of policy processing or an error identified by PEEM. That status can be accompanied by policy-specific output.

Third, the policy itself may produce a decision or data that a requestor must interpret and act upon.

These three layers can align and still stop before enforcement. A Diameter message can be accepted, PEEM processing can complete, and a policy decision can be returned—while the requestor later declines, cannot install, partially installs or supersedes it. Conversely, PEEM may enforce internally and return only bounded status. An auditor cannot infer the path from a generic success lamp.

The minimum useful vocabulary is explicit: transported, protocol-accepted, processed, decision-returned, received-by-enforcer, installed, active, effect-observed, superseded, rolled-back. Not every system needs every label. Every system needs to avoid using one label for all of them.

An implicitly terminated session limits what history exists

The OMA Diameter binding sets Auth-Session-State to NO_STATE_MAINTAINED. The server does not preserve Diameter session state and the client need not send a session-termination request. That is an efficient design for a callable exchange. It is also a warning against inventing lifecycle evidence that the protocol does not retain.

A matching answer correlates to a request. It does not create a durable policy lease, prove that an installation remained active, or reveal when a local enforcer replaced the decision. Operators who need that history must record it in the application and enforcement layers.

This boundary also separates the piece from existing coverage. RFC 3539 is about AAA transport reliability, watchdogs, failover, pending requests and duplicates. Those mechanisms can determine whether an answer was received or replayed. They do not convert receipt into enforcement. RFC 2989 defines AAA capability requirements. A system can satisfy a capability checklist and still need transaction-specific evidence that an action occurred.

RFC 7683 further shows why application success and operational capacity should not be merged: overload signaling can alter how Diameter work is handled. RFC 4006 supplies another mature request/answer application with explicit service and credit state. Neither document is evidence about a particular RFC 5224 exchange; both help expose the category error of treating a syntactically successful answer as the whole service outcome.

Build the receipt where control changes hands

An accountable chain does not need one omniscient database. It needs joinable facts at each transfer of control:

request bytes, identifiers, client, realm/host route and secure peer;
subject, resource, policy reference/version and input provenance;
evaluation start, dependencies, subordinate calls and returned decision;
protocol result, PEEM status and policy-specific output as separate fields;
the component designated to enforce and its receipt of the decision;
installation target, intended state, previous state and conflict checks;
activation time, partial failures and rollback path;
later policy or local state that supersedes the decision;
observed effect at the layer capable of seeing it;
reconciliation tying the effect or failure back to the originating request.

The record should be monotonic about evidence, not optimistic about state. A returned decision remains returned even if later superseded. An installation failure should not rewrite the earlier answer into failure. It should add the missing stage. This preserves causality and makes compensation possible.

Heng Lu's reality-layer doctrine is useful because it refuses to let the symbol borrow the authority of the thing symbolized. The application ID is a symbol. The answer is a record. The policy decision is an instruction. Running systems make the later reality by accepting, installing, enforcing and exposing observable state. The chain is strongest when each fact keeps the narrow name it earned.

The Policy Engine Returned a Result. Enforcement Was Still a Different Event.

Why it matters

Summary

The answer arrived before the action

A registry number coordinates parsers, not principals

Policy-Data is intentionally open-ended

“Policy processing” has more than one execution path

Three results can coexist in one answer

An implicitly terminated session limits what history exists

Build the receipt where control changes hands

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing