Why YANG?

YANG is easy and targets the right audience

YANG is simple and easy to learn. The syntax is trivial and regular. The hierarchy is clean, the role of elements is obvious, and the use of braces for containment is consistent. YANG stresses readability, but still gives sufficient flexibility, extensibility, and power to allow it to be useful for large schemas.

YANG sees readability as first priority, since review and understanding of the data model is a key for developing quality specifications. (If you can't read it, you can't find bugs in it.) The population of readers will vastly exceed the number of model writers, and the reviewers time is a scarce resource which we cannot abuse. (If they don't read it, they won't find bugs in it.) After the readers, YANG prioritizes for writers of models and for tool builders.

The audience YANG is targeting (IETF) knows very little about either XSD or DSDL and is unlikely to learn them. All experience from NETCONF demonstrates this.

YANG is written for NETCONF and network management

YANG is NETCONF-specific; it does not try to compete with XSD and of course not with something as big and ambitious as DSDL; YANG actually does not assume that you know any of these technologies since it is self-contained.

YANG is a domain specific language designed to do what it needs to do well; it is not constrained by any framework it is derived from (making augmentations for example really easy, natural and powerful).

YANG sees the data model as a contract between the device and the application. The model works like an API, and a device which violates it should be regarded as broken. Imagine trying to make portable C code if the return value from fork() was vendor dependent. The cost of interoperability would be immense. YANG gives the application the ability to trust the device will behave in accordance with the contract as written in the data model.

Modular, flexible, and not!

YANG is fully modular (to the level of self-compiling sub-modules). Like SMIv2, YANG enables development of certain parts of the model without influencing those parts that need no change.

YANG puts flexibility where it is needed and in places where extensions won't impact the basic contract of the data model. If different implementations of a standard data model are allowed to use different default values, the cost is that my application needs to discover those defaults, or that my application can't count on defaults at all and must explicitly instantiate default values according to its understanding of the defaults. Neither is acceptable.

YANG provides enough features to support network management configuration, but ultimate modeling complexity/capability is sacrificed for ultimate ease-of-use, extensibility, and modularity.

YANG has its heritage in the IETF network management community

YANG has a long heritage and is not "a completely new thing" (which seems to be a commonly used phrase in this context) if you look at how it came along, YANG is based on years of experience with proprietary NETCONF data modeling languages and shares some history as well with the SMIng project and the SMIv2.

YANG continues the IETF tradition of being backed by "running code"

YANG is supported by running code. Have a look at YangTools. Furthermore, YANG has the backing of multiple NETCONF implementors.

YANG developed openly

YANG has an open active mailing list with discussions on technical details where all participants are welcome.

YANG gaining acceptance

YANG is being used outside the YANG team in other WGs in the IETF.