
The YANG 1.1 Data Modeling Language - based2
http://www.rfc-editor.org/rfc/rfc7950.txt
======
gioele
The hyperlinked RFC from IETF.org:
[https://tools.ietf.org/html/rfc7950](https://tools.ietf.org/html/rfc7950)

------
pella
[https://en.wikipedia.org/wiki/YANG](https://en.wikipedia.org/wiki/YANG)

------
ZenoArrow
On first glance this seems to be JSON with stronger typing. Is that a fair
assessment?

~~~
geezerjay
I haven't read it thoroughly but it appears that YANG is way more than that.
It also supports schemas, declares data in a modular way, impose data
constraints, and of course strong typing.

It is, however, absurdly complex compared with JSON.

~~~
sametmax
So a less supported/powerful/tested XML.

~~~
camoberg
It's a schema language, not a general data encoding language. Widely used for
NETCONF[1] and RESTCONF[2].

1\. [https://tools.ietf.org/html/rfc6241](https://tools.ietf.org/html/rfc6241)
2\. [https://tools.ietf.org/html/draft-ietf-netconf-
restconf-18](https://tools.ietf.org/html/draft-ietf-netconf-restconf-18))

~~~
keithb-
To be fair, I think that previous comment was implying the constellation of
XML technologies e.g. XSD, XPath. XML encoding is rarely used in isolation
because, honestly, what's the point? Sure, your document is well-formed, but
you could achieve the same thing with tab+carriage return.

So if I can continue to clarify the previous comment: given that YANG is an
data modeling language, what benefit does it offer when compared with XSD
which as been used/tested for many projects?

~~~
camoberg
YANG has a distinctly different purpose. XSD, RelaxNG, and some other
alternatives were considered during the development of what eventually became
YANG back in 2007. We spent quite a bit of time with XML grey beards on this
topic in the IETF, and eventually realized that YANG had too many domain
specific requirements that it wasn't worth trying to bend existing languages
for it.

In my mind, there were two major things that influenced the final decision.
First; we wanted it to be easily readable by humans first and foremost, as
schemas are written once but read many times. Second; it needed to be able to
separate between configuration and state data, and describe Remote Procedure
Calls (RPCs) and notifications.

~~~
keithb-
Thank you for clarifying.

wrt your final decision: obviously, those aren't very compelling reasons. It
would be simpler for you to say "We don't care about previous solutions. We're
following the standardization track so that people can understand our design
and provide comments/suggestions, but we're not going to justify our
decision."

For example, the "easily readable" constraint is simply ridiculous because the
most common format for data on the web is HTML which survives partly because
it can be rendered in a format that is easy to read.

~~~
camoberg
Well, I would say that we did spend considerable time and energy among peoole
with vast experience from designing various kinds of languages before we ended
up going down the path towards what became YANG. If you poke around the IETF
mailing list archives I think you will find ample amounts of justification
before we were given the green light from the IAB.

I meant to say "easily readable in it's native encoding". I.e. Looking at the
source in your favourite text editor.

~~~
ZenoArrow
Thanks for the clarification. Out of interest, did you evaluate building a
Lisp DSL? If so, any pros and cons you identified from that approach? I
would've thought it would have been a quicker option to get going, though if
you've reached version 1 you've put in the groundwork required now.

~~~
camoberg
I know that parts of the original design team for YANG are old lisp-fans, but
I can't recall the option of developing a lisp-based DSL ever being evaluated.
I would personally suggest that the fit would not be very good, since YANG is
fundamentally a modeling language that "models the hierarchical organization
of data as a tree in which each node has a name, and either a value or a set
of child nodes."
([https://tools.ietf.org/html/rfc7950#section-4.1](https://tools.ietf.org/html/rfc7950#section-4.1)).

But I happen to personally think that a datalog- or lisp-based policy language
for YANG-modelled data sources would be a very interesting concept.

~~~
ZenoArrow
> "models the hierarchical organization of data as a tree in which each node
> has a name, and either a value or a set of child nodes"

That matches the structure of Lisp. Lisp code is basically set out as an AST.
A Lisp node basically either contains a function and a list, or a function and
simple value(s). The former can be thought of as a parent node, the latter can
be thought of as a child node.

~~~
camoberg
So what you're saying then is that YANG could be a data modeling language for
Lisp ;-)

------
algesten
Why would I want this rather than say WebServices/SOAP?

~~~
bewo001
Some historical background might be helpful: to configure network devices, the
IETF specified SNMP in the 1990s. Cisco only did a read-only implementation of
it, as their configuration concept did not align with SNMP very well (a change
of a single SNMP variable gets effective immediately, which is cumbersome in
cases where several variables need to be changed in unison). So network
operators resorted to 'expect' scripting of the routers' CLI, which was a
brittle and ugly solution. Netconf/YANG was done to replace that.

~~~
algesten
Great thanks! Got it.

