Summary

  • RFC 5225's co_repair packet places a CRC-7 over the reconstructed uncompressed header chain and a separate control CRC-3 over applicable control fields. The split exists because those fields may not have influenced the header that just decompressed successfully.
  • Leadership should treat output validity and state-transition validity as separate evidence claims. Accepting a present result, advancing durable state and sending positive feedback need not be one indivisible decision.

One packet, two questions

A decompressor reconstructs a header and the CRC-7 agrees. The packet can move forward. Positive feedback may follow. On an ordinary dashboard, that sequence would be compressed into one word: success.

RFC 5225 refuses that compression. Its co_repair format carries another, smaller check, control_crc3_encoding. The CRC-7 is calculated over the entire reconstructed uncompressed header chain. The control CRC-3 is calculated over the applicable control fields carried with the repair. These checks are not stronger and weaker versions of one verdict. They have different subjects.

The reason is unusually explicit. A control field being updated is not always used to decompress the header that carries it. The reconstructed header can therefore validate while an update to state remains outside the evidence supplied by CRC-7. Without the separate control check, decompression could succeed, positive feedback could be sent, and control fields could still have been updated incorrectly.

The current result may be sound. The future has not yet been proved.

Context is an operating asset, not a side effect

ROHC obtains efficiency by avoiding repeated transmission of information that compressor and decompressor can derive from shared context. That context is an operational asset: it is the basis on which later compressed packets will be interpreted.

RFC 5225's state machine makes confidence visible. In Repair Context, packets have decompressed successfully, yet the decompressor does not trust the whole context. A packet protected by the specified CRC-7 or CRC-8 can restore Full Context. Even here, the standard does not pretend that every successful packet performs the same evidentiary work. A sequentially late packet may decompress successfully without updating state, and feedback can be withheld. Detection of context damage is implementation-dependent.

That is disciplined uncertainty. “The packet worked” reports an event. “The context is trustworthy” reports a condition that governs a sequence of later events. A system that stores only the first proposition destroys the distinction it will need when the sequence diverges.

A checksum has a subject

Operators often treat a check result as a general halo around a transaction. The useful question is narrower: what exact bytes, fields or state transitions were inside the calculation?

For co_repair, CRC-7 speaks about the reconstructed uncompressed header chain. The control CRC-3 speaks about the applicable control fields. Neither is a cryptographic signature. Neither proves origin, delivery to an application, media quality or the correctness of an unrelated implementation. Most importantly, one must not be borrowed to certify the other's subject.

This is why a green indicator without a scope description is weak evidence. A receipt should identify the object checked, the input state used, the state proposed, the check applied, and the consequence authorised by that result. “CRC passed” is incomplete in the same way that “review passed” or “model succeeded” is incomplete: it omits the proposition that was actually tested.

The dangerous error arrives later

An invalid current output tends to fail near its cause. A valid current output paired with an invalid state transition can fail much later, after positive feedback has encouraged both ends to continue from the same mistaken premise.

That delay changes governance. Incident responders may inspect the packet where failure becomes visible rather than the earlier transaction that corrupted future state. Success telemetry may have discarded the earlier evidence. Retries can deepen the divergence. Rollback may restore software while leaving state produced by the old path in place.

The control problem is therefore not simply error detection. It is causal preservation. Systems need enough evidence to reconstruct which observation justified acceptance of the output, which observation justified mutation of state, and which actor allowed the system to proceed.

Separate acceptance from advancement

RFC 5225 is not a general enterprise architecture standard, but its boundary transfers cleanly as an analytical test. Any operation that both emits a visible result and changes hidden state should answer at least four questions.

Did the current output satisfy its own validity condition? Did the proposed state transition satisfy a check that actually covered the changed fields? Should the system acknowledge the current result? Should it advance, quarantine or re-establish the durable state used for future work?

Those answers may differ. A result may be usable while its accompanying learning, cache update, policy mutation or control-state change is rejected. Conversely, a state update can be internally consistent without proving that a user received the intended outcome. Tying all four decisions to one success bit creates an incentive to overstate evidence because operational simplicity looks like certainty.

What the record does not establish

RFC 5225 does not show that a named modem, handset, radio network, vendor or implementation mishandled control state. It provides no current deployment share, packet trace, incident count or quality result. The IANA profile registry proves registration, not use. The surrounding ROHC RFCs establish a standards family, not market adoption.

The article also does not claim that every repair packet contains an error. The second check exists because the first check does not cover the same subject; its presence is not evidence that the adverse condition occurred. This distinction between a designed safeguard and a documented incident must remain intact.

Keep a two-part success receipt

For a consequential stateful operation, retain two linked receipts. The output receipt records the observed input, reconstruction or computation, exact validation scope, result and delivery boundary. The transition receipt records the prior state identifier, proposed fields, independent validation, accepted or rejected mutation, feedback sent, resulting state identifier and the principal who authorised continuation.

Preserve negative and ambiguous outcomes: successful output with rejected state update, valid update without confirmed delivery, late input that did not advance state, feedback withheld, repair requested and context re-established. They are not clutter. They describe the boundaries within which success remains true.

Lu Heng's reality-first doctrine matters here. Institutional confidence is not running evidence, and responsibility cannot be assigned to a protocol label. One owner must be answerable for the decision to advance state when the evidence for today's output does not cover tomorrow's dependency.

Sources

Additional standards record

  1. RFC 5225 plain text
  2. RFC 5225 information record
  3. RFC 5225 Datatracker record
  4. RFC 5225 history
  5. RFC 5225 errata
  6. RFC 5225 inline errata view