The vendor config->abstract data (really structured data) is the point of YANG definitions. I think I'm correct but Tail-F's system works by importing the YANG definitions from the router and it builds the CLI interpreter based on those definitions. The trick is getting the standards bodies and vendors to support common definitions for common protocols like they sorta have with SNMP. So when I need to put a route on a router it's the same common definition and I guess the pie in the sky goal is then using common NETCONF syntax as well to do the configuration. So the router itself is doing the translation into whatever native format it uses, not someone having to write translation scripts which are a PITA when vendor syntax changes, or some new feature is added, etc. Phil On 10/25/13 11:03 AM, "Saku Ytti" <saku@ytti.fi> wrote:
On (2013-10-25 10:22 -0400), Phil Bedard wrote:
There are companies like Tail-F who are trying to use things like YANG
Tail-F is very cool, but it needs support for both direction.
Abstract data -> Vendor Config (easy problem, just agnostic ascii template) Vendor Config -> Abstract data (hard problem)
I don't think the latter is needed, why verify what is wrong in the config, either it is what you want it to be or it's something else, in which case you make it what you want it to be. The price of knowing exactly what to fix to bring it up-to standard is very high. It's definitely nice thing to have and necessary thing to have unless 100% is from system. If 100% is from system, we can ommit the hard problem. To support new vendor, you just write simple new vendor-specific templates focusing on exactly just the subset of stuff your abstract data needs. Instead if you need to understand vendor config, you need to understand every nyance of it, vendors own parser gets it wrong, my chances are very small to get it right.
-- ++ytti