Hacker News Reader

Comment by camoberg | Hacker News Reader

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 2. https://tools.ietf.org/html/draft-ietf-netconf-restconf-18)

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?

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.

So like SOAP and XMPP ?

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.

I would add the Point that XML is _the_ readable format. Just only because the seperations and nearly there is no trick-shit-thing(e.g. as in Rust, Go, C, JS, ...(that's nothing what i want to blame some language for, but seriously, nearly any language has some Tricks with it's Syntax))

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.

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.

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).

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.

> "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.

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

I think the biggest problem with YANG is all of the serialization overhead, particularly for large YANG models. For a large SDN network with a centralized controller, I am not convinced that a NETCONF-YANG implementation is really performant. It seems particularly problematic as SDN moves from specifically a Layer2/3 into the optical layer.

In my view Thrift is probably a better approach. Thrift files are still human readable and strongly typed. Since they are native C structs, there is no need for serialization. Those structs automatically show up as objects in something like Python. With Yang there's all this middle code that people use that is not doing anything but mapping the Yang data model to objects. Seems to be that this adds a lot of unnecessary bloat and the potential for lots of buggy behavior.

But YANG does not do serialization, that's up to the protocol that acts on the YANG-modelled data sets. Depending on your needs, I do agree that there are good reasons to look at protocols with less overhead (some interesting work is being done with e.g. CoAP/CoMI https://tools.ietf.org/html/draft-vanderstok-core-comi-05) and in most real-life environments I have come across, the latency in making configuration changes to networks are not in the overhead of the protocol, but in the application behaviour. I.e. it takes many seconds for most routers to update their configuration compared to the milliseconds of overhead incurred by protocol serialization. YMMV.

I personally and currently believe we need more context-specific language features for network management than what is available out of the box in Thrift. E.g. I think having the concepts of "configuration", "state data", "rpcs" as first class entities in the language itself is of great value. On the other hand, I can see the value of tool reuse in shops that have invested heavily in Thrift (or grpc/protocol buffers).

I also don't think we need the type of middle-code that you mention, and that's just the side effect of immature implementations. Always avoid intermediary steps if at all possible.

Reply on news.ycombinator.com