Summary

  • draft-ietf-opsawg-veloce-yang-00 proposes that RFC prose reference an exact tagged YANG module maintained in a source repository. The tag is a strong content-identity receipt, but a merge or green CI run does not automatically prove Working Group consensus or publication authority.
  • The operational chain continues after publication: preserved governance records, release custody, the server's actual YANG Library, representative operations and observed network effects remain distinct proof obligations.

The validation badge was green. The pull request was merged. A release tag now pointed to one immutable commit.

In a software team, those three facts often feel like closure. In a standards process, they answer only the first questions. Which source was tested? Which change entered the repository? Which object should a later reader retrieve?

They do not answer whether the Working Group agreed with the change, whether the publication process accepted it, whether a vendor shipped those bytes, whether a device enabled the same features and deviations, or whether an operation using the model produced the expected network state.

That is the important promise—and the important boundary—inside draft-ietf-opsawg-veloce-yang-00. VELOCE, short for YANG deVELpment PrOCEss and maintenance, proposes separating a YANG module from the prose that explains it. The prose would continue to carry the model's explanation, references, IANA actions, security analysis and operational considerations. The module would live in a source-code-management repository, where contributors could review small diffs, run validation and maintain it without republishing a large document merely to adjust code.

The proposal deserves attention because YANG is source code as well as specification. A long RFC publication cycle can be a poor fit for an artifact that benefits from parsers, linters, dependency checks, tests and incremental correction. VELOCE tries to retain the IETF process while giving the module a workflow closer to the one engineers actually use.

The current document is an active OPSAWG Working Group Internet-Draft dated 25 August 2026. Its header says the intended status is Experimental, while the Datatracker summary field shows no intended RFC status. It is not an RFC, a completed experiment or evidence of deployment. The frozen record names only revision 00. Its proposed one-year and two-year targets, and its claims about reduced friction, remain hypotheses to be tested.

The sharpest rule appears near the centre of the draft. The YANG module must not be inserted into the document. Instead, the document must point to a specific tagged version, such as a tag or commit hash, rather than the head of a branch. That makes the module at publication time permanently retrievable and verifiable.

This is a material improvement over a mutable link. main is a moving address. A commit is a content history object. A protected release tag can give reviewers, implementers and auditors a stable rendezvous point. The tag answers: which repository state did this publication mean?

But the precision of that answer can invite a category error. A tag freezes an object. It does not freeze legitimacy.

RFC 8874, the IETF's guidance for Working Group use of GitHub, is explicit that work done on GitHub has no special status. Its output remains subject to Working Group approval, rejection or modification. It also says a repository copy need not perfectly reflect Working Group consensus at every point in time. Editors require room to manage a document; repository state and collective decision are related, not identical.

That distinction matters because repository interfaces make administrative events unusually visible. A pull request has reviewers. A check has a color. An issue has a state. A commit has an author. A merge has a timestamp. Working Group consensus is less visually compact. It is assessed by chairs across mailing lists, meetings, interim sessions and other venues, accounting for who did not happen to follow one repository thread.

RFC 8874 therefore requires Working Group consensus decisions to be confirmed through the mailing list and places the ultimate consensus determination with the chairs. RFC 2418 makes the same institutional point from an older process vocabulary: rough consensus is not a numerical vote; the chair determines whether it exists, and decisions reached in a meeting must be reviewed on the list.

A merged pull request can be entirely proper without being a consensus receipt. RFC 8874 allows editors discretion to merge, notes that chairs may ask them to wait on a particular change, and distinguishes ordinary editorial work from design issues that affect implementations or interoperability. An issue label can record a process state, but it receives authority from the documented process and chair action, not from the label string itself.

VELOCE tries to bridge that gap. It directs editors to review proposed module changes, ensure that they align with Working Group consensus and validate them before merging into the primary branch. The right implementation is not to slow every correction until the repository becomes unusable. It is to bind the eventual consensus record to the exact commit that implements the decision.

That binding needs a receipt with at least four identities: the issue or design question, the accepted resolution, the chair's bounded consensus determination and the resulting commit/tag. Without the join, an auditor can prove that a decision occurred and that code changed, but not that this code is the decision the group accepted.

Continuous integration has a similarly important but narrow role. RFC 8874 describes CI building drafts, validating formal languages and checking source or examples. VELOCE recommends suitable YANG validation and a containerized build environment so contributors can reproduce checks locally.

A green run is evidence about named tests over named inputs. Its force depends on the exact commit, validator version, dependency graph, enabled features, lint profile, container image and test corpus. It can prove that a module parsed or satisfied chosen rules. It cannot prove that omitted tests would pass, that a security consideration was fully implemented, that every imported revision resolved as intended or that two devices will behave identically.

This is not an argument against automation. It is an argument for preserving its denominator. “Validated” is a meaningful statement only when the record says what was validated, by what, against which dependencies and with which exceptions.

Publication creates another boundary. VELOCE's exact reference can bind prose and module more honestly than an unversioned repository link. YANG Doctors can review the same tagged object that publication names. The RFC record can then identify the intended module snapshot without embedding pages of generated source.

Yet publication does not move those bytes into a vendor package. Between tag and device sit repository custody, release production, artifact signing, dependency selection, packaging, vendor integration, image construction, rollout and local enablement. A perfectly preserved standard can coexist with an old module on a router.

The IETF's own GitHub guidance warns about this custody layer. Git replication helps preserve repository content, but issues, pull-request discussions, reviews and wiki material are more exposed to loss. External-service failure and compromised privileged accounts remain relevant. RFC 8875 adds administrative and backup guidance. A durable standards record therefore needs more than the Git object: it needs archived decision context, recoverable ownership and a protected mapping from decision to release.

The first credible runtime receipt comes from the device, not the repository. RFC 8525's YANG Library lets a server report module sets associated with its datastores, including revisions, features and deviations. That readback can test whether a target says it implements the intended module context. A tag cannot.

Even that evidence has limits. A YANG Library response is a server assertion about its schema. It does not prove every constraint, RPC or state transition works. An operator still needs representative NETCONF or RESTCONF operations, state readback and an observation of the service outcome. Schema identity, protocol acceptance and network effect are three different claims.

This is where Heng Lu's running-code lens is most useful. It does not require standards groups to wait for universal deployment before writing specifications. It requires them not to promote symbolic evidence into operating truth. The tag belongs to the repository layer. Consensus belongs to the decision layer. Publication belongs to the standards layer. Loaded schema and behavior belong to the running system.

The minimum-initial-specification principle supplies a constructive design choice. Standardize the smallest evidence joins necessary for interoperability: exact content identity, reproducible validation, a discoverable consensus record and an immutable publication reference. Leave repository tooling and local release systems adaptable. Then let voluntary implementation and interoperable running code carry the proposal beyond its institutional origin.

The multi-stakeholder warning is equally precise. A busy repository is not automatically a representative room. Participants who follow issues closely are a selected population; those who rely on the mailing list may never see the same thread. RFC 8874 already recognizes that bias. Good process does not count interface activity as mandate. It deliberately reconnects the repository to the wider Working Group.

VELOCE's potential value is therefore larger than “put YANG on GitHub.” Its real experiment is whether the IETF can accelerate code-shaped specifications without allowing repository convenience to collapse separate authorities into one. Success would mean faster, reproducible module maintenance with stronger—not weaker—links among the source object, the human decision and the running implementation.

The leadership test is simple. When someone says the module is done, ask which receipt they mean. If the answer is a commit, the bytes may be done. If it is a chair's consensus record, the Working Group decision may be done. If it is an RFC, publication may be done. If it is a YANG Library readback plus successful operations and service observation, deployment may be done.

One green check cannot carry all four meanings. Neither can one tag.

Sources