Spec compliance

ndn-rs’s compliance with the NDN Packet Specification and the NDNCERT specification is tracked by live witness scripts under testbed/tests/audit/ that exit non-zero when a compliance claim regresses. This page summarises which areas are covered.

The live source of truth is testbed/EXPECTED_FAILURES.md. This page is a reader-facing map to the witnesses, not a substitute for the tracker. A feature is release-ready only when the corresponding witness passes or the tracker explains why the remaining work is out of scope.

Coverage areas

The testbed/tests/audit/*.sh scripts are the runnable witnesses; each exits non-zero when the claim it tracks regresses.

As of the 2026-05-28 release-readiness pass, the tracker-driven audit harness runs every script named by testbed/EXPECTED_FAILURES.md and reports 54 PASS / 0 FAIL / 0 SKIP. The report for that local pass was captured in testbed/tests/audit/transcripts/release_audit_run_all_after.txt; the important release signal is zero divergences from the tracker.

Grep-only checks are not release-quality proof for protocol behavior. They may guard documentation wording, removed APIs, or source inventory, but packet, security, forwarding, and management claims need a RUST-UNIT, RUST-INTEG, INTEROP-SCRIPT, or WIRE-CAPTURE witness before this page should describe them as complete.

Reading the witnesses

Each witness is a shell script with exit-code semantics:

• 0 — finding passes / claim holds.
• 1 — finding fails / claim regressed; the script prints the exact diagnostic.
• 2 — live interop precondition is missing; Rust/local witnesses may have passed, but the Docker leg did not run.

# Run a single witness:
bash testbed/tests/audit/a17_blake3_registered.sh ; echo exit=$?

# Run every release-tracked audit witness:
RESULTS_DIR=/tmp/ndn-audit-results bash testbed/tests/audit/run_all.sh

The audit harness scaffold is testbed/tests/audit/_template.sh; new findings follow the same shape (project memory feedback_witness_first_compliance).

Cross-impl on-disk references

Per project memory feedback_cross_reference_standard, every audit finding cites the source implementation it tracks against the upstream NDN reference implementations cloned on disk. The references live alongside each witness script’s # Finding: header comment.

Recently closed blockers

These audit rows were release blockers in the pre-v0.1 tracker and now have passing behavioral or live witnesses:

The remaining shared-medium depth work is now optional transport breadth: Ethernet/BLE captures can extend the same invariants beyond the live UDP socket fixtures when those environments are available.

Intentional extensions (downstream-relied-upon divergences)

A few ndn-rs behaviors deliberately extend or diverge from stock NFD/ndn-cxx. They are intentional, not findings, and downstream stacks (notably NDF) build on them, so each is pinned by a passing regression-guard witness in testbed/tests/audit/ and tracked in testbed/EXPECTED_FAILURES.md under “NDF-relied-upon extensions”. They are listed here so the divergence is part of the documented compliance surface rather than an untracked delta.

The SignedTrustContext wire object also carries an optional non-critical provenance hint (SOURCE_BUNDLE_HASH, TLV 0x041A) recording the SHA-256 digest of the source trust bundle a context was projected from; old nodes skip it per the NDN evolvability rule.

Strictness divergences (stricter than ndn-cxx/NFD)

The LP/SVS NNI-width leniency is a known internal inconsistency (audit I-2): the same rule is enforced in some decoders and not others. It is tracked to be made uniformly strict as part of consolidating the duplicated TLV/NNI codecs onto one ndn-tlv API (audit R-1).

This is intentional: a minimal-length VAR-NUMBER is the canonical wire form, and rejecting non-minimal encodings avoids two distinct wire representations of the same logical packet. The NDN Packet Format recommends minimal encoding, and the reference implementations emit minimal forms, so in practice interop is not affected — a conforming peer never sends a non-minimal length. ndn-rs likewise encodes minimally. The only one-directional risk is a hand-crafted or deliberately non-minimal encoder; a differential test against python-ndn / NDNts is tracked to confirm the references never emit non-minimal lengths in the wild. (Audit finding I-1.)

TLV codepoint allocations

ndn-rs’s TLV allocations split into three classes:

• IANA / registry codes ndn-rs implements (forwarding).
• ndn-rs-internal codes used only on in-process or shared-memory faces (no wire reach).
• Codes reserved for v0.1.x.

Releasing under v0.1.0

Release-readiness is gated on every critical-severity audit finding being closed, the cross-implementation interop suite running in the interop image, and the release notes matching the live tracker. The 2026-05-28 Docker baseline for testbed/tests/interop/run_all.sh passes all eight ndn-cxx and NDNts packet-exchange scenarios. The same pass now also includes live G.03 PSync, G.04 NLSR, G.06 AutoConfig, C.09 SafeBag, N.12 management-response signing, and E.05 notification-stream witnesses. Remaining work is mostly deeper optional fixture coverage and smaller semantic policy rows, not a blocked generic interop harness. For heavy AutoConfig/testbed rebuilds on Docker Desktop, prefer NDN_TESTBED_BUILD_JOBS=2 testbed/tools/up-g06-low-memory.sh so the reference C++ and Rust tool images build sequentially.

See also

• testbed/tests/audit/ — runnable witness scripts.
• v0.1.0 release boundary — what is in scope once the release is tagged.