YangModels/yang: a repository for organizing shared YANG modules

A shared catalogue for YANG model sources

YangModels/yang solves a repository problem rather than a runtime problem. It collects YANG modules associated with IETF standards-track work, IEEE experimental work, ETSI, the Metro Ethernet Forum, the Broadband Forum, OpenDaylight, and specific vendors. That makes it a reference point for engineers who need model files without assembling separate sources for each standards body or implementation. The repository also gives contributors a defined place to add or update models, including a review process and CI conventions.

The intended audience includes network engineers, tooling developers, and organizations that maintain YANG-based models. A module consumer may use the repository to locate an IETF RFC module, an experimental draft, an OpenDaylight model, or a vendor file. A contributor may use it to expose a maintained set of modules through a fork and a pull request. The repository does not present itself as a YANG compiler, network controller, or application server. Its value depends on the quality and provenance of the individual files and on the validation performed by the consuming tool.

Directory structure distinguishes source and maturity

The directory layout is the repository's main organizational mechanism. Experimental modules live under `experimental/`, while `standard/` contains standards-track modules. Within the experimental tree, `experimental/ietf` is intended for IETF submissions and `experimental/odp` for OpenDaylight submissions. Standard content is separated into `standard/ieee`, `standard/ietf`, `standard/odp`, and the Broadband Forum areas `standard/bbf/draft` and `standard/bbf/standard`. The `standard/ietf` tree further separates work in progress under `DRAFT` from completed modules under `RFC`.

Vendor content has its own top-level area, with directories for Cisco, Netconf Central, and YumaWorks. This arrangement is more informative than putting every `.yang` file into one flat directory. It allows a caller to narrow a search by provenance or publication state, although the README does not provide a command that selects a module by metadata. The labels describe intended sources and status, not a guarantee that every file has passed the stricter checks required by every implementation.

Contribution flow uses forks, submodules, and review

Direct contributions are described as the preferred route. A contributor chooses the appropriate organization directory, manages files mainly in a fork, and submits a pull request. The README requires review by at least one repository committer before the request can be committed. It also states that pull requests are generally expected to include a `check.sh` script and a reference to that script from `.github/workflows/complete_check.yml`.

The documented submodule route is intended for standards bodies and vendors that maintain models in their own source repositories. The repository's `.gitmodules` file is present, and the README points to examples under `standard/`, including BBF and MEF submodules. The documented process requires enabling GitHub Actions in the contributor's fork, adding the source repository as a submodule, adding a CI entry, running the repository checks, and submitting a pull request only after those checks work.

This process creates a clear maintenance boundary. The YangModels repository can reference an external source rather than duplicating every upstream update. It also introduces an operational dependency: the submodule source, its accessibility, and its own change process determine when the referenced models change.

The documented CI check is compilation, not full semantics

The README says that existing check scripts use `pyang`, with the `tree` plugin named as an example. The minimum stated requirement is that contributed models compile correctly and that the schema tree can be produced for interrogation and tasks such as code generation. GitHub Actions jobs are expected to run cleanly before a pull request is accepted, and contributors are also told to test with `testall.sh` from the top-level directory.

That boundary matters for adoption. The README explicitly states that `pyang` does not validate content such as regular expressions or XPath constraints. It warns that modules accepted by the repository may still be rejected by tools performing more complete semantic validation, and names the OpenDaylight controller as an example of such a tool. A successful repository check therefore should not be treated as proof that a model is accepted by every controller, service, or implementation. Consumers that depend on constraint semantics need a separate validation path, even though the repository does not document one here.

A contributor tutorial using the documented submodule steps

The README does not describe installation or a command that turns this repository into a running service. It is a collection of source files and contribution infrastructure. A first practical use for a contributor is to fork the repository, add or update a model in the appropriate directory, and wire a contributor-provided check script into CI. The README gives the following command for adding an external source as a submodule. Replace the placeholders according to the source repository and directory name, then follow the remaining documented steps.

git submodule add https://github.com/<owner>/<repository>.git <name>

The command should be run from the relevant vendor or standards directory after cloning the fork. The contributor then adds the corresponding check invocation to `complete_check.yml`, commits the changes, enables GitHub Actions in the fork, and tests the CI run and `testall.sh`. The README does not provide exact `check.sh` contents, so no validation command beyond those documented references should be inferred.

./testall.sh

The expected result described by the README is a clean CI build and working module checking. After that, the contributor submits a pull request. Direct contributors use the same review concept without necessarily introducing a submodule, but they still need to select the correct hierarchy and satisfy the `check.sh` convention.

Maintenance and licensing require file-level review

The repository is not archived. Its last push was on 2026-10-06, so the repository has a recent recorded change, but it has no GitHub releases. That means there is no documented release channel in the repository metadata for selecting versioned module bundles. Users who need reproducible inputs should record the commit they use and track changes in the repository history. The README does not define a release policy or compatibility promise.

License information is similarly uneven. The directory descriptions contain bracketed license numbers, including `[1]` for IETF areas, `[2]` for OpenDaylight areas, `[3]` for IEEE content, `[4]` for listed vendor content, and `[6]` for Broadband Forum content. Other areas are marked `[any]`. The README excerpt does not define those numbers in the visible text, and the repository metadata says the license is unknown. Accordingly, a user cannot infer one blanket license for every module from the documentation. License review belongs at the file or source level, especially for standards-body and vendor content, and should be checked before redistribution or incorporation into another distribution.

When YangModels/yang is the wrong tool

YangModels/yang is the wrong choice when the requirement is a packaged validator, a running network management service, or a guaranteed compatibility decision for a particular implementation. The repository provides files and contribution checks, not an executable management platform. It also does not claim that all included modules pass complete semantic validation. If a target system rejects a model because of XPath or regular-expression constraints, the documented repository checks may not identify that problem.

The same limitation affects vendor selection. A vendor directory indicates where files are grouped, but the visible documentation does not establish version compatibility, implementation support, or a support commitment. Consumers who need a single authoritative module for production should compare the file revision with the requirements of the controller or tool that will load it. The repository remains useful as a starting point for that comparison, but it does not replace implementation-specific acceptance testing.

YangModels/yang versus organization-specific sources

A real alternative is to obtain modules directly from the standards organization, OpenDaylight, or vendor that owns them. The difference is ownership and update flow. YangModels/yang centralizes many sources and provides a common directory hierarchy, contribution guidance, review expectations, and CI conventions. A direct source may provide a more focused release history or a clearer relationship between the modules and the organization that maintains them.

For a standards team or vendor, the submodule model in YangModels/yang can preserve that upstream relationship while exposing the models through the shared repository. For a user who needs only one organization's modules, adding an extra repository layer may be unnecessary. For a user who searches across several ecosystems, the shared hierarchy can reduce the number of repositories to inspect. The trade-off is that repository inclusion does not remove the need to check the originating source, license notes, and target implementation's validation requirements.

Editorial conclusion

Engineers needing a shared, source-organized collection of YANG modules can use YangModels/yang, especially when they need to inspect standard, experimental, or vendor models. It is less suitable as a standalone deployment tool or as the only validation gate for production use. Verify the module provenance, directory, license note, and behavior under the stricter semantic validation used by the target controller before adopting it. The repository has no GitHub releases, so consumers should treat the repository contents and commit history as the distribution source rather than expecting a release package.

Frequently asked questions

Official sources

1. Issues
2. README
3. YangModels/yang on GitHub