From a high level point of this YANG catalog goal is become a reference for all YANG modules available in the industry, for both YANG developers (to search on what exists already) and for operators (to discover the more mature YANG models to automate services). This YANG catalog should not only contain pointers to the YANG modules themselves, but also contains metadata related to those YANG modules: What is the module type (service model or not?) What is the maturity level? (for the IETF: is this a RFC, a working group document or an individual draft?), Is this module implemented? Who is the contact? Is there open-source code available? And we expect much more in the future. The industry starts to understand that the metadata related to those YANG modules become equally important as the YANG modules themselves. We based on work on openconfig catalog, as a starting point but we realized that we have slightly different goals.
The YANG catalog added value, compared to a normal github repository resides in the toolchain and the additional metadata:
- the ability to validate YANG modules (including IETF drafts) with multiple validators.
- the related metadata regarding implementation
- the ability to visualize the dependencies between YANG modules, including the bottleneck in case of standardization
- the search capabilities on any YANG type and metadata, avoiding this way module or module part redefinitions, which are costly to integrate.
- the REST APIs to query and post any content
- the demonstration of connection to data model-driven management with opensource tools:
YANG explorer (a GUI-based tool to explore modules, generate some code, and connect the devices)
YANG Development Kit (a more advanced tool for code generation)
Using this one-stop set of tools, the typical flow for a YANG module designer is to validate the YANG module and to populate the YANG catalog (via an IETF drafts, via github, or directly via the YANG catalog).
And the typical flow for a YANG module user is to search for an existing YANG module, to look up the metadata (such as maturity level, implementation, etc.), and to look up the import and include dependencies if any. Once the YANG module of choice is found, the YANG module user would browse the YANG module content, then load the YANG module in the YANG explorer and test it by connecting to a NETCONF or RESTCONF server, and finally generate python scripts to start the automation.