Summary

  • RFC 9713 makes BP-version applicability explicit in the IANA Bundle Administrative Record Types registry and requires a BPv7 administrative element to use entries marked for version 7.
  • The RFC reserves 64384–64511 for BPv7 Experimental Use and 64512–65535 for BPv7 Private Use, preventing collision with centrally assigned values without creating cross-organization semantic agreement.
  • A defensible operating record must separate registry allocation, version scope, the referenced type specification, implementation capability, local convention, receipt, policy authorization, action and observed result.

One column changed the question

Before RFC 9713, the Bundle Administrative Record Types registry had history but lacked a crucial dimension. RFC 7116 had created the registry around BPv6’s four-bit type field. RFC 9171 then defined BPv7 administrative records as two-item CBOR arrays: an unsigned type code followed by type-specific content. Yet the registry did not explicitly say which entries belonged to BPv6, BPv7 or both.

That omission could make an integer look more authoritative than it was. Value 2 was a BPv6 Custody signal; BPv7 had moved away from that custody mechanism. Value 1, the Bundle status report, applied to both versions. A lookup that returned only “2: Custody signal” could be accurate as a historical registry fact and wrong as permission for a BPv7 element to process the value.

RFC 9713 repaired the lookup by adding a leftmost Bundle Protocol Version column. A BPv7 administrative element must determine usable values by finding 7 in that column, not by treating every occupied number as universally applicable. The public coordination surface became a pair: number plus protocol version.

The reference owns the content

Even number-and-version is not a complete instruction. RFC 9713 explicitly declines to define how BPv6 and BPv7 interoperate when they use the same code point, or whether the two versions interpret it similarly. The specification for each administrative-record type must state how that type relates to each BP version.

This is visible in the live registry. The row for value 1 points to RFC 5050 and RFC 9171. The present table also includes BPv7 values 13 and 14 for CCSDS signals and value 255 for ACME Node ID Validation. The registry identifies the allocation and its reference; RFC 9891 supplies the CBOR structures, tokens, checks and processing for value 255. The integer is an index into semantic custody, not a compressed copy of the semantics.

For operations, preserve the registry snapshot, the version cell and the exact reference revision together. Otherwise a parser can claim “registered” while implementing an obsolete structure, applying another version’s meaning or silently substituting a private convention.

Private space coordinates absence of central assignment

RFC 9713 sets aside 64384–64511 for Experimental Use and 64512–65535 for Private Use, all for BPv7. Those ranges solve a concrete collision problem: IANA will not assign a public type from the same space and unexpectedly occupy the chosen private value.

RFC 8126 draws the limit. Private Use is defined locally; IANA records no individual assignments, and separate sites may use one value in incompatible ways. Experimental Use is also not generally useful for broad interoperability. Reserving a range therefore creates room, not agreement.

Two operators can choose 65000 and both comply with the public registry while encoding unrelated content. A merger, roaming link, emergency interconnection or vendor replacement can bring those once-separated conventions together. The first shared Bundle does not negotiate which private dictionary wins. That requires an external agreement with owner, scope, revision, expiry, fallback and conflict behavior.

Delivery and processing remain separate facts

RFC 9713 supplies an unusually useful failure boundary. If an administrative element receives a malformed application data unit or a type code it cannot process, it must ignore the record. That handling does not alter the fact that the enveloping Bundle was delivered to the administrative element, nor other Bundle Protocol Agent processing such as status reports.

This is more than implementation hygiene. It prevents a monitoring system from erasing transport success merely because application processing failed. It also prevents transport success from becoming evidence that the instruction was understood.

A clean ledger needs at least these events: envelope delivered; payload identified as an administrative record; type code extracted; BP-version applicability confirmed; type specification and local convention resolved; content parsed; source and integrity checks evaluated where configured; policy authority decided; action attempted; state changed; effect observed. “Received” can be true while every later event is false or absent.

A registry is a coordination surface, not a remote control

RFC 9713 did not change the registry’s Specification Required procedure. Nor did it add security structures; RFC 9171’s security considerations continue to apply. The document improves a shared table and the rule for consulting it. It does not attest that a sender is trusted, that a parser is safe, that a local controller approved an action or that a change produced the intended service result.

This distinction is operationally valuable precisely because the registry matters. Without it, public allocations collide and version assumptions drift invisibly. With it, parties share a stable reference point. But the authority of that reference point ends at the claims it actually records.

Heng Lu’s Running-Code Primacy, Minimum Initial Specification and Reality Layers provide a disclosed editorial lens for that limit: common records should remain narrow and locally verifiable; later adoption belongs to running systems; a symbolic record must not borrow an execution result it does not contain. Those essays are analysis, not statements of IETF intent.

Sources