Randy Bush writes: [in response to John Payne <john@sackheads.org>:]
I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it.
does this not imply that all devices would need to be semantically congruent? if so, is this realistic?
Personally I don't think it is. The way that configuration is structured is something that at least some vendors use to differentiate themselves from each other. (Though other vendors make a point of being compatible with some "industry standard CLI".) So if you think that configurations in NETCONF should be similar to the "native" configuration language, that doesn't bode well for industry-wide standardization of a NETCONF configuration data model. It might still be possible to have a common NETCONF data model, but then that would probably be quite different from the (all) "native" configuration languages; much in the same way as SNMP MIBs are (structurally) different from how information is presented at the CLI. Personally I'm not sure that this would be a very useful outcome, because there would necessarily be a large lag between when features are implemented (with a "native" CLI to configure them of course) and when they can be configured through NETCONF. Maybe the best we can shoot for is this: * A common language to describe parts of NETCONF configuration. The newly chartered IETF NETMOD working group[1] is working on this. Vendors can then describe their specific NETCONF data models using this language, and tool writers can use these descriptions to generate code for applications that want to manipulate device configurations. * Common data models for certain well-understood parts of NETCONF configuration. This could include simple "atomic" things such as how to write an IP address or a prefix in (NETCONF) XML, or configuration of standardized protocols such as OSPF, IPFIX etc. The problem is how well will this support migration from vendor-specific configuration to standardized configuration - which, as I said, is always bound to lag far behind. And even if/when an aspect of a configuration model (let's say for OSPF) is standardized, vendors are bound to extend that model to support not-yet-standardized extensions (e.g. sub-second timers, BFD). This will be another challenge to support. (But there are smart people working on this :-) -- Simon. [1] http://www.ietf.org/html.charters/netmod-charter.html