RFC 9947 needs an evidence-exit receipt

Summary

RFC 9947 confines its experimental Alternate-Marking SRH TLV to a controlled SR domain, while expecting results from willing live-network deployments to be shared with the Independent Submissions Editor or the IETF SPRING Working Group. Packet containment and evidence disclosure are different control problems.
A credible result needs a compact evidence-exit receipt: release authority, exact protocol and implementation versions, code point, tested field subset, comparison baseline, device cohort, sampling and uncertainty, negative findings, privacy transformations, artefact hashes and corrections—without publishing raw traffic, customer identities or exploitable topology.

The firewall stops a packet, not an inference

RFC 9947 draws a hard operational perimeter. Its Alternate-Marking experiment must run only within a controlled domain corresponding to an SR domain. Nodes are locally administered. One operator decides whether and how to configure the feature. Packets carrying the experimental TLV are prevented from entering or leaving. Participants coordinate a value from the experimental range 124–126 so that one trial does not collide with another.

That perimeter makes sense. The proposal was developed outside the IETF as an alternative to the Standards Track method in RFC 9343. It does not have IETF consensus, creates no IANA action and does not replace the existing specification. An experimental extension should not escape from the environment whose participants have coordinated its meaning.

But the experiment exists to produce an outward-facing conclusion. RFC 9947 expects results to be collected and shared with the Independent Submissions Editor or with the SPRING Working Group as Internet-Drafts. Initial results are expected within two years of publication. The document even recognises the tension: it anticipates a single-service-provider deployment partly because performance-monitoring data collected along packet paths may be hard to share.

The packet and the conclusion therefore have different borders. A border router can reject the first. It cannot decide whether a chart derived from it exposes a customer, a topology, an architecture weakness or merely enough method to support public review. “No experimental packet left the domain” is a security statement. It is not a disclosure authorisation.

The result is meant to choose between real alternatives

This is not an experiment whose answer can be reduced to “the feature worked.” RFC 9947 asks whether placing Alternate-Marking data in the SRH performs better or worse than carrying it in an IPv6 extension header under RFC 9343. It asks whether the TLV survives across the network, whether processing is faster or slower than the Destination Option, whether effects differ across device architectures, whether ordinary SRv6 programming still behaves correctly, and how the enhanced fields compare with other on-path telemetry.

Those questions require denominators. A claim of lower processing cost means little without the compared configuration, packet sizes, enabled features, traffic class, offered load and device cohort. A claim of wider survivability needs the path shape, the number and role of supporting and non-supporting nodes, and a definition of survival. An operator preference for extended metadata needs to disclose what was enabled and which operational cost was counted.

RFC 9947 allows more than the loss flag, delay flag and 20-bit FlowMonID. Enhanced use can carry an extended identifier, measurement mode, fragmentation state, direction, a timestamp, reverse-flow setup information and a sequence number. The reverse-flow controls can reflect prefix masks, protocol, ports, DSCP, tunnel scope and period. Even if a public report never reveals a raw value, the combination of fields determines what was measured and what privacy or reconnaissance risk had to be managed.

A polished average stripped of those choices would be safe-looking but weak evidence. A packet capture would be rich evidence but an irresponsible publication. The governance problem is to preserve the structure of the test while suppressing the operational particulars that should remain inside.

An experimental code point is part of provenance

The TLV type is not a permanent assignment. Implementations choose from an experimental range, coordinate the value among participants and should allow it to be configured so more than one experiment can operate without conflict. That chosen value belongs in the result's provenance even though it says nothing about merit.

Why record it? Because a later reviewer must know that two datasets describe the same wire experiment. A parser build configured for 124 and a device configured for 126 can produce an apparent failure that is really a coordination error. A collision with another local experiment can contaminate observations. Neither case proves the SRH approach inferior.

This is distinct from the broader proposition that an IANA code point does not confer deployment authority. RFC 9947 has no IANA action at all. Here, the code point is a join key between a method revision, a build, a domain configuration and an observation interval. Omitting it breaks the chain by which an outsider can distinguish protocol behaviour from an experimental setup mistake.

The same principle applies to the implementation subset. A device that ignores an unsupported TLV is behaving consistently with SRH processing rules. A test that expected every segment endpoint to collect data must identify which endpoints actually supported the function and which SID behaviours were selected. “Implementation present” is not a binary property when the experiment includes optional enhanced fields and programmable endpoint behaviour.

A controlled domain contains legitimate secrets

RFC 8799 describes a limited-domain boundary as a place where trust changes. It can also protect operational parameters that an operator does not wish to reveal. That is separate from the privacy of individual users, but both interests matter here.

RFC 9343 explains why. Alternate Marking does not need user payload, yet its metadata can assist reconnaissance. FlowMonID may help track a flow, and combined observation points can reveal network-path or performance information. Statistics travelling from monitoring points to a management system require secured channels. RFC 9341 adds integrity risks: an attacker may manipulate marking or time, interfere with collection, or exploit a very low-rate covert channel.

Public evidence can amplify those risks if it preserves the wrong granularity. Exact timestamps, narrow traffic classes, device locations and small counts can recreate the identity of a path even after names have been removed. A benchmark table can disclose which architecture struggles under a particular header combination. A topology diagram can reveal redundancy that an operator treats as sensitive. “Anonymised” is not a sufficient method description.

The opposite mistake is to invoke confidentiality as a reason to publish only conclusions. Outside reviewers then cannot see whether an apparent gain came from one vendor, one software build, one quiet interval or exclusion of the failures. The controlled domain becomes a rhetorical shield: trust us, the packets stayed in and the result was good.

Neither extreme serves the experiment. The task is not to make the protected dataset public. It is to expose the transformation from protected observation to bounded public claim.

The evidence-exit receipt

The smallest useful public record begins with authority. It should name the operator or research sponsor, the role that approved release, the submission destination and time, and any material equipment-supply or funding relationship. The ISE can receive an evaluation; SPRING can discuss it. Receipt or discussion is not endorsement, IETF consensus or a standards-track decision.

Next comes identity. The record should bind the RFC or draft revision, implementation build, configured experimental TLV value, base and enhanced field subset, SID behaviours and the RFC 9343 comparison configuration. Artefact hashes can show that a later report is discussing the same method bundle without exposing the bundle itself.

Then comes population. The public layer should describe device-architecture and firmware cohorts at an abstraction level that does not reveal exploitable inventory; topology shape without disclosing sensitive locations; observation interval; eligible traffic; exclusions; sample treatment; clock and counter assumptions; and the definitions used for loss, delay, jitter, survivability and processing cost. Missing data and confidence intervals belong beside averages, not in an unpublished appendix.

Finally comes outcome and transformation. Positive, negative, inconclusive and rollback-triggered findings should be represented. The record should say which flow, path, time and vendor attributes were aggregated, redacted or suppressed; what no longer can be reproduced by an outside reviewer; what protected material, if any, could be examined under narrower access; and how corrections replace or qualify an earlier public claim.

This receipt is Daniel Kade's editorial proposal, not a field list required by RFC 9947. It is deliberately smaller than a dataset and larger than a press release. Its purpose is to make the boundary crossing auditable.

Running code is evidence, not a verdict

RFC 7942 offers a useful but limited analogy. Its voluntary Implementation Status section asks Internet-Draft authors to record an implementation's responsible organisation, name, maturity and coverage so reviewers can take running code into account. It warns that a listing is not IETF endorsement and treats the information as time-dependent.

RFC 7942 explicitly excludes Independent Stream documents, so it cannot be imposed on RFC 9947. That boundary matters. The lesson is not “copy this BCP.” The lesson is that implementation evidence has identity, scope and time, and that public deliberation improves when those attributes travel with the claim.

RFC 7841 makes the other boundary visible. An Independent Stream Experimental RFC is not a candidate for an Internet Standard. Strong experimental evidence may motivate new work or shape an IETF decision, but it does not retroactively turn the original publication into IETF consensus. An evidence-exit receipt should preserve that distinction rather than place an institutional halo around a result.

What the sources can and cannot prove

The cited sources establish RFC 9947's status, protocol fields, controlled-domain rule, experimental questions and expectation of shared results. They establish the related privacy, integrity, limited-domain, SRH and stream context. They do not provide a result report, a deployed operator inventory or a public dataset for this experiment.

No claim is made here that results are late. RFC 9947 was published in March 2026, and its two-year wording is an expectation, not a deadline that has expired. No claim is made that an operator must disclose protected material or that every useful evaluation can be reproduced from public data.

The conclusion is narrower. When results do arrive, their authority and limits should be legible. The domain boundary can remain closed to experimental packets and raw traffic while a carefully bounded evidence object crosses it. That is how confidentiality and public scrutiny become compatible states rather than competing slogans.

RFC 9947 Keeps the Packets In. The Evidence Still Has to Leave

Why it matters

Summary

The firewall stops a packet, not an inference

The result is meant to choose between real alternatives

An experimental code point is part of provenance

A controlled domain contains legitimate secrets

The evidence-exit receipt

Running code is evidence, not a verdict

What the sources can and cannot prove

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing