Summary
- RFC 9682 relocates a nonempty-model requirement: zero rules may be acceptable in a source file, but an entry point remains necessary after directive processing.
- The September 2026 CDDL module draft makes composition more explicit without universally fixing dependency lookup. Approval therefore needs to identify the assembled model, its selected root and the environment that produced it.
A single digit disappears from a grammar. An acceptance checklist written against the old grammar may now reject something deliberately permitted by the new one. That is the small administrative trap in RFC 9682: continuing to enforce yesterday's check can be wrong, while simply deleting it can also be wrong.
The digit is the minimum repetition count. In ABNF, the notation used to describe the grammar, an unspecified minimum means zero; a minimum of one requires at least one occurrence. This is a rule about what a parser may accept, not a judgment about whether accepting it completes the task. RFC 5234, section 3.6
For a self-contained data description, insisting on a rule in the file is reasonable. For a component that obtains all its rules through composition, it demands the answer before all the inputs have arrived. The useful reform is to inspect the whole at the point where a whole exists. The dangerous reform is to forget that inspection.
An empty component is not an empty answer
Published in November 2024, RFC 9682 updates the CDDL grammar. Section 3.1 permits zero rules in a file because module directives can supply them later. It explicitly retains at least one rule as a semantic constraint after all directives are processed. Its informative Appendix B.2 makes another staged-processing choice: qualified byte-string contents are handled semantically after their outer syntax. Neither change licenses arbitrary finished models. RFC 9682
The distinction is not between data that fits a schema and data that tells the truth. It concerns formation of the model itself. An empty CDDL input is not an all-accepting completed validator. Nor should a contributor add an irrelevant rule merely to make an old file-level check turn green. That would substitute a ceremonial answer for the information the check was meant to establish.
Basic CDDL takes its root from the first defined rule, which must define a type rather than a group. The name need not literally be “start”. Application designers separately decide how deeply to enforce a data description; that discretion does not erase the model-formation requirement. RFC 8610 also urges clarity and warns against relying on a matcher without further defenses. RFC 8610, sections 2.2.4, 4.2 and 5
This makes “there is at least one rule” a necessary but inadequate procurement answer. Which rule became the root? Does it express the intended entry point? Can the receiving team reconstruct the same selection? A populated file can be the wrong answer just as an empty component can be a legitimate input.
The composition environment joins the specification
The current module proposal, draft-ietf-cbor-cddl-modules-07, is dated 2 September 2026. It is an Internet-Draft, not an RFC; RFC 9682 referred to an older draft. Its directives can be read as comments by basic tools. That compatibility technique allows carefully designed dual-use files, not a guarantee that directive-blind and directive-aware tools will produce the same model.
The draft also distinguishes inclusion from dependency-following import. It intentionally leaves the general arrangement and precedence of source directories to context. One documented implementation searches the current directory before its own collection. Its command-line example supplies a chosen root and produces a synthetic first rule even without an input file. These are documented design and tool examples, not tests performed for this article. CDDL Module Structure, version 07
Consider a hypothetical supplier delivering a small module and a successful parsing result. The customer assembles it using a different set of dependencies. Neither organization necessarily changed the visible file, yet the artifact on which acceptance should rest has changed. The relevant evidence is no longer exhausted by the attachment in the purchase order.
The problem can be mundane rather than malicious. A developer's local directory may contain a newer definition with the same name. A release environment may fall back to its packaged collection. A support team may retain the top-level file but lose the selected dependency version. These are plausible failure mechanisms, not reported incidents involving a named vendor.
A namespace prefix helps distinguish rule names. It does not, by itself, establish who supplied the bytes behind a module name. Conversely, a trusted supplier does not establish which root a consumer selected. Source identity, name resolution and entry-point choice answer different questions; a single “validated” badge compresses them too aggressively.
Move the evidence with the check
For a modular model, a useful acceptance record would preserve the source identifiers, lookup configuration, processor version, selected root and resulting model. This is an editorial recommendation, not a new protocol requirement. Its value is that another team can inspect the same completed object without guessing how a previous operator assembled it.
The record should also say what was actually checked. Parsing an individual file, resolving its dependencies and validating a finished model are distinct results. They need not be performed by different products or departments. They do need distinguishable evidence. Otherwise a well-intentioned change to an early check can erase the only visible sign that the later one never happened.
There is a limit to this analysis. The cited documents establish the design and identify security considerations; they do not establish an adoption rate, a supplier breach or a measurable loss. No implementation experiment was run here. The leadership lesson is narrower and more actionable: when a requirement survives a change of checking stage, its evidence and accountable owner must survive too.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
