openconfig/public: where network operators publish vendor-neutral YANG models

A publication repository, not a library you install

The README is unusually explicit about what this repository is for: it is primarily for publishing the models, documents, and other material developed by the OpenConfig operators group. That sentence is worth quoting because it sets expectations before a single YANG file is opened.

OpenConfig itself is described as a collaborative effort by network operators to develop programmatic interfaces and tools for managing networks in a dynamic, vendor-neutral way. Its initial focus is compiling a consistent set of vendor-neutral data models written in YANG, based on actual operational needs from use cases and requirements from multiple network operators. The emphasis on operational needs from several operators is the mechanism of legitimacy here. A model lands here because multiple operators found the same operational need, not because one vendor shipped a model.

The audience is therefore split. Tool authors are the first group, because the models are the interface that a configuration generator, a validator, or a collector is written against. Operators are the second, because the models are the artefact their requirements shaped. Vendors are the third audience, and the interesting thing about them is that the licence permits them to implement the models, which is what makes the set vendor-neutral in practice rather than only in aspiration.

YANG files, and the tool badges that test them

The data model language is YANG, the IETF language defined in RFC 6020, and the repository root shows what a working model repository looks like in practice. There is a doc/ directory for documents, a release/ directory that holds released material, a scripts/ directory, a third_party/ directory, a regexp-tests/ directory, and a cloudbuild.yaml file for the build and test pipeline. The presence of a .github/ directory and a CONTRIBUTING.md file at the root rounds out a normal governance layout.

What is distinctive is the badge row at the top of the README. Six compatibility badges appear, for pyang, the OpenConfig linter, pyangbind, goyang/ygot, ygnmi and yanglint. These are separate projects with their own release cadences, and the badges record whether the models in this repository still validate and compile under each of them. A model change that breaks a parser or a generator is therefore visible on the front page rather than discovered later by a user of that tool.

This is the closest thing to a test suite in the project, and it is worth understanding what it does and does not check. It checks that the models are still accepted by the tools that consume them. It does not check that the models match what any particular network device does, because that is a question for the implementations, not for the schema.

The contribution path runs through a guide, a list, and an issue tracker

There is no install step here, and no command to run, because there is nothing to install. The README does not document a clone and build sequence for consumers, and the repository does not ship a binary or a package. If you want to use the models, you read the released material and point your existing tooling at it. The tooling is where the work is, and the badges name the usual candidates.

Contributing is a different path, and it is documented. For information about how to contribute to OpenConfig models, the README points to the external submissions guide at doc/contributions-guide.md. The word external is the important part of that filename: it describes a process for people and organisations outside the operators group, and it is a process document rather than a code contribution, since the artefacts under discussion are models and prose rather than a program.

The other two channels are the public mailing list for feedback and suggestions, and the GitHub issue tracker for the same purpose. The mailing list is a Google group, and the issues are on the openconfig/public repository itself. Joining the group itself is a separate matter: the README directs anyone who wants to join OpenConfig to the OpenConfig web site, and specifically to the FAQ for operators, which is a sign that participation is structured around operator membership rather than open sign-up.

Versioned releases with dates you can plan against

The recent release list is a useful signal about the shape of the project. Three tagged releases are listed: v5.10.0 on 2026-10-05, v5.9.0 on 2026-07-17, and v5.8.0 on 2026-05-08. That is a minor version every couple of months, with no patch releases visible in the list, which fits a project where the artefact is a schema set that gets revised as new operational requirements appear rather than patched for a bug.

The default branch is master and the last push to the repository was on 2026-10-16, a few days after the v5.10.0 tag. So the tip of master and the newest release are close together, but not identical, and the difference is unreleased model work.

The release/ directory in the repository root is where that versioning becomes concrete, and the scripts/ and cloudbuild.yaml files are how the released material is produced and checked. The cloudbuild.yaml file points to a Google Cloud build configuration, and the third_party/ directory records where vendored dependencies live, which is what you would look at if you needed to understand what a given release was built against. The regexp-tests/ directory suggests that some model validation is written as regular expression tests rather than as schema checks, which fits a project that checks things like naming and pattern constraints across many model files.

What the models cannot do for you

The limits of this repository are the limits of a schema, and they are significant. A YANG model describes the shape of configuration and the state that a network device may expose, along with the valid values and their types. It does not implement anything. It does not talk to a device, it does not validate a live system, and it does not generate configuration for a particular vendor. A model that says a path exists and what type it holds still leaves open whether a given platform implements it, and how it behaves under load.

The tooling compatibility badges make this visible in a specific way. Each of the six tools has its own idea of what it supports, and the badges reflect the models passing through them, not the models being correct in the field. If your generator is one of them, the badge tells you the models still compile. It does not tell you that the generated configuration will be accepted by a device, because that depends on the device.

There is also a governance limit worth naming. The models are shaped by operator requirements, and external contributions follow the process in doc/contributions-guide.md. A change that does not correspond to an operational need from multiple operators has a harder path in, which is a feature for a shared model set and a friction point for anyone who needs an extension quickly. If what you need is a single vendor's private tree, the vendor-neutral premise works against you.

Apache-2.0 and the operator membership question

The repository is licensed under Apache-2.0, and that choice does real work for a model set. A permissive licence with an explicit patent grant is what lets a vendor implement the same models as an operator, which is the mechanism behind the vendor-neutral goal. The cost of the permissive choice is that there is no way to prevent divergence, so a vendor that needs an extension will still build a private model, and interoperability will hold only as far as operators choose to keep using the common set.

The other thing the licence does not do is settle the governance. Membership in OpenConfig, as the README points out, is described on the web site and in the FAQ for operators, and the repository itself is described as being for material developed by the operators group. In other words, the artefact is openly licensed and openly published, while the process that produces it is a membership process. That asymmetry is normal for a consortium and it is the thing to understand before you invest in changing the models.

For a team evaluating this, the realistic sequence is short. Read the released models for the technology you care about, check that the tooling you already use, or the tools the badges name, supports them, and then decide whether to raise a change through doc/contributions-guide.md. If your tooling is missing something, the honest first step is an issue or a post to the public mailing list, not a fork.

Editorial conclusion

Use openconfig/public if you build network management tooling and want a model set that multiple operators agree on, and read doc/contributions-guide.md before proposing a change, since external submissions have their own process. Do not look here for a runtime, a validator, or a generator: this repository publishes models and documents, and the tools that consume them live in separate projects such as the ones the compatibility badges name. Before you pin a version, check the release/ directory against the tag you intend to use, since the recent tags are v5.8.0, v5.9.0 and v5.10.0 and the repository received its last push on 2026-10-16.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openconfig/public on GitHub
4. README
5. Releases