[mmmBacon]

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.

[camoberg]

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.