Summary

  • RFC 7754 distinguishes a policy setter, an enforcing party, a purpose, an intended target and a technical component.
  • A request that fails from one vantage point is evidence of that failure; it is not a self-contained attribution of authority, motive, legality or intent.

A probe reports an outcome at an interface. It might record that a resolver returned an unexpected address, that a TCP connection was reset, that a certificate changed, or that a request timed out. Such observations matter. They are the beginning of an investigation. The error begins when a dashboard or report treats them as a finished account of who acted and why.

RFC 7754, Technical Considerations for Internet Service Blocking and Filtering, was published by the Internet Architecture Board with Dave Thaler among its authors. Its value is not a universal test for censorship or a verdict on any jurisdiction. The document instead gives a vocabulary for keeping distinct questions apart: who sets a blocking policy, what purpose that policy has, what it intends to target, and which Internet component implements it.

Those distinctions are operationally important. A policy-setting party might be a government, a court, an enterprise, a network operator, an application provider, a reputation service, or an end user. The party that enforces a rule can be the same actor, but it can also be a different organisation acting under another party’s instruction or choosing to consume another party’s reputation data. A packet trace at one enforcement point cannot resolve that ownership chain on its own.

The target is likewise not guaranteed by the effect. DNS modification may disrupt unrelated services sharing a name or address. An address or port rule can affect several applications. A transport failure can originate in a local firewall, an upstream fault, an overloaded service, an expired certificate, a configuration mistake or a deliberately deployed control. RFC 7754 explicitly confines its scope to intentional blocking and excludes accidental blocking caused by misconfiguration or an unintended side effect. That is a warning against using the RFC as a shortcut from observation to accusation.

An honest block record should therefore state its smallest verifiable claim. It should preserve the subject requested, the resolver or route used, the client and network vantage, time, protocol, observed response, repeatability and comparison conditions. It should also say what was not observed: the policy source, enforcement operator, configuration rule, target list, legal authority, business incentive and purpose. Those facts need their own attributable records.

This is not a call to ignore an access failure. It is a way to make it actionable. A network team can investigate the path and enforcement surface. A service owner can compare endpoints and certificates. A policy owner can disclose its instruction and scope. A legal reviewer can assess a jurisdictional claim. Each actor can contribute evidence without one technical symptom silently becoming everybody else’s statement.

Heng Lu’s operational discipline is useful here: a record should not borrow authority from a layer it does not control. A resolver response proves what that resolver returned to the measuring client at that time. It does not prove that a named government ordered the response, that an operator intended it, or that every user saw it. A bounded observation is not weak evidence; it is evidence that can survive review.

Dave Thaler’s contribution in RFC 7754 is collective IAB work, not ownership of any filtering system. Its durable lesson is simple. Before calling a technical effect a policy outcome, retain the chain that connects the effect to a responsible decision. Until then, report the block observation as a block observation.

Sources