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.