Summary

  • OPSAWG adopted VELOCE and published Working Group revision 00 on 25 August 2026. The public record describes a WG document and Internet-Draft, not an RFC, BCP or final IETF rule.
  • An attributed project-call summary from that date says an IANA pointer to the repository was confirmed, while revision 00 consciously declares that it has no IANA actions. Pull request 49, which sketches an IANA registry with hashes, states and approval fields, was still open and unmerged at the research cutoff.
  • A project-call conclusion is not the same thing as a Working Group consensus act confirmed on the mailing list. A GitHub merge is not the same thing as WG, Area Director or IESG approval. An IANA row can record an approved artifact without becoming the institution that approves its normative meaning.
  • VELOCE already avoids one familiar hazard: an RFC reference must lead to a specific tagged version rather than a moving branch head. The remaining question is how a later approved module becomes the relevant immutable target, how IANA verifies it, and what version an implementor is entitled to claim conformance against.
  • The practical remedy is a thin decision-to-pointer receipt: a linked public record of consensus, approval actor, exact module bytes, registry request and state change, version-selection rule, recovery evidence and later operational adoption. It should add traceability, not a new veto or a replacement RFC for every bounded correction.

One date, four different states

The public history starts with an ordinary but important distinction. OPSAWG chairs closed the June adoption call by finding sufficient support and asking for the individual submission to be republished as draft-ietf-opsawg-veloce-yang-00, with no other change. The Datatracker record shows that revision as a Working Group document approved on 25 August. That establishes custody of the document by the group; it does not settle every design choice that will emerge in later revisions.

Revision 00 proposes an experiment in which a YANG module is not inserted into the RFC. Instead, the RFC would link to a particular tagged repository version. That detail matters. A branch called main can move after publication; a designated tag or commit lets a future reader retrieve and verify the bytes that the publication referred to. The draft also contemplates an adopted module being updated in an IETF repository, with the RFC reference changed to point to the new version. Its stated ambition is lighter module maintenance while retaining Working Group involvement and IETF rough consensus.

That ambition answers a real cost problem. A small, security-relevant or interoperability-correcting module revision need not automatically require a full replacement RFC merely because the module was printed inside the old document. But unbundling text from the RFC also unbundles facts that the old publication object silently kept together: which bytes were approved, who authorised them, where they can be recovered, and which exact revision satisfies a conformance claim.

Before IETF 126, the authors put those questions in the open. A mailing-list discussion asks whether an RFC should point to a Git tag, an IANA entry or another target; what a latest pointer would mean; which version an implementor should use; and how conformance stays testable after an update. The IETF 126 minutes preserve competing views about GitHub, an IETF-controlled environment, IANA publication, archival and recovery. That discussion ran out of scheduled time and continued on the list. It is evidence of a live design question, not evidence that any participant did something improper.

The 25 August project-call summary adds a fourth state. It says contributors may work through issues and pull requests in the repository; views formed in biweekly calls will be summarized to the mailing list; objections should lead to further discussion before merge; and an IANA indirection model was confirmed. The summary is useful provenance, but its own form matters. It is an attributed account of a project call, not a published Working Group consensus call or an IESG decision. RFC 8874 gives GitHub work no special status and requires Working Group consensus decisions to be confirmed on the mailing list.

A call can advance a design; it cannot silently replace that confirmation.

Now set that statement beside the actual Working Group draft. The IANA Considerations section says that the document has no IANA actions. Under RFC 8126, an explicit no-action section is not a blank to be read through. It records a conscious conclusion that IANA has nothing to do in that document as written. It does not prohibit a later revision from adding a valid request. It does mean that the pointer architecture described in the call summary had not yet become an IANA instruction in revision 00.

A proposed registry is not a completed registry

The gap is visible in pull request 49. At the cutoff it was open and unmerged. It proposes replacing the no-action section with a YANG File/Module References registry. Its proposed fields include permanent and proposed state, a precise URL, a SHA-256 value, controlling contacts, and IESG or other approval paths. Those are promising separation devices: a hash identifies bytes, a contact establishes stewardship, a state distinguishes proposal from current record, and an approval field names a decision path.

But proposed fields are not current public authority. The existing IANA YANG Module Names registry is governed by RFC Required and exposes familiar module information such as name, file, namespace, prefix, reference and notes. It does not presently expose the proposed VELOCE fields for a file hash, approval state, controlling contact or decision receipt. No conclusion should be drawn that IANA has already created the new registry, adopted its policy or fetched a VELOCE version.

This is not pedantry about labels. The four objects do different jobs. A repository can receive a pull request and retain a review history. A merged change can indicate that a maintainer applied repository rules. A Working Group can reach rough consensus on a document or a bounded change. An Area Director or the IESG may hold a further approval role. IANA can perform a defined registration or publication action. The resulting registry row can preserve the identity of a version. None of those acts automatically proves the others.

The distinction protects each institution. Asking IANA to decide whether an otherwise disputed module is substantively ready would turn a recorder into an approver. Treating a merge as proof of consensus would give a repository permission a constitutional weight it does not have. Treating a tagged release as proof of deployment would confuse repeatable bytes with an operator’s decision to use them. The right design lets each act be visible precisely because it does not impersonate another.

There is already useful counterevidence to the darker reading of this situation. Revision 00 does not point to a branch head. It explicitly retains rough-consensus procedures. The open pull request tries to constrain IANA with hashes and named approval paths, not grant it unbounded discretion. And an early Working Group revision may properly lag an unresolved discussion. VELOCE is not an approved RFC, a BCP or a mandate to produce a registry tomorrow. It is a proposal whose controls need to catch up with its stated direction.

The receipt that makes a pointer governable

The missing artifact is smaller than a second standards process. For each later module change, VELOCE could publish one linked decision-to-pointer receipt with the following elements:

  1. the change class and claimed normative effect;
  2. the controlling Working Group and the document’s current authority state;
  3. the mailing-list consensus call, opening and closing dates, material objections and chair disposition;
  4. the exact draft or approval text that asks for the registration;
  5. the repository URL, immutable commit, tag and content SHA-256;
  6. separate names and timestamps for author, reviewers, merger and the actor who holds approval authority;
  7. the IANA policy, requestor, request time, fetched bytes and verification result;
  8. the prior and new registry-row identities, effective time and supersession link;
  9. the publication-time version, latest approved version and the version an implementation is tested against;
  10. compatibility and test evidence, with any limits stated plainly;
  11. mirror and backup locations, their latest successful synchronization and a recovery exercise; and
  12. a separate record of actual implementation or operator uptake.

The receipt should not declare that a call is consensus merely because it was constructive. It should link the later formal confirmation. Nor should it elevate the IANA transaction into a substantive judgment. The approval actor decides whether a candidate may become current; IANA checks and records the requested, approved artifact under the agreed policy. The registry is then an evidence-bearing pointer, not a miniature legislature.

This is the useful lesson in Heng Lu’s Note 63. The note is not evidence about VELOCE or IANA. It offers a design lens: custody, recording and provenance can make a decision auditable without appropriating the authority to make it. A pointer that merely says “latest” risks collapsing record and judgment. A pointer that carries an immutable identity plus a decision trail preserves their boundary.

The same discipline applies to conformance. RFC 9907 supplies today’s published baseline: normative YANG statements are treated like normative RFC prose, and new or updated modules are registered through the IETF XML and YANG Module Names registries. VELOCE may eventually define a different maintenance arrangement, but it has not displaced that BCP at the cutoff. An implementor should therefore not be left to infer whether “latest repository version,” “latest IANA row,” “the version cited by an RFC,” and “the version certified by a test” are interchangeable. They may sometimes coincide; the receipt must say when they do not.

Sources

  1. OPSAWG charter
  2. VELOCE Datatracker record
  3. IETF 126 OPSAWG minutes
  4. Pull request 49
  5. Heng Lu Note 63
  6. IANA YANG parameters
  7. OPSAWG VELOCE adoption result
  8. VELOCE pointer discussion
  9. 25 August VELOCE call summary
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907