Summary

  • A 201 Created response in the proposed CDNI Triggers v2 interface proves that a trigger resource exists. It does not prove that a purge, invalidation or preposition operation finished.
  • Revision 20 says a transit CDN that has already accepted an upstream request must convert a later downstream HTTP rejection into an asynchronous Error.v2 record. It may identify the rejecting CDN, but it may also substitute its own provider identifier.
  • Completion, cancellation, cumulative counts, returning-node reconciliation and reader-visible recovery are separate evidence. Leadership should contract and monitor them separately.

The receipt arrived before the refusal

Imagine three delivery networks. CDN A asks CDN B to purge an object. B authenticates the request, creates a trigger resource and replies 201 Created with its location. The control room sees green. B then passes the work to CDN C. C does not support an element in the request and replies 400 Bad Request.

The first response was not false. B really did create a resource. It was simply evidence of the wrong event if the business question was whether every affected cache stopped serving the object.

That distinction is the centre of revision 20 of the CDNI Control Interface / Triggers 2nd Edition, dated 2 September 2026. The IETF Datatracker record describes it as an active CDNI working-group Internet-Draft in the “WG Document” state. The text says it would obsolete RFC 8007 if approved. It is not an RFC, an IESG decision, an implementation report or evidence that any named CDN has deployed it.

The news is not that CDNs can receive purge commands. The older RFC already defined the first edition. The change from revision 19 is a much fuller account of error handling, including what must happen when acceptance at one administrative boundary precedes rejection at another.

One failure, two transports

Before B accepts A’s request, an error that B can detect belongs in the HTTP exchange. A malformed request, insufficient permission or a locally unsupported trigger element produces a 4xx response and no trigger resource. After B has accepted, however, the original HTTP exchange is over. C’s later synchronous rejection cannot travel backwards through time as A’s HTTP status.

Revision 20 therefore requires B to translate C’s rejection into an Error.v2 Description inside B’s trigger status resource. An asynchronous failure reported by C follows the same upstream record path. A polls B’s resource and eventually sees failed plus an error code such as eunsupported.

This is more than an API detail. The same operational fact changes representation at the trust boundary. At C it may be an immediate 400; at A it is evidence asserted later by B. A monitoring system that records only request status misses the failure. One that records only the final error but drops the route by which it was transformed loses provenance.

The draft makes provenance optional at a crucial point. B may include C’s CDN Provider ID in the propagated error, but it may instead use its own PID, obscuring where the refusal occurred. The IANA CDNI parameter registries supply the shared namespaces around the interface. Registration makes values interoperable; it does not force one provider to disclose another provider’s operational identity.

“Complete” has a graph

The state machine is more disciplined than a simple accepted/completed flag. New work normally begins pending, becomes active, and ends complete or failed. In a cascade, a transit CDN must not report complete until processing is complete locally and in every downstream CDN. If it or a downstream participant reports processed, the transit CDN must also report processed—a state meaning that the request was accepted but further status updates will not be supplied.

That is a valuable admission of an observability limit. It prevents an implementation from turning “I will no longer tell you” into “the work is complete.” A unique trigger URI, for which the draft recommends identifiers aligned with RFC 9562, makes a durable handle. It does not make the handled operation successful.

The distinction also matters for failure timing. If one downstream branch fails, the transit CDN waits until its own and all downstream processing has finished before reporting the trigger as failed. A terminal word therefore describes the state of a declared processing graph, not the instant at which the first problem occurred.

The counters are deliberately not an inventory

Revision 20 adds useful cumulative indicators: total objects, total nodes and total object bytes affected. The draft recommends accumulating them across a CDN’s nodes and cascaded downstream CDNs without deduplicating the same object processed on several nodes. Their purpose is to help detect an unexpectedly small or large operation.

That makes a count operationally useful and evidentially dangerous. Ten thousand affected objects might mean ten thousand unique objects, one thousand objects on ten nodes, or another mixture. Zero is not necessarily failure either: an invalidate or purge that matches no known object may still complete successfully.

The right question is not whether the number looks large. It is whether the measurement definition, duplication rule, expected scope and independent observation agree. Otherwise a dashboard turns processing volume into false coverage.

Stop and delete are not stronger verbs

Cancellation sounds authoritative, but the draft makes its implementation optional. Even when a cancellation is accepted, a trigger observed as pending may become active before the stop request is processed. Active or processed work may run to completion during the same race. A cancelling state is evidence that stopping is under way, not that downstream effects have ceased.

Deletion is more destructive to the audit trail, not more certain in the cache. It removes the trigger resource and eventually makes its URI return 404 Not Found. The draft recommends cancellation rather than deletion when the upstream CDN still needs to inspect terminal status. Deleting the receipt does not reverse work already performed, and a 204 No Content response speaks to removal of the status resource.

Timing also divides the data set. Purge and invalidate actions must cover data acquired before processing enters active. They should cover acquisition already in progress. They should not apply to data acquired after processing begins, but the upstream CDN is warned not to rely on that exclusion always being achievable. A purge followed immediately by prepositioning can even remove the replacement unless ordering is explicit.

The broader CDNI architecture matters here. RFC 6707 framed the interconnection problem; RFC 7336 described the interface relationships; and RFC 7337 set requirements for the control interface. The trigger protocol is one component in that composition. RFC 9110 supplies HTTP method and status semantics, but an HTTP success remains scoped to the request it describes.

The node that was absent can return

The draft treats temporary unavailability of an individual downstream node as an internal condition that should not, by itself, change the reported trigger state. A returning node should be brought into a state consistent with earlier trigger operations before normal service resumes.

That is sensible service abstraction, but it creates another evidence boundary. The upstream customer may receive a terminal state without seeing every transiently absent node. Confidence then depends on the downstream operator’s reconciliation discipline. A user-path probe after the node returns answers a different question from the trigger resource before it returned.

The same caution applies to topology. A diamond path can deliver conflicting metadata through different transit CDNs and is treated as a configuration error. Provider IDs can help detect loops. Neither mechanism proves that the upstream party sees the full commercial chain.

The protocol improves the ledger. It does not collapse the ledger into the result.