Summary

  • In draft-ietf-cdni-ci-triggers-rfc8007bis-20, a downstream CDN must answer a cancellation request, but implementing actual cancellation is optional; even an accepted request can lose a race with work that starts or finishes first.
  • cancelling, cancelled, processed, complete and deletion are different receipts. A deletion can remove the status resource while execution remains possible, and a cascaded trigger cannot honestly close until every downstream branch has reached the specified terminal condition.

The awkward moment in a cache emergency is not sending the purge. It is deciding what to believe after someone tries to stop it.

Imagine an upstream content delivery network has launched an invalidation across an interconnected provider. A scope mistake is discovered. The operator immediately asks for cancellation and receives a successful response. That answer feels like a safe boundary: stop accepted, next action authorised. Yet revision 20 of the IETF CDNI Triggers second-edition draft says something more exact. The downstream CDN must respond to cancellation, but actual cancellation is optional to implement. A trigger observed as pending may start before the request reaches its execution point. An active or processed trigger may run to normal completion while the cancellation is being handled.

The control message is real. Its authority is limited.

A state machine built around an unavoidable race

The draft describes three content actions. preposition asks a downstream CDN to acquire content or metadata. invalidate prevents use until revalidation but need not erase the stored data. purge requires the selected data no longer to be held. These are not cosmetic distinctions. A purge can create origin load and force reacquisition; invalidation preserves bytes but changes when they may be served; preposition changes what is ready before demand arrives.

The scope also has a time boundary. Invalidate and purge apply to data acquired before processing enters active. Acquisitions already in progress should be covered, while data acquired afterwards should not be—but the draft warns that this cannot always be achieved. An operator therefore cannot treat the trigger as an infinitely sharp cut through all cache activity.

The same timing problem appears when replacing content. If a preposition runs before an earlier purge or invalidation finishes, the new copy can arrive first and then be removed by the older action. The draft offers an execution-policy dependency so the second trigger can wait. The dependency is not ceremony; it is the mechanism that prevents two individually valid commands from producing the wrong order.

Cancellation enters that moving system. An upstream CDN requests that state become cancelled. If a downstream CDN cannot stop immediately, it must expose cancelling. Only when processing has stopped before normal completion does the resource become cancelled. If the action reaches its ordinary end first, the final truth may instead be complete or failed. “We asked in time” and “the system stopped in time” are different facts.

Processed is a deliberate limit on knowledge

Most operational state names sound stronger than their definitions. This draft makes one weakness unusually explicit. processed means a trigger was created and no more status update will be made; it is available where completion cannot be confirmed. A downstream CDN that cannot provide later representations marks the trigger processed at creation, estimates completion time if possible, and continues the work.

That is not failure disguised as success. It is a declared observability boundary. The remote system accepted responsibility for execution but cannot return a final receipt through this interface. The correct response is not to relabel processed as completion. It is to decide whether the action can safely proceed without a confirmable result, and which independent evidence will close the gap.

For a purge, that evidence might combine the final trigger representation, affected-object data where supported, cache probes, origin request changes and delivery observations. For prepositioning, it may include controlled requests from the intended footprint and evidence that the expected object version is served. None of these observations alone turns a CDN-wide action into certainty, but together they can test the outcome that the control plane cannot certify.

HTTP responses mark still earlier stages. 201 Created establishes a trigger resource and its URI. 202 Accepted says a command has been admitted but not finished. A 204 No Content response to immediate deletion says the status resource was removed. These messages are useful precisely because they do not pretend to be cache-result receipts.

Delete can erase the native witness

The draft treats deletion as similar to cancellation, with one decisive difference: after deletion completes, the trigger resource is unavailable. It therefore recommends cancellation when the upstream CDN will need the final status.

Deletion inherits the same race. A supposedly pending action may begin before the delete is processed. An active or processed action should stop, but is not guaranteed to stop. The operator can therefore destroy the easiest native route to later status while the content-side work is still capable of finishing.

Automatic expiry creates a quieter version of the same problem. A downstream CDN may remove terminal resources and later answer with 404. It must advertise the stale-resource lifetime, and it should not expire a processed trigger while execution or redistribution may reasonably continue. Retention is part of the evidence contract: a unique trigger URI prevents identity reuse, but uniqueness does not help if the receipt has disappeared before the investigation begins.

Cascades turn one cancel into a distributed finish

An interconnected CDN can forward the trigger through transit providers to further downstream CDNs. Revision 20 refuses to let an intermediate node compress that topology into premature success. A transit CDN cannot report complete until the action is complete locally and in every affected downstream CDN. If any branch is processed, the aggregate must remain processed. A cancellation remains cancelling until every branch says cancelled, complete or failed.

That rule prevents a fast branch from speaking for slow or unreachable branches. It also reveals what an operator needs to retain: originating trigger identity, each transit mapping, the CDN path, branch-level errors, the moment each branch crossed state and the content evidence observed afterwards.

Topology can make the evidence less clean. In a diamond, one downstream CDN may receive related content or metadata through more than one path, with conflicting objects and different propagation delays. The draft calls that a configuration error. Cumulative object, node and byte counters can help detect an anomalous result, but they may count the same object at several nodes and are optional. They are indicators, not a unique-object ledger.

Complete is strong—and still scoped

The draft gives complete a firm meaning. It must not be reported until all operations in the trigger have succeeded, including required downstream processing. That is materially stronger than processed, cancelling or an HTTP acceptance response.

The meaning nevertheless depends on the request. An invalidate or purge matching no known objects may complete successfully with zero affected objects. A pattern may describe something different from what the operator intended. Counters may aggregate repeated work. The trigger protocol records control execution; CDNI separately defines metadata, request-routing and logging interfaces. A completed trigger is not automatically proof of the representation an end user received.

The practical rule is to preserve the distinction rather than distrust every status. Complete closes the protocol action it actually names. Target identity, unique-object effect and delivery outcome require the corresponding evidence.

What an operator should require

A safe runbook makes five moments visible: the original trigger, acceptance by the next CDN, the cancellation or deletion request, the terminal state of every cascade branch, and an independently observed content result. It retains resources longer than the incident and rollback window, treats processed as an open evidence item, and forbids an irreversible follow-on action from relying only on cancelling or an HTTP 2xx.

It also makes capability discovery operational. If a partner does not implement cancellation, lacks extended status or cannot expose the object set, the upstream CDN should know before a live purge. Local autonomy remains intact: each CDN decides how it executes internally. But the interconnection contract should make the resulting uncertainty visible to the party carrying the business consequence.

Revision 20 remains an Internet-Draft. The current IANA registry still shows the RFC 8007 payloads rather than the proposed v2 entries, and no reviewed source establishes deployment by a named CDN. The document is valuable without pretending otherwise. It puts a hard boundary around a comforting but unsafe sentence: the cancel was accepted, therefore the purge did not happen.

Sources