Summary

  • draft-ietf-netmod-yang-next-agreement-00 sorts the YANG Next issue inventory into work that should enter the next version, work that may be considered, work deferred beyond the next version, and work closed or proposed for closure.
  • The map is a revision-specific classification receipt. Neither a bucket, a closed GitHub issue nor WG Document status alone proves item-by-item consensus, final inclusion, normative meaning, backwards compatibility, implementation feasibility, tool readiness or deployment.

Imagine a release board with four columns. One says “include”; the next says “consider”; the third says “later”; the fourth says “close”. Around 160 language requests, clarifications and complaints have been moved into those columns. The board is already more useful than a single backlog: it exposes priorities, reduces accidental scope and lets people argue about the same map.

Now imagine a procurement team reading the first column as a product roadmap. A compiler maintainer treats it as the next grammar. An operator assumes that a closed card means the risk has been settled. Each reader has promoted a planning artifact into evidence it does not contain.

That is the important mechanism in revision 00 of YANG Next Agreement. The document does not define YANG 2.0. It projects the netmod-wg/yang-next GitHub issue inventory into a Working Group Internet-Draft and proposes four lanes for deciding the scope and shape of a future language revision. Its contribution is constitutional before it is syntactic: it tries to decide which questions deserve to become specification work.

The visible status is deliberately incomplete

The document's current standing needs two separate sentences. The IETF Datatracker lists revision 00 as an active NETMOD Working Group Internet-Draft, last updated on 23 June 2026. It shows the WG state as WG Document and the IESG state as I-D Exists. The structured Intended RFC status field is blank. The draft header, separately, says Intended status: Informational and says the draft expires on 25 December 2026.

Those surfaces are not interchangeable. A Working Group document is a recognized vehicle for group work. I-D Exists records the existence of an Internet-Draft in the process. The header states an intended treatment chosen for the document text. None says that the IETF has approved the four buckets, accepted every placement or adopted any listed language change.

The draft narrows the claim itself. Its abstract says the purpose is to discuss and hopefully find agreement on the scope and shape of the next YANG version. Its introduction says there is no goal to publish this document as an RFC and suggests that a GitHub dashboard might eventually track the issues. The object is a map for discussion, not the destination standard.

Why four lanes are better than one backlog

The GitHub tracker contained, by the draft's count, roughly 125 open issues and 35 closed ones. They differ in importance, complexity and compatibility risk. If work were selected only by whoever happens to volunteer, the resulting language could grow large and inconsistent before the group has agreed what problem the new version should solve.

The four-lane design tackles that failure. The strongest lane contains changes the authors believe should be made in any future version. A second lane holds proposals worth considering if there is enough interest. A third defers work beyond the next version. A fourth contains issues that should not be pursued further, including changes considered too harmful, large or complex.

This creates a useful negative power. It lets the group freeze the perimeter before every attractive feature becomes part of the core. It also forces alternatives into view. The draft notes that Appendix Issue 152 offers a somewhat different scoring and classification. That disagreement is not an embarrassment; it is evidence that the classification remains a proposal subject to review.

Even the strongest lane is qualified. Section 2 calls its contents issues that the authors believe should be added. It says some clarifications may, after review, require no specification change. A heading cannot remove those conditions.

Closed is a routing state, not a technical verdict

The fourth lane is especially easy to misuse because “closed” sounds final. In this draft it is not one uniform conclusion. The closed section contains issues already closed on GitHub, open issues the author proposes closing, duplicates, misunderstandings, changes believed harmful, and requests judged to belong to protocol work rather than the language.

Some previously closed issues also appear in other lanes because circumstances have changed; a YANG 2.0 option may make an earlier compatibility objection worth reconsidering. Therefore the same visible state can carry several meanings. A duplicate is not a rejected idea. A protocol issue is not an impossible feature. A low-priority request is not proven harmful. A closure proposal is not a chair's consensus determination.

The evidence must retain the reason, the revision and the forum. For any issue, record the exact GitHub identity, discussion and timestamp; its placement in the exact draft revision; the editor's rationale; unresolved alternatives; and any later working-group conclusion. Without those joins, “closed” is only a database state.

From issue map to running code

Earlier NETMOD discussions show why the extra steps matter. IETF 120 minutes record interest in YANG Next but no clarity on whether the objective was YANG 1.1, 1.2 or 2.0. The chair asked for motivations and objectives and said Git would not replace the working group's consensus process. At IETF 121, participants described a self-selected issue-scoring team and insisted that resulting work return to the WG. The proposal to create and adopt a summary document was a way to seek group buy-in, not proof that buy-in already existed.

RFC 7282 makes rough consensus more demanding than a count or label: justified objections must be found, understood and addressed. A complete evidence ladder for a YANG Next item therefore has several rungs.

First comes inventory evidence: what was requested, by whom, with what examples and current state. Second comes classification evidence: where revision 00 placed it and why. Third comes consensus evidence: mailing-list and meeting discussion, objections, responses and a chair's scoped judgment. Fourth comes normative evidence: exact later specification text and its dependencies. Fifth comes compatibility evidence: old and new grammar, semantics, modules, extensions, deviations and client/server behavior. Sixth comes implementation evidence: independent parsers, compilers, tests, negative cases and interoperation.

Only then can deployment evidence show staged adoption, rollback and observed operational effects.

The current draft is strongest at the second rung. That is valuable. It is also where its authority should stop.

What the map does not own

Existing YANG work already addresses adjacent but different questions. The YANG 2.0 draft proposes a language baseline. Module versioning describes revision identity and ancestry. Schema comparison classifies differences under stated inputs. Module filename guidance addresses repository names and aliases. YANG Packages describes composition and conformance sets. None of those mechanisms turns the four-lane map into implementation proof; the map likewise does not replace their technical rules.

For a vendor, “included” should trigger design and feasibility review, not a release promise. For a tool maintainer, it should trigger grammar and corpus experiments, not default acceptance. For an operator, it should trigger monitoring of specification and implementation evidence, not a migration. For the working group, it should create a bounded agenda on which consensus can be tested issue by issue.

This is the productive reading of Heng Lu's minimum-initial-specification discipline. Freeze the smallest visible decision surface. Keep future choices local. Let voluntary adoption follow reproducible results. The symbolic layer—the draft state, bucket and label—coordinates attention. The reality layer begins when exact text compiles, independent tools agree and operators can observe and reverse the consequences.

Sources

Current document and history: YANG Next Agreement revision 00; Datatracker record; Datatracker history.

Process and technical context: IETF 120 NETMOD minutes; IETF 121 NETMOD minutes; RFC 7282 on rough consensus; YANG 1.1, RFC 7950; YANG 2.0 draft revision 00.

Interpretive framework: Minimum Initial Specification; On Reality Layers; Running Code Primary.