In the world of data model-driven management, automation success depends on how well the YANG data models are written. The API used by automation is generated from YANG data models. Bad YANG data models will lead to bad automation.
YANG, considered an API contract language, is an IETF standardized data modeling language that can be used to write a specification for what the interface between a client and a server should be. It can be used to model configuration data, operational state data, administrative actions, Remote Procedure Calls, and notifications. It is most often used in conjunction with the NETCONF and RESTCONF network management protocols in order to enable network programmability for network elements, both physical and virtual.
As with any language, be it a data modeling language, a programming language, or another type of language, there are usually many ways of “saying” the same “thing”. In YANG, there are different ways of representing the same data and many ways of defining types and relationships between the data.
A YANG data model developer can easily get lost in this expansive language and pick inappropriate choices to use from the RFC, which results in a bad interface specification for the application being developed. Knowledge of YANG Best Practices should be a requirement before modeling data and a strict review process should be employed to ensure that these best practices are followed for each YANG module being developed.
YANG data models can be optimized further, beyond what the RFC describes. These optimizations are necessary to fulfill the requirement of interoperability with other data consumers such as third-party NETCONF or RESTCONF clients or orchestration systems. As an example, some of the standard language statements can be precise enough to remove any ambiguity on the data and weed out any potential errors and, therefore, they should be used. However, some other statements can be used in the wrong way or used “vaguely”, which leaves a hole in the data specification. This makes it not descriptive enough of the capabilities of a network element. A simple example of this is the overuse of the string type. A YANG data model developer should keep in mind that the final YANG data model will represent a contract and, therefore, the properties of contracts should be applied. The data model should be accurate, clear (from a reader perspective), and efficient (for example, long repeating data trees can be grouped).
Other constructs of the YANG language deal with data constraints and relationships, which if done wrong, can lead to a whole new set of problems for YANG data model consumers. This also leads to more frequent backward compatibility issues affecting every consumer of the data model.
YANG best practices should always be considered when modeling data; whether these models become a standard or not.
To start on your journey of using YANG best practices, I suggest that you watch the recording of our recent webinar “YANG Best Practices”. Further knowledge of YANG best practices can be gained by understanding the purpose of each construct in YANG by reading RFC 7950 “The YANG 1.1 Data Modeling Language” and then reading RFC 8407 “Guidelines for Authors and Reviewers of Documents Containing YANG Data Models”. Also, look at IETF standard YANG data models as a good example of how to model data.