> On 28 Dec 2015, at 15:24, Juergen Schoenwaelder > <[email protected]> wrote: > > On Wed, Dec 23, 2015 at 10:05:46PM +0000, Robert Wilton wrote: >> >> Personally, ignoring all the backwards compatibility issues, I would >> prefer that interfaces and interfaces-state were a combined single list >> (as proposed by OpenConfig). E.g. something along the lines of: >> - the system can still provide an operational list of discovered >> interfaces so that clients can know what is there. >> - but management agents would be expected to explicitly configure >> (i.e. create an entry for) all interfaces for which it wanted to >> retrieve data for. >> > > A clear separation of config from operational state is one of the > outcomes of the IAB workshop documented in RFC 3535 and it is one of > the key foundations of both NETCONF and YANG. Config and operational > state have different and _independent_ lifetimes - you can have config > for resources that are not present and you can have operational state > for resources that are present but not configured. In addition, the > data models for operational state are often not the same as the data > models for configuration. Merging all things back into a single list > with a single keying (naming) structure gets us back into the mess we > were in with SNMP.
I agree. A good example is in ietf-routing: static routes are part of configuration but in state data they only appear in RIBs together with protocol originated-routes - there is no representation of static routes per se in state data. Data models for configuration and state data can indeed be rather different. I would also add that IMO state data can in general be expected less standardised than configuration because they often need to be closer to the underlying device implementation. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
