Summary

  • RFC 9907 is Best Current Practice 216, published in March 2026. It obsoletes RFC 8407 and updates RFC 8126, providing guidance for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules.
  • Its mechanism is editorial but operational: code-component delimiters, unique names, complete headers, revision-to-RFC traceability, explicit datastore semantics, useful examples, security analysis, and registry procedures make a specification easier to interpret consistently.
  • This is not a wire-protocol change and it does not guarantee interoperable implementations. It is process discipline aimed at increasing NETCONF and RESTCONF interoperability and usability.

A YANG data model is the conceptual description of management information and its relationships. An individual module is one implementation of that model in YANG; the two terms should not be treated as interchangeable. That distinction matters when reviewers inspect extracted code, imports, revisions, examples, and the surrounding prose.

RFC 9907 treats normative YANG modules and submodules as code components. They must be enclosed by CODE BEGINS and CODE ENDS tags. Published module names must be unique: normative IETF modules begin with ietf-, while examples should use example-. These are small controls with a large review benefit: they identify the authoritative component and reduce accidental collision between normative material and illustration.

The module header is part of the specification, not decoration. It should contain the current IETF Trust copyright statement and identify the YANG Parameters registry. References outside imported modules belong in reference statements. Each published revision needs a revision statement whose reference identifies the document containing that module. This traceability turns a generated or extracted module into an auditable artifact rather than an orphaned snippet.

Review also has to follow semantics beyond syntax. YANG 1.1 supplies language rules, while the Network Management Datastore Architecture supplies NMDA terminology and operational-state context. Authors must say what belongs in which datastore, how configuration and state relate, and what lifecycle or operational meaning a node has. A clean parse cannot resolve an omitted authority boundary.

Examples are review aids, not normative modules. They should clarify intended structure without being presented as implementation requirements. The document should also explain security consequences, including the management exposure created by the modeled data and actions. Finally, an IANA-maintained module needs an explicit registry procedure. The policy authority is the registry process; an ad hoc edit to generated module text is not a substitute for that procedure.

Pre-publication review checklist

  1. Are every normative module and submodule bounded by CODE BEGINS and CODE ENDS?
  2. Are published names unique, with ietf- reserved for normative IETF modules and example- used for examples?
  3. Does each module header contain the current Trust statement and identify the YANG Parameters registry?
  4. Are references outside imported modules present in reference statements?
  5. Does every revision identify the RFC or other containing document?
  6. Does the prose distinguish the data model from each implementing module?
  7. Are NMDA datastores, configuration, operational state, lifecycle, and authority explicit?
  8. Are examples clearly non-normative, and are security implications analyzed?
  9. For IANA-maintained modules, is the registry procedure explicit and authoritative rather than an edit to generated text?
  10. Can a reviewer trace each extracted code component back to its containing document?

Operator acceptance decision path

Accept a model only when the review record answers all ten questions. If a delimiter, name, header, revision reference, semantic boundary, example label, security analysis, or registry procedure is missing, return it for specification correction. If the answers are complete, accept the document as review-ready evidence—not as a promise that every implementation will interoperate. Escalate unresolved NMDA or registry authority questions before release, because ambiguity becomes harder to reverse once consumers build operational assumptions around it.

Sources